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. |
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
