<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 :<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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><br>