<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>I know the problem predates (by very long) this patch. But at least, it is currently contained. I don´t think we should expose a fundamentally broken API.</p>
</blockquote>
<p>I just understood a little better what you mean, but just for clarification: you do not like the helpers because they would allow things other than code in decoder.c to access the i_preroll_end?</p>
<p>I guess I could submit a patch that handles this through some sort of indirection, though the major issues is that we need to propagate the preroll end timestamp from es_out.c to decoder.c in some way or another in order to have the decoders react appropriately to the preroll itself.</p>
<p>Maybe one could establish a “could you please do X” relationship between the es and the underlying decoder, instead of the es unconditionally updating the value.</p>
<p>It would mean added complexity, but it would also be more correct.</p>
<h3 id="immediate-fix">Immediate fix</h3>
<p>Though, one fix to the immediate issue would be to update DecoderPrerollBlock (which is introduced in a later patch), so that there is no chance for someone to update the preroll-end timestamp between the functions call to input_DecoderGetPrerollEnd and input_DecoderSetPrerollEnd(…, VLC_TS_INVALID ).</p>
<p>Because that is the only code-path where it would be problematic with an intermediate write.</p>