[vlc-devel] [PATCH 1/5] [RFC] core: allow use different pool sources for different types
robux4 at gmail.com
Wed Mar 29 08:43:26 CEST 2017
On Wed, Mar 29, 2017 at 8:41 AM, Steve Lhomme <robux4 at gmail.com> wrote:
> 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. It makes hardware filters impossible, at
> least on Windows.
Another food for throught: https://trac.videolan.org/vlc/ticket/16637
Opaque formats cannot be snapshoted because the picture copy does
nothing. If my old proposal of a pool with various callbacks was in, a
picture copy would actually work.
> As for an "intrinsinc design requirement", my proposal actually works.
> So the requirement must not be that strong. 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
> distinct. And if it didn't make sense there wouldn't be display_pool,
> decoder_pool and private_pool in the core. Plus, as explained above,
> in the case of D3D11 it's impossible to have a pool that covers all
> cases, by design.
>> So this proposal makes absolutely no sense to me. Nack.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
More information about the vlc-devel