[vlc-devel] [PATCH] core: add a callback to init/release data for picture pool of opaque formats

Steve Lhomme robux4 at videolabs.io
Mon Apr 20 17:16:40 CEST 2015

On Mon, Apr 20, 2015 at 4:44 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le lundi 20 avril 2015, 16:38:07 Steve Lhomme a écrit :
>> On Mon, Apr 20, 2015 at 4:14 PM, Rémi Denis-Courmont <remi at remlab.net>
> wrote:
>> > Le 2015-04-20 17:01, Steve Lhomme a écrit :
>> >> On Mon, Apr 20, 2015 at 3:43 PM, Rémi Denis-Courmont <remi at remlab.net>
>> >>
>> >> wrote:
>> >>> Le 2015-04-20 16:25, Steve Lhomme a écrit :
>> >>>> a gargabe collector callback is introduced for the global release
>> >>>> after all pictures are released from the pool
>> >>>
>> >>> I still think this is completely useless. And on top of that, it's very
>> >>> invasive.
>> >>
>> >> I'm open to other working solutions. I think it makes sense that a
>> >> pixel format comes with the instructions on how to handle it pixels.
>> >
>> > And I think it makes no sense for reasons already outlined on this list.
>> >
>> >> The tricky part in the case of D3D9 compared to the others is that the
>> >> surface passed from the decoder to the vout need to be created from
>> >> the same D3D9 device handle. So this handle needs to be shared one way
>> >> or another between the decoder and the vout.
>> >
>> > And I already stated that the video output, not the decoder, should
>> > allocate the device in that case.
>> This is not possible in the case of avcodec's dxva decoder.
>> When vlc_va_Setup() is called, we need to fill the dxva_context with
>> the surfaces it can use internally. That's way before a vout is
>> created. So I designed my solution around this constraint.
> So what are you going to do if the decoder output is unable to handle DxVA or
> is using another DxVA device? Your design has a problem.

The case where "direct rendering" is not possible is already handled.
A filter from D3D9 surfaces to I420 planes is automatically added in
the chain.

In the case of the D3D9 vout there could be a chance that the D3D9
device it's using is not the same as the one from DXVA2. That's why
this handle is passed to the vout and the vout is created accordingly.

More information about the vlc-devel mailing list