Mpeg ts output created with invalid timestamps using gstreamer

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.

cat /etc/nv_tegra_release

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:
https://github.com/jocover/jetson-ffmpeg"

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

Some further details:

A problem with timestamps also exists when using the ffmpeg patched for the Jetson Nano. The command below which encodes with b-frames shows the dts timestamp warnings during operation. Both the ffmpeg command and the resulting ffmpeg stderr output are shown below. The ffmpeg command runs terribly slow (about 1/4 of realtime). The timestamps in the ffmpeg output file nvmpi_bf2.ts look okay.

ffmpeg -y -f lavfi -i “testsrc=duration=10:size=1920x1080:rate=30000/1001” -c:v h264_nvmpi -bitrate 3000000 -g 15 -bf 2 nvmpi_bf2.ts

a sample of ffmpeg stderr output:

[mpegts @ 0x5573e8c830] Non-monotonous DTS in output stream 0:0; previous: 846847, current: 843843; changing to 846848. This may result in incorrect timestamps in the output file.
[mpegts @ 0x5573e8c830] Non-monotonous DTS in output stream 0:0; previous: 852852, current: 849849; changing to 852853. This may result in incorrect timestamps in the output file.
[mpegts @ 0x5573e8c830] Non-monotonous DTS in output stream 0:0; previous: 864864, current: 858858; changing to 864865. This may result in incorrect timestamps in the output file.
[mpegts @ 0x5573e8c830] Non-monotonous DTS in output stream 0:0; previous: 864865, current: 861861; changing to 864866. This may result in incorrect timestamps in the output file.

Hi,
We are deprecating omx plugins.Please check 5.12 in release note.
Suggest you try v4l2 plugins such as nvv4l2h264enc.

Thanks for the quick response.

nvv4l2h264enc has the same issue. Somewhat makes sense since the Jetson Nano ffmpeg source code shows calls to nvenc that are close to the encoder sample application and the Jetson Nano ffmpeg seems to have a similar problem with pts/dts.

Where are the sources to the Jetson Nano’s gstreamer plugins? I’d rather focus on gstreamer than looking at the problem in the Jetson Nano ffmpeg port.

Below is the command used to create “a.ts” which shows the same problem as “aomx.ts” from my earlier post.

gst-launch-1.0 -e videotestsrc num-buffers=600 ! nvvidconv ! ‘video/x-raw(memory:NVMM),framerate=30000/1001,width=1920,height=1080’ ! nvv4l2h264enc profile=2 num-B-Frames=2 ! h264parse ! mpegtsmux ! filesink location=a.ts

Hi,
r32.4.3 is published. Please upgrade and check if the issue is still there. And gst-v4l2 is open source. You can download it from
https://developer.nvidia.com/embedded/L4T/r32_Release_v4.3/Sources/T210/public_sources.tbz2