Hello,<div><br></div><div>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.</div>
<div><br></div><div>My current pipeline looks like the following:</div><div>videotestsrc ! encoder (ffenc_mpeg4) ! queue ! mux (matroskamux) ! filesink</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>The purpose of the event probe is to simply log the events.</div><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks in advance!</div><div>Randy</div>