[gstreamer-bugs] [Bug 546955] New: gstoggmux EOS handling issue

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=546955

  GStreamer | gst-plugins-base | Ver: 0.10.x
           Summary: gstoggmux EOS handling issue
           Product: GStreamer
           Version: 0.10.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: dsd at gentoo.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I reported a problem on the list:
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...


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=546955.