#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
