Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using gstreamer to stream over a custom AppSink that mimics the UdpSink. We are doing it this way so we can incorporate listening on other ports for some metadata. Plus, the stock UdpSink is broken. Anyway, I've successfully had video streamed, but the UDP packets seem to be not packaged correctly. I'm wondering if I have missed some step.

Here's my sending pipeline:

filesrc (mpeg TS file) ! displayQueue ! streamTee ! tsdemux ! decoder ! videosink

streamTee ! sendQueue ! udpSink (our custom one)

the receiving end:

UdpSrc (custom) ! queue ! mpegtsdemux ! queue ! (mpegdecode || h264decode) ! ... ! videosink

Streaming works. But it seems very fragile. Sometimes it just stops. There are lots of artifacts.

So, I tried VLC. I set it up to stream over UDP unicast. It works great. I noticed that VLC sends out the video way different than my pipeline. I used Wireshark to analyze the packets:

Protocols used: VLC: IP:UDP:MP2T (and PET, PMT packets and all other sorts of TS-related stuff)

Mine: IP:UDP:Data

It seems like the pipeline I'm using is just sending raw video over UDP without any error correction. What am I missing? The videos used are h264 or mpeg encoded .mpg files.

I am using gstreamer-java to program the custom UdpSink and UdpSrc elements, but cannot use gstreamer in the console to test since the stock UdpSink plugin is broken. I tried a simple pipeline in a Linux VM, and got a similar bunch of packets as VLC:

gst-launch-0.10 -v videotestsrc ! mpeg2enc ! mpegtsmux ! udpsink host= port=1234

share|improve this question
In your send pipeline you have a tsdemux whereas in the linux VM you were using mpegtsmux, you should have a mux not a demux on the send side. – heavyd Feb 28 '13 at 17:08
Oops, yeah, after the tee, that end goes to a videosink. Just edited it. – Nick Feb 28 '13 at 19:21
up vote 1 down vote accepted

This is just a thought, I'm not really that familiar with gstreamer, so I don't know how the filesrc works, but I'm assuming that it doesn't understand MPEG-TS. MPEG-TS requires packets to come in on certain boundaries (usually 188 bytes). I would try putting your tee after the demux, then add a mpegtsmux before your udpSink.

I realize this is going to do more work then is really needed (demux just to mux again), but it will insure the packets are aligned correctly. If it works and you need to eliminate the overhead, you may need to look into implementing a smarter file source.

share|improve this answer
I think this is a step in the right direction. I tried streaming the file in the Linux VM: filesrc ! queue ! udpsink and it doesn't have the TS protocol. Using filesrc ! mpegtsdemux ! mpegtsmux ! udpsink and it does. Looks like the filesrc is stripping out the TS info. – Nick Feb 28 '13 at 22:13
Either that or your original file is not really MPEG-TS :) – heavyd Feb 28 '13 at 22:20
ffmpeg -i file.mpg reports MPEG-TS stream. – Nick Mar 1 '13 at 14:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.