In NvBufSurfaceColorFormat, what does the _ER ending some format have mean?

I am currently working with DeepstreamSDK 6.1 and writing some simple test programs. The NvBufSurfaceFormat enum defined in nvbufsurface.h has entries like NVBUF_COLOR_FORMAT_NV12_709 and NVBUF_COLOR_FORMAT_NV12_709_ER but its not clear what the _ER ending signifies. The text just says it “Specifies BT.709 colorspace - Y/CbCr ER 4:2:0 multi-planar.” but I can find no mention of an ER variant for colorspaces except in NVidia’s products.

It corresponds to gamma pre-corrected signals. You can simply understand whether there is gamma correction with or without ER.

According to ChatGPT the ER stands for “Extended Resolution” meaning 10-bit samples instead of 8-bit. This seems more likely.

No, it’s “Entended Range” here for lumma algorithm.

Thanks for the correction. Where can I find documentation on the storage layout of these extended range luma formats?

Because these are not open source code yet, there is no detailed external explanation document.

Meanwhile you want folks to adopt your technology for their projects, but its not documented enough for even some trivial tasks. Like using our technology to display one your buffers.

We provide detailed documentation for the nvbufsurface. You can dump raw data with various formats from it at any time. You can refer to the link below:
https://docs.nvidia.com/metropolis/deepstream/dev-guide/sdk-api/structNvBufSurfaceParams.html
Did you encounter any specific issues during the code development process?

Yes. As we are developing our own elements which will be working with deepstream buffers, we need to be able to interchange your data formats with our own. As I already said, not having your data formats completely defined makes that difficult. Currently if we ever get an _ER buffer, we’ll abort with a assertion error as we can’t convert its contents without knowing its format.

We’ve also discovered that there are no NVDS allocator interfaces that are public, only NVDS BufferPools. As the propose_allocation and decide_allocation stages of GStreamer’s pipeline negotiation wants to be able to talk about allocators, that also hampers our ability to interoperate. We have written some workaround but they are kludgy and we’ve yet to get them fully working.

There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks

The storage layout is same as without _ER. But it uses a larger numerical range to represent colors. You can learn more about color space. Also you can refer to the Gstreamer source code first:
https://github.com/jojva/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.h#L39

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.