<br><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 5:21 AM, Stefan Kost <span dir="ltr"><<a href="mailto:ensonic@hora-obscura.de">ensonic@hora-obscura.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">Attila RS wrote:<br>
> I'm working on a app that needs to dynamically add/remove outputs<br>
> without affecting already active outputs. Below is a simple example.<br>
><br>
> 1. Receive an RTP stream with audio/video and playback both.<br>
> 2. Stop audio output associated with the above stream.<br>
> 3. Receive a 2nd RTP stream with audio and playback audio.<br>
> 4. Stop 2nd RTP stream.<br>
> 5. Connect audio output back to the first RTP stream without affecting<br>
> the video.<br>
><br>
> In order to be able to dynamically add/remove outputs I<br>
> have separated the input (udpsrc/depay/demux), the video output<br>
> (decode/vidsink) and the audio output (decode/audsink) into<br>
> 3 separate pipelines and link them together with ghost pads. This<br>
> seems to work well for doing the above controls, but I have 2 problems.<br>
><br>
> 1. Synchronization is a mess. It looks like each pipeline is using a<br>
> different clock and as a result audio/video is out of sync.<br>
> 2. Adding a new output pipeline to a running input pipeline result in<br>
> out of sync clocks, so the newly added output thinks it is too far<br>
> ahead/behind and just dumps all data instead of outputting it.<br>
> Disabling sync and the newly added pipeline starts playing fine, but<br>
> of course it is out of sync.<br>
><br>
> I think the second problem can probably be improved or eliminated by<br>
> forcing a new segment event when linking the output, but still the<br>
> clocks need to be synchronized between the pipelines in order for a/v<br>
> to sync correctly and playback smoothly.<br>
><br>
> Any thoughts on how to better handle these problems? Maybe forcing the<br>
> output pipelines to use the input pipelines clock? Or perhaps there is<br>
> a way to maintain the control I need without using 3 different pipelines?<br>
<br>
</div></div>You want to have one pipeline, so that you share *one* clock. You can<br>
dynamicly link and unlink elements. Read part-blocking.txt in the source<br>
tree under gstreamer/docs/design. You need to use pad-blocking to ensure<br>
no dataflow is happening on the unlinked pads. If a sink is not<br>
conencted its probably a good idea to pause it (and lock the<br>
paused_state). If you don't use the audiosink, you need to trigger clock<br>
re-selection (dunno how from the top of my head - maybe you can check<br>
what playbin2 does if you unset the audio flag). When connecting a new<br>
upstream branch to a sink, you need to resend the newsegment event to<br>
the sink so that it 'knows' whats playing.<br>
<br></blockquote><div>I guess what I will do then is instead of creating the 3 pipelines I will create 3 bins (one for the input elements, one for the audio elements and one for the video elements) and put them all in the same pipeline. That way I can still easily control the 3 components individually and they will all share the same clock. Then I'll just have to send the appropriate events when adding/removing from the pipeline. Thanks.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I know that all this is a bit complicated. Making this easier on the<br>
framework level would be nice ...<br>
<font color="#888888"><br></font></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">Stefan<br>
</font><div class="im"><br>
<br>
><br>
> Thanks for the help.<br>
><br>
> Attila<br>
</div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="h5">><br>
> ------------------------------------------------------------------------------<br>
> Download Intel&#174; Parallel Studio Eval<br>
> Try the new software tools for yourself. Speed compiling, find bugs<br>
> proactively, and fine-tune applications for parallel performance.<br>
> See why Intel Parallel Studio got high marks during beta.<br>
> <a href="http://p.sf.net/sfu/intel-sw-dev" target="_blank">http://p.sf.net/sfu/intel-sw-dev</a><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br>
><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Download Intel&#174; Parallel Studio Eval<br>
Try the new software tools for yourself. Speed compiling, find bugs<br>
proactively, and fine-tune applications for parallel performance.<br>
See why Intel Parallel Studio got high marks during beta.<br>
<a href="http://p.sf.net/sfu/intel-sw-dev" target="_blank">http://p.sf.net/sfu/intel-sw-dev</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br>