Instant Replay with Gstreamer

[Todd Agulnick]

I have this nearly working now (see below for the remaining puzzle) and
wanted to send my thanks to Sebastian, Tim, and Pedro for helping to steer
me in the right direction. I really appreciate your guidance.

Here's my setup. It's similar to Pedro's.

videotestsrc is-live=true ! capsfilter ! videorate ! videoconvert ! x264enc
! queue leaky=downstream max-size-bytes=500MB max-size-buffers=0
max-size-time=0 ! bin, where bin is disposed and recreated for each request
and contains mp4mux ! filesink.

I've got this rigged up inside a server that listens on a socket for
incoming requests which identify a desired time-based segment of the video
stream. In the quiescent state, there's a blocking probe on the leaky
queue's source pad, so data flows all the way into that queue and then,
once the queue is full, old data is dropped.

When a request comes in, I install a new (non-blocking) probe and remove
the existing blocking probe. Data starts to flow through the leaky queue,
and the new probe's callback inspects the PTS on each video frame, waiting
first for a keyframe that's within the requested window (at which point it
stops dropping frames and instead starts passing them to the mux and sink),
and then for a video frame that is beyond the requested window, at which
point it sends an EOS through the bin to finalize the file; when the EOS
appears on the application bus, the app removes the non-blocking probe,
re-instates the blocking probe, NULLs the bin, removes the bin, and then
sends the result back to the client through the socket and awaits the next
request.

All of this works like a charm, EXCEPT for the following observed behavior:
when I reinstate the blocking probe on the queue's source pad, if there is
any data in the queue, data stops flowing into the queue. Indeed, the whole
pipeline goes eerily quiet. If, however, the request ends up draining the
queue completely, when I reinstate the blocking probe data continues to
flow into and build up inside the queue.

I'm about to dig into the queue code to see if I can understand why that
might be happening, but I thought I would ping the experts first to see if
this rings a bell.

-Todd



On Wed, Jan 1, 2014 at 1:39 PM, Todd Agulnick <todd at agulnick.com> wrote:

>
>
>
> On Wed, Jan 1, 2014 at 4:23 AM, Sebastian Dröge <sebastian at centricular.com
> > wrote:
>>
>>
>> You should be able to drop the message from the sync bus handler of the
>> bin too, to prevent it going up in the pipeline hierarchy.
>>
>
> Just to follow up with a conversation that took place on IRC just now:
>
> You can't do this because the GstBin already has a sync bus handler, and
> there can be only one. We talked about possible modifications to GstBin to
> support the desired behavior (bug filed here:
> https://bugzilla.gnome.org/show_bug.cgi?id=721310), but for now as a
> work-around we're going to catch the EOS just upstream of the filesink to
> see if that works.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140106/60653bd4/attachment.html>