totem-gstreamer doesn't play Apple QuickTime movie (fast start)

Bug #3236 reported by Sitsofe Wheeler on 2005-10-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gst-plugins-bad-multiverse0.10 (Ubuntu)
Sebastian Dröge
totem (Ubuntu)

Bug Description

Despite having gstreamer0.8-faad installed I hear no sound out of the following videos when trying to play them in totem (gstreamer) or xine-ui:

The faad extracted audio track from ntv006.mp4 sounds fine.

I will note that the audio in previous nerdtv video files has sounded fine, so I don't think this problem is because I am missing a codec.

Changed in totem:
assignee: nobody → gnome

make sure you have gstreamer0.8-plugins and gstreamer0.8-plugins-multiverse installed, and see if this is still an isssue for you.

Sitsofe Wheeler (sitsofe) wrote :


After doing a presitine install of Breezy and installing gstreamer0.8-plugins, gstreamer0.8-plugins-multiverse and gstreamer0.8-ffmpeg I now get the following error message trying to play ntv006.mp4:

"Failed to play: Internal GStreamer error: pad problem. File a bug."

If totem is launched from the console I see:

(totem:8398): GStreamer-WARNING **: element internal_thread claimed state-change success,but state didn't change to PLAYING. State is PAUSED (NONE_PENDING pending), fix the element

** (totem:8398): CRITICAL **: gst_ffmpegdec_release_buffer: assertion `buf != NULL' failed

If I press the play/pause button repeatedly after dismissing the dialog I can get sound but no video and the following messages are printed on the terminal:

** (totem:8398): CRITICAL **: gst_ffmpegdec_release_buffer: assertion `buf != NULL' failed

(totem:8398): GStreamer-WARNING **: pushing data on non-negotiated pad ffdec_mpeg41:src, not allowed.

xine (which doesn't use gstreamer) still has the opposite problem - video but no sound.

I suspect this bug should have been split in two. The gstreamer problem now sounds like #2776 and the xine problem need to be classified separately.

That should have been bug #2776

...and bug #2776 looks in turn to be a duplicate of bug #2311

This bug is no longer a problem in the xine-ui within dapper but totem-gstreamer is no longer capable of playing mpeg4 files.

Sebastien Bacher (seb128) wrote :

Ccing slomo, he probably knows about mpeg4 reading :)

Sebastian Dröge (slomo) wrote :

Sitsofe, do you have gstreamer0.10-plugins-bad-multiverse installed? It includes the gst0.10 version of the faad plugin...

Sitsofe Wheeler (sitsofe) wrote :

No I didn't have gstreamer0.10-plugins-bad-multiverse (how did I overlook that?)

The good news is that ntv006.mp4 appears to play and there is the accompanying sound.

The bad news is that the brings up a dialog which says "Could not decode stream.". xine can play this file seemingly without problem though.

Daniel Holbach (dholbach) wrote :

Let's try to dissect the bug a bit.

Changed in totem:
assignee: gnome → desktop-bugs
status: Unconfirmed → Confirmed
Sebastian Dröge (slomo) wrote :

ok, let's take a look at it...
Do you have gstreamer0.10-plugins-bad installed?

Sebastian Dröge (slomo) wrote :

hm, tried to play it with gst-launch and qtdemux from plugins-bad installed:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /playbin0/decoder/faad0: Could not decode stream.
Additional debug info:
gstfaad.c(930): gst_faad_chain (): /playbin0/decoder/faad0:
Failed to decode buffer: Maximum number of scalefactor bands exceeded
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

sounds like either a bug in qtdemux (sending wrong data to faad), a bug in the faad2 gst0.10 element or a bug in faad (can't handle some new aac extensions or something). as xine works fine it should be the first or the second...

Sitsofe Wheeler (sitsofe) wrote :

And now after the latest round of gstreamer updates I think this problem has gone away...

Mark as fixed?

Mirco Müller (macslow) wrote :

No I would not mark it as fixed. I just ran into some H.264/AVC-encoded quicktime trailers where I get that exact same faad-related "Maximum number of scalefactor bands exceeded"-error. The example clips below used to work just a few days ago. I don't know in which update-cycle they stopped working. Only today I recognized that they don't work anymore.

I believe those URLs won't be valid for a long time. But it should be enough for you to grab them with curl or wget if you need some material to test.

Mirco Müller (macslow) wrote :

Damn it... forgot to mention that I'm running dapper (flight 7) here and using the most up-to-date gstreamer (in this particular case I've gstreamer0.10-plugins-bad 0.10.3-0ubuntu1 installed) bits from the repository. Ehm... according to the the gstreamer-plugin list faad should be part of gstreamer-plugins-bad 0.10.3. But

