Changing filesink location after a mux with many inputs.

[Paddy]

More details - I'm using videotestsrc & audiotestsrc as my sources (just in
case this is significant)

I've tried some more things:

Sending a flush_start event from the first block callback (to the newly
blocked pad) - which gives 
gstpad.c:3133:gst_pad_alloc_buffer_full:<queue0:src> pad block stopped by
flush
gstpad.c:3050:gst_pad_buffer_alloc_unchecked:<queue0:sink> alloc function
returned error (-2) wrong-state
gstpad.c:3148:gst_pad_alloc_buffer_full:<videosink:proxypad0> alloc function
returned error wrong-state
gstpad.c:3050:gst_pad_buffer_alloc_unchecked:<record_bin:videosink> alloc
function returned error (-2) wrong-state
gstpad.c:3148:gst_pad_alloc_buffer_full:<video_src_bin:src> alloc function
returned error wrong-state
... more of the same
gstbasesrc.c:2562:gst_base_src_loop:<videoSrc> pausing after gst_pad_push()
= wrong-state
gstbasesrc.c:2588:gst_base_src_loop:<videoSrc> pausing task, reason
wrong-state
gstpad.c:5646:gst_pad_pause_task:<videoSrc:src> pause task
gsttask.c:698:gst_task_set_state:<videoSrc:src> Changing task 0x7fcc2c0c0370
to state 2

blocking one of the queue src pads & probing the other - the
gst_pad_send_event() never returns (it's stuck on a mutex somewhere). A wild
& hopeful stab in the dark to no avail.


The use case in
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-block.txt
does lead me to think that I can block 2 paths in the same pipeline, but the
second callback never happens.

Either I'm doing something wrong, or I'm trying to do something that can't
be done. Does anyone have any ideas ??

Cheers again





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Changing-filesink-location-after-a-mux-with-many-inputs-tp4656116p4656161.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.