Recherche avancée

Sur d’autres sites (8442)

• mpegvideo : Expand macro

  10 juin 2015, par Vittorio Giovara

  mpegvideo : Expand macro
  Having this macro in an header only facilitates the use of such header.
  
  The code increase is minimal and files have one less dependency
  
  on mpegvideo.h.
  

  • [DBH] libavcodec/flvenc.c
  • [DBH] libavcodec/h261enc.c
  • [DBH] libavcodec/mpegvideo.h
  • [DBH] libavcodec/mpegvideo_enc.c
  • [DBH] libavcodec/rv10enc.c
  • [DBH] libavcodec/rv20enc.c

• avformat/mpegts : parse sections with multiple tables

  9 mai 2018, par Aman Gupta

  avformat/mpegts : parse sections with multiple tables
  Fixes PMT parsing in some mpegts streams which contain
  
  multiple tables within the PMT pid. Previously, the parser
  
  assumed only one table was present in each packet, and discarded
  
  the rest of the section data after attempting to parse the first
  
  table.
  A similar issue was documented in the BeyondTV software[1], which
  
  helped me diagnose the same bug in the ffmpeg mpegts demuxer. I also
  
  tried DVBInspector, libdvbpsi's dvbinfo, and tstools' tsinfo to
  
  help debug. The former two properly read PMTs with multiple tables,
  
  whereas the last has the same bug as ffmpeg.
  I've created a minimal sample[2] which contains the combined PMT.
  
  Here's what ffmpeg probe shows before and after this patch :
  Before :
      Input #0, mpegts, from 'combined-pmt-tids.ts' :
  
        Duration : 00:00:01.08, start : 4932.966167, bitrate : 741 kb/s
  
        Program 1
  
        No Program
  
          Stream #0:0[0xf9d] : Audio : ac3, 48000 Hz, mono, fltp, 96 kb/s
  
          Stream #0:1[0xf9b] : Audio : mp3, 0 channels, fltp
  
          Stream #0:2[0xf9c] : Unknown : none
  After :
      Input #0, mpegts, from 'combined-pmt-tids.ts' :
  
        Duration : 00:00:01.11, start : 4932.966167, bitrate : 718 kb/s
  
        Program 1
  
          Stream #0:0[0xf9b] : Video : mpeg2video ([2][0][0][0] / 0x0002), none(tv, top first), 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
  
          Stream #0:1[0xf9c](eng) : Audio : ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
  
          Stream #0:2[0xf9d](spa) : Audio : ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 96 kb/s
  With the patch, the PMT is parsed correctly so the streams are
  
  created in the correct order, are associated with "Program 1",
  
  and their codecs are set correctly.
  [1] http://forums.snapstream.com/vb/showpost.php?p=343816&postcount=201
  
  [2] https://s3.amazonaws.com/tmm1/combined-pmt-tids.ts
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/mpegts.c

• ffmpeg avformat_open_input() function causes memory leak when receiving live stream

  12 septembre 2023, par george_d

  I have live streams (can be UDP or HLS, video codec is H264), from which I grab frames for further processing.

  


  For this purpose, I use ffmpeg + nvjpeg + cuda libraries.

  


  However I noticed memory leak - memory usage periodically (every 10-20 seconds) is increased by 100-400 KB, the amount and period may vary.

  


  After disabling pieces of code one by one, I realized that it is avformat_open_input() which causes memory leak.

  


  No matter which buffer settings (https://ffmpeg.org/ffmpeg-protocols.html#udp) I choose for UDP, the leak still persists. Same goes for HLS streams.

  


  I tried to find anything related to this problem, but all the sources I found claimed that this problem took place in the past and has been fixed.

  


  Is there some mysterious setting I am missing, so that memory could be freed properly ?

  


  Or is this memory supposed to be freed when processing frames (i.e. using av_read_frame() and av_packet_unref(), etc) ?

  


  Minimal example of code to reproduce the problem :

  


  avformat_example.cpp

  


  #include &#xA;extern "C" {&#xA;    #include <libavformat></libavformat>avformat.h>&#xA;    #include <libavcodec></libavcodec>avcodec.h>&#xA;}&#xA;&#xA;int main(int argc, char *argv[]){&#xA;    if (argc &lt; 2) {&#xA;      return 1;&#xA;    }&#xA;&#xA;    char* inputSource = argv[1];&#xA;    AVFormatContext *ctx = NULL;&#xA;&#xA;    if (avformat_open_input(&amp;ctx, inputSource, NULL, NULL) != 0) {&#xA;        av_log(NULL,&#xA;               AV_LOG_ERROR,&#xA;               "Cannot open &#x27;%s&#x27;",&#xA;               inputSource);&#xA;        return 1;&#xA;    }&#xA;&#xA;    /*&#xA;    This loop is placed here to demonstrate&#xA;    avformat_open_input() causing leak.&#xA;    Actually, instead of noop loop there is logic of getting and processing frames,&#xA;    but it doesn&#x27;t matter now.&#xA;    As loop goes on, the amount of leaked memory increases.&#xA;    */&#xA;    while(true) {&#xA;      sleep(1);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;

  


  Compile with :

  


  g++ avformat_example.cpp -lavcodec -lavutil -lavformat -I/usr/include/ffmpeg-cuda -o avformat_open_input_example


  


  Run :

  


  ./avformat_open_input_example "udp://127.0.0.1:5000?reuse=1&pkt_size=1316&buffer_size=1310720&fifo_size=40000"


  


  Version of ffmpeg underlying libraries :

  


  libavutil      58.  7.100 / 58.  7.100
libavcodec     60. 11.100 / 60. 11.100
libavformat    60.  5.100 / 60.  5.100
libavdevice    60.  2.100 / 60.  2.100
libavfilter     9.  8.100 /  9.  8.100
libswscale      7.  2.100 /  7.  2.100
libswresample   4. 11.100 /  4. 11.100