dpkg -L gstreamer0.10-plugins-bad | grep faad

does not yield any result on my system here. This seems to be wrong, doesn't it? Is this maybe a packageing error?

Sitsofe Wheeler (sitsofe) wrote :


I think this is a similar but different problem because first up your examples are H264 whereas mine where MPEG-4 video.

Secondly my examples played in xine but not gstreamer whereas yours seem to stutter and make a strange cricketty sound in xine even though there is a fair amount of CPU left.

Mirco Müller (macslow) wrote :

In the gstreamer-bugzilla for gst-plugins-bad 0.10.3 are some nasty issues discussed regarding faad ABI-incompatibilities for faad-CVS and last stable faad-release. I have the feeling this is not directly gstreamer- or totem-related at all. It would also explain why I have these faad-issues with gst-launch-0.10 and totem, but not with mplayer on my machine. Afaik mplayer uses compiled-in faad where as gstreamer uses a different (shared) library-version of faad. My installed faad-library is
2.0.0+cvs20040908+mp4v2+bmp-0ubuntu3. I don't know how to check which faad version is compiled into my mplayer (0.99+1.0pre7try2+cvs20060117-0ubuntu6). For sure is that mplayer doesn't use the shared library installed on my box. "ldd /usr/bin/mplayer | grep -i faad" did no produce any results. I hope this info helps a bit.

Tim Müller (t-i-m-zen) wrote :

FWIW, that some of those superman trailers didn't play due to faad erroring out was

and should be fixed in gst-plugins-bad CVS (patch should be easy to backport).

MacSlow: I doubt the faad binary incompatibility issues cited in GNOME bug #340762 apply to Ubuntu.

Sebastian Dröge (slomo) wrote :

Thanks Tim, I'll get this fix backported later :)

Changed in totem:
assignee: desktop-bugs → slomo
status: Confirmed → In Progress
Sebastian Dröge (slomo) wrote :

ok, the spiderman movies play fine for me with
gst-plugins-bad 0.10_0.10.3-0ubuntu2
gst-plugins-bad-multiverse 0.10_0.10.3-2

and it seems that both updates are necessary.

Changed in gst-plugins-bad-multiverse0.10:
status: In Progress → Fix Released
Sebastian Dröge (slomo) wrote :

And the ABI/API incompatibility of faad upstream is fixed for us. I put some effort into it to a) get us the latest CVS that we can ship (latest has a very bad license) and b) make it ABI/API compatible to the 2.0 release (the API changes were nonsense anyway... faad -> neroaac in general)

Sitsofe Wheeler (sitsofe) wrote :

Even the superman trailers work now. Can this be marked fixed?

Sebastian Dröge (slomo) wrote :

yes, I guess we should mark it as fixed ;)

Changed in totem:
status: Unconfirmed → Fix Released
Mirco Müller (macslow) wrote :

Indeed, totem and even my video-texture stuff - with the custom pipeline - works now with sound. Great! I'd say this is a "Fixed" candidate.

Simos Xenitellis  (simosx) wrote :

On vanilla 8.04, when I try to place the screencasts from

(such as,
GStreamer crashes without giving the option to install a supported codec package:

$ totem
** Message: Error: GStreamer encountered a general stream error.
qtdemux.c(1838): gst_qtdemux_loop (): /play/decodebin0/qtdemux0:
streaming stopped, reason not-negotiated

$ _

Installing manually the bad and ugly gstreamer packages solves the problem (totem with gstreamer backend).

Sitsofe Wheeler (sitsofe) wrote :

I think you would be better off filing a new bug report and posting a link to it from here.

Simos Xenitellis  (simosx) wrote :

Sitsofe: Thanks.
I made the new bug report, it's available at

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.