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

Julian Scheel julian at jusst.de
Tue Apr 21 16:08:24 CEST 2015

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

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...


More information about the vlc-devel mailing list