TX2 h264 encoded videos will not play in web browsers

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[3] = 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.

Additional info:
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>

Please refer to patch below:

diff --git a/omx/gstomxh264enc.c b/omx/gstomxh264enc.c
index 99d1ddb..dafae03 100644
--- a/omx/gstomxh264enc.c
+++ b/omx/gstomxh264enc.c
@@ -768,6 +768,7 @@ gst_omx_set_avc_encoder_property (GstOMXVideoEnc * enc)
     oH264Type.nBFrames = self->nBFrames;
     oH264Type.nSliceHeaderSpacing = self->slice_header_spacing;
     oH264Type.eProfile = self->profile;
+    oH264Type.eLevel = OMX_VIDEO_AVCLevel22;

     eError =
         gst_omx_component_set_parameter (GST_OMX_VIDEO_ENC (self)->enc,

Thanks for the speedy response DaneLLL, the patch works perfectly.

Will this change make it’s way into a future version of the Jetpack/L4T or apt-get repo?

We will check and update.

We support it on r28.2. Below command is for reference.

gst-launch-1.0 filesrc location=park_joy_1080p50.y4m  ! y4mdec ! 'video/x-raw,framerate=50/1' ! omxh264enc profile=high ! 'video/x-h264,<b>level=(string)4.2</b>' ! qtmux ! filesink location=test.mov

is it possible to stream the video without writing file to disk?

gst-launch-1.0 filesrc location=park_joy_1080p50.y4m  ! y4mdec ! 'video/x-raw,framerate=50/1' ! omxh264enc profile=high ! 'video/x-h264,level=(string)4.2' ! qtmux ! filesink location=test.mov

Yo may use udpsink:
Or test-launch to run a rtsp server: