Dynamically updating filesink location at run-time, on the fly

[lsmithso at hare.demon.co.uk]

Wow! that sounds complicated, but not as complicated as the work
around I came up with. This involved spawning a child process and
writing a continuous pipe of raw data down a fdsink. The child process
read the pipe and wrote the data to file until signalled. At each
signal it created a new pipeline to encode to a new output file.  This
uses the pipe to buffer data while the child is switching files and
encoding. I am not completely sure its not losing data though.

I've never programmed pads or bins before.  I guess blocking a pad
stops it sending data to the next element and it buffers it
instead. While its blocked you can remove and add the next element in
the pipeline then unblock the pad without loss of data. Contrast this
with setting the state of the sink to say PAUSED, which pauses the
whole pipeline.

Is this surmise correct? What is the purpose of the bin here?

I'll certainly give this a go, and thanks for your help.




Paddy writes: > I had much pain
in getting this to work for audio & video - for one tho it > was quite
easy.
 > 
 > Assuming you have a pipeline that looks like this:
 > audiosrc -->  encoder --> mux --> filesink
 > 
 > then you'll need to change it to:
 > audiosrc --> encoder --> queue --> muxsink_bin
 > where muxsink_bin is a bin
 > ghostpad --> mux --> filesink
 > 
 > then the procedure is:
 > 1 - Block the queue srcpad using gst_pad_set_blocked_async()
 > 2 - In the blocked callback:
 > 2a - unlink muxsink_bin with gst_pad_unlink()
 > 2b - send an EOS event to the muxsink_bin sink pad with gst_pad_send_event()
 > 2b - create a new muxsink_bin
 > 2c - set filesink location
 > 2d - add the new bin to the pipeline with gst_bin_add()
 > 2e - sync with parent using gst_element_sync_state_with_parent()
 > 2f - link it to the queue srcpad with gst_pad_link()
 > 2g - unblock the queue srcpad with gst_pad_set_blocked_async(). When the
 > unblocked callback occurs you're recording again & no data has been lost. No
 > action is required in the unblocked callback
 > 
 > 3 - handle the EOS & delete the old muxsink_bin. I had a msg handler that I
 > installed in my bin_init() function using "gstbin_class->handle_message =
 > GST_DEBUG_FUNCPTR(msg_handler)" & in the handler:
 > 3a - lock the bin state with gst_element_set_locked_state()
 > 3b - set the state to NULL with gst_element_set_state()
 > 3c - remove it from the pipeline with gst_bin_remove()
 > 
 > That's it. The only thing to be mindful of is that data must be flowing thru
 > the pipeline for this to work.
 > 
 > Cheers
 > 
 > Paddy
 > 
 > 
 > 
 > --
 > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Dynamically-updating-filesink-location-at-run-time-on-the-fly-tp4660569p4660577.html
 > Sent from the GStreamer-devel mailing list archive at Nabble.com.
 > _______________________________________________
 > gstreamer-devel mailing list
 > gstreamer-devel at lists.freedesktop.org
 > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Les Smithson