<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>In this case the duration is <em>only</em> an implementation detail of the decoder, or possibly the demuxer.</p>
</blockquote>
<p>Indeed, though I am not sure how to handle cases as the previosly mentioned sample otherwise. The problem is of course that we discard more data than we really should; and I (perhaps naively) thought that the patch could solve this issue in a manner that would still aid user-experience.</p>
<ul>
<li>Do you have an alternative idea that would yield the correct result?</li>
</ul>
<p>Writing code is the easy part, having it be theoretically and practically correct is another. With my lack of experience I most often base my patches on the practical issues they solve.</p>
<p>Once again; thanks for taking a look at another RFC from me! <code>:-)</code></p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Stating the obvious here, but if you want to cut at AOUT_MAX_PTS_DELAY, then it´s not the length you should be looking at. It´s the start (pts) and the end (pts + length).</p>
</blockquote>
<p>Certainly, but since the drift (named “advance” in this particular piece of code) is based on the PTS simply using the length together with the drift would yield the same result.</p>