[Libav-user] Problema with RTP stream (h264)
i.like.privacy.too at gmail.com
Thu Oct 17 15:53:18 CEST 2013
[resending, because Thunderbird insisted on sending this in HTML for
some reason; hopefully now it will be 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
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).
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
More information about the Libav-user