Gstreamer H.264 video not showing up on Windows Computer

[altamimisajad0]

I have tried multiple solutions to get H.264 video to get to a windows computer. Both systems are connected to Wi-Fi and both ports in both scripts use the same port. I am also using the correct IP address for target pc which is the windows IPv4 IP address. Here is what I am getting:

Jetson Pipeline:

gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM),width=(int)1640, height=(int)1232, framerate=(fraction)30/1' ! nvvidconv flip-method=2 ! 'video/x-raw, width=(int)820, height=(int)616, format=(string)I420' ! omxh264enc control-rate=2 bitrate=4000000 ! video/x-h264, stream-format=byte-stream ! rtph264pay ! udpsink host=[redacted] port=5009 sync=false

Jetson Output:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4 
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4 
H264: Profile = 66, Level = 40 
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3264 x 2464 FR = 21.000000 fps Duration = 47619048 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 3264 x 1848 FR = 28.000001 fps Duration = 35714284 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1920 x 1080 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1640 x 1232 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1280 x 720 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1280 x 720 FR = 120.000005 fps Duration = 8333333 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: Running with following settings:
   Camera index = 0 
   Camera mode  = 3 
   Output Stream W = 1640 H = 1232 
   seconds to Run    = 0 
   Frame Rate = 29.999999 
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.

Windows computer pipeline:

gst-launch-1.0 -v udpsrc port=5009 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! openh264dec ! videoconvert ! autovideosink sync=false

Windows computer output:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96
/GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96
Setting pipeline to PLAYING ...
New clock: GstSystemClock

I am currently in a pretty narrow deadline working with this, please be quick if you could. I will be available at my workplace to see the forums from 2:30 and after at the New York timezone.

Thanks.

[proventusnova]

Hello @altamimisajad0,

We have seen similar issues when trying to capture a UDP stream on a MAC.
In our case, it was the MAC’s firewall which was causing the problems.

Would it be possible for you to check if you have any firewalls enabled on your Windows computer?

Also, another test you can use to verify the host pipe is to run both pipes on the Jetson. That way you would verify that the Jetson pipe is working as expected.

Finally if you had access to a linux PC or another linux system such as another Jetson board, you should be able to test the receiving pipeline.

Please keep us posted on your test results.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

Embedded Software Engineering Support - Proventus Nova

[altamimisajad0]

I have a firewall on but it allows allowed applications through and gst-launch-1.0 is included.

[proventusnova]

Hi @altamimisajad0,

Thanks for getting back so quickly.

Understood. I would still test disabling the Firewall altogether just so you can be 100% sure that is not the issue.

Also, I would suggest you try capturing the stream with a different application, VLC for example, that way you can also make sure is not only GStreamer on Windows that is causing the issue.

I have a Windows machine but does not have GStreamer installed.
I will try to take some time to install it and test your pipelines, hopefully I can replicate the behavior.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

Embedded Software Engineering Support - Proventus Nova

[altamimisajad0]

These setups show nothing has changed, I am using my phone to get my Jetson connected to the WiFi and when I start streaming on my Jetson the data bandwidth usage rockets to 1MB/a which means there are no errors on the Jetson side.

[DaneLLL]

Hi,
Please use nvv4l2h264enc plugin since omx plugins are deprecated. And please try this setup:
Jetson Nano FAQ

The latest release for Jetson Nano is Jetpack 4.6.6. If you use previous version, may consider upgrade to latest version.

[altamimisajad0]

I will try that but OpenMax H.264 encoding worked extremely well with the Jetson and I could see the video result using that encoding when using a pipe on the Jetson with that and avdec_264. I don’t think it’s really and Encoding issue.

[altamimisajad0]

I used your examples, here is what I got:

I could tell something is wrong with the sink since the Gstreamer (version 1.16.3) I have installed does not have xvimagesink so I tried to use autovideosink and the fact that my computer is receiving a consistent 4 Mbps during streaming.

[altamimisajad0]

I am also getting the same thing with the same omxh264enc pipeline that I was using when I posted.

This is definitely a problem with the windows computer.

[altamimisajad0]

It seems that when I am using intervideosink, the pipeline tries to work but we need a queue of some sort.

[altamimisajad0]

Ok, I finally managed to get video with making sure everything is ok and I used autovideosink. But it seems to be very laggy and blocky. It’s nothing like how it shows up on the Jetson internally. I updated the windows pipeline with:

gst-launch-1.0 udpsrc port=5009 ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! queue2 ! h264parse ! avdec_h264 ! videoconvert ! autovideosink sync=false

[DaneLLL]

Hi,
If you observe the same issue in using videotestsrc plugin, it is very likely the network bandwidth is insufficient or not stable. If using videotestsrc plugin is good and see corruption with nvarguscamerasrc, it looks like the camera source does not generate frame data correctly. You may break down the pipeline to check further.

[altamimisajad0]

It may have something to do with how UDP streaming is done/the network itself; the camera source already generates frame data extremely consistently without any images being lost when I use appsink on the Jetson. I don’t think streaming encoded data affects the camera source compared to using appsink in the Jetson.