How to restart a pipeline after network connection loss?
Michael Gruner
michael.gruner at ridgerun.com
Wed Aug 7 21:50:31 UTC 2019
Hi Daniel
Full disclosure first: I’m one of gstd developers.
The way I see it is that there are some use cases where Gstreamer Daemon may save you a lot of development time, and there are other applications where you are way better off with plain GStreamer API.
Gstd abstracts a lot of boilerplate low-level code, exposing instead a set of simpler high-level TCP commands. The tradeoff is, of course, that you give up a lot of flexibility. If your pipelines are fixed (do not grow or shrink) in their lifetime Gstd may help you. On the other hand, if you have a dynamic pipeline, with more sophisticated stream handling, Gstd definitely falls short.
We like to think of Gstd as a gst-launch-1.0 under steroids. Besides creating and playing pipelines, you can query/set properties at runtime, check for bus messages, listen to element signals (limited though), etc… Again, I’d like to insist in that it’s not suitable for all applications. Internally, we handle both approaches: for simpler, static media servers we use gstd, for complex highly dynamic media servers we use GStreamer API instead. Another big use we give to Gstd is to automate testing. Since it is controlled via TCP commands, the test can be controlled from a host PC while everything is running on an embedded platform, for example...
Long story short, my rule of thumb is:
Whatever pipeline that can be built and played using gst-launch-1.0 can be properly handled by Gstreamer Daemon.
Michael
www.ridgerun.com <http://www.ridgerun.com/>
> On Aug 6, 2019, at 8:30 AM, Daniel Rossi <electroteque at gmail.com> wrote:
>
> I'm looking into this project to start and monitor for 24/7 receiver purposes. In my case SRT. I have to use sources for SRT functionality and having difficulty getting it installed right now and finding the prefix path. It might be suitable ? I've yet to test it.
>
> https://github.com/RidgeRun/gstd-1.x <https://github.com/RidgeRun/gstd-1.x>
>
> ------ Original Message ------
> From: "Jorne De Smedt | IndigoCare" <Jorne.DeSmedt at indigocare.com <mailto:Jorne.DeSmedt at indigocare.com>>
> To: "gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>" <gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>>
> Sent: 8/6/2019 6:17:22 PM
> Subject: How to restart a pipeline after network connection loss?
>
>> Hello,
>>
>> I’ve been trying to get an rtsp stream working on Android, based on the tutorials.
>> Now, the basic stream itself works, but whenever the stream is lost (due to network issues or other reasons), the stream just pauses and I can’t seem to figure out how to restart it without restarting the app. (Sometimes it also shows a “no signal” screen, but I’m unsure if this is part of gstreamer or the source.)
>> There’s also a light issue that whenever the stream is just a slideshow of static images, it gets stuck on the first frame (unless you put an animation in there somewhere, like a single animated slide or animated pixel). I’m unsure if this is related to the previous issue
>>
>> The goal is to have the app display the stream 24/7, so it should try to reconnect until it finds the stream again.
>>
>> I’m currently using the following pipeline:
>> "rtspsrc name=source location=rtsp://192.168.30.4:554/0 <rtsp://192.168.30.4:554/0> ! rtph264depay ! h264parse ! decodebin name=convert ! glimagesink"
>>
>> Which seems to do the same as the previous one I used:
>> "uridecodebin name=source ! videoconvert name=convert ! glimagesink"
>>
>> What is the right way to restart a pipeline like this?
>> Do I need to use a dynamic pipeline instead of one like this?
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel <https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190807/5f6d8ae0/attachment-0001.html>
More information about the gstreamer-devel
mailing list