Jetpack 4.3 Multimedia API NvVidConv ABGR32

Hi everyone,

I tried to write a jpeg compresser for ROS based on NvVideoConverter + NvJpegEncoder. but experience the issue that BGR and RGB seemed to be flipped although the format specifies it correctly.

As output plane I have:

  • USERPTR, pitch linear
  • BGRA8 ( ROS/ OpenCv byte order -> bgra), which maps to V4L2_PIX_FMT_ABGR32 (see V4L2 RGB formats)

As capture plane:

  • MMAP, block linear
  • NV12 (V4L2_PIX_FMT_NV12M)

Encoding using encodeFromFdlike in the jpeg_encode sample. If I flip the channels beforehand the output looks fine, although if display the original image using ROS the order appears correct.

Could somebody confirm this behaviour/bug or tell me if I am missing something?

Besides I do not see that any formats with more bits per channel are supported through the Multimedia API (vidconv and jpegenc). I am looking for formats to encode gray (12-bit encoded as 16 bit) or rgb (12-bit encoded as 16 bit). Are there some formats resp. is it supported?

Best regards,


The correct format should be NvBufferColorFormat_ARGB32. You can create NvBuffer and call NvBufferTransform() for the conversion. The APIs are defined in


So does the NvVidConv specify/treat the format wrong? Should I rather use the NvBuffer framework than the NvVidConv? L4T VidConv supported formats
Because from what I get from the V4L2 Doc + OpenCV + ROS ABGR32 should be the format to use for BGRA8. I only swap the channels right now because it seems that, although I specify ABGR32 my image gets treated as ARGB32.

Regarding my second question:

Can I use NvJPEGEncoder from the mmapi to encode BGR10/12/16 (actual 10 or 12-bit) images somehow? Which format is suitable or does the Encoder not support them anyway? Are the NV12_10LE formats 10-bits per channel or just 10-bits on average due to the subsampling (so a reduced NV12_10LE which is 12-bit on average per pixel)?



NvVideoConverter is fine but we don’t add the format NvBufferColorFormat_ARGB32 to it. NvBuffer APIs are more straightforward and we suggest use the APIs.

We support YUV420 in jpeg encoding. Please check 1.6.3 JPEG Processing in module datasheet.

Ok thank you. I will try to switch to NvBuffer API later. As it really gives me more options. To make it clear for me: They (VidConv and Buffer API) both use the same HW/Methods to convert the format or is there anything I need to think of?

Although I still think NvVidConv (or doc) is buggy since I define the plane to be ABGR32 (which it supports according to the doc) and provide data as ABGR32, yet my encoded images appear to have flipped R/B channels (as if NvVidConv expected ARGB32). But for now I will continue to provide ARGB32 instead of ABGR32.

Because you mentioned the JPEG Encoder only supports YUV420 images, is there any advantage over using YUV420 instead NV12(M), which the jpeg_enc example uses and I currently use, for jpeg encoding?



It is possible NvVideoCoverter does not work in certain cases since NvBufferTransform() is straightforward and we encourage users to use the function. Please give it a try.

YUV420 includes I420 and NV12. I420 has Y, U, V planes, and NV12 has Y, interleaved UV planes. Both are identical excpet data order of UV plane(s). It is fine to use NV12 in jpeg encoding.