Dear developper,<br><br>We tested various version of VLC for a "special project" where we need low latency decoding.<br>Here are our finding based on behaviour and log message observation.<br>I don't have much inside knowledge of VLC so I might have miss a few obvious option.<br>
<br>If anybody know the obvious parameter to use in 1.1.0-git to fix our problem or where to dig... please speak.<br><br>Thanks in advance.<br><br>David Glaude<br><br>===<br><br>Goal:<br><br>Find a version in wich IE plugin is<br>
* Low latency = there is a minimum delay between receiving the data and displaying it<br>* Stable = no memory leak and no crash<br>* Robust = there is not latency variation over time if some packets (from 1 to x minutes) are lost<br>
* long lasting = can run for days without problem and if required support many IE page refresh<br><br>We tested the following version of VLC:<br>(A) VLC-0.8.6i-win32.exe (default parameter)<br>(B) VLC-1.0.5-win32.exe (default parameter)<br>
(C) VLC-1.1.0-git-20100305-0002-win32.exe (default parameter)<br>(D) VLC-1.1.0-git-20100305-0002-win32.exe (with "--clock-jitter=0")<br>(E) VLC-1.0.2-win32.exe (default parameter)<br><br>Crash test:<br><br>(1) Start VLC in plugin and in player mode<br>
(2) Display message and debug level 2<br>(3) Check the latency (compare the decoded picture to the source)<br>(4) Unplug the network cable of the encoder (or VLC) for short and long time<br>(5) Observe the latency variation and behaviour = time to stop, time to restart, latency at restart, log message<br>
(6) Press F5 many time and observe = does it restart always? does it eat memory? does it keep the latency?<br>(7) Let VLC run for hours and days<br>(8) Observe memory usage of IE and VLC over time (mostly peak value) <br>
<br>Our stream:<br><br>QCIF Video only (no sound) MP4 (part 2) video inside UDP multicast send with RTP and describe by an SDP file either local or HTTP downloaded<br><br>Here are the result:<br><br>VLC-1.0.2-win32.exe (E) give us the best result for the low latency and for 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 introduce additionnal latency.<br>The problem is not fully solved with "--clock-jitter=0" in 1.1.0-git and there must be other buffer involved that were not triggered before.<br>
Presentation buffer? Decoding buffer? RTP Buffer?<br>Something is else is dynamic and change the buffering when we cut the stream.<br><br>Our possible options:<br>* Find the trick or solution within 1.1.0-git<br>* use 1.1.0 and force frequent refresh (30 minutes/1 hour) to resync if needed <br>
* use VLC 1.0.2<br><br>Here are the detail:<br><br>(A) With 0.8.6i we encountered a crash (picture freeze) after a few hours of continuous streaming.<br>Since that version is old (but stable) the chance to have a long term support are small so that path was abandonned.<br>
<br>(B) With 1.0.5 we found a lot of stability and low latency, but after a few days we noticed that the latency did increase over time.<br>To try the robustness of VLC we created artificial loss of connectivity between the encoder (network cable unplug).<br>
We found that between VLC 1.0.2 and 1.0.3 an feature was added in VLC to dynamicaly compute a value for "pts_delay".<br><br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late, increasing pts_delay to 300 ms<br>
main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late, increasing pts_delay to 9023 ms<br>main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late, increasing pts_delay to 30000 ms<br>
main error: ES_OUT_RESET_PCR called<br><br>(C) At our request a VLC developper added into the source code tree of VLC 1.1.0 a parameter to disable that new feature.<br>We were able to test VLC-1.1.0-git-20100305 with or without the new option "--clock-jitter=0".<br>
Without "--clock-jitter=0" the behaviour is similar to previously<br><br>(D) By using the same version with the option "--clock-jitter=0" (simultaniously) we did notice the change but other source of latency are present.<br>
It return to low latency behaviour when we see those message in the log:<br>main warning: clock gap, unexpected stream discontinuity<br>main warning: feeding synchro with a new reference point trying to recover from clock gap<br>
<br>However there are time where there is a sometime huge buffering occuring somewhere else (pts_delay) despite the "--clock-jitter=0":<br>main debug: Stream buffering done (3039 ms in 2348 ms)<br>main debug: Stream buffering done (4359 ms in 837 ms)<br>
<br>The main difference between --clock-jitter=0 or not is here:<br><br>With:<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (jitter of 6016 ms ingnored)<br>main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (jitter of 65270 ms ingnored)<br>
main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (jitter of 3008 ms ingnored)<br>main error: ES_OUT_RESET_PCR called<br><br>Without:<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (pts_delay increased to 1804 ms)<br>
main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (jitter of 65270 ms ingnored)<br>main error: ES_OUT_RESET_PCR called<br>main error: ES_OUT_SET_(GROUP_)PCR  is called too late (pts_delay increased to 2023 ms)<br>
main error: ES_OUT_RESET_PCR called<br><br>(E) Currently the best result (at least for robustness) is VLC-1.0.2-win32.exe. We don't know yet the result after 2 or 3 days.<br>But whenever the video restart after the network connectivity is restored, it is always with low latency.<br>
<br>On occasion we see the following message (not always) when we force a connectivity loss:<br>main warning: clock gap, unexpected stream discontinuity<br>main warning: feeding synchro with a new reference point trying to recover from clock gap<br>
<br>There is no additionnal message in the log except for some message always present under normal condition and low input buffer.<br>main warning: late picture skipped (8842 > -956)<br>main warning: late picture skipped (128124 > -334)<br>
<br>