"Uncrashable" video/audio source and sinks

[superlou]

Baby Octopus wrote
> You can think of using queue and input selector. Based on queue
> activity(underrun, running) you can choose which pad you want to connect
> to, using input selector. One of the input can be videotestsrc and other
> one can be your real source such as v4l2
> 
> Hangs can be addressed with queue activity(data flow) and dynamically
> changing the pipeline based on the required output

So if I understand this right, at the input sink of every bin representing
something run-time pluggable, there'd be a 2 queues leading two an input
selector.  One queue would provide the sink for the bin's actual input, the
other queue would have a videotestsrc.  I would then start the pipeline
running, and if I get a signal from the external facing queue that it is
empty, I can change the input selector to the queue fed by a videotestsrc. 
Then if I get a signal that the external facing queue has data available, I
can switch input-selector back.  All of the switching can be done without
any need for pad blocking, or connecting the videotestsrc to a fakesink when
the input-selector is not using it?  Does this run into any issues if I am
missing live (dv or v4l2src) and non-live (uridecodebin) sources?


Baby Octopus wrote
> 'Uncrashable' is something that no program can manage to handle IMO. You
> can have background daemons to restart the process for handling crashed
> application. 

Definitely understood, hence the quotes.  It was more just a goal of having
a standardized approach to minimize the amount of hair pulling I was doing.



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Uncrashable-video-audio-source-and-sinks-tp4664776p4664796.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.