<html><head></head><body>Hi,<br><br>No it's not the hard part. You have demuxers where the NPT can be computed properly, and it will be a step-wise offset of the timestamps, most often 0 or VLC_TS_0, with the notable exceptions of TS and discs.<br><br>And then you have some pathological cases like seekable TS without EIT. But computing an NPT offset is not harder or more jittery than whatever is being done right now to estimate the NPT value.<br><br><div class="gmail_quote">Le 12 mars 2021 12:05:33 GMT+02:00, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Le 11/03/2021 à 16:28, Rémi Denis-Courmont a écrit :<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">And my point is that we should just report that offset (second bullet point)<br>from NPT to PCR whenever it changes.<br></blockquote><br>That's the hard task. I tried to bind both references on my side and <br>there's more than one corner case.<br><br>As they usually don't have the same update frequency, depending on when <br>you create a reference point, or update it, that creates unwanted jitter <br>or unaligned start offset.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>