Im 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.
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:
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.
You are close. The filesrc plugin knows nothing about the contents of the file it is reading. GStreamer needs to know that the data is a transport stream in order to stream it properly. While demuxing and the muxing the stream does that job, there's a better way:
The plugin tsparse reads the stream and parses out information about the stream. It also identifies it's output as a transport stream. That by itself may be sufficient for your streaming needs as it allows udpsink to know that the data is in 188 byte packets. On the receiving side, tsdemux is needed to parse out the actual video stream. The element "set-timestamps" tells tsparse to set timestamps on the outgoing packets so the udpsink sends each frame on time rather than as fast as it can.
I'm currently working on a DVB streaming project and it seems like there is a problem with the gst-plugins-bad package. This package is supposed to provide mpegts-plugins e.g. "mpegtsdemux", "mpegtsparse" and so on. However no application on my system can find "mpegtsdemux" or "mpegtsparse". I have installed "gstreamer1.2.4-1" and also "gstreamer0.10.23-8". Of course I have installed "gst-plugins-bad" for both versions of gestreamer and even all of the other plugin packages. I have also read that it is absolutely ok to to run both versions of gstreamer on the same system.
Ok, I actually found the solution for the second example:
renaming mpegtsdemux to tsdemux seems to work. I still have to find out if tsdemux does the same as mpegtsdemux. Maybe they just changed the name. That would also be an explenation why the installation of Gnome DVB Daemon does not work. I will post again as soon as I know more.
Regarding the "First example" from my post:
Gnome DVB Daemon uses/searches for the mpegtsparse, so I assume that the plugin names really did change.
Gnome DVB Daemon should be using/searching for tsparse instead of mpegtsparse. I will write the developers a bug report later. Problem Solved.
I am using gstreamer, and running a command in terminal, but for some reason when using Ubuntu 18.04 and QGC 4.0.8 everything worked fine (my partner also confirmed that QGC 4.0.8 also displayed video stream on Windows 10 Enterprise), but as soon as I started to use QGC 4.1.0 and above no stream was displayed even though the streaming command did no change. To make matters worse, once I upgraded to Ubuntu 20.04 I have not found any version of QGC that would display my video stream.
I have been following the material in The Manifest Format - The Cargo Book and Specifying Dependencies - The Cargo Book but cannot get a patch section to do what it should. I also tried replace and it also didn't seem to work.
The two repositories are GitHub - sdroege/gstreamer-sys: Rust FFI bindings for GStreamer - This repository moved to -rs-sys and GitHub - sdroege/gstreamer-rs: GStreamer bindings for Rust - This repository moved to -rs I am working on the gstreamer-mpegts subproject. The idea is to have changes in my local clones in the rw_mpegts branch of both and be able to compile and test changes in my clone of GStreamer_Rs using the local clone changes to GStreamer_Sys so as to test both prior to making pull requests for either.
It turns out that putting the patch section in the top-level project/workspace Cargo.toml instead of the subproject Cargo.toml does the needful. Thanks to Arvid E. Picciani and David Hewson on Twitter for pushing me in the right direction. Everything now seems to work and much progress can be made.
3a8082e126