Demuxing/Muxing MPEG-2 source leads to pixelated video output on udpsink

Application Development
1

Hello,

When I run this pipeline:

  • gst-launch-1.0 udpsrc uri=udp://(source) ! queue ! tsdemux ! video/mpeg, mpegversion=2, systemstream=false, parsed=true ! mpegtsmux alignment= 7 ! queue ! udpsink host=127.0.0.1 port=8888 buffer-size=100000

The video output when viewing it on VLC comes out to be really pixelated and stutters. For context the output is only bad when the udpsrc is an MPEG-2 source. When demuxing and muxing MPEG-4 or H.264 everything comes out great. I was wondering if their would be a way to figure out why video is coming out like? I tried utilizing --gst-debug but the only thing that shows on the log is Continuity details.

2

What kind of bitrate are we talking about?

First step would be to figure out if it’s an issue on the receiving / udpsrc side, with the transmuxing, or on the sending / udpsink side.

You could do that by writing to a file with filesink location=foo.ts and checking if that plays back fine or also has problems.

Have you already tried an mpegvideoparse Instead of the capsfilter between your demuxer and muxer ?

3

Yeah I tried saving the output to a filesink and it’s still having playback issues, I’ve also tried using an mpegvideoparse instead of a capsfilter and it’s having the same playback issues as well.

Bitrate of my source is coming in pretty high around 16000 kb/s (which could be my issue). I did try to decode and encode the source again with a lower bitrate, but of course if we’re already seeing issues with the transmuxing, then video playback wouldn’t be good.

4

It would be interesting to know if it’s bitrate related or something else.

You could try increasing the maximum allowed buffer size for the kernel-side UDP receive buffer, as the default is quite low, and a lot of that may be taken up by kernel-internal data structure overhead already.

On Linux systems you can change the maximum allowed value for the receive buffer with e.g.

sysctl -w net.core.rmem_max=1048576

Alternatively this can also be configured in /etc/sysctl.conf.

Once this is configured kernel-side, you can use udpsrc buffer-size=1048576 to increase the
value to something larger than the default. If the value is too low it’s possible that some
packets may never get read out by the pipeline after capture because they will be overwritten
by new data before they can all be read out, in case of scheduling issues or so.

5

Yeah I tried to increase the buffer size on the udpsrc but the output is still the same.

6

Just to be sure, I was talking about both checking udpsrc ... ! queue ! filesink location=udp-recv.ts as well as the output of the transmuxing, to make sure the receiving alone works fine, and the stream is fine at that stage.

7

Yeah I tested the receiving end (udpsrc) and it’s fine with no transmuxing when writing to a filesink.

Adding transmuxing to the pipeline leads to output issues.

8

You may try higher kernel socket max buffer size and also set net.core.wmem_max as you’re restreaming to udpsink.
You may also try restreaming as RTP/MP2T (see rtpmp2tpay) it should be fine for VLC.

9

Is it possible to do a higher kernel socket max buffer size on a windows system?

10

If the problem also occurs when writing the output of the transmuxing to a file and playing that back, that makes it unlikely to be udpsink related I think.

Hard to remote diagnose the problem with the remuxing. We’d need an input file and your exact gstreamer version, then we can try and reproduce it.

11

Yeah I think the issue is with the tsdemux or mpegtsmux elements when taking in a high bitrate mpeg2source.

Just transmuxed a low bitrate mpeg-2 source and it came out fine in a filesink.