So I’ve got a Jetson Orin Nano Super set up with a Siyi A8 Mini, that serves the video through RTSP. I’m however getting weird frame artifacts that keep building up. The camera is mounted on a drone, and when i spin the drone around and the scenery changes radically, it starts working again. But when stationary or moving slowly and the scenery not changing much, frames seem to overlap and pixels “stop changing”.
Here’s an example video:
And here’s how i have it set up:
rtspsrc location=rtsp://192.168.144.25:8554/main.264 latency=100 protocols=tcp buffer-mode=slave
! rtph264depay ! h264parse config-interval=-1
! video/x-h264,stream-format=byte-stream,alignment=au
! mpegtsmux alignment=7
! srtsink uri=“srt://server:8890?streamid=…” latency=500 mode=caller sync=false
The actual pipeline has a tee that also feeds nvv4l2decoder to appsink for on-device inference, but that branch doesn’t touch the stream output…
Any ideas?
Hi,
You may run this command on Orin Nano and check video preview:
$ rtspsrc location=rtsp://192.168.144.25:8554/main.264 latency=100 protocols=tcp buffer-mode=slave ! rtph264depay ! h264parse config-interval=-1 ! nvv4l2decoder ! nvvidconv ! video/x-raw,format=I420 ! xvimagesink sync=0
If video preview is good when running the command, the h264 stream from camera should be good. And the issue may be triggered by re-muxing h264 stream through mpegtsmux plugin.
Thanks for your reply! The decoded preview is clean after 60 seconds. The artifacts only appear after mpegtsmux.
Our stream path is:
h264parse config-interval=-1 ! mpegtsmux alignment=7 ! srtsink
Is there a known issue with mpegtsmux?
Hi,
Not sure if this is known in mpegtsmux of 1.20.3. Would see if other users can share experience.
You may download source code of mpegtsmux and add debug prints. Please check the links in
Mpegtsmux Memory Leak When Muxing KLV Metadata (meta/x-klv) with H.264 Video - #7 by DaneLLL
Hello @maxdrone
Have you tried adding a tsparse element after mpegtsmux? It is a good idea to configure a parser after the muxer, as it can help with MPEG-TS timestamp handling before the stream is sent through SRT
h264parse config-interval=-1 ! mpegtsmux alignment=7 ! tsparse set-timestamps=true ! srtsink ...
It could also be useful to test with a different muxer (for example qtmux or mp4mux) to determine whether the issue is specific to the MPEG-TS path:
h264parse config-interval=-1 ! qtmux ! ...
or
h264parse config-interval=-1 ! mp4mux ! ...
Best regards!
Julian Camacho
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com