#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 by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-----------------------------------
Comment (by Ph0t0n):
michael is correct - something has definitely been fixed. i just tried git
version 2c44aed (from 2011-11-21) and i no longer get errors when using
the camera on my local network.
With the cameras on the public internet (like the one in the link from my
previous post), errors still occur and I'm guessing it's due to dropped
packets. on my 40mbit internet connection at home it gets an error once a
minute or so, and on my slow connection at work the error rate is hundreds
per minute. the errors that display due to dropped packets are nearly
identical to the errors that came from that bug that is now fixed. there's
not much that can be done about dropped UDP/RTP packets except perhaps
wait longer and buffer more, but even then, that's probably not going to
help much.
vlc handles dropped packets differently than ffplay. i think they do more
buffering (well you can set the buffer size), and they also drop the
entire frame instead of passing a corrupted packet to the decoder. so
instead of getting mpeg4 errors and visual artifacts, you get lower frame
rates.
in my opinion, live rtsp/rtp over the public internet is too unreliable to
be useful. with tcp visual quality is better, but then you get high
latency which make video conferencing and live ptz cameras useless. it's
fine on a local gigabit network, but for internet that's not blazing fast,
good luck!
to whomever fixed the udp/rtp bug: hell yeah, you rock!!!!
draku1a - if you're still having problems after making sure you have the
latest version of libav, use wireshark or something and check to make sure
your network is reliable. if you're using a fast local network that
doesn't drop packets then i have no idea what's going on!
--
Ticket URL: <http://ffmpeg.org/trac/ffmpeg/ticket/285#comment:19>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
