[vlc-devel] [PATCH 1/4] filters: flush before closing filters

Steve Lhomme robux4 at ycbcr.xyz
Tue Oct 13 08:49:56 CEST 2020

On 2020-10-13 8:37, RĂ©mi Denis-Courmont wrote:
> Hi,
> I don't think that's correct. A filter could very well want to drain 
> rather than flush at close, or whatever. It's no surprise that flushing 
> is often done at close but I don't think it should be forced.

This is a Close call. At this point the filter cannot decide to drain, 
there's noone left to receive the pictures. On the other hand, if it has 
buffers pending, it MUST release them on Close. It can be done 
internally or via a global Flush.

> And then it makes reading the code more difficult, as it's nonobvious 
> that Flush would be called implicitly at exit. Soon we'd see Close -> 
> Flush calls being added again to fix nonexistent leaks.

It's a possibility but it's not a bug and won't cause any problem, just 
wasted CPU cycles. Code review or debugging should avoid this in most cases.

Having filters with dangling pictures/blocks on Close is totally 
preventable by making sure we always flush. It also avoids duplicate 
code in Close when the Flush is already coded. I can see some other 
filters that could be simplified because of this.

More information about the vlc-devel mailing list