Instant Replay with Gstreamer

Tim Müller tim at centricular.com
Tue Dec 31 02:51:56 PST 2013


On Sun, 2013-12-29 at 01:58 -0500, Todd Agulnick wrote:

Hi Todd,

> Inspired by the example in the App Developers Manual, I'd been trying
> to finalize the file by sending an EOS through the bin that contains
> the mux and filesink. I can make that work, but the EOS also tends to
> want to shut down the whole pipeline, which isn't what I want. So then
> I found that I could override the bin's handle_message method to
> discard the EOS before it bubbled up to the pipeline. It works, but
> what a mess!

You need to push the EOS to the muxer + filesink to get the file
finalised properly.

> So I was happy to see the solution that you linked below that shows
> the code simply setting the bin to GST_STATE_NULL to trigger the
> finalizing of the file. But I can't seem to get that to work in my
> app.

That's because this won't work right. State changes will happen from
sink to source, so this will just make the filesink close the file
before the other elements have a chance to finalise anything (i.e. write
clean headers). Assuming the filesink is in the bin.

> The critical difference seems to be that as soon as I decide that the
> muxer has seen all the data intended for the current file, I want to
> block the sourcepad on the queue upstream of the bin so that the queue
> resumes accumulating video. And my impression is that if I'm blocking
> buffers on that pad (with GST_PAD_PROBE_TYPE_BLOCK |
> GST_PAD_PROBE_TYPE_BUFFER), the transition to NULL state doesn't
> finalize the file -- the elements transition to GST_STATE_NULL, but
> the finalization code isn't called.

See above why.

 Cheers
  -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com



More information about the gstreamer-devel mailing list