[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