[vlc-devel] [PATCH 1/5] [RFC] core: allow use different pool sources for different types
remi at remlab.net
Wed Mar 29 17:02:41 CEST 2017
Le keskiviikkona 29. maaliskuuta 2017, 8.41.11 EEST Steve Lhomme a écrit :
> On Tue, Mar 28, 2017 at 6:08 PM, Rémi Denis-Courmont <remi at remlab.net>
> > Le tiistaina 28. maaliskuuta 2017, 16.23.56 EEST Steve Lhomme a écrit :
> >> This patches allows a vout to request different types for each pool we
> >> need
> >> (decoder, display and filter).
> > It is an intrinsic design requirement of the video filter 2 API that the
> > input and output pictures of a format-preserving filter come from the
> > same pool.
> This is a broken design.
No. It is an intrinsic implementation consequence of the functional
requirements to avoid memory copying and support seamless insertion and
removal of video filters.
What´s broken by design is your patch, in more than one way.
> It makes hardware filters impossible, at least on Windows.
Yeah right(tm). Funny that filters work with VDPAU, which also has what you
call strongly typed surfaces.
> As for an "intrinsinc design requirement", my proposal actually works.
> So the requirement must not be that strong.
We must have a different understanding of "actually working".
> And it's opt-in. Until we
> have a proper filter pool solution. Other than the fews I already
> > This is of course a transitive requirement. So the distinction makes no
> > sense in that case.
> > Distinguishing decoder and filter pool also makes no sense, since there
> > can be any number of conversions in the pipeline - including zero in
> > which case there is intrinsically only one pool.
> No, in the case on zero, the filter pool is not used. It's still
The number of filters is not constant. At the time when the picture is
allocated by the decoder, you don´t know if/how it will be filtered.
More information about the vlc-devel