I will try my luck again, There is some problem that I do not succeed to solve first I will describe my setup:
- my computer (windows)
- jetson orin nx
- another windows computer with MPVplayer (some aplication).
** All the computers/jetson connect to the hub.
I do 2 experiments the first I play rtp video from my jetson in multicast with the following pipeline :
gst-launch-1.0 videotestsrc ! jpegenc ! queue ! nvv4l2decoder mjpeg=1 ! nvv4l2h264enc insert-sps-pps=1 idrinterval=15 ! mpegtsmux ! rtpmp2tpay ! udpsink host=126.96.36.199 port=46002
I see the video in the MPVplayer in addition I receive the video on my jetson orin with this pipeline :
gst-launch-1.0 -v udpsrc uri=udp://188.8.131.52:46002 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T, payload=(int)33" ! rtpmp2tdepay ! tsdemux ! queue ! h264parse ! nvv4l2decoder enable-max-performance=1 ! nvvideoconvert ! autovideosink
Now all the time I capture the packets and save them in a pcap file using Wireshark on my computer. In the second experiment, I take the recorded pcap and play am with Colsoft the mpv player again succeed to see the video but for some reason my jetson orin with exactly the same pipeline that sucssed last time not sucssed to show the video what is can be?
I thing maybe timiing problem or loss packets but still why the jetson so sensteive to this situation and how I can modify my reciver pipeline to handle with this problem?
I will be happy to any help thanks.
Just to clarify: you play the recorded pcap file on your windows computer(1), and the pipeline on the other computer(3) with MPVplayer can receive the stream and display correctly, right?
The jetson runs the second pipeline but cannot play video.
- Can you use wireshare or tcpdump to capture the packat? Ideally the multicast packets shoudl arrive on the Jetson Orin NX
- I’m wondering it is related with the source MAC of the Ethernet frames arrived on you Orin NX, which should be the same MAC as MAC address of the Orin NX’s NIC, this seems to be a wrong condition.
Yes, you describe it right.
I attached images from Wireshark one from Windows computer(3) and one from Jetson (2). I am not really sure where I see the MAC I think that I see it in Jetson NVIDIA IPv4mcast.
I hope you will succeed to help me I try anything a long 10 days.
Maybe you need check with networking expert, imho this is an Ethernet loopback condition and the frame is discarded in Orin NX’s NIC, you can check ifconfig to see if it has RX error or drops statistics.
Hi thank you for the reply, Unfortunately, I am not so expert I will be very happy if you can give me more details or instructions on how I can tackle this problem.
I will mention again my setup of two Windows computers and one Jetson orin connected to the hub so I am in some “close system”.
In general, I am not sure that the problem is drop packets because I succeed in a Windows computer using an MPV player to open the stream but I will be happy to check your direction.
I try ifconfig but I see a frozen screen how I can continue from here if the problem is drop packets, and if you are right what I can do to solve this problem?
I want you to pay attention to one thing if you look at the image of the Wireshark screen from the Nvidia jetson you can see in the info the message:
MP2T fragment of a reassembled packet
I am not sure what it means but in the Wireshark on Windows computer, everything looks fine.
thank you for helping me.
I try the following experiemnt just take from udpsrc to .ts file with the following pipeline:
gst-launch-1.0 -v udpsrc uri=udp://184.108.40.206:46002 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T, payload=(int)33" ! rtpmp2tdepay ! filesink location=received_packets.ts
and for some reason, it looks like nothing since the size of the file is always 0.
For UDP streaming, please refer to the setup in Jetson Nano FAQ
It shall work on either Jetson platform. Please try and see if you can run it successfully.
I sucssed to capture UDP stream using the setup.
I run your example and I sucssed to capture video
gst-launch-1.0 videotestsrc is-live=1 ! video/x-raw,width=1280,height=720 ! timeoverlay valignment=4 halignment=1 ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1280,height=720' ! tee name=t ! nvv4l2h264enc insert-sps-pps=1 idrinterval=15 ! h264parse ! rtph264pay ! udpsink host=220.127.116.11 port=46002 sync=0
gst-launch-1.0 udpsrc port=46002 ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! nvv4l2decoder enable-max-performance=1 ! nvvidconv ! autovideosink
still how It’s helped me to solve my strange problem?
You may apply the same to your use-case and try. It may be better to encode into h264 or h265. The compression ratio is better than JPEG.
unfortunately, I can’t change it.
I make to myself this sample example because in the future someone send my MPEG2 video in RTP and I need to capture this stream.
I think this is a very strange problem because if you read my first message in the post you pay attention that I succeed to capture the video and display on the screen, in the same time (parallel) I use Wireshark on a Windows computer to capture udp packets then when I play again the same video in windows computer I succeed but in jetson No. I do not understand what it can be I will be happy to get any help or idea on how I can tackle this problem I work on this for 10 days.
when I run this command:
gst-launch-1.0 udpsrc uri=udp://18.104.22.168:46002 ! queue ! filesink location=~/Downloads/captured_packets.pcap
and play PCAP that is not RTP everything works great, but when I play the same pipeline on a PCAP file with RTP I capture nothing 0-size pcap I do not succeed to understand this problem maybe you have any idea?
gst-launch-1.0 udpsrc uri=udp://22.214.171.124:46002 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T, payload=(int)33" ! rtpmp2tdepay ! tsdemux ! queue ! h264parse ! nvv4l2decoder enable-max-performance=1 ! nvvideoconvert ! autovideosink
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.