<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>No. The point is that this API is broken by design and should not exist. In fact, I think preroll end should not even exist at all, in any form, and most definitely not as an API between ES out and decoder.</p>
</blockquote>
<p>But given the current state of the codebase, how do you propose that we:</p>
<ol style="list-style-type: decimal">
<li>fix the problems related to PREROLL and decoders?</li>
<li>fix the issues we are facing at this time (such as broken audio/video/subtitle after seeking)?</li>
</ol>
<p>This at least fixes some of the issues that has to do with the preroll, while also (as a little perk) making the code a little bit easier to refactor in the future.</p>
<p>There is only one code-path in which the input_Decoder{Get,Set}PrerollEnd could cause issue with the decoder (after the patches), and it can be fixed as below (draft implementation).</p>
<p>Please mind that this was just written at the top of my head (ie. there could be typos):</p>
<ul>
<li>https://gist.github.com/anonymous/87ab302de9d78301cb58f1ba8e210513</li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Preroll end is a hack because decoders don´t perform preroll internally correctly and</p>
</blockquote>
<p>Agreed, there are many things that could be improved further regarding the preroll; but those require some big changes to the core.</p>
<p>And even if the decoders are fixed to handle preroll in a more efficient manner (such as not generating data that the core just discards), we are still faced with the issue where an incoming block does not have a PTS.</p>
<p>For such blocks we can never know (since the demuxer cannot know) whether they are supposed to be part of the preroll or not without getting back a decoded packet, and deciding afterwars whether it should be played or not.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>it is fundamentally incompatible with asynchronous decoding.</p>
</blockquote>
<p>The introduction of input_Decoder{Get,Set}PrerollEnd is certainly debatable, which I agree with; but I fail to see how we could solve the issue in an easy manner using some alernative implementation.</p>
<p>Given the current state, the ES out needs to be able to tell the decoder-side of the core the preroll-end date; otherwise we cannot solve the issues described earlier.</p>