[gst-devel] Dynamic Pipelines - Some special cases - Need some precisions... on part-block.txt

[Antoine Tremblay]

Hi all,

I've been playing around with dynamic pipelines lately , I've been refering
to : the part-block.txt design doc but I would need more precisions :

The context :

I'm trying to change from a file to a rtp source and vice versa while
keeping my encoder and destination ( rtp for now)  So that I keep the
continuity of the rtp flow...

Things i've done:

I've created a element that restamps the buffers to allow continuity , I
just adds the duration to the last ts ( I link this just before my encoder)
And this element also intercetps EOS events in case my file ends before I
switch to rtp , or if I wan't to switch to rtp after my file ends.

Things i'm not sure how to do :

My big problem is stopping the dataflow to allow my source change properly:

I've tryed 2 approches

1. Having the pipeline in PLAYING and blocking (sync) my source pads .. then
unlinking /removing (setting state to null before) my elements and adding
/relinking my new elements

This seems to work but there's still some problems :

My main problem is if I change from udpsrc to file for example and there's
no data going throught the udpsrc I won't ever block since no push is done ,
so I won't be able to change my pipeline .. (this can happen at the end of a
rtp stream for example.. no eos , just no more data and I can't block :( )
Or if I try to change after a file went to EOS... same thing..

I could block ASYNC and wait for a timeout I guess and then on the timeout
send a FLUSH_START event on the pipeline up to my encoder and before
unblocking my pad send a FLUSH_STOP event...
To make sure no buffer is going throught the part of the pipeline I will
modify...
But then there's the question of how much time should I wait ... :(

Would this be a good way ?

Or maybe another solution would be to send something from another thread to
make sure it will block but I wonder what I could send that wouldn't affect
my pipeline and still do a push on the pad.... ideas ?

Or if you ppl see any other solutions ?

2. I've tryed too setting the pipeline to PAUSED and blocking my src pads
async

But In that case I get weird problem like when removing an element like
ffdec_mpeg4 that is completly unlinked ... seems like on post_activate the
pad will that GST_PAD_STREAM_LOCK(pad) and that will try to lock the sink
element ( basesink_do_sync) but it's already locked since i'm in PAUSED and
then I deadlock, I really wonder why I trys to lock the sink when it's not
linked to the pipeline anymore :(

So going to paused to do this seems bad to me... am I right ?


Thanks a lot , your help is very apreciated :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20060706/6ce679d3/attachment.htm>