[gstreamer-bugs] [Bug 517185] queue not emptied

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Mon Feb 18 05:03:42 PST 2008


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=517185

  GStreamer | gst-openmax | Ver: 0.10.17




------- Comment #3 from Frederik  2008-02-18 13:03 UTC -------
Hello Felipe,

It seems that in between songs, totem removes the gst-openmax mp3 decoder from
the element chain, causing it to execute its dispose function, so when it gets
attached again later (if next song is also an mp3) it gets freshly initialised.

This does not seem to be the case for the gst-openmax's audiosink however. 
It will get its buffers freed in g_omx_core_finish, but the port's queue might
still contain pointers to these buffers so that the gst-openmax's audiosink
will try to use those freed buffers when playing the next song.

emptying the port queue in g_omx_core_finish fixes this problem for me,
although I'm getting OMX buffer underuns from the next song unwards.


-- 
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=517185.




More information about the Gstreamer-bugs mailing list