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

Rémi Denis-Courmont remi at remlab.net
Mon Apr 20 16:44:24 CEST 2015


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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/




More information about the vlc-devel mailing list