Unexpected file size when using video_encoder

Hello,

I am seeing unexpected behavior when using the xavier video encoder, for this question I will use the 01_video_encode sample application for testing.

I expect that when I change bitrate/s that the resulting image and file size have changed according to the set bitrate but seems that only the quality has changed. I added a print statement in encoder_capture_plane_dq_callback to print buffer->planes[0].bytesused to highlight this fact.

lets compare to TX2 which I have available

on Xavier-NX (bitrate is 1024 kb):

./video_encode 0_recorded_10000.yuv 1910 1272 H264 encoded_test.yuv -br 1024000
bytes in frame was 9265
 bytes in frame was 9006
 bytes in frame was 7956
 bytes in frame was 7675
 bytes in frame was 7358
 bytes in frame was 7175
 bytes in frame was 7375
 bytes in frame was 7580

On other calls with different bitrate the bytesize in this call is always about the same

in Tx2 (bitrate also 1024 kb):

./video_encode 0_recorded_10000.yuv 1910 1272 H264 encoded_test.yuv -br 1024000
 bytes in frame was 310
 bytes in frame was 310
 bytes in frame was 303
 bytes in frame was 302
 bytes in frame was 296
 bytes in frame was 297
 bytes in frame was 296
 bytes in frame was 300
 bytes in frame was 324
 bytes in frame was 309
 bytes in frame was 302
 bytes in frame was 298
 bytes in frame was 295
 bytes in frame was 301
 bytes in frame was 299

In other calls with changing bitrate the values here seem to change as predicted…

Not sure why this is occurring, do not see anything in the documentation to explain this, on Xavier am using l4t 35.5.0, on Tx2 using l4t 32.4.4

Hi,
It looks to be an issue in 01 sample. The bitrate setting does not take effect. We will check and update.

Hi,
The issue is specific to the resolution 1910x2172. We will check further. In the meantime, please try standard resolution like 1920x1080 and 1280x720.

And please share a valid YUV file in 1910x2172. We are not able to generate a valid file by running gst-launch-1.0 command like:

$ gst-launch-1.0 videotestsrc num-buffers=100 is-live=1 ! video/x-raw,width=1910,height=1272,format=I420 ! filesink location=a.yuv

Hi,
We use 07 sample to get YUV420 data in 1910x1272 and encode it. The size looks expected.

// generate YUV420 in 1920x1272(90 frames = 3 seconds in 30fps)
$ gst-launch-1.0 videotestsrc num-buffers=90 is-live=1 ! video/x-raw,width=1920,height=1272,format=I420 ! filesink location=a.yuv

// convert YUV420 to 1910x1272
07_video_convert$ ./video_convert a.yuv 1920 1272 YUV420 b.yuv 1910 1272 YUV420

// encode the YUV420 in 1910x1272
01_video_encode$ ./video_encode b.yuv0 1910 1272 H264 b.264 -br 1024000
01_video_encode$ ll b.264
-rw-rw-r-- 1 nvidia nvidia 379779 Dec 19 07:07 b.264
// 379779 bytes = 3038232 bits(3 seconds) = 1012744 bps

Please give it a try.

Thank you,

Discovered the issue was due to NvBuffer::NvBufferPlaneFormat::bytesperpixel field being overwritten during our conversion step, fixed this and the encoding is working as expected.

1 Like

Ok, maybe final question for this topic,

Lets say I create data in format NV12, when I try to use the video_encode on the raw data I come up on the same issue, is this due to the NV12 format?

gst-launch-1.0 videotestsrc num-buffers=90 is-live=1 ! video/x-raw,width=1920,height=1272,format=NV12 ! filesink location=a.yuv

encode step just for clarity:

./video_encode a.yuv 1920 1272 H264 encoded_test.mp4 -br 102400 --report-metadata

Example frame metadate output. I expect it to be much lower here

Frame 230: isKeyFrame=0 AvgQP=50 MinQP=50 MaxQP=51 EncodedBits=2281936

Note: I am working with 1920x1272 and see this issue

Edit: I changed to use NV12 since it should be supported by encoder

Ok, I see that --sp (semiplanar) option needs to be set in order for this sample to set to raw pixel format NV12 mode in encoder (otherwise it is YUV420) and output seems correct now, but why is this required?

Hi,
If format of frame data is wrong, it is more like encoding white noise so the encoded size may vary in large range.

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