[libav-api] Problems with RTSP Feed from Ethernet Webcam

Luca Barbato lu_zero at gentoo.org
Fri Jul 27 23:57:54 CEST 2012


On 07/27/2012 08:34 PM, James Walker wrote:
> Hello,
> 
> I'm a C.S. graduate student working on developing an optical
> tracking system as part of my research. I'm trying to
> figure out the best way to get a working, low-latency
> feed from an Ethernet camera. Unfortunately, when
> connecting to the camera with UDP, the image is badly
> corrupted. It gives errors such as the following:
> 
> Input #0, rtsp, from 'rtsp://
> username:password at 192.168.0.90/axis-media/media.amp':
>   Metadata:
>     title           : Media Presentation
>   Duration: N/A, start: 0.099878, bitrate: N/A
>     Stream #0.0: Video: h264 (Baseline), yuvj420p, 640x480 [PAR 1:1 DAR
> 4:3], 90k tbr, 90k tbn, 180k tbc
> [avsink @ 0x7f9624001020] auto-inserting filter 'auto-inserted scaler 0'
> between the filter 'src' and the filter 'out'
> [scale @ 0x7f9624001700] w:640 h:480 fmt:yuvj420p -> w:640 h:480
> fmt:yuv420p flags:0x4
> [h264 @ 0x7f962c0073a0] corrupted macroblock 15 27 (total_coeff=-1)/0
> [h264 @ 0x7f962c0073a0] error while decoding MB 15 27
> [h264 @ 0x7f962c0073a0] concealing 154 DC, 154 AC, 154 MV errors
> [h264 @ 0x7f962c0b7760] negative number of zero coeffs at 29 12
> [h264 @ 0x7f962c0b7760] error while decoding MB 29 12
> [h264 @ 0x7f962c0b7760] concealing 740 DC, 740 AC, 740 MV errors
>    5.05 A-V:  0.000 s:0.0 aq=    0KB vq=    0KB sq=    0B f=0/0
> 
> Lots of Google searching has revealed that this is a fairly
> widespread problem common to both ffmpeg and avlib. We've
> tried multiple versions of both libraries, but the problem persists.
> It appears to be some kind of bug in the UDP protocol.
> If I specify the connection to use TCP instead; e.g.,
> 
> avplay 'rtsp://username:password@192.168.0.90/axis-media/media.amp?tcp'
> 
> then it works, but the latency is very high (~1 sec) which
> is not good enough for an optical tracking system.
> 
> Either fixing UDP or significantly improving the latency
> of the TCP connection would be an acceptable solution
> to the issue. Our research group probably has the
> knowledge needed to modify the code ourselves, but
> this would be significantly easier if we had some
> guidance beforehand, rather than just diving right in.
> Would anyone be able to advise me in this issue?
> 
> Thank you for your time.
> 

add -threads 1 to avplay and -analyzeduration 0 and either force the udp
buffer to be incredibly large or use tcp.

I hope it helps =)

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero



More information about the libav-api mailing list