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

[Camera Man]

[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 
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).

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.