[FFmpeg-trac] #1475(avformat:new): Memory leak in ff_read_packet when decoding udp mpegts multicast stream

[FFmpeg]

#1475: Memory leak in ff_read_packet when decoding udp mpegts multicast stream
-----------------------------------+---------------------------------------
             Reporter:  thutschen  |                     Type:  defect
               Status:  new        |                 Priority:  normal
            Component:  avformat   |                  Version:  unspecified
             Keywords:             |               Blocked By:
             Blocking:             |  Reproduced by developer:  0
Analyzed by developer:  0          |
-----------------------------------+---------------------------------------
 Summary of the bug:

 I am receiving 4 udp multicast streams on different ports, which each
 contain 4 programs.
 I transcode one program out of each of those using one ffmpeg instance.
 Everything works fine until at some random point in time, the memory usage
 of ffmpeg starts to grow constantly.

 It seams as if at this point in time, the mpegts demuxer reports a bogus
 new stream and sets its request_probe property to 1.

 Now since this stream is bogus there won't be any subsequent packets for
 this stream.

 The problem is, that this packet will be put to the raw_packet_buffer in
 ff_read_packet.

 Now the loop in ff_read_packet has no chance of ever terminating because
 each new packet will be put on the packet buffer but the first packet will
 never be popped since probing will never be done because no new packet for
 the stream to be probed will arrive.

 Thus I suggest the following patch
 {{{
 #!c
 diff --git a/libavformat/utils.c b/libavformat/utils.c
 index 284cb9f..f998b0e 100644
 --- a/libavformat/utils.c
 +++ b/libavformat/utils.c
 @@ -720,10 +720,12 @@ int ff_read_packet(AVFormatContext *s, AVPacket
 *pkt)
          if (pktl) {
              *pkt = pktl->pkt;
              st = s->streams[pkt->stream_index];
 -            if(st->request_probe <= 0){
 +            if(st->request_probe <= 0 ||
 s->raw_packet_buffer_remaining_size <= 0){
                  s->raw_packet_buffer = pktl->next;
                  s->raw_packet_buffer_remaining_size += pkt->size;
                  av_free(pktl);
 +                if(s->raw_packet_buffer_remaining_size <= 0)
 +                    av_log(s, AV_LOG_WARNING, "probing stream %d failed",
 st->index);
                  return 0;
              }
          }
 }}}

 How to reproduce:
 The reproduction is a bit tricky since I only encountered this problem
 with multicast udp mpegts streams

 I have attached a complete log file.
 The memory growth starts after the entry in line 28650.

 When running ffmpeg in gdb and interrupting after the memory growth has
 started, extremely large negative values for s->raw_buffer_remaining_size
 can be observed.

 Since this is my first bug report here, I want to apologize for any formal
 mistakes.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1475>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker