[gst-devel] gstoggmux EOS handling issue

[Daniel D. <ds...@la...>]

Hi,

I reported a problem earlier:
http://marc.info/?l=gstreamer-devel&m=121562099110189&w=2
with this program:
http://dev.laptop.org/~dsd/recordtwice.txt
It tries to record 2 ogg videos of videotestsrc, but always fails to
record the 2nd one. I reproduced this problem on multiple systems.

I have investigated further and I believe it is a bug in the gstoggmux
element.

I only have a little knowledge of gstreamer and don't feel that I have a
100% understanding of the issue, but I'll try anyway:

The first time we stop recording, gstoggmux detects the EOS:
oggpad->buffer is not NULL, oggpad->next_buffer is NULL, and oggpad->eos
is TRUE

However, that buffer is not flushed from the pad. So when we try to
reuse the oggmux later, it finds the non-NULL buffer (final frame of
last session), shifts the NULL next_buffer onto it, and then encounters
this:

gst_ogg_mux_process_best_pad()
  /* best->buffer is non-NULL, either the pad is EOS's or there is a
next 
   * buffer */
  if (best->next_buffer == NULL && !best->eos) {
    GST_WARNING_OBJECT (ogg_mux, "no subsequent buffer and EOS not
reached");
    return GST_FLOW_WRONG_STATE;
  }

I think the issue is that after detecting EOS, the appropriate buffers
should be flushed from the pads, leaving clean state for next time.

Am I making any sense?

I'm attaching a patch which fixes the problem - my recordtwice program
now records two vidoes of videotestsrc. Unfortunately it doesn't
actually fix the real application which I was trying to fix, but I
believe that I've found a real bug and fixing this is a necessary step
in the process...

Thanks,
Daniel