Encoding extended range YUV formats with MMAPI

Hi,

I’m using L4T 32.3.1 on a Jetson Nano based product and I am interested in supporting encoding of extended color range data to H.264 and H.265 using the MMAPI. I have modified our own product code to support this but I noticed that the encoder does not seem to support any of the _ER formats (e.g. NvBufferColorFormat_YUV420_ER).

Thinking it was probably a mistake I made, I went back and flashed the stock Ubuntu distro and tested the video_encode sample as well, with the --enable-extcolorfmt flag. This also fails in the same way as my own code. There are some messages printed to the console when this happens (these are from running the video_encode sample):

 NvMMLiteVideoEncDoWork:NvMSEncConvertSurfaceFormat failed
VENC: NvMMLiteVideoEncDoWork: 4231: BlockSide error 0x4
NvVideoEnc: BlockError
NvVideoEncTransferOutputBufferToBlock: DoWork failed line# 667
NvVideoEnc: NvVideoEncTransferOutputBufferToBlock TransferBufferToBlock failed Line=678
[ERROR] (NvV4l2ElementPlane.cpp:178) <enc0> Capture Plane:Error while DQing buffer: Invalid argument
Error while dequeing buffer from output plane
[ERROR] (NvV4l2ElementPlane.cpp:256) <enc0> Output Plane:Error while Qing buffer: Invalid argument
Error while queueing buffer at output plane

If I run the video_encode sample without the --enable-extcolorfmt flag it does work as expected.

For reference, I have a different TX1-based product which originally used L4T 28.2. I updated this product to 28.3.2 and added support for extended color range formats, and everything is working on this product.

Any ideas or help with this are greatly appreciated.

Thanks,

Chris Richardson

Hi,
Looks like it can be reproduced by running 01_video_encode on r32.3.1/Nano. Please share a command so that we can reproduce the issue.

Hi DaneLLL,

I am able to reproduce it with the following command, given an input YUV file named test.yuv with a resolution of 1920x1080:

./video_encode test.yuv 1920 1080 H264 test.264 --enable-extcolorfmt

I’m happy to provide any other details on the system. If this works on your setup, I will be happy to know it is supposed to work and something must be wrong on my end.

Thanks,

Chris Richardson

Hi,
We can reproduce it. It is under investigation. Will update once there is further finding.

Hi,
We will have it fixed in next r32 release(r32.4).

Hi DaneLLL,

Thanks for checking on this and for the status update. Do you have any info on when R32.4 will be released?

Thanks,

Chris Richardson

Hi,
We will have Jetpack4.4 Developer Preview release by next one or two weeks.

Hi DaneLLL,

Thanks for the information. I look forward to testing the new release when it is available.

Thanks,

Chris Richardson

Hi DaneLLL,

I have one more question related to this. Will the next release support the _709_ER variants of the NvBufferColorFormat enum (e.g. NvBufferColorFormat_YUV420_709_ER) as well? I am hoping this will be supported.

Thanks,

Chris

Hi,

No, 01_video_encode handles

            cParams.colorFormat = ctx->enable_extended_colorformat ?
                 NvBufferColorFormat_YUV420_ER : NvBufferColorFormat_YUV420;

NvBufferColorFormat_YUV420_709 and NvBufferColorFormat_YUV420_709_ER are not included.

Hi DaneLLL,

Thanks for the information. I was more wondering if my own application used in my product would be able to support those values, as I will be encoding HD video in BT.709 format. This does seem to be supported on L4T 28.3.2 which I use in another product. It won’t matter to me if 01_video_encode supports BT.709 or not, but it would be nice if the encoder supports it in general.

Thanks,

Chris Richardson

Hi All,

For anybody else visiting this post later, I can confirm that NvBufferColorFormat_YUV420_ER, NvBufferColorFormat_YUV420_709_ER are both working with the underlying encoder software in rev 32.4.2.

Thanks for fixing this.

Chris Richardson

1 Like

Hi @cjwti
Thanks for the confirmation. One issue is color space is not put in VUI to distinguish BT601 and BT709. We shall have this supported in next release.

Hi DaneLLL,

Thanks! That’s a good point, and I’m glad to hear it will be added in a future release. If you guys are considering adding support for anything else to the VUI information, I would like to vote for adding aspect ratio support. I have some code to transform the VUI for H.264/H.265 because I need to insert all this extra data and the older L4T release that I started from didn’t support it.

Thanks,

Chris Richardson