[Libav-user] Problema with RTP stream (h264)
bowljoman at gmail.com
Thu Oct 17 18:28:46 CEST 2013
On 10/17/2013 6:54 AM, Camera Man wrote:
> [thunderbird is insisting on html output; trying again as forced
> 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
> 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
More information about the Libav-user