[vlc-devel] [PATCH v2 09/20] deinterlace: implement draining of extra pictures

Steve Lhomme robux4 at ycbcr.xyz
Thu Oct 15 11:28:01 CEST 2020

On 2020-10-15 9:19, Rémi Denis-Courmont wrote:
> Hi,
> Extra pictures are chained. That's how it always worked or has been 
> supposed to work, to the extent that multiple pictures are supported.
> Adding a different way to handle more than one picture vs zero or one 
> picture is making things both more complicated and less consistent.

What is not consistent is using p_next to return multiple pictures at 
once *and* using p_next to list pictures in a FIFO/picture chain. The 
fact it doesn't collide/leak pictures is just luck.

I submitted a simple (epileptic) to exhibit what happens with filters 
that would hope to add extra pictures. It returns the source picture and 
the same picture inverted. Can you guess what will happen with the 
current code when trying to play the file ?

The same issue(s) happens if you use the fps plugin manually.

The fact some basic things work doesn't mean it works in general nor 
that the design is correct.

> Draining is used to forcefully process buffers at EOS; this is also how 
> audio works. It's just that nobody bothered to convert the 
> filter_video(NULL) to drain_video(NULL). I disagree with changing the 
> meaning/scope of drain.

I'm fine with that but what would be another name to get extra pictures 
from a filter ?

Or should we stop using p_next for 2 different things and just a 
vlc_array or separate (intrusive) vlc_list for the picture_chain ?

> Le 15 octobre 2020 08:34:55 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a 
> écrit :
>     On 2020-10-14 18:25, Rémi Denis-Courmont wrote:
>         Le keskiviikkona 14. lokakuuta 2020, 15.39.09 EEST Steve Lhomme
>         a écrit :
>             Each filter using the common deinterlacing code now calls
>             DoDrain (similar
>             to DoDeinterlacing) to do its draining.
>         That does not sound like what is usually called draining, which
>         means to
>         process all buffers *before* an end or a discontinuity.
>     Happy to use another term if there is one.
>             We no longer return pictures chained using
>             vlc_picture_chain_AppendChain().
>         This seems odd too.
>     That's my whole goal with this "draining". To handle extra pictures
>     explicitly and consistently, forced by the API. Not have some rare
>     places (display for deinterlace, transcode for deinterlace/fps) handle
>     it manually and leave everything else up to
>     interpretation/guessing/parsing hundreds of modules.
>     As a transition I could do #16-#20 with just the picture and
>     picture_chain API's that can do this properly. And then we can
>     transition them to "drain" calls.
>     ------------------------------------------------------------------------
>     vlc-devel mailing list
>     To unsubscribe or modify your subscription options:
>     https://mailman.videolan.org/listinfo/vlc-devel
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser 
> ma brièveté.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list