GStreamer File Chopper Question(s)

lestoilfante lestoilfante at gmail.com
Thu Feb 14 08:42:32 PST 2013


Hello,
I'm experiencing same problem with my app, it looks very closer to
this previous message except that I'm working with theora encoder and
oggmux.

I can change dinamically filesink location and the resulting files are
fine but each file except 1st start with an offset equal to pipeline
running time.

So how can I solve this problem and tell to pipeline or to newly
attached bin to reset his running time or to start without offset?

thank you

On Tue, Nov 6, 2012 at 3:29 AM, Randall Scheifele <rjscheif at gmail.com> wrote:
> 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
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>


More information about the gstreamer-devel mailing list