[FFmpeg-trac] #285(FFmpeg:new): RTSP h264 video stream always reports corrupted macroblock

[FFmpeg]

#285: RTSP h264 video stream always reports corrupted macroblock
------------------------+----------------------
Reporter:  bovine       |       Owner:  michael
    Type:  defect       |      Status:  new
Priority:  normal       |   Component:  FFmpeg
 Version:  unspecified  |  Resolution:
Keywords:               |  Blocked By:
Blocking:               |  Reproduced:  0
Analyzed:  0            |
------------------------+----------------------

Comment (by Ph0t0n):

 Hey I'm pretty sure I figured out why these RTP streams are getting
 corrupted when in UDP mode (which is the way RTP was intended to
 function!). If you set the loglevel to debug, and then set the queue size
 (max_delay), and do a very simple loop like:

 while (1) {
     av_read_frame(ctx, pkt);
 }

 then you'll see errors like:

 [mpeg4 @ 0037b6a0] RTP: missed 3 packets
 [pcm_mulaw @ 0037d980] RTP: missed 5 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [mpeg4 @ 0037b6a0] RTP: missed 2 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [mpeg4 @ 0037b6a0] RTP: missed 3 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [pcm_mulaw @ 0037d980] RTP: missed 3 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [mpeg4 @ 0037b6a0] RTP: missed 1 packets
 [mpeg4 @ 0037b6a0] RTP: missed 4 packets

 You can also get the above errors plus the mpeg4 decoding errors that you
 guys are seeing by using ffplay. The mpeg4 errors will be red, and the rtp
 missed packets will be yellow. Here's an example using a camera in Boston:

 ffplay -max_delay 50000 -sync video -loglevel debug
 rtsp://128.197.178.104/mpeg4/media.amp

 Much older version of ffmpeg didn't have this problem, however they
 instead had a different problem where they would timeout after a couple of
 minutes because they weren't responding to a ping or something.

 Ok so now for the "solution"...

 The problem is in libavformat/udp.c . Someone added code that uses a
 pthread and a circular buffer when reading from a udp socket. There is a
 bug in that code - I don't know exactly where. The circular buffer/thread
 code is only executed if pthreads are enabled. So if pthreads are
 disabled, then the "backup" code runs. If you comment out the sections
 within HAVE_PTHREADS, magic happens... no more mpeg4 macroblock/missing
 packet errors!!!

 I don't know how important that circular buffer/thread code is. Most of us
 probably don't want to disable pthreads for everything just to fix this
 one problem.  Do we really need this circular buffer code since it seems
 to work fine without it? Or should we try and fix it? I'm a noob when it
 comes to the code in udp.c, so fixing it would be a lot easier for someone
 more familiar with it.

 --luke

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/285#comment:12>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker