I would like to use the Jetson Nano to transcode a number of mpeg transport files to a more bit efficient video encoding using either h.264 or hevc. The appeal of the Jetson Nano is the speed and energy efficiency of the hardware decoder and encoder.
R32 (release), REVISION: 4.2, GCID: 20074772, BOARD: t210ref, EABI: aarch64, DATE: Thu Apr 9 01:22:12 UTC 2020
There seems to be an issue with mpeg transport files (.ts) created by gstreamer on the Jetson Nano. Below are three commands are used to create 3 files. The first file “aomx.ts” is a short mpeg transport file that has the timestamp issues. The second file is “aomx.mp4” which does not show timestamp issues. The third file is “aomxm.ts” transport file created by ffmpeg with “aomx.mp4” as the input file. This third file does not show timestamp issues.
ffmpeg/ffprobe was installed on the Jetson Nano using sources and instructions from:
The timestamp problem in “aomx.ts” shows up on the stderr output when running the command :
ffprobe -show_frames aomx.ts > /dev/null
These timestamp issues seem to be incurring due to the b-frames in the h.264 elementary stream.
Timestamp issues are not reported by ffprobe on the files “aomx.mp4” or the “aomxm.ts”. This appears to show there is a workaround when a mp4 is first created by gstreamer followed by ffmpeg converting the mp4 to a ts file. However, it would be preferable if the gstreamer pipeline could be fixed to create a correct ts file in one step so speed and energy efficiency are not compromised.
gst-launch-1.0 -e videotestsrc num-buffers=600 ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=NV12,framerate=30000/1001,width=1920,height=1080’ ! omxh264enc profile=2 num-B-Frames=2 ! h264parse ! mpegtsmux ! filesink location=aomx.ts
gst-launch-1.0 -e videotestsrc num-buffers=600 ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=NV12,framerate=30000/1001,width=1920,height=1080’ ! omxh264enc profile=2 num-B-Frames=2 ! h264parse ! qtmux ! filesink location=aomx.mp4
ffmpeg -y -i aomx.mp4 -c:v copy aomxm.ts