<html><head></head><body>Hi,<br><br>Extra pictures are chained. That's how it always worked or has been supposed to work, to the extent that multiple pictures are supported.<br><br>Adding a different way to handle more than one picture vs zero or one picture is making things both more complicated and less consistent.<br><br>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.<br><br><div class="gmail_quote">Le 15 octobre 2020 08:34:55 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2020-10-14 18:25, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le keskiviikkona 14. lokakuuta 2020, 15.39.09 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Each filter using the common deinterlacing code now calls DoDrain (similar<br>to DoDeinterlacing) to do its draining.<br></blockquote>That does not sound like what is usually called draining, which means to<br>process all buffers *before* an end or a discontinuity.<br></blockquote><br>Happy to use another term if there is one.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">We no longer return pictures chained using vlc_picture_chain_AppendChain().<br></blockquote>This seems odd too.<br></blockquote><br>That's my whole goal with this "draining". To handle extra pictures <br>explicitly and consistently, forced by the API. Not have some rare <br>places (display for deinterlace, transcode for deinterlace/fps) handle <br>it manually and leave everything else up to <br>interpretation/guessing/parsing hundreds of modules.<br><br>As a transition I could do #16-#20 with just the picture and <br>picture_chain API's that can do this properly. And then we can <br>transition them to "drain" calls.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>