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

[Rémi Denis-Courmont]

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.

> First I went with each individual picture_t being passed some blob to
> handle extra init. But in the end we allocate picture_t in a pool so 
> a
> "pool_setup_t" made more sense.

All the possible customization for allocating and freeing picture from 
pools is already there.

Pool-wide resources can already be garbage collected with a reference 
counter in the picture release callback. Adding a convenience callback 
is possible. But your patch is much much more invasive than necessary 
for that purpose.

> I think in general some deeper changes could be made to picture_t and
> picture_pool_t so they don't assume that their data are in planes
> allocated in CPU memory.

The only assumption was that planes are mapped in CPU address space, 
not necessarily in main memory. And that assumption was already removed 
when support for chromas with zero- planes was added.

-- 
Rémi Denis-Courmont