After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 546955 - gstoggmux EOS handling issue
gstoggmux EOS handling issue
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other Linux
: Normal normal
: 0.10.22
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-08 15:32 UTC by Daniel Drake
Modified: 2008-10-08 12:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
free buffers during cleanup (643 bytes, patch)
2008-08-08 15:32 UTC, Daniel Drake
committed Details | Review

Description Daniel Drake 2008-08-08 15:32:29 UTC
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...
Comment 1 Daniel Drake 2008-08-08 15:32:59 UTC
Created attachment 116157 [details] [review]
free buffers during cleanup
Comment 2 Daniel Drake 2008-08-11 20:18:03 UTC
After correcting my app to cleanly shut down the live recording, this bug(?) is circumvented.
Comment 3 Sebastian Dröge (slomo) 2008-10-08 12:12:21 UTC
2008-10-08  Sebastian Dröge  <sebastian.droege@collabora.co.uk>

	Patch by: Daniel Drake <dsd at laptop dot org>

	* ext/ogg/gstoggmux.c: (gst_ogg_mux_clear_collectpads):
	Unref all buffers when clearing collectpads. Fixes bug #546955.



This was a bug in your application, you shut down everything cleanly, otherwise you can expect memory to be leaked :) But your patch was correct too, it will clean things up in any case...