GNOME Bugzilla – Bug 324082
[qtdemux] [faad] playback issues with quicktime videos
Last modified: 2006-05-03 21:49:44 UTC
Totem + gst 0.10 (including gst-ffmpeg HEAD) has problems playing back the videos @ http://rubyonrails.org/screencasts. Symptoms are: 1. qtdemux errors in terminal. "Can't decode stream" dialog appears. 2. grey rectangle with the changes in frames gradually appearing (start out with a grey rectangle, text appears as the user enters it in the video; old changes are not being cleared etc) 3. Problems reading local file: (totem:21620): libgnomevfs-CRITICAL **: gnome_vfs_read_cancellable: assertion `handle != NULL' failed ERROR (0x8ff39c8 - 0:00:02.739307000) gnomevfssrc(21620) gstgnomevfssrc.c(1036):gst_gnomevfssrc_create:<source> Failed to read data: Invalid parameters 4. "Internal dataflow error" dialog appears for the flickr video on the above page.
I think (3) and (4) are unrelated to this, and (4) seems to be due to (3). I've never been able to reproduce those libgnomevfs warnings, but now I just got it on an AVI file (but only once, not reproducable).
Ronald tested the videos with 0.8. They play fine with 0.8. So this is a regression.
by uncommenting "#define FORCE_OUR_GET_BUFFER" in gstffmpegdec.c HEAD, it works perfectly fine (no more gray, just like 0.8).
Created attachment 59254 [details] [review] patch for our get/release buffer functions in gstffmpeggdecoders
damn bugzilla, patch for the wrong bug :)
ping?
Just built everything from HEAD (including gst-ffmpeg). I still get decoding errors and the "Cannot decode stream" dialog when playing the flickr video: $ totem flickr-rails-ajax.mov ERROR (0x921a0d0 - 0:00:02.326256000) qtdemux(28326) qtdemux.c(1461):qtdemux_parse: atom length too long (1441792 > 26) ERROR (0x921a0d0 - 0:00:02.326582000) qtdemux(28326) qtdemux.c(1457):qtdemux_parse: atom length too short (0 < 8) ERROR (0x921a0d0 - 0:00:02.326692000) qtdemux(28326) qtdemux.c(1609):qtdemux_parse: length too long (1751411826 > 407) ERROR (0x921a0d0 - 0:00:02.326807000) qtdemux(28326) qtdemux.c(1526):qtdemux_parse: length too long (1024 > 151) ERROR (0x921a0d0 - 0:00:02.326914000) qtdemux(28326) qtdemux.c(1457):qtdemux_parse: atom length too short (0 < 8) ERROR (0x921a0d0 - 0:00:02.327046000) qtdemux(28326) qtdemux.c(1457):qtdemux_parse: atom length too short (0 < 8) ERROR (0x921a0d0 - 0:00:02.327149000) qtdemux(28326) qtdemux.c(1457):qtdemux_parse: atom length too short (0 < 8) Other quicktime videos also still start out totally black and only updates/changes appear in the video. I'll attach a screenshot.
Created attachment 59697 [details] rails-ajax.mov video screenshot
I can't reproduce the "Other quicktime videos also still start out totally black and only updates/changes appear in the video" error with current cvs but i can reproduce the error with the flickr video. The error is in faad: ERROR: from element /pipeline0/decodebin0/faad0: Could not decode stream. Additional debug info: gstfaad.c(930): gst_faad_chain (): /pipeline0/decodebin0/faad0: Failed to decode buffer: Maximum number of scalefactor bands exceeded
Jeroen : the problem is this codec does not support seeking. If you use mplayer and seek through the file you will encounter the same thing. The only difference I notice is the very first image not being displayed.
I'm not seeking when playing back the videos. I just launch totem with the quicktime video and sit back (and watch the errors appear).
Using mplayer, seeking using "up" and "down" (seek backward/forward 1 minute) works. What doesn't sometimes work is seeking using "left" and "right" buttons.
seek fine. faaddec has the usual problem (see #332892), video seems to freeze for some reason, seeking restarts it. Also appears to leak quite a lot of memory, maybe it's related.
All of these work fine for me now with CVS (after the latest fixes to faad in gst-plugins-bad).
Assuming qtdemux rewrite and faad fixes in CVS fixed this issue. Videos look fine for me now even without the get_buffer function patch. Please re-open if there are still problems with CVS -bad and -ffmpeg.