[Solved] Stream H264 over RTP using nvv4l2h264enc using Gstreamer (Getting corrupted frames)

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hello,

I am trying to stream H264 video captures with my v4l2 device (Microsoft Lifecam HD-3000). The H264 is encoded with the nvv4l2h264enc using Gstreamer.
The Jetson Nano is connected to my laptop (through a switch), in which I hope to decode the video.

In the receiving end I do receive the stream. However, some of the frames appear corrupted. It appears that the i-frames are valid, but some of the p-frames are corrupted.
I used GST_DEBUG=4 (on the receiving end) to see more debug information, and for each frame that looks corruped, I get a message saying:
libav :0:: Got unexpected packet after EOF
libav :0:: Reinit context to 640x480, pix_fmt: yuv420p

The pipelines I used are the following:
Sender:

gst-launch-1.0 v4l2src ! queue ! videoconvert ! video/x-raw, format=BGRx ! nvvidconv ! nvv4l2h264enc insert-vui=1 ! video/x-h264, stream-format=byte-stream, alignment=au ! h264parse ! video/x-h264, stream-format=byte-stream ! rtph264pay pt=96 config-interval=1 ! application/x-rtp, media=video, encoding-name=H264 ! udpsink host=192.168.1.214 port=5555

Receiver:

GST_DEBUG=4 gst-launch-1.0 -v udpsrc port=5555 ! ‘application/x-rtp, encoding-name=H264, payload=96’ ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! xvimagesink

I also tried to stream “videotestsrc” instead, and it too had corrupted frames. When I lowered the resolution to les than 1000x1000 then the corrupted frames were gone. But that’s not really a valid use case.

One last thing to note. I tried to save the H264 video inside an mp4 container, copy it to my laptop, and play it there using Gstreamer, and it played just fine.
Also, lowering the encoder bitrate to 500000 also solves the issue (but gets really low quality).
My current guess is that it has something to do with rtp / udp properties.

I am using the latest image of Jetson Nano. On my laptop I have Ubuntu 18.04.

Does anyone knows what may solve this?
Thank you very much!

2

You may try if omxh264enc instead of nvv4l2h264enc gets better result.

If not, it may be a socket buffer issue.

On receiver end, you may try:

sudo sysctl -w net.core.rmem_max=33554432
sudo sysctl -w net.core.rmem_default=33554432

and if not enough try on sender end:

sudo sysctl -w net.core.wmem_max=33554432
sudo sysctl -w net.core.wmem_default=33554432
3

Hello @Honey_Patouceul,

Thanks for your reply.

Unfortunately it didn’t help. Stream is still corrupted.
Probably losing packets along the way.
I will also try to connect the Jetson directly to my computer (as soon as I can get my hands on an ethernet crossover cable).

Thanks again.
Omer

4

Sorry it didn’t work out.
You may try to add plugin rtpjitterbuffer on receiver end. This may add some latency (2s by default, you may adjust latency option of rtpjitterbuffer):

gst-launch-1.0 -v udpsrc port=5555 ! application/x-rtp, media=video, encoding-name=H264, payload=96 ! rtpjitterbuffer ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! xvimagesink
5

OK so after about a week of struggling with this issue, I finally found that the problem was caused by the packet size.

I lowered the mtu to 700 and the problem went away. I still get some packet lost every now and then but MUCH MUCH less often… Something like every ~5 minutes. I guess I can lower the packet size even more and see if it helps, but I can live with the current result.

So hopefully this will help anyone who suffer from this in the future.

Thanks @Honey_Patouceul for your help.