Instant Replay with Gstreamer

[Pedro Côrte-Real]

On Sun, Dec 29, 2013 at 4:18 PM, Todd Agulnick <todd at agulnick.com> wrote:
> Thanks for making your code available -- it was really helpful. In
> particular, reading your code I realized that I had very early on picked the
> wrong flags when creating my blocking probe. Without your working code to
> look at as an example (and compare, line by line, with mine) I don't know
> that I ever would have detected my mistake.

No problem, most of the code is from bits and pieces of gstreamer
examples anyway... :)

> I read your manifesto and what you're doing definitely shares some
> similarities with my project. But yours is much more elaborate. In my case,
> I start with a collection of raw, live HD video streams. I compress them so
> I can keep a few minutes' worth in an in-memory ring buffer. Occasionally I
> receive an external request to provide a short (< 30 second) clip of some of
> the stored video as an MP4. The clip is short and the network is local, so I
> don't need to stream.

If I implement this correctly yours should be a valid use. Just run a
very short time limit per stream and save into a ramdisk. But it
wouldn't be the normal use of the software, you can probably create
something much simpler.

What's the use case exactly if it's not secret? Where are you getting
raw HD from? v4l2?

> I haven't seen the pipeline stalling problem that you have, but then again I
> haven't run a pipeline for very long as I still don't have the basics
> working yet. In your setup, when you close a file you immediately start
> streaming into the next file, and it's my impression (possibly wrong) that
> your code succeeds in finalizing the previous file properly because the
> queue is still streaming (into the new file). In my case, when I finish
> producing my clip, I block the queue again to wait for the next request and
> as an apparent consequence, the previous file doesn't get finalized.

That seems strange as in both cases the pipeline is running and the
bin is moving into NULL state. The other bin draining the queue
shouldn't really make a difference. Are you checking the result of
gst_element_set_state to see if the change to NULL was successful? I
guess I need to check that as well.

> Separately, I don't know if you ever got answers to the questions you posed
> in your linked document, but disk-life was definitely a concern that led to
> my keeping everything in memory. The server that runs this stuff for us is
> remote "in the field" so maximizing MTBF is a real concern.

Not really no. The "dirty disk" solution is always an option.

Pedro