<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
span.EmailStyle17
{font-family:"Calibri","sans-serif";
color:windowtext}
.MsoChpDefault
{font-family:"Calibri","sans-serif"}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
{}
-->
</style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">My setup is streaming a mp4 file in an infinite loop with vlc. encapsulation is mpeg-ts and transport is RTP on a multicast IP address.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">On the client side, we use libvlc (2.0.3) with the following global switches:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> , "--clock-synchro=0"</p>
<p class="MsoNormal"> , "--network-caching=0"</p>
<p class="MsoNormal"> , "--clock-jitter=0"</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It is maybe extreme but since my problem seem to be related to buffering and tried to be as clear as possible to the library that I didn’t want any buffering at all. Despite my efforts, it seems that code in src/input/es_out.c adds buffering
to compensate some problem between PCR updates and the input clock state.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">As long as we do not touch the streaming source, the playback is fine. However, if we do pause/unpause the stream from the source (that is something we do regularly in our application) then it seems to disrupt the computation of the buffer
size to compensate for sync problems. It would be great if VLC was not doing that (it wasn’t in 0.9.8, the version we have upgraded from to 2.0.3) but one could argue that if you pause/unpause the stream from the streamer, vlc player behavior is undefined.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">However, once the es_out module has compensated for detected sync problems by having enlarged decoder buffer to 3-4 seconds, this new buffer size seems to remain to that size even when the decoder is deleted/recreated because of the discontinuity
caused by the transition when the mp4 clip restart. IMO, this is the major problem.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In practical terms, the effect is if you have 30 secs clip playing in loop. As soon as you pause for a couple of seconds the streamer, on the client side, you will experience a pause of 4-5 seconds every time the clip restart because of
buffering of a real-time stream (no burst whatsoever).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">If you destroy/recreate the decoder, then ,IMHO, PCR compensation by buffering should go away. Maybe it is not as simple as that but I just wanted to bring your attention to my vlc behavior observation.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Greetings,</p>
<p class="MsoNormal">Olivier</p>
<p class="MsoNormal"> </p>
</div>
<br>
<hr>
<font face="Arial" color="Black" size="2">CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use
it for any purpose or store or copy the information in any medium.<br>
</font>
</body>
</html>