<div dir="ltr">I eventually did get this functionality to work. One of the things I remember changing was in cb_bus_message. Instead of returning FALSE when I got the EOS I returned TRUE. There may have been some other changes but I'm not sure off the top of my head what they were. If you still have issues post back and I'll do my best to help.<div> </div><div style>-Randy</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Feb 14, 2013 at 10:42 AM, lestoilfante <<a href="mailto:lestoilfante@gmail.com" target="_blank">lestoilfante@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div><div class="h5"> On Tue, Nov 6, 2012 at 3:29 AM, Randall Scheifele <<a href="mailto:rjscheif@gmail.com">rjscheif@gmail.com</a>> 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 > </div></div>> _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > </blockquote></div> </div>