Jetson Nano multimedia API example 01_encoder with gdr

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
#1

I’ve tried to run an encoder from Multimedia API samples/01_video_encode with the following command line:

./video_encode input.yuv 1920 1080 H265 output.h265 --egdr -gdrf params.conf --input-metadata

while param.conf includes text with numbers “first_frame first_frame-1” lets say “11 10”

The gdr made wrong number of slices (2 or 3 each frame) and always put the “I” slice at the same position (second).

Do you have any idea what I’ve done wrong?
Maybe do you know some example I can learn from?

Thanks for future help :)

#3

Hi,
Please share detail about your usecase. The function is advancing and in general usecases, we suggest use basic encoding functions.

And please share your release version( $ head -1 /etc/nv_tegra_release ), device information( 4GB/2GB, SD card/emmc ).

#4

/etc/nv_tegra_release
R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t210ref, EABI: aarch64, DATE: Tue Dec 10 06:58:34 UTC 2019

4GB RAM , 16GB mmc , no SD.

My usecase’s require spliting the I-frame into slices (slice each frame for N frames) in order to reduce decode delay and avoid skipping.

Is my param.conf file is correct?
Do I need to enable or set any other feature or property?
Any flag missing at cmd line?

Thanks,

#5

Hi,
Please try

01_video_encode$ cat gdr_params.txt
4 11

01_video_encode$ ./video_encode 320.yuv 320 240 H264 test.h264 --egdr -gdrf gdr_params.txt --input-metadata -gdrof gdr_out.h264

And check gdr_out.h264

#6

I don’t have a proper tool to check h264 encoding with GDR.
of course the output h264 is playable, but I don’t know how the GDR affected the I and P frames.
I tried with “4 11” and H265 - got “test.h265” and “gdr_out.h265” which are differ but the same final result in both files when analyzing the GDR.
The result is 2 or 3 slices per frame , I-frame is always second.

I expect the GDR will create 11 slices (starting with frame 4) and the I-frame’s location will rotate.

#7

Hi,
It looks like there is no free bitstream analyzer. A possible way is to check the picture type and packet size through ffprobe. We can encode two streams:

01_video_encode$ ./video_encode /home/nvidia/test.i420 1280 720 H264 test.h264 --egdr -gdrf gdr_params.txt --input-metadata -gdrof gdr_out.h264
01_video_encode$ ./video_encode /home/nvidia/test.i420 1280 720 H264 test_1.h264

And run the command:

$ ffprobe -i test.h264 -show_frames | grep 'pict_type\|pkt_size'
$ ffprobe -i test_1.h264 -show_frames | grep 'pict_type\|pkt_size'

The picture type and packet size of frames are different between the two stream. However, for accurate check , you may need to get a bitstream analyzer.

#8

I checked the h265 and h264 with analyzing tools inserting many different params in the GDR conf file.

My conclusions so far:

  1. the gdr_start_frame_number param works fine for both encoders
  2. the gdr_num_frames split the h264 to correct number of slices
  3. h265 does not affected by gdr_num_frames and always split the frame to 2 or 3 slices - I/P or P/I/P
  4. for both encoders the cycle is always 6 slices no matter what gdr_num_frames I choose - it means that if the gdr_num_frames is bigger than 6 (lets say 10) only 6 of 10 slices will be shown, and the other 4 will get not enough data (stays green on display).

Is there a way to configure it differently or ‘6’ is hard coded and cannot be changed?
Why the H265 does not split to slices like the h264?

Thanks,

#9

Hi,
Please set the two options to large value such as 1000 and try:

        -ifi <interval>       I-frame Interval [Default = 30]
        -idri <interval>      IDR Interval [Default = 256]

IDR/I frame interval may impact the function.

#10

the problem remains with -ifi 1000 -idri 1000

In the following examples I display the output from the -gdrof file, the outcome is similar to the standard output file.

for h264:
17 slices - I-frame cycle with only first 6

image
image1197×670 140 KB

for h265:
it seems like the I-frame “knows” there are 17 slices - cycle with only first 6. the P-frames are always the rest of the picture - not sliced into the other 6 but only 1/2 P-frames each Frame.

image
image1109×635 305 KB

h265 from another encoder:
you can see how it sliced into 17 - the I-frame cycle between all.
in this example I took the 15th Frame so the last two still green.

image
image1110×637 427 KB

Which property suppose to affect the slices cycle (which is now constant 6)?

#11

Hi,
So are you able to use H264 encoding with gdr_num_frames=6? This looks to be only working solution on JP4.4.1. Or you must use H265 encoding with gdr_num_frames=10 in your usecase?

#12

Hi,
Yes, H264 with gdr_num_frames=6 works.
For my usecase I must use H265 with gdr_num_frames=17.

I’m using JP4.3 actually - future JP will solve this issue? is there an estimated release date?

#14

Hi,
We will check this. Since the function is advancing, the investigation may take some time. On current release(s), we suggest use the working case in h264. For h265, instead of enabling GDR, we suggest try to set virtual buffer size in CBR mode:

        -vbs <size>           Virtual buffer size [Default = 0]

You can refer to the gstreamer pipelines and apply the setting to 01_video_encode:

1 Like