Instant Replay with Gstreamer

[Todd Agulnick]

Hi,

I'm trying to build a server application that allows a client to request a
video covering a specific time range in the recent past from a camera
attached to the server.

My plan is to block the source pad of a leaky queue which is set up to hold
~ 1 GB of encoded video, with the queue always running full and dropping
old video as the new video arrives. The first part of the pipeline looks
something like:

videotestsrc ! videoconvert ! queue ! x264enc ! queue

On a signal from the the client, the controlling app would unblock the
queue's source pad, inspecting each buffer as it comes through: drop any
buffers that are before the requested time window, pass through to a mux
and filesink any buffers within the requested window, and send along an EOS
to wrap things up and block the queue again as soon as it sees a buffer
timestamped after the requested window. (Requests will always be
non-overlapping and in chronological order.)

To handle a request, the app would append to the above pipeline:

mp4mux ! filesink

... and then tear those elements down again to wait for the next request.

My questions are:

 * Are blocking probes the right tool here? The documentation suggests that
blocking probes are really intended for short-term blockages, but in this
system the normal state is that the stream is blocked and accumulating in
the queue. I worry whether this will have unexpected consequences, and
indeed my experiments thus far have failed to produce a proper MP4 file.

 * Do you know of any examples of similar problems and solutions on the 1.x
codebase? The only examples I've been able to find are pre-1.x. (For
example, this one:
http://gstreamer-devel.966125.n4.nabble.com/Dynamically-updating-filesink-location-at-run-time-on-the-fly-tt4660569.html#a4660577
)

Thanks in advance for any guidance you can offer.

-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131227/3b6d592e/attachment.html>