<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"
text="#000000">
On 10/17/2013 03:52 PM, Carl Eugen Hoyos wrote:<br>
<br>
<blockquote cite="mid:loom.20131017T145130-419@post.gmane.org"
type="cite">
<pre wrap="">Thank you for this analysis!
Is this documented anywhere else (afayk)?
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:loom.20131017T145130-419@post.gmane.org"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Do you know of a public stream that I could use to test if
I wanted to fix this?
</pre>
</blockquote>
<br>
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:<br>
<br>
ffplay -x 320 -y 240 -rtsp_flags listen <a class="moz-txt-link-freetext" href="rtsp://localhost:8888">rtsp://localhost:8888</a><br>
<br>
and server second:<br>
<br>
ffmpeg -i huge2560x1920file.h264 -f rtsp
<a class="moz-txt-link-freetext" href="rtsp://localhost:8888/live.sdp">rtsp://localhost:8888/live.sdp</a><br>
<br>
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).<br>
<br>
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.<br>
</body>
</html>