[vlc-devel] [PATCH 1/5] [RFC] core: allow use different pool sources for different types

Rémi Denis-Courmont 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> 
wrote:
> > 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
> proposed.
> 
> > 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
> distinct.

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.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/



More information about the vlc-devel mailing list