[vlc-devel] [PATCH 1/8] decoder: let the decoder tell how many pictures it needs in the pool

[Rémi Denis-Courmont]

Le perjantaina 31. heinäkuuta 2020, 7.18.13 EEST Steve Lhomme a écrit :
> On 2020-07-30 17:43, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 29. heinäkuuta 2020, 8.06.31 EEST Steve Lhomme a écrit :
> >> The contract is that the decoder tells the owner how many surfaces it's
> >> going to use and it will query the owner for new wrappers via
> >> decoder_NewPicture().
> > 
> > That's true for the legacy picture allocation path whereby the decoder
> > asks
> > the core to allocate the picture pool. But if the decoder allocates its
> > own
> > picture pool or has its own bespoke picture buffer management, the core
> > has no reasons to know about the picture buffer count.
> 
> That's where the size of 0 comes in. It tells the owner not to bother
> with a picture pool because the decoder won't be using it (no
> decoder_NewPicture).

Yes but then it's only used by existing software decoders, which just work 
anyway with the current per-codec system.

And it should not be used by new codecs, so adding the field at this point 
seems counter-productive. It will just make it easier to write deprecated-
style code.

> > So I don't think it should be embedded in the common generic decoder_t.
> > 
> >> For now it's only done for HW surfaces but it can also be done for all
> >> other buffers if we want to (IMO we don't).
> > 
> > In the hardware case, the core can anyway not perform the allocation, so
> > by definition it does not need to know the picture buffer count.
> 
> But it does.

No. If the core cannot allocate the buffers, it cannot allocate the buffers. And 
it indeed cannot allocate the buffers. It has nothing to do with this value.

I don't agree with this patch.

-- 
Реми Дёни-Курмон
http://www.remlab.net/