[vlc-devel] [PATCH v2 09/20] deinterlace: implement draining of extra pictures
remi at remlab.net
Thu Oct 15 09:19:16 CEST 2020
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.
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.
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
>>> Each filter using the common deinterlacing code now calls DoDrain
>>> to DoDeinterlacing) to do its draining.
>> That does not sound like what is usually called draining, which means
>> 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
>> 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:
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel