[vlc-devel] [PATCH] [RFC] always output an opaque D3D9 surface from DXVA

[Rémi Denis-Courmont]

Le 2015-04-27 12:24, Steve Lhomme a écrit :
>> OK but I would expect Extract to be unnecessary when doing direct 
>> rendering
>> (the one in VDPAU is pretty much doing nothing).
>
> Yes, we need to copy pixels between the surfaces like we were copying
> pixels from the surface to the planes. The target is from the
> "decoder" pool (the one from the vout wrapper), not the internal DXVA
> one. These picture_t end up in the display FIFO. So they need a
> different reference counting that the one used for the dxva2 
> surfaces.

I am not sure I understand what you mean by that.

In VDPAU, we need to explicit convert the decoded unscaled YUV surfaces 
to scaled RGB for output. But that cannot be done in the decoder because 
the decoder does not know the final resolution. The decoder cannot know 
the final resolution since it varies asynchronously when the user 
resizes the video window.

But maybe DxVA has even more manual steps than VDPAU. I can't really 
say if it needs Extract() or not. I just find it odd that it would.

>>>      if (sys->p_va != NULL)
>>>      {   /* TODO: Move this to get_format(). We are screwed if it 
>>> fails
>>> here. */
>>> -        if (vlc_va_Setup(sys->p_va, ctx,
>>> &dec->fmt_out.video.i_chroma))
>>> +        if (vlc_va_Setup(sys->p_va, ctx,
>>> &dec->fmt_out.video.i_chroma, pic)) {
>>
>> And you can't change i_chroma after you've allocated a picture.
>
> We can remove the chroma parameter from setup(), given the changes
> above. The va provides the output pixel format earlier and it won't 
> be
> regonatiated for that instance.

Yes and no. VA still needs the chroma parameter, unless:
- support for one of NV12 or YV12 gets dropped so we can hardcode the 
other,
OR
- VA is ported to direct rendering too.

Also the old VDA code should be dropped. The new VDA code only uses one 
chroma.

-- 
Rémi Denis-Courmont