Gstreamer Timeshift Record

[DDRam]

Hello,
i'm trying to implement a Timeshift like recording application with
gstreamer recording multiple h264 camera streams.

The idea is based on:
https://people.freedesktop.org/~tpm/code/test-backlog-recording-h264.c

I successfully build this in an application.
The idea is that there is an queue which is running as ring buffer and the
source pad of the queue is blocked. So the queue generates the backlog and
as soon as the sink pad is  unblocked the first frame is  send into an
matroskamux and to a filesink. After a timeout an eos event is send over the
peer of the queue src pad(the mux sink pad) which finalizes the matroska
container and the file of the filesink.
The eos event is caught by setting "message-forward" of the pipe to true.
And after the eos was caught by the message bus callback the filesink and
the matroskamux are set to GST_STATE_NULL the file of the filesink is
changed and then both are set to GST_STATE_PLAYING again.

I also set up another branch which is connected to a tee which is situated
in front of the blocked queue.
This streams a live preview of the stream over tcp.

This all worked fine until i tried a more modular approach as shown in this
picture.
The h264 source is packed into a bin which has two ghost pads one for
recording one for preview.
The recording part is put in another bin which has a sink pad for an parsed
h264 stream.
The preview is in another pipeling which has to be connected to the preview
ghost pad.
Preview is optional and not connected in this plot.
For the eos to get passed on to the bus message callback the bin
"message-forwarding" property is set to true too.

I preroll the pipeline by setting a probe to the sink pad of the filesource
and waiting for the first buffer so the preview can stream prior to the
first record. The queues pad is blocked after the prerolling of the
pipeline.

The first record work just fine but then the filesink changes it state from
NULL to READY(pending PLAYING) and won't leave this state the bin changes to
PAUSED with pending PAUSED and the Pipeline which contains the bin changes
to PAUSED pending PAUSED too.
Then preview branch is connected to the pipeline it continues to send the
stream.
When the eos is send through the muxer a second time then the eos won't
reach the bus message callback and my application comes to an halt.

The bin1.queue0 src pad is blocked because it is probed waiting for a frame
to leave the queue but the probe callback isn't called anymore.

Kind Regards, David Ramunno


  <http://gstreamer-devel.966125.n4.nabble.com/file/t378035/pipe_dump_1.png>





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel