[gst-devel] Dynamic Pipelines - Some special cases - Need some precisions... on part-block.txt
hexa00 at gmail.com
Thu Jul 6 23:03:22 CEST 2006
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
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
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...
More information about the gstreamer-devel