[vlc-devel] Developing decode/encode plug-in: NV12/D3D

[Rémi Denis-Courmont]

   Hello,

Please don't answer to mails when you don't actually mean to answer.

On Friday 10 December 2010, Larsson, Petter wrote:
> It seems the NV12 format is not fully supported by VLC. It's listed in
> vlc_fourcc.h but it's not supported in vout_pictures.c which makes it
> impossible to create (decoder_NewPicture(...)) a picture object for the
> purposes of decode surface creation.

Yeah. Proper support for a new chroma involves quite a bit of work, and in 
principles testing/validation.

> A non optimal solution is to convert NV12 to/from YV12, this works fine but
> this is obviously a large CPU hit.

Yes :-( On the bright side, that stuff is very prone to vectorization. In any 
case, slow software conversion is hardly avoidable until at least one video 
output plugin provides native/hardware support for NV12.

> Hacking vout_pictures.c I did add NV12 format as a new format with the same
> planar setup as YV12, but this solution is not entirely correct since NV12
> is a hybrid planar format (albeit the same size as YV12). This solution
> works for the transcode case where both my decoder and encoder is used.
> 
> If an existing VLC encoder (such as x264) is used together with my NV12
> type decoder for transcode it works but since the encoder does not expect
> NV12 format resulting in an output has the UV plane colors all wrong.
> 
> What is the stance on NV12 support in VLC? Am I missing something here?

At this point in time, NV12 is only used with avcodec VAAPI/DxVA2 decoders. In 
particular, it is not supported by any video outputs.

So I guess Laurent found it much simpler to convert on-the-fly to/from YV12.

Of course, if proper NV12 turns out to be useful, then it should be added to 
the core.

> Regarding using the NV12 decoder for the playback case, it does appear that
> NV12 rendering is understood (at least from the log). But I'm currently
> not able to fully verify this due to some odd behavior (bitstream blocks
> delivered for the playback case differs from the transcode case. For
> playback the blocks are missing header info, and as it seems start codes)
> 
> 
> 
> D3D frame surface support:
> ---------------------------
> Is there a way to use D3D surfaces instead of system memory surfaces for
> decoder and encoder plugin frame buffers. I confess, I have not been
> digging deep here but maybe some can give some pointers on where to find
> more info or dismiss it altogether.

If you mean to ask whether you can fetch Direct3D handles to surfaces, then 
no. VLC (currently) follows a rather strict separation and abstraction of 
tasks. Using D3D surfaces would tangle decoding and output.

That said, if the active video output happens to be Direct3D, *and* if the 
decoder raw video output format is supported by the Direct3D output, then the 
picture buffers will be Direct3D surfaces.

Best regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/