Launching the test in first and second way, with GST_DEBUG:ffmpeg:5 I can see that with "./test 1 rec.asf" then "gst_ffmpegenc_flush_buffers" is called woth param TRUE whereas in the second way the parameter is FALSE. So I think the last buffer, which contains index informations maybe, is not sent to the muxer and so not written into the result file. Why a such distinction in "gst_ffmpegenc_flush_buffers" (param send 0/1)  ? Sincerely Julien <div class="gmail_quote">2008/11/25 Julien Isorce <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi I join to this mail a simple test. The test demonstrates that when the pipeline is stopped when sending eos from the client code, then ffmux_asf does not write the index, so it's not possible to seek when playing back the result file. If I set num_buffers=N instead of sending eos, then the muxer write the index. Yes it should be the same result because when GstBaseSrc reachs num_buffers_left = 0 then it return GST_FLOW_UNEXPECTED then an EOS is generated. So something is not flushed when ffmux receive eos in the first way. Is it a bug from gstffmpegmux or a problem in ffmpeg-asfmux-libavcodec ? or something else ? ( ./test 0 rec.asf   -> index not written)  (eos sent from a g_timeout_add callback) ( ./test 1 rec.asf   -> asf correclty generated)  (use num_buffers=N) Sincerely Julien </blockquote></div>