Poor video quality when streaming results via rtp

[ElwoodG]

Hi,

I tried some of the examples and in all got a very low quality result when sending the video via RTP to a linux host. On the receiving end I tried gstreamer as well as mplayer with sdp file (cut and paste). I also saw similar quality when i tried to convert a video on the jetson with video viewer. Is there maybe a default setting wrong? Using the examples with output directories to generate jpgs works fine.

[dusty-nv]

Can you try it from outside container? By building from source, as shown here:

https://github.com/dusty-nv/jetson-inference/blob/master/docs/building-repo-2.md

[ElwoodG]

Apparently it was this. The version built from source outside the container gives Crystal clear pictures. Thanks for Your great work (also on the web-course!)

[dusty-nv]

Thank you, sorry about that, it is an issue I am currently debugging with the containers.

[tkislan]

@dusty-nv Is there something I can help with? I have this set up as both development and later deployment containers .. and video output is really bad I can give a hand by testing different versions of library or whatever the reason for this might be.

[dusty-nv]

@tkislan what would need to be done is to change over gstEncoder.cpp to using these nvv4l2-based encoder elements instead of the current omx-based elements:

nvvideo4linux2:  nvv4l2vp9enc: V4L2 VP9 Encoder
nvvideo4linux2:  nvv4l2vp8enc: V4L2 VP8 Encoder
nvvideo4linux2:  nvv4l2h265enc: V4L2 H.265 Encoder
nvvideo4linux2:  nvv4l2h264enc: V4L2 H.264 Encoder

I haven't had the chance to fully test these (i.e. recording each codec to video file and then streaming RTP, with a variety of test inputs including camera and video files), but they should fix the quality issues inside the container. My thought was to start by enabling them just inside of the container. If you wanted to take a crack at it, that would be great.

[tkislan]

@dusty-nv Didn't help .. i've also double checked the gstreamer version, and it matches the one thats on the device actually

using nvidia encoders cause the pipeline to get stuck, and produces empty size file

[gstreamer] gstEncoder -- pipeline full, skipping frame (7312896 bytes)

using omx encoder, video has correct resolution, but the images looks like it had the 10% resolution this is issue for me when saving it into mp4 file

full gstreamer launch string

appsrc name=mysource is-live=true do-timestamp=true format=3 ! nvv4l2h264enc bitrate=4000000 ! video/x-h264 !  h264parse ! qtmux ! filesink location=garage_camera.mp4

not sure where to look next

[tkislan]

[gstreamer] gstEncoder -- codec not specified, defaulting to H.264
[gstreamer] gstEncoder -- pipeline launch string:
[gstreamer] appsrc name=mysource is-live=true do-timestamp=true format=3 ! nvv4l2h264enc bitrate=4000000 ! video/x-h264 !  h264parse ! qtmux ! filesink location=middle_garden_camera.mp4
[video]  created gstEncoder from file:///usr/src/app/middle_garden_camera.mp4
------------------------------------------------
gstEncoder video options:
------------------------------------------------
  -- URI: file:///usr/src/app/middle_garden_camera.mp4
     - protocol:  file
     - location:  middle_garden_camera.mp4
     - extension: mp4
  -- deviceType: file
  -- ioType:     output
  -- codec:      h264
  -- width:      0
  -- height:     0
  -- frameRate:  30.000000
  -- bitRate:    4000000
  -- numBuffers: 4
  -- zeroCopy:   true
  -- flipMethod: none
  -- loop:       0
------------------------------------------------
[OpenGL] failed to open X11 server connection.
[OpenGL] failed to create X11 Window.
RingBuffer -- allocated 2 buffers (7312896 bytes each, 14625792 bytes total)
[gstreamer] gstEncoder-- starting pipeline, transitioning to GST_STATE_PLAYING
Opening in BLOCKING MODE 
[gstreamer] gstreamer changed state from NULL to READY ==> filesink0
[gstreamer] gstreamer changed state from NULL to READY ==> qtmux0
[gstreamer] gstreamer changed state from NULL to READY ==> h264parse2
[gstreamer] gstreamer changed state from NULL to READY ==> capsfilter2
[gstreamer] gstreamer changed state from NULL to READY ==> nvv4l2h264enc0
[gstreamer] gstreamer changed state from NULL to READY ==> mysource
[gstreamer] gstreamer changed state from NULL to READY ==> pipeline1
[gstreamer] gstreamer changed state from READY to PAUSED ==> qtmux0
[gstreamer] gstreamer changed state from READY to PAUSED ==> h264parse2
[gstreamer] gstreamer changed state from READY to PAUSED ==> capsfilter2
[gstreamer] gstreamer changed state from READY to PAUSED ==> nvv4l2h264enc0
[gstreamer] gstreamer stream status CREATE ==> src
[gstreamer] gstreamer changed state from READY to PAUSED ==> mysource
[gstreamer] gstreamer changed state from READY to PAUSED ==> pipeline1
[gstreamer] gstreamer message new-clock ==> pipeline1
[gstreamer] gstreamer stream status ENTER ==> src
[gstreamer] gstreamer changed state from PAUSED to PLAYING ==> qtmux0
[gstreamer] gstreamer changed state from PAUSED to PLAYING ==> h264parse2
[gstreamer] gstreamer changed state from PAUSED to PLAYING ==> capsfilter2
[gstreamer] gstreamer changed state from PAUSED to PLAYING ==> nvv4l2h264enc0
[gstreamer] gstreamer changed state from PAUSED to PLAYING ==> mysource
[gstreamer] gstEncoder -- new caps: video/x-raw, width=2944, height=1656, format=(string)I420, framerate=30/1
[gstreamer] gstreamer mysource ERROR Internal data stream error.
[gstreamer] gstreamer Debugging info: gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline1/GstAppSrc:mysource:
streaming stopped, reason not-negotiated (-4)
[gstreamer] gstreamer message stream-start ==> pipeline1
[gstreamer] gstreamer changed state from READY to PAUSED ==> filesink0

Here is the log from opening the video output .. unfortunately I don't see any helpful information there

[dusty-nv]

Hi @tkislan , as per this suggestions from the forums, I am now mounting /etc/enctune.conf into the container (see https://github.com/dusty-nv/jetson-inference/commit/68867c5b5d82754daf2979b14cbc4454c3c93eac)

Can you try pulling from master, or applying that same change from https://github.com/dusty-nv/jetson-inference/commit/68867c5b5d82754daf2979b14cbc4454c3c93eac, and confirming that it works for you?

[YoelBerger]

Hi @tkislan , as per this suggestions from the forums, I am now mounting /etc/enctune.conf into the container (see 68867c5)

Can you try pulling from master, or applying that same change from 68867c5, and confirming that it works for you?

I can confim it solve the issue on my setup.

[dusty-nv]

OK great! 👍

[David-VTUK]

I had this issue with a USB camera which was resolved by mounting /etc/enctune.conf. However, this doesn't appear to rectify the issue for CSI cameras. Any ideas @dusty-nv?