H.264 decoding failure

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Greetings!

I’m trying to play video stream from “custom” usb-camera on Jetson Nano (32.3.X and 32.4.2 images) via GStreamer. And run into some weird behaviour of nvv4l2decoder.

Camera is some kind of “black-box” for me. Only know, it produces h.264 encoded video(656x496@60), packed into mpeg-ts protocol.

According to “Accelerated GStreamer user guide”, my pipeline should looks like:

appsrc ! tsdemux ! h264parse ! nvv4l2decoder ! nvdrmvideosink

And it’s only black screen, with no error (or even warnings on codec site) messages. (or transparent window with X and nd3dsink)

There is no proper driver for this camera, so i have to grab stream via libusb api to push it to pipline.

I dumped some stream data to file, for debug purposes, so pipeline is:

gst-launch-1.0 -v filesrc location=out.mp4 ! tsdemux  ! h264parse !  nvv4l2decoder ! nvdrmvideosink

The output is:

nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE 
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4
NvMMLiteOpen : Block : BlockType = 261 
NVMEDIA: Reading vendor.tegra.display-size : status: 6 
NvMMLiteBlockCreate : Block : BlockType = 261 
/GstPipeline:pipeline0/nvv4l2decoder:nvv4l2decoder0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4
/GstPipeline:pipeline0/nvv4l2decoder:nvv4l2decoder0.GstPad:src: caps = video/x-raw(memory:NVMM), format=(string)NV12, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstNvDrmVideoSink:nvdrmvideosink0.GstPad:sink: caps = video/x-raw(memory:NVMM), format=(string)NV12, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.000432402
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

And no video, ofc.

After some experiments i tried to enable enable-frame-type-reporting, and it works! I saw the video.

$ gst-launch-1.0 -v filesrc location=out.mp4 ! tsdemux  ! h264parse !  nvv4l2decoder enable-frame-type-reporting=true ! nvdrmvideosink
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE 
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4
NvMMLiteOpen : Block : BlockType = 261 
NVMEDIA: Reading vendor.tegra.display-size : status: 6 
NvMMLiteBlockCreate : Block : BlockType = 261 
NvMMLiteNVMEDIADecSetAttribute:: Error status reporting set to 1
/GstPipeline:pipeline0/nvv4l2decoder:nvv4l2decoder0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4
/GstPipeline:pipeline0/nvv4l2decoder:nvv4l2decoder0.GstPad:src: caps = video/x-raw(memory:NVMM), format=(string)NV12, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstNvDrmVideoSink:nvdrmvideosink0.GstPad:sink: caps = video/x-raw(memory:NVMM), format=(string)NV12, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
FrameType = P
nActiveRefFrames = 2
Frame 0
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
FrameType = P
nActiveRefFrames = 2
Frame 1
FrameType = P
nActiveRefFrames = 2
Frame 2
FrameType = P
nActiveRefFrames = 2
Frame 3
FrameType = P
nActiveRefFrames = 2
Frame 4
FrameType = P
nActiveRefFrames = 2
Frame 5
FrameType = P
nActiveRefFrames = 2
...

The same result was with enable-error-check=true parameter.

...
New clock: GstSystemClock
ErrorType= 0  Decoded MBs= 1271  Concealed MBs= 0  FrameDecodeTime 572
ErrorType= 0  Decoded MBs= 1271  Concealed MBs= 0  FrameDecodeTime 577
ErrorType= 0  Decoded MBs= 1271  Concealed MBs= 0  FrameDecodeTime 574
...

I saw, there is no I-frames/slices in my stream, so some first frames are “broken”, but it’s fine for me.

The same behaviour was with deprecated omxh264dec. No video with error/frame-type checks set to false and all works fine if any is true.
So, technically, stream is fine and VPU can handle it.

Also, all works fine with software decoding with avdec_h264 (libav). But it uses “avc” stream-format cap, nor byte-stream:

