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

[Steve Lhomme]

On Wed, Mar 29, 2017 at 5:02 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> 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.

I see vdp_output_surface_create() and vdp_video_surface_create() which
produce different types of surfaces. Given the display module doesn't
know of VdpVideoSurface, I assume it creates the whole pool size
requested by the core (let's say 30 4K pictures) and then each module
creates its own surface (!) to deal with processing and copies to the
vout pool at some point.

Obviously that means the vout doesn't actually do any direct
rendering. It also means the pipeline may fail if an allocation fails
during decoding/filtering.

I am looking for a solution that actually does as little allocation
and copying as possible.

>> 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.

In the case of filtering direct rendering is disabled. So there's
always a copy into a picture from the display pool.

If the vout is can do direct rendering, the decoder pool should be
displayable. And that's why I added an extra flag can_display_decoder
because in some case it may not be possible.

> --
> 雷米‧德尼-库尔蒙
> https://www.remlab.net/
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel