[vlc-devel] [RFC-PATCH 04/12] core: introduce input_Decoder{Set, Get}PrerollEnd

[Rémi Denis-Courmont]

On Wednesday 11 May 2016 20:47:47 Filip Roséen wrote:
> > >That´s completely missing the point. An atomic variable would have the
> > >exact same fundamental timing issues as a variable with a mutex.
> > 
> > Hi Rémi,
> > are you really sure.
> > See here ->
> > https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/
> It is not the integrity of the variable itself that Remi was referring to,
> but the fact that writes to the variable (not from within the decoder)
> could happen inbetween work where the decoder assumes that "hey, I am the
> one controlling the preroll, so I can overwrite this value with
> VLC_TS_INVALID if I want to".
> 
> The problem stated above could be fixed by an atomic_compare_exchange, where
> the decoder does not unconditionally write VLC_TS_INVALID to denote the end
> of the preroll, but instead only does so if the preroll-end timestamp is
> what it expects it to be.

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.

Preroll end is a hack because decoders don´t perform preroll internally 
correctly and, as I believe as already been pointed out, it is fundamentally 
incompatible with asynchronous decoding.

-- 
Rémi Denis-Courmont
http://www.remlab.net/