$ gst-launch-1.0 -v filesrc location=out.mp4 ! tsdemux ! h264parse !  avdec_h264 ! nvdrmvideosink
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1002627640028ad0056c0a43fbff007c007b68800000303200000bb87100002d9f800331931e4014001000528de029cb0
Redistribute latency...
/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, pixel-aspect-ratio=(fraction)124/123, width=(int)656, height=(int)496, framerate=(fraction)30/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1002627640028ad0056c0a43fbff007c007b68800000303200000bb87100002d9f800331931e4014001000528de029cb0
/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)mpeg2, colorimetry=(string)bt601, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstNvDrmVideoSink:nvdrmvideosink0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)656, height=(int)496, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)124/123, chroma-site=(string)mpeg2, colorimetry=(string)bt601, framerate=(fraction)30/1
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
...

I try to enable this parameters in code, playback works, but latency was about ~600ms vs ~100ms using software avdec_264, at the same conditions. “sync” parameter of nvdrmvideosink was disabled in both cases.
Also, i try to disable frame type check “on hot”. Stream still playing, debug info output was stopped, but latency was still about ~400-600ms.

So… My questions: Is there any suggestions of codec behaviour? Why it works only with “debug” output parameters? Is there way to decrease latency on hw-decode? (disable-dpb only increase it.) Is there any additional capabilities for decoder tuning?

Thanks in advance for your help.

3

Hi,
It looks like you don;t install nvdisplay driver. Should not see the error on a normal system:

nvbuf_utils: Could not get EGL display connection

Please refer to

4

Thanks for reply!

There is no nvbuf_utils error appears if i use X-subsystem with nv3dsink. Only if i use nvdrmvideosink. But, as i said, codec behavior still the same with X.

Also, it seems logical, that i cant get EGL display, using DRM.

5

I got some additional info via DST_DEBUG:

Verbosity level (GST_DEBUG=*v4l2*:2) gave only one difference between success (enable-frame-type-reporting=true) and failure (enable-frame-type-reporting=false) cases:

v4l2bufferpool gstv4l2bufferpool.c:1535:gst_v4l2_buffer_pool_dqbuf:<nvv4l2decoder0:pool:src>e[00m Driver should never set v4l2_buffer.field to ANY

Not so meaningful, i think…

But Ver level 5 gave me an interesting result:

In failure case:

DEBUG  e[00m e[00m        v4l2videodec gstv4l2videodec.c:1279:gst_v4l2_video_dec_handle_frame:<nvv4l2decoder0>e[00m Handling frame 27
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:2085:gst_v4l2_buffer_pool_process:<nvv4l2decoder0:pool:sink>e[00m process buffer 0x7fa80b5b08
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1642:gst_v4l2_buffer_pool_acquire_buffer:<nvv4l2decoder0:pool:sink>e[00m acquire
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:sink>e[00m release buffer 0x7fa80fcbf0
WARN   e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1491:gst_v4l2_buffer_pool_dqbuf:<nvv4l2decoder0:pool:sink>e[00m v4l2 provided buffer that is too big for the memory it was writing into.  v4l2 claims 1008 bytes used but memory is only 0B.  This is probably a driver bug.
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:sink>e[00m release buffer 0x7fa80b57a0

In success case:

DEBUG  e[00m e[00m        v4l2videodec gstv4l2videodec.c:1279:gst_v4l2_video_dec_handle_frame:<nvv4l2decoder0>e[00m Handling frame 27
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:2085:gst_v4l2_buffer_pool_process:<nvv4l2decoder0:pool:sink>e[00m process buffer 0x7f800d6b08
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:2085:gst_v4l2_buffer_pool_process:<nvv4l2decoder0:pool:src>e[00m process buffer 0x7f7d9f9878
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1642:gst_v4l2_buffer_pool_acquire_buffer:<nvv4l2decoder0:pool:sink>e[00m acquire
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:sink>e[00m release buffer 0x7f800d3bf0
WARN   e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1491:gst_v4l2_buffer_pool_dqbuf:<nvv4l2decoder0:pool:sink>e[00m v4l2 provided buffer that is too big for the memory it was writing into.  v4l2 claims 1008 bytes used but memory is only 0B.  This is probably a driver bug.
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:sink>e[00m release buffer 0x7f800d67a0
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:src>e[00m release buffer 0x7f80012230
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1642:gst_v4l2_buffer_pool_acquire_buffer:<nvv4l2decoder0:pool:src>e[00m acquire
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:2085:gst_v4l2_buffer_pool_process:<nvv4l2decoder0:pool:src>e[00m process buffer 0x7f7d9f9878
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1720:gst_v4l2_buffer_pool_release_buffer:<nvv4l2decoder0:pool:src>e[00m release buffer 0x7f80053400
DEBUG  e[00m e[00m      v4l2bufferpool gstv4l2bufferpool.c:1642:gst_v4l2_buffer_pool_acquire_buffer:<nvv4l2decoder0:pool:src>e[00m acquire

Seems like decoder uses twice more buffers per frame, in success cases. As it was in debug output:

nActiveRefFrames - Number of active frames present in the DPB, according to docs.

How i can set this option? Or it set by gst-plugin via caps?

6

Hi,
Do you observe the issue if you run local video file playback through nvdrmvideosink on Jetson Nano + devkit? Would like to know if it is specific to the custom source.

7

Hi,
Yes, it’s some conflict with source. If i play normal (downloaded from the net) h264-coded video - all’s fine. In any resolution. With any sink. But when i try to playback dumped part of stream - i see this issue. I think, it can be some corrupted metadata in stream. And, as i use appsource, i can parse and fix it “online”. So i need additional info about codec behaviour. Why it can handle stream only in “debug” mode.

8

Well… Seems like, metadata is fine. I found utility, that parse h.264 byte-stream. NAL’s are normal.

Also, the same issue, when i try to decode stream to file. About 130MB raw video with those parameters, and empty file without them.

Seems like, codec ignores num_ref_frames field of SPS NALu for some reason. Or it will always wait for IDR slice, to start decoding?

9

Hi,
To start decoding, decoder requires SPS/PPS NALs to know video information. Also without a complete IDR frame, the rest I/P/B frames cannot be decoded correctly.

10

Hi,
SPS and PPS NAL’s seems fine. I parsed stream via this utility, and all looks normal. SPS and PPS are present and looks valid.

There is a part of parser output:

...
!! Found NAL at offset 166 (0x00A6), size 2 (0x0002) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 0 
0.5: nal->nal_unit_type: 9 
1.8: h->aud->primary_pic_type: 1 
1.5: rbsp_stop_one_bit: 1 
1.4: rbsp_alignment_zero_bit: 0 
1.3: rbsp_alignment_zero_bit: 0 
1.2: rbsp_alignment_zero_bit: 0 
1.1: rbsp_alignment_zero_bit: 0 
!! Found NAL at offset 172 (0x00AC), size 2 (0x0002) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 0 
0.5: nal->nal_unit_type: 9 
1.8: h->aud->primary_pic_type: 1 
1.5: rbsp_stop_one_bit: 1 
1.4: rbsp_alignment_zero_bit: 0 
1.3: rbsp_alignment_zero_bit: 0 
1.2: rbsp_alignment_zero_bit: 0 
1.1: rbsp_alignment_zero_bit: 0 
!! Found NAL at offset 178 (0x00B2), size 38 (0x0026) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 1 
0.5: nal->nal_unit_type: 7 
1.8: sps->profile_idc: 100 
2.8: sps->constraint_set0_flag: 0 
2.7: sps->constraint_set1_flag: 0 
2.6: sps->constraint_set2_flag: 0 
2.5: sps->constraint_set3_flag: 0 
2.4: sps->constraint_set4_flag: 0 
2.3: sps->constraint_set5_flag: 0 
2.2: reserved_zero_2bits: 0 
3.8: sps->level_idc: 40 
4.8: sps->seq_parameter_set_id: 0 
4.7: sps->chroma_format_idc: 1 
4.4: sps->bit_depth_luma_minus8: 0 
4.3: sps->bit_depth_chroma_minus8: 0 
4.2: sps->qpprime_y_zero_transform_bypass_flag: 0 
4.1: sps->seq_scaling_matrix_present_flag: 1 
5.8: sps->seq_scaling_list_present_flag[ i ]: 0 
5.7: sps->seq_scaling_list_present_flag[ i ]: 0 
5.6: sps->seq_scaling_list_present_flag[ i ]: 0 
5.5: sps->seq_scaling_list_present_flag[ i ]: 0 
5.4: sps->seq_scaling_list_present_flag[ i ]: 0 
5.3: sps->seq_scaling_list_present_flag[ i ]: 0 
5.2: sps->seq_scaling_list_present_flag[ i ]: 0 
5.1: sps->seq_scaling_list_present_flag[ i ]: 0 
6.8: sps->log2_max_frame_num_minus4: 1 
6.5: sps->pic_order_cnt_type: 0 
6.4: sps->log2_max_pic_order_cnt_lsb_minus4: 2 
6.1: sps->num_ref_frames: 2 
7.6: sps->gaps_in_frame_num_value_allowed_flag: 0 
7.5: sps->pic_width_in_mbs_minus1: 40 
8.2: sps->pic_height_in_map_units_minus1: 30 
9.1: sps->frame_mbs_only_flag: 1 
10.8: sps->direct_8x8_inference_flag: 1 
10.7: sps->frame_cropping_flag: 0 
10.6: sps->vui_parameters_present_flag: 1 
10.5: sps->vui.aspect_ratio_info_present_flag: 1 
10.4: sps->vui.aspect_ratio_idc: 255 
11.4: sps->vui.sar_width: 124 
13.4: sps->vui.sar_height: 123 
15.4: sps->vui.overscan_info_present_flag: 0 
15.3: sps->vui.video_signal_type_present_flag: 1 
15.2: sps->vui.video_format: 5 
16.7: sps->vui.video_full_range_flag: 0 
16.6: sps->vui.colour_description_present_flag: 0 
16.5: sps->vui.chroma_loc_info_present_flag: 0 
16.4: sps->vui.timing_info_present_flag: 1 
16.3: sps->vui.num_units_in_tick: 100 
20.3: sps->vui.time_scale: 6000 
24.3: sps->vui.fixed_frame_rate_flag: 1 
24.2: sps->vui.nal_hrd_parameters_present_flag: 1 
24.1: hrd->cpb_cnt_minus1: 0 
25.8: hrd->bit_rate_scale: 1 
25.4: hrd->cpb_size_scale: 0 
26.8: hrd->bit_rate_value_minus1[ SchedSelIdx ]: 23358 
29.3: hrd->cpb_size_value_minus1[ SchedSelIdx ]: 13080 
33.8: hrd->cbr_flag[ SchedSelIdx ]: 0 
33.7: hrd->initial_cpb_removal_delay_length_minus1: 12 
33.2: hrd->cpb_removal_delay_length_minus1: 15 
34.5: hrd->dpb_output_delay_length_minus1: 4 
35.8: hrd->time_offset_length: 0 
35.3: sps->vui.vcl_hrd_parameters_present_flag: 0 
35.2: sps->vui.low_delay_hrd_flag: 0 
35.1: sps->vui.pic_struct_present_flag: 1 
36.8: sps->vui.bitstream_restriction_flag: 0 
36.7: rbsp_stop_one_bit: 1 
36.6: rbsp_alignment_zero_bit: 0 
36.5: rbsp_alignment_zero_bit: 0 
36.4: rbsp_alignment_zero_bit: 0 
36.3: rbsp_alignment_zero_bit: 0 
36.2: rbsp_alignment_zero_bit: 0 
36.1: rbsp_alignment_zero_bit: 0 
!! Found NAL at offset 220 (0x00DC), size 5 (0x0005) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 1 
0.5: nal->nal_unit_type: 8 
1.8: pps->pic_parameter_set_id: 0 
1.7: pps->seq_parameter_set_id: 0 
1.6: pps->entropy_coding_mode_flag: 0 
1.5: pps->pic_order_present_flag: 1 
1.4: pps->num_slice_groups_minus1: 0 
1.3: pps->num_ref_idx_l0_active_minus1: 0 
1.2: pps->num_ref_idx_l1_active_minus1: 0 
1.1: pps->weighted_pred_flag: 0 
2.8: pps->weighted_bipred_idc: 0 
2.6: pps->pic_init_qp_minus26: 10 
3.5: pps->pic_init_qs_minus26: 0 
3.4: pps->chroma_qp_index_offset: 0 
3.3: pps->deblocking_filter_control_present_flag: 1 
3.2: pps->constrained_intra_pred_flag: 0 
3.1: pps->redundant_pic_cnt_present_flag: 0 
4.8: pps->transform_8x8_mode_flag: 1 
4.7: pps->pic_scaling_matrix_present_flag: 0 
4.6: pps->second_chroma_qp_index_offset: 0 
4.5: rbsp_stop_one_bit: 1 
4.4: rbsp_alignment_zero_bit: 0 
4.3: rbsp_alignment_zero_bit: 0 
4.2: rbsp_alignment_zero_bit: 0 
4.1: rbsp_alignment_zero_bit: 0 
!! Found NAL at offset 228 (0x00E4), size 18 (0x0012) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 0 
0.5: nal->nal_unit_type: 6 
!! Found NAL at offset 249 (0x00F9), size 1467 (0x05BB) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 1 
0.5: nal->nal_unit_type: 1 
1.8: sh->first_mb_in_slice: 0 
1.7: sh->slice_type: 5 
1.2: sh->pic_parameter_set_id: 0 
1.1: sh->frame_num: 15 
2.4: sh->pic_order_cnt_lsb: 30 
3.6: sh->delta_pic_order_cnt_bottom: 0 
3.5: sh->num_ref_idx_active_override_flag: 0 
3.4: sh->rplr.ref_pic_list_reordering_flag_l0: 0 
3.3: sh->drpm.adaptive_ref_pic_marking_mode_flag: 0 
3.2: sh->slice_qp_delta: -8 
4.1: sh->disable_deblocking_filter_idc: 0 
5.8: sh->slice_alpha_c0_offset_div2: 1 
5.5: sh->slice_beta_offset_div2: 1 
!! Found NAL at offset 1719 (0x06B7), size 4644 (0x1224) 
0.8: forbidden_zero_bit: 0 
0.7: nal->nal_ref_idc: 1 
0.5: nal->nal_unit_type: 1 
1.8: sh->first_mb_in_slice: 41 
2.5: sh->slice_type: 5 
3.8: sh->pic_parameter_set_id: 0 
3.7: sh->frame_num: 15 
3.2: sh->pic_order_cnt_lsb: 30 
4.4: sh->delta_pic_order_cnt_bottom: 0 
4.3: sh->num_ref_idx_active_override_flag: 0 
4.2: sh->rplr.ref_pic_list_reordering_flag_l0: 0 
4.1: sh->drpm.adaptive_ref_pic_marking_mode_flag: 0 
5.8: sh->slice_qp_delta: -8 
6.7: sh->disable_deblocking_filter_idc: 2 
6.4: sh->slice_alpha_c0_offset_div2: 1 
6.1: sh->slice_beta_offset_div2: 1 
...

I only noticed, nal_ref_idc of SPS/PPS NALu is “1” (0x27/0x28 header), in my stream. But most of articles about h264 are recommends to use “3” (0x67/0x68 header). I’ll try to fix it via hex editor, for tests.

Whats about lack of IDR… Yes, first 5-10 frames are broken (green squares), when i use nvv4l2decoder with debug opts. Also, same result with 'avdec_h264 '. So, as i said, technically, decoder can handle this stream. Even without I-slices. But for some reason, there is no output without debug.

11

Well. I reproduced this issue with stream encoded by Jetson itself (via nvh254enc). Seems like, the reason is lack of IDR frames in my stream. I cut all IDR frames in recorded part of stream. And nvv4l2decoder didn’t start to decode without debug options. But, as in my case, all’s fine with debug (except, a bit corrupted image, ofc). So, is there any “force-output” option in gst-plugin or driver?

12

Hi,
It looks like the stream is invalid. Please try to decode it through the sample in

/usr/src/jetson_multimedia_api/samples/00_video_decode

See if the h264 stream can be decoded successfully.

14

Thanks! I’ll try it soon.