[Libav-user] Problema with RTP stream (h264)

[Andy Shaules]

On 10/17/2013 6:54 AM, Camera Man wrote:
> [thunderbird is insisting on html output; trying again as forced 
> plaintext]
>
>  On 10/17/2013 03:52 PM, Carl Eugen Hoyos wrote:
>
>> Thank you for this analysis!
>> Is this documented anywhere else (afayk)?
>
> Not that I know of. I have been replying on this list several times to 
> people describing this problem with solution (switch to tcp) and 
> analysis over the last two years, but I'm guilty of not actually 
> opening a ticket. At some point in time, it actually WAS possible to 
> append "?udp&buffer_size=1048576" to the RTSP url and have that be 
> passed down to the underlying layer, but with the (excellent and 
> welcome!) revision of moving these to AVOptions, the ability was lost.
>
>>> The udp layer does have a "buffer_size" parameter, but there's no way
>>> that I'm aware of to pass it to the udp layer through the rtsp layer.
>> Do you know of a public stream that I could use to test if
>> I wanted to fix this?
>
> Unfortunately not. I can reproduce this on my linux desktop with a 
> large pre-recorded h264 file (2560x1920) which has ~400k I-Frames, by 
> running client first:
>
>     ffplay -x 320 -y 240 -rtsp_flags listen rtsp://localhost:8888
>
> and server second:
>
>     ffmpeg -i huge2560x1920file.h264 -f rtsp 
> rtsp://localhost:8888/live.sdp
>
> And of course by connecting directly to the udp feed from the 
> 2560x1920 camera this was recorded from. (Unfortunately, this camera 
> is property of my employer and I am not allowed to share the movies 
> generated from it).
>

Ive never personally used these commands directly, but I use h264 over 
rtp often, and you should be using packetization-mode that allows 
fragmented nals. 1920x1080 typically splits the IDR into 4 or 5 packets.





> Note, I do not trust the localhost interface to perfectly reproduce 
> these issues (localhost does things differently), but qualitatively it 
> does: the kernel buffers are too small, and a complete I-frame cannot 
> be sent.
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user