It is flushing, and I have considered that. I've set both the queues to hold 1 buffer max, and that seem to have made no difference at all. <br>Is there any other element in that pipeline that can queue a large number of buffers (rtpmp4vpay maybe? I'm not familiar with its behavior), hence causing this problem?
<br><br>Thanks,<br>Itay.<br><br><div><span class="gmail_quote">On 8/24/07, <b class="gmail_sendername">Andy Wingo</b> <<a href="mailto:wingo@pobox.com">wingo@pobox.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu 23 Aug 2007 21:02, "Itay Kirshenbaum" <<a href="mailto:ikirsh@gmail.com">ikirsh@gmail.com</a>> writes:<br><br>> filesrc -> queue -> avidemux -> queue -> rtpmp4pay -> udpsink<br>>
<br>> When I tried adding seek support, I've noticed a strange behavior.<br>> After a seek event is performed in the avidemux element, it pushes<br>> 5-10 seconds worth of buffers as fast as it can (the 5-10 seconds
<br>> following the seek position), and will only get to normal playing rate<br>> afterwards.<br><br>The seek is probably flushing, which removes all buffers in the queue.<br>About 5-10 seconds' worth.<br><br>> From going over basesink logs it seems after
<br>> flush_start/stop+newsegment the clock is reset, and all buffers<br>> received are just sent out, without actually waiting for their time.<br><br>The thing that waits on the time is the sink. Everything else runs until
<br>the sink is blocked, hence the buildup in the queue until it blocks too<br>(when it is full).<br><br>Regards,<br><br>Andy.<br>--<br><a href="http://wingolog.org/">http://wingolog.org/</a><br></blockquote></div><br>