Nv gst plugin decode h264 abnormal

I have found some h264 files can not be decode by nv gst plugin normally on TX2.
When I try to decode the h264 file ,I will get some almost black pictures.
However the h264 file can be decoded well by using ffmpeg or gstreamer on x86 ubuntu16.04.
The problem can be reproduced on both R32.2.1 and R28.2.1
The gstreamer pipeline is :
gst-launch-1.0 filesrc location=1.h264 ! h264parse ! omxh264dec ! nvjpegenc ! multifilesink location=%04d.jpg
On x86 ubuntu, the ffmpeg and gstreamer pipeline are:
ffmpeg -i 1.h264 %04d.jpg
gst-launch-1.0 filesrc location=1.h264 ! h264parse ! adec_h264 ! jpegenc ! multifilesink location=%04d.jpg

The h264 file link
https://pan.baidu.com/s/1ESNyIDuTCCGSgfld6Y7B_g
passwd:ocnc

Not sure, but the problem might be with nvjpegenc.
Does the following improve ?

gst-launch-1.0 filesrc location=1.h264 ! h264parse ! omxh264dec ! jpegenc ! multifilesink location=%04d.jpg

#or
gst-launch-1.0 filesrc location=1.h264 ! h264parse ! nvv4l2decoder ! jpegenc ! multifilesink location=%04d.jpg

jpegenc and nvv4l2decoder no improove.

Does avdec_h264 work on Jetson ?

it doesn’t appear possible to download from baidu url without logging in.
can you upload to some other filehosting service?

avdec_h264 work well on Jetson

please try this link
http://u.163.com/5L9BYTlC
passwd: vVY3Zvi4

 gst-launch-1.0 filesrc location=1.h264 ! h264parse ! avdec_h264 ! xvimagesink

it plays at jetson Xavier;
At the moment I do not have access to tx2 to test with

please try this:
gst-launch-1.0 filesrc location=1.h264 ! h264parse ! omxh264dec ! nvjpegenc ! multifilesink location=%04d.jpg

 gst-launch-1.0 filesrc location=1.h264 ! h264parse ! omxh264dec ! nvjpegenc ! multifilesink location=%04d.jpg
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_caps_truncate: assertion 'GST_IS_CAPS (caps)' failed

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_caps_fixate: assertion 'GST_IS_CAPS (caps)' failed

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_caps_get_structure: assertion 'GST_IS_CAPS (caps)' failed

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_structure_get_string: assertion 'structure != NULL' failed

(gst-launch-1.0:29000): GStreamer-CRITICAL **: 19:23:59.862: gst_mini_object_unref: assertion 'mini_object != NULL' failed
NvMMLiteOpen : Block : BlockType = 261 
NVMEDIA: Reading vendor.tegra.display-size : status: 6 
NvMMLiteBlockCreate : Block : BlockType = 261 
Allocating new output: 4096x2160 (x 12), ThumbnailMode = 0
OPENMAX: HandleNewStreamFormat: 3605: Send OMX_EventPortSettingsChanged: nFrameWidth = 4096, nFrameHeight = 2160 
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:01.862438998
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

 ls
0000.jpg  0019.jpg  0038.jpg  0057.jpg  0076.jpg  0095.jpg  0114.jpg  0133.jpg
0001.jpg  0020.jpg  0039.jpg  0058.jpg  0077.jpg  0096.jpg  0115.jpg  0134.jpg
0002.jpg  0021.jpg  0040.jpg  0059.jpg  0078.jpg  0097.jpg  0116.jpg  0135.jpg
0003.jpg  0022.jpg  0041.jpg  0060.jpg  0079.jpg  0098.jpg  0117.jpg  0136.jpg
0004.jpg  0023.jpg  0042.jpg  0061.jpg  0080.jpg  0099.jpg  0118.jpg  0137.jpg
0005.jpg  0024.jpg  0043.jpg  0062.jpg  0081.jpg  0100.jpg  0119.jpg  0138.jpg
0006.jpg  0025.jpg  0044.jpg  0063.jpg  0082.jpg  0101.jpg  0120.jpg  0139.jpg
0007.jpg  0026.jpg  0045.jpg  0064.jpg  0083.jpg  0102.jpg  0121.jpg  0140.jpg
0008.jpg  0027.jpg  0046.jpg  0065.jpg  0084.jpg  0103.jpg  0122.jpg  0141.jpg
0009.jpg  0028.jpg  0047.jpg  0066.jpg  0085.jpg  0104.jpg  0123.jpg  0142.jpg
0010.jpg  0029.jpg  0048.jpg  0067.jpg  0086.jpg  0105.jpg  0124.jpg  0143.jpg
0011.jpg  0030.jpg  0049.jpg  0068.jpg  0087.jpg  0106.jpg  0125.jpg  0144.jpg
0012.jpg  0031.jpg  0050.jpg  0069.jpg  0088.jpg  0107.jpg  0126.jpg  0145.jpg
0013.jpg  0032.jpg  0051.jpg  0070.jpg  0089.jpg  0108.jpg  0127.jpg  0146.jpg
0014.jpg  0033.jpg  0052.jpg  0071.jpg  0090.jpg  0109.jpg  0128.jpg  0147.jpg
0015.jpg  0034.jpg  0053.jpg  0072.jpg  0091.jpg  0110.jpg  0129.jpg  0148.jpg
0016.jpg  0035.jpg  0054.jpg  0073.jpg  0092.jpg  0111.jpg  0130.jpg  0149.jpg
0017.jpg  0036.jpg  0055.jpg  0074.jpg  0093.jpg  0112.jpg  0131.jpg  0150.jpg
0018.jpg  0037.jpg  0056.jpg  0075.jpg  0094.jpg  0113.jpg  0132.jpg  1.h264

Please check and view the output pictures, 0011.jpg ~ 0047.jpg are abnormal pictures on my TX2.

yes, I can confirm the issue at my device;
0011.jpg → 0.047jpg are black;
0001->0010 & 0048->0150 shows road images
the video duration is 0:00:06.051384496
will the issue repeat if you take another recording?
may be it is just 1.7 seconds where a lag has taken place on recording device? which resulted in black frames?
otherwise seems an issue related to codecs

There is a another h264 file. 0008.jpg~0048.jpg are wrong pictures.
http://u.163.com/ZYsVgaBu passwd: BSHtqNVz
How to make the omxh264dec work well like avdec_h264 in this case?

I don’t understand the root cause, but in my case decoding your file on host with avdec_h264 or with ffmeg does produce same black images.
On the other hand, both do work on my Xavier.
I see different versions of used libs, so I guess a bug has been fixed or a new feature got supported.

BTW, the following pipelines with hw h264 decoding work for me:

gst-launch-1.0 -v filesrc location=1.h264 ! h264parse ! nvv4l2decoder ! nvvidconv ! jpegenc ! multifilesink location=%04d.jpg

gst-launch-1.0 -v filesrc location=1.h264 ! h264parse ! nvv4l2decoder ! nvvidconv ! 'video/x-raw(memory:NVMM), format=I420' ! nvjpegenc ! multifilesink location=%04d.jpg

What is the L4T version of your jetson please?

head -n1 /etc/nv_tegra_release 
# R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t186ref, EABI: aarch64, DATE: Tue Dec 10 07:03:07 UTC 2019