I’m working with a TX2 development board, using the MMAPI to capture and encode video in H.264 format. This is mostly working fine. However, I notice two things:
The SPS NAL unit seems to be invalid. The (fairly old) JM build I am using to test this does not accept the SPS due to the reserved_zero_4bits not actually being zero. A sample NAL unit looks like this:
As you can see, two of the lower 4 bits of byte 6 are 1. Other encoders that I have access to from different vendors produce zeros in these bits. Any ideas what is going on here?
I can’t find a way to insert VUI information in the SPS. I am aware that I could generate my own VUI data if I wanted to, but I don’t really want to have to do this. Does anyone at NVIDIA know if there are plans to allow VUI insertion via the MMAPI? The specific parameters I am interested in are the timing info, aspect ratio, color primaries and pixel range.
Hi Chris,
For 1 please attach the correct SPS for our reference. What is the revision of your JM decoder? Does the non-zero padding lead to failure of decoding in any PC/Android/iOS platform?
For 2, does absence of VUI lead to failure of decoding in any platform?
I don’t notice any problem decoding the stream with ffmpeg on my PC, but I like to test with JM as well to make sure I am not sending out invalid streams. Additionally, my customers have an unknown array of hardware decoders, and I won’t be able to test them all. Assuming we end up using this NVIDIA module, I will eventually get feedback from my customers.
Anyways, for completeness, below you can see an example SPS generated by TI hardware which we currently use. Please ignore that the start code is not present at the beginning; it is from a live stream that doesn’t include them. You can see that byte 3 is all zeros in this case, and that much more information (including the VUI) is included in the SPS.
It’s not that decoding fails without the VUI, but display is not good, since the video comes out with the wrong color levels and aspect ratio. Additionally, the timing information is used by several broadcast decoders I am testing with, and I would like to continue sending this information in our streams if we switch our hardware over from TI to NVIDIA. It seems very surprising to me that NVIDIA does not have software support for this basic feature on such an expensive module.
Thanks for the response. Regarding 1, thanks. It looks fine with the newer JM. Thanks for consideration on adding support for number 2. VUI insertion will be very helpful for us.