Degraded H.264 encoding quality with docker and OpenMAX

[shahar_s]

I know that docker support is still considered experimental, just wanted to find out if this is a known issue or if I am missing something.

I am using a Jetson TX2 dev board with Jetpack 4.3 (recently flashed) and installed the l4t-base:r32.3.1 and deepstream-l4t:4.0.2-19.12-samples images.

I am running the following pipeline* on both the host and the docker container:

gst-launch-1.0 -e videotestsrc num-buffers=300 ! timeoverlay ! \
 'video/x-raw, format=(string)I420, width=(int)1280, height=(int)720' ! \
 omxh264enc bitrate=8000000 ! \
 'video/x-h264, stream-format=(string)byte-stream' ! h264parse ! \
 qtmux ! filesink location=$FILE -e

When I look at the output video created in the docker container, the encoded quality is much lower than one created by the host machine. I can also see that in the file size:

$ ls -l videotestsrc_*.mp4
-rw-r--r-- 1 root root  612163 Feb 17 13:24 videotestsrc_docker.mp4
-rw-rw-rw- 1 slt  slt  5876646 Feb 17 13:24 videotestsrc_host.mp4

Downloads: docker output, host output.

This is how I run the docker container:

docker run -it --rm --net=host --runtime nvidia -e DISPLAY=:1 \
  -v /tmp/.X11-unix/:/tmp/.X11-unix \
  -v /tmp/argus_socket:/tmp/argus_socket \
  -v $PWD:/workdir \
  nvcr.io/nvidia/l4t-base:r32.3.1

I tried running the pipeline with GST_DEBUG=omx*:4 but did not see any difference in the output. I also tried the deepstream-l4t image just in case but got the same results.

Any ideas what is going on? Am I missing a configuration option in omxh264enc or the docker container itself? Thanks!

*I also tried the following pipeline to make sure it’s not an issue with videotestsrc:

gst-launch-1.0 -e nvarguscamerasrc ! \
  'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! \
  nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)I420' ! omxh264enc bitrate=8000000 ! \
  'video/x-h264, stream-format=(string)byte-stream' ! \
  h264parse ! qtmux ! filesink location=$FILE -e

[DaneLLL]

Hi,
Please try nvv4l2h264enc. We are deprecating omx plugins. Please check if the issue is also seen with using v4l2 plugins.

[shahar_s]

Thanks a lot for the tip. I am not experiencing this issue with nvv4l2h264enc.

[kmi.samhong]

Hi
I met the same issue on jetson docker.
Did u fix this issue?
Thanks

[kislan.tomas]

This is not really a solution, as it doesn’t work for me.
Pipeline outputs empty file, and it seems that it gets stuck somewhere, because stdout is full of following messages:
[gstreamer] gstEncoder – pipeline full, skipping frame (7312896 bytes)

Just FYI, when using jpeg gstreamer encoder, the quality is fine

[kislan.tomas]

Also, will leave the link to github issue here, because there are some discussions there as well

Poor video quality when streaming results via rtp

[DaneLLL]

Hi,
The pipeline looks not right. It should be

appsrc name=mysource is-live=true do-timestamp=true format=3 ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' !  nvv4l2h264enc bitrate=4000000 ! video/x-h264 !  h264parse ! qtmux ! filesink location=middle_garden_camera.mp4

And the resolution looks to be 2944x1656. 4Mbps may be too small for this resolution.

[kislan.tomas]

It doesn’t seem so, now it fails even sooner.

[gstreamer] gstEncoder -- pipeline launch string:
[gstreamer] appsrc name=mysource is-live=true do-timestamp=true format=3 ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' ! nvv4l2h264enc bitrate=4000000 ! video/x-h264 ! h264parse ! qtmux ! filesink location=garden_camera.mp4

(python3:18603): GStreamer-CRITICAL **: 07:56:27.346: gst_element_make_from_uri: assertion 'gst_uri_is_valid (uri)' failed
[gstreamer] gstEncoder -- failed to create pipeline
[gstreamer]    (syntax error)
[gstreamer] gstEncoder -- failed to create encoder engine

[mark.goodall]

I’ve discovered a similar issue, but with omxh265 ignoring the bitrate parameter inside of a docker image. The solution was to mount /etc/enctune.conf into the docker image. It seems like without this file it only uses the default parameters

[abdo.babukr1]

sweet! thanks @mark.goodall