Mpeg2 tts

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hi All!

I’d like to play a MPEG2-TTS (timestamped TS) camera’s stream on Jetson Nano.

The displayed video is too noisy and broken.

Does anyone have any suggestions for playback well?

Following is the pipeline what I used:
gst-launch-1.0 uridecodebin uri=“udp://239.192.0.20:37004” name=bin ! queue ! nvvidconv ! “video/x-raw(memory:NVMM), format=(string)NV12, width=3840, height=2160, pixel-aspect-ratio=1/1” ! queue ! nvoverlaysink sync=false overlay=1 overlay-x=0 overlay-y=0 overlay-w=3840 overlay-h=2160

Thanks

3

Hi,
For 4K video playback, please do

  1. Execute sudo nvpmodel -m 0 and sudo jetson_clocks
  2. Refer to the post to run VIC engine at maximum clock:
    EGLstream DMA Consumer solutions

And see if there is improvement. Furthermore, you may construct the pipeline manually so that enable-max-performance can be enabled in nvv4l2decoder plugin.

The source looks to be a UDP source and you can refer to the pipelines:
Gstreamer TCPserversink 2-3 seconds latency - #5 by DaneLLL
Nvv4l2decoder sometimes fails to negotiate with downstream after several pipeline re-launches - #16 by DaneLLL

4

Thanks your answer.

I tried the enable-max-performance settings, but the issue is very same.

So this issue looks like decoding error (TTS) not performance error.

5

Hi,
Please try to construct the pipelines manually and check if it is specific to using hardware decoder:

$ gst-launch-1.0 udpsrc ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! avdec_h264 ! xvimagesink sync=0

$ gst-launch-1.0 udpsrc ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! xvimagesink sync=0

Not sure if above commands work since you have mentioned it is MPEG2-TTS stream. Probably need rtpmp2tdepay and tsdemux like:

$ gst-launch-1.0 udpsrc ! rtpmp2tdepay ! tsdemux name=demux ! h264parse ! avdec_h264 ! videoconvert ! xvimagesink

Please give it a try and find out working pipelines. And then clarify if it is specific to using hardware decoder.

6

Hi, here is the responses:

first pipeline:

gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! avdec_h264 ! xvimagesink sync=0
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: The stream is in the wrong format.
Additional debug info:
gstrtph264depay.c(1270): gst_rtp_h264_depay_process (): /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0:
NAL unit type 26 not supported yet
Execution ended after 0:00:10.619273746
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

the second pipeline:

gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! 'application/x-rtp,encoding-name=H264,payload=96' ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! xvimagesink sync=0
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
Stream format not found, dropping the frame
Stream format not found, dropping the frame
Stream format not found, dropping the frame
Stream format not found, dropping the frame
Stream format not found, dropping the frame
Stream format not found, dropping the frame
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:01.198406354
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

the third:

 gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 caps='application/x-rtp,encoding-name=H264,payload=96' ! rtpmp2tdepay ! tsdemux name=demux ! h264parse ! avdec_h264 ! videoconvert ! xvimagesink
WARNING: erroneous pipeline: could not link udpsrc0 to rtpmp2tdepay0

Do you have any suggestion?

7

For the third pipeline, you may try:

gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! application/x-rtp,media=video,encoding-name=MP2T,payload=33,clock-rate=90000 ! rtpjitterbuffer ! rtpmp2tdepay ! tsdemux ! h264parse ! avdec_h264 ! queue ! videoconvert ! xvimagesink

# Or
gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! application/x-rtp,media=video,encoding-name=MP2T,payload=33,clock-rate=90000 ! rtpjitterbuffer ! rtpmp2tdepay ! tsdemux ! h264parse ! nvv4l2decoder ! queue ! nvvidconv ! autovideosink

Maybe for 4K you would have to increase max kernel socket buffer size. You may try with buffer-size property of udpsrc, but the limitation may also be on sender size (udpsink also has a buffer-size property if using gstreamer on sender).

8

Thank you for for your suggestion.

I don’t know why but your pipelines didn’t give any picture.

FYI:
I recorded the issue: https://dexonsystems.com/stuff/2023-08-11_19-36-31.mkv
You can see that at the right side insertion. What I got this issue from these pipelines:
gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! tsdemux ! queue ! h264parse ! queue ! nvv4l2decoder ! queue ! autovideosink
gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! tsdemux ! queue ! h264parse ! queue ! nvv4l2decoder ! queue ! nvvidconv ! nvoverlaysink sync=0
gst-launch-1.0 udpsrc address=239.192.0.20 port=37004 ! tsdemux ! queue ! h264parse ! queue ! avdec_h264 ! queue ! xvimagesink sync=0

The source is a Panasonic Network Camera (AF-KS1131)

Maybe it will be helpful.

9

Probably because I imagined that you were receiving RTPMP2T over udp, but with the last information you’ve provided it seems that you are receiveing raw MP2 TS over UDP. Note that UDP has no control flow and that packets may be lost. Furthermore, multicast may not be the best solution over WiFi if this is your case.

If you can change the sender source, I’d advise to switch either to raw TS streaming over TCP (would be better using matroskamux with streamable=true on sender side and matroskademux on receiver side), or for UDP try RTPMP2T.

Not sure if it might help, but you may also try adding tsparse after tsdemux.

10

If I change the sender source’s packetise method to TS (instead of TTS) then your pipelines are working well.
Unfortunately I need to display TTS Packetise only.
The differences between TS and TTS is the added timestamp. Each packet takes about additional 4 bytes for which parsing is required and it looks like this method is not supported into gstreamer :(

11

I may not be able to further help, I have no experience with MP2 TTS, most of info for it seems for asia and it might be patented so not so available from open source software.

My last suggestion would be trying to set rtpmp2tdepay property skip-first-bytes to 4 in receiver, but I suppose it would discard the TS timestamp. Would be harmless to try, though.

12

Thank you so much indeed for your suggestions. Tell the truth these didn’t work but it was a gstreamer problem or deficiency.
Because the solution come from this patch:

1 Like
13

Glad to see you’ve moved forward despite my unaccurate advice,… I’m still in the learning curve ;-) Thanks for sharing.

1 Like
15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.