GStreamer File Chopper Question(s)

[Randall Scheifele]

Hello,

I've been looking into implementing a file chopper in GStreamer and I've
come across a few posts to this newsletter that have been helpful.
 However, I still haven't been able to implement a solution without running
into some sort of issue.  The goal is to start a new file with no (or very
limited) amounts of dropped frames.

My current pipeline looks like the following:
videotestsrc ! encoder (ffenc_mpeg4) ! queue ! mux (matroskamux) ! filesink

I create all of the elements in the pipeline and attach a debug buffer
probe on the videotestsrc source pad, a guard probe on the queue source
pad, and an event probe on the mux source pad.

The purpose of the debug buffer probe on the videotestsrc is to inform me
that buffers are flowing out of the videotestsrc element.  This probe
always returns TRUE to allow the buffers through.

The guard probe on the queue source pad only allows data to pass when the
global savingEnabled flag is set to TRUE.  This flag is modified at various
parts of the execution to save only data that is wanted.

The purpose of the event probe is to simply log the events.

The pipeline starts and a timeout callback is called after 5 seconds.  At
this point, the queue's source pad is blocked (for data only) by modifying
the savingEnabled flag.  This is followed by sending an eos event to the
queue.  The EOS event is then passed down the rest of the pipeline and the
EOS event is then posted to the bus.  Question: Other posts on this mailing
list suggest that all elements in a pipeline need to handle the EOS event
in order for it to get posted to the bus.  Since I injected the EOS event
at the queue, the elements upstream didn't receive the event yet I get the
EOS event on the bus.  Is this correct?

When the EOS event is received at the bus, the queue and mux elements are
unlinked and the mux and filesink are put into the NULL state.  The
location on the filesink is changed and then the two elements are synced
with the parent (pipeline) back into the playing state.  The queue and mux
are then re-linked.  This bus callback returns FALSE to drop the EOS.

The initial 5 second timer fires again and this time the savingEnabled flag
is changed to TRUE.  This causes data to flow again into the mux and
filesink elements.  At this point, data is being written into the second
file (yay!).  However, there are some issues.  The second file starts at
time offset 10 seconds.  I think this has something to do with not
resetting the timestamps somewhere in the pipeline (either by a newsegment
or something else).  Can anyone comment on what is needed to reset it so
the file starts at time 0?  Second, a second EOS is injected into the
pipeline by the source because the num-buffers limit is reached on the
videotestsrc and that EOS shows up at my mux source pad but it doesn't make
it to the bus.  Why doesn't this EOS event make it to the bus?

The attached code demonstrates where I'm at.  I'm probably not
understanding some concept correctly, so any hints as to which sections to
re-read from the app devel manual or any other resources would be helpful.
 Also, if anyone else has created a file chopper before and solved it a
different way, I would be eager to hear how you solved this problem.

Thanks in advance!
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121105/7dbea825/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file_chopper_mpeg4.c
Type: text/x-csrc
Size: 5057 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121105/7dbea825/attachment.c>