Hello,<br><br>We are still trying to get the most stable VLC with low latency. Nowdays we try with VLC 1.0.5 waiting for 1.1.0.<br>However we fail to see wich *-caching parameter we need to use.<br><br>Our stream is multicast UDP+RTP packet described by an SDP file wich is downloaded via http and we are on WIN32 with VLC player (and next come the IE pluggin).<br>
<br>On IRC I was suggested --udp-caching or --rtp-caching but once it was clear that LIVE555 was involved we got the advice to go for --rtsp-caching<br><br>In order to find out wich *-caching to use... we tried all of them... and we decided to use very high value (10s) to see if we could get high latency. <br>
<br>"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 10000
--udp-caching 10000 --realrtsp-caching 10000 --rtp-caching 10000
MCAST.sdp
<div>"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 40
--udp-caching 40 --realrtsp-caching 40 --rtp-caching 40 MCAST.sdp</div>
"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 10000
--udp-caching 10000 --realrtsp-caching=10000 --rtp-caching=10000
MCAST.sdp
<div>"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 40
--udp-caching 40 --realrtsp-caching=40 --rtp-caching=40 MCAST.sdp</div>
<br>But whatever we try we always get a rather good latency were we expect (but we don't know why on on wich parameter we are suppose to be able to play).<br>We also tested with various syntax such as :rtsp-caching=10000 and :rtsp-caching 10000.<br>
<br>Does anybody has a clue on what we did wrong or wich *-caching we should try next. We would like to stop doing random guess.<br><br>Here is the content of our SDP file (MP4 part 2 video only)... if it help:<br>
<div>v=0</div>
<div>o=- 13006724340976744 13006724340976745 IN IP4 136.173.110.16</div>
<div>s=MCAST</div>
<div>c=IN IP4 <a target="_blank" href="http://239.1.110.16/128">239.1.110.16/128</a></div>
<div>t=0 0</div>
<div>a=range:npt=now-</div>
<div>m=video 1500 RTP/AVP 96</div>
<div>a=rtpmap:96 MP4V-ES/90000</div>
<div>a=fmtp:96 profile-level-id=3; config=000001B003000001B509000001000000012000C4F969658B0D460FA21608482887000001B2656D347620342E352E302E3200C7FF</div>
<div>a=control:trackID=3</div><br>Thanks<br><br>David Glaude<br><br>PS: Next step is to text started from msys with -vvv to have more debug.<br><br><div class="gmail_quote">2010/3/9 David Glaude <span dir="ltr"><<a href="mailto:david.glaude@gmail.com">david.glaude@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>I have some bad from my test of VLC 1.0.2...</div>
<div> </div>
<div>This morning both the stand-alone player and the IE Plugin where freezed (video freeze) after a bit more than 7H of assumed continuous playing (I was not there overnight to monitor it). There may have been some network event (packet lost or such) but at least they were not user generated in order to test VLC robustness. Unfortunately there was no other player (QT/GPAX) to see if they had the same trouble and were also freezed. "F5" did fix it for the plugin and STOP/START did fix it for the player (so the encoder was still running).</div>
<div> </div>
<div>Unfortunately the debug message do not have a time stamp, so I can only assume that the problem is related to this new (to me) message: "avcodec error: more than 5 seconds of late video -> dropping frame (computer too slow ?)".</div>
<div> </div>
<div>main warning: late picture skipped (2603 > 0)<br>main warning: late picture skipped (3603 > 0)<br>avcodec error: more than 5 seconds of late video -> dropping frame (computer too slow ?)<br>main warning: late picture skipped (40621 > 0)<br>
main warning: late picture skipped (5621 > 0)<br></div>
<div>Right now I do not know exactly what I am going to test next... and were I need to dig in the code between 1.0.2 and 1.0.3 for possible change that affect the behaviour.</div>
<div> </div>
<div>I have also seen in trac some low latency related parameter, but I don't know if they are still current.</div>
<div> </div>
<div>I know that refresh "F5" of the page every hour can help so I will try that path either with VLC 1.0.2 or with VLC 1.1.0-git.</div>
<div> </div>
<div>...</div>
<div> </div>
<div>Any other place within VLC code where 10, 20 or 30s of video can be stored?<br>What is the best way to document the problem so that it can be reproduced? (network trace? how to enable more debuging or timestamping of the debug message?)<br>
<br>David Glaude<br></div>
<div class="gmail_quote">Le 8 mars 2010 21:51, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> a écrit :<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="padding-left: 1ex; margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);">Le lundi 8 mars 2010 22:38:09 David Glaude, vous avez écrit :<br>
<div>> VLC-1.0.2-win32.exe (E) give us the best result for the low latency and for<br>> maintaining that low latency over time and despite packet loss.<br>> Some change occured between 1.0.2 and 1.0.5 that change the behaviour and<br>
> introduce additionnal latency.<br>> The problem is not fully solved with "--clock-jitter=0" in 1.1.0-git and<br>> there must be other buffer involved that were not triggered before.<br>> Presentation buffer? Decoding buffer? RTP Buffer?<br>
<br></div>The RTP reorder buffer code has been pretty much unchanged since... 1.0.2. The<br>RTP plugin only buffers when reordering occurs. De-jittering really is done<br>downstream in the input clock synchronization code.<br>
<br>There's been quite a bunch of changes to that piece between 1.0.2 and 1.0.3 as<br>$(gitk src/input/) shows, but I am not very familiar with it.<font color="#888888"><br>--<br>Rémi Denis-Courmont<br><a href="http://www.remlab.net/" target="_blank">http://www.remlab.net/</a><br>
<a href="http://fi.linkedin.com/in/remidenis" target="_blank">http://fi.linkedin.com/in/remidenis</a><br></font></blockquote></div></div></div><br>
</blockquote></div><br>