GNOME Bugzilla – Bug 319784
mad claims to need more data
Last modified: 2005-12-01 16:04:22 UTC
Please describe the problem: Sometimes when playing a video (avi/mpeg4/mp3) totem tells me that it cannot decode the stream, looking at the GST_DEBUG=*:3 log i can see: WARN (0x83310f0 - 0:00:17.696434000) mad(18657) gstmad.c(1283):gst_mad_chain:<mad0> error: mad claims to need more data than 7701 bytes, we don't have that much INFO (0x83310f0 - 0:00:18.607176000) GST_ERROR_SYSTEM(18657) gstelement.c(1467):gst_element_message_full:<mad0> posting message: Impossibile decodificare lo stream. (Impossibile decodificare lo stream = Impossible to decode the stream) two things: - it happens only with totem, using playbin from command line works fine - it happens only sometimes. Others time totem just hangs I'm using current cvs as of 2005/10/25 19:00 CET and totem head cvs with the latest 0.9 patch. Steps to reproduce: 1. Play a file with totem Actual results: Expected results: Does this happen every time? Other information:
GST_DEBUG=*:5 log bzipped at: http://skaboy.no-ip.org/~luogni/mad-needs-more.log.bz2
It seems that: - in mad_chain the gst_pad_push call returns GST_FLOW_NOT_LINKED - this is handled like an error by mad and so it doesn't decrease the size of "mad->tempsize" Doing the change makes disappear this error but then totem will hang :/ backtrace here: http://skaboy.no-ip.org/~luogni/hang-mad-totem
Example file here: http://skaboy.no-ip.org/~luogni/Hellsing%20-%20Order%2000%20-%20Special.avi I can reproduce it with current cvs of gstreamer and totem. It works fine with the seek example.
If i change totem to use alsasink and xvimagesink instead of gconf* elements then totem works fine.. Also using auto* elements work fine (using auto* elements trigger a bug in totem where totem asks the backend if it can seek but the gst 0.10 backend doesn't know yet if it can seek or not and so the seek bar in totem is disabled). If i change totem source code and make it to always enable the seek bar then all work fine. I don't know if the gconf* elements trigger a bug in the core or if they are just borked..
I get this error from time to time in totem as well. I can reproduce it by loading a playlist of mp3 files and switching frequently between the files (with visualisation enabled here). Usually it will error out with a random 'cannot decode stream' error message after less than 20 or so changes. I say 'random' because the same files that error out sometimes will play fine at other times. The error message in the logs is the same as the one mentioned above ('mad claims to need more than x bytes, but we only have N').
Fixed in CVS: * ext/mad/gstmad.c: (gst_mad_chain): When pad_alloc returns other-than-GST_FLOW_OK and mad exits early, skip frame synthesis and consume input data as if we'd done the decode. Makes mad not error when the src pad is not connected. (#319784)