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