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