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

[Edward Hervey]

Hi,

  Just to point out that multifilesink has multiple ways of deciding
when to split/create a new file. See the next-file property:

===================
  next-file           : When to start a new file
                        flags: readable, writable
                        Enum "GstMultiFileSinkNext" Default: 0, "buffer"
                           (0): buffer           - New file for each
buffer
                           (1): discont          - New file after each
discontinuity
                           (2): key-frame        - New file at each key
frame (Useful for MPEG-TS segmenting)
                           (3): key-unit-event   - New file after a
force key unit event
                           (4): max-size         - New file when the
configured maximum file size would be exceeded with the next buffer or
buffer list
====================

  You could therefore just send a key-unit-event from somewhere in your
pipeline to force the generation of a new file.

   Edward

On Fri, 2013-06-14 at 22:18 +0100, lsmithso at hare.demon.co.uk wrote:
> I've seen this asked lots of times but have never found a direct
> answer. I hope you don't mind my  asking the question  again.
> 
> I want to programatically change the file location that filesink
> writes to as the program runs. I an saving an audio stream as a series
> of short flac files. A new file is written after 30 seconds, or a
> period of silence, whichever comes first. The source is any one of
> mmssrc, souphttpsrc or pulsesrc. Ideally no src data will be lost
> while switching files. The silence detector is either level or cutter
> - I'm not sure yet.
> 
> I have tried naively setting the filesink location attribute but get
> the 'cannot change the open file' error. multifilesink won't help
> because it writes to a sequence of fixed length files, and my files
> will be of varying lengths. I haven't tried fdsink but I suspect I'll
> get the same error as for filesink.
> 
> 
> I suspect the answer involved sending an eos and changing the state of
> the file sink, and would have to be controlled by bus messages, but
> I'm not sure what the sequence of operations should be.
> 
> 
> This seems such a simple and obvious things to want to do. Is there a
> reason I shouldn't do it, and should the answer to this be in the FAQ?
> 
> 
> Thanks for any insights.
> 
> 
> 
>