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

[Steve Lhomme]

On Tue, Apr 21, 2015 at 4:08 PM, Julian Scheel <julian at jusst.de> wrote:
> On 21.04.2015 14:00, Rémi Denis-Courmont wrote:
>>
>> Le 2015-04-21 11:51, Steve Lhomme a écrit :
>>>
>>> In the case of DXVA that would mean delaying the surface allocation
>>> until the vout can provide it. Why not. But what happens if there's no
>>> compatible vout ?
>>
>>
>> If downstream cannot cope with your picture format, you should probably
>> use another one. That is to say, you should fall back to software
>> decoding.
>>
>>> That sounds like doing the whole decoding/displaying chain backwards
>>> and that would open a whole big can of worms.
>>
>>
>> If this is backward, what do you suggest is the forward approach?
>>
>> You think the decoder should tell the video output which device and
>> buffers to use, then the video output should tell the application which
>> window to embed? To me *that* seems backward (if at all possible).
>>
>>> Anyway it cannot work with DXVA because, if I understand the chaining
>>> properly, the vout is created when the first frame comes out of the
>>> decoder. So it needs decoding surfaces before there's a vout.
>>
>>
>> I thought that Thomas and Julian had lifted that limitation.
>
>
> In fact you don't need to get a picture out of the decoder, but you need to
> know the format. So you can configure the output format and the vout gets
> created (see
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/hw/mmal/codec.c;h=3204def1a8db5bf6269b9718115abaafc152fdf7;hb=HEAD#l285)
>
> In mmal we get notified about the output format before pictures are actually
> decoded into memory, which is exactly for that usecase: Allow the host to
> allocate pictures after starting the decoder.
>
> But if DXVA doesn't tell you the format before actually allocating pictures
> you're indeed lost...


Thanks. Before we allocate the surfaces we decide which format to use.
We could stop there and allocate using that format later. That could
work.

I may need to bring back the three D3D9 opaque formats though. I
noticed vdpau also has a few that are not called "opaque" and are
converted back to planes if needed.