I have encountered an issue with video encoded by the Jetson TX2. The videos are being encoded with an h264 “level” of 5.2. This causes many machines with hardware accelerated video decoding to give up on the video.
The following gstreamer pipeline will produce the problematic video:
gst-launch-1.0 videotestsrc ! 'video/x-raw, format=(string)I420, width=(int)256, height=(int)256, framerate=(fraction)30/1' ! omxh264enc bitrate=40000 ! 'video/x-h264, streamformat=(string)byte-stream, barf=(string)2' ! h264parse ! qtmux ! filesink location=test.mp4 -e
and the following command will show the “level” required to decode this simple video:
ffprobe -show_streams test.mp4 | grep level
The Jetson TX1 running an older (unknown) version of the Jetpack will give a similar video a “level” of 2.2 and it will play correctly.
I have recompiled the gstomxh264enc from source and tried changing the seemingly hardcoded “level” to other values with no success. Despite the “level” being set to 2.1 in the code, the output manages to be 5.2.
gstomxh264enc.c, line 620: data = 0x15; // level2.1
How is this 5.2 being set? Is it being calculated based on the encoder inputs? Manually changing the “level” of the problematic video file to a more sane value of 3.0 will allow it to be played by browsers.
To determine if hardware acceleration is being used on the Chrome web browser see chrome://media-internals/, the video_decoder property will be GpuVideoDecoder.
I have only reproduced this on windows machines with Chrome and IE 11 web browsers, no Linux machines I have ready access to can properly use the GpuVideoDecoder. Not all windows machines will use GpuVideoDecoder, some have blacklisted videocard types.
HTML to reproduce issue:
<video controls src="test.mp4"></video>