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 345513 - Movie playing fails with gstreamer but succeeds with mplayer
Movie playing fails with gstreamer but succeeds with mplayer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-06-21 08:24 UTC by Lubomir Marinov
Modified: 2008-10-04 21:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Lubomir Marinov 2006-06-21 08:24:28 UTC
I have this movie that doesn't start playin with gstreamer but plays fine with mplayer. Because the nature of the movie, it's probably not allowed to post parts of it here (not that I know how to do it), but I'm ready to carry out instructions if I'm required to.

$ gst-launch playbin uri=file:///home/lubo/share/movies/The\ Omen.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /playbin0/decoder/faad0: Could not decode stream.
Additional debug info:
gstfaad.c(1403): gst_faad_chain (): /playbin0/decoder/faad0:
Failed to decode buffer: Unexpected channel configuration change
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

$ mplayer -xy 2 share/movies/The\ Omen.mp4
MPlayer dev-SVN-r18765-4.1.1 (C) 2000-2006 MPlayer Team
CPU:                 Intel(R) Celeron(R) CPU 2.60GHz (Family: 15, Model: 2, Step
ping: 9)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2


Playing share/movies/The Omen.mp4.
ISO: Unknown File Type Major Brand: MSNV
Quicktime/MOV file format detected.
VIDEO:  [mp4v]  320x192  24bpp  25.000 fps    0.0 kbps ( 0.0 kbyte/s)
[VO_SDL] Using driver: x11.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
==========================================================================
Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder)
==========================================================================
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 320 x 192 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.67:1 - prescaling to correct movie aspect.
VO: [sdl] 320x192 => 640x384 Planar YV12
Selected font is fixed-width.
Comment 1 Tim-Philipp Müller 2006-06-21 12:43:00 UTC
Is this with gst-plugins-bad CVS? If not, could you try with CVS - there have been a few fixes since the last release.

If it is with CVS, could you do 

 $ head --bytes=5m foo.mp4 > foo-head.mp4

and temporarily put the file up somewhere? (otherwise find us in #gstreamer on irc.freenode.net).
Comment 2 Lubomir Marinov 2006-06-21 13:09:12 UTC
I'm sorry that I've missed to state that gst-plugins-bad is HEAD from CVS. I thought that it wasn't necessary because I've chosen the VERSION entry to be HEAD CVS.

I've updated (and compiled) gstreamer and gst-plugins-{base,good,ugly,bad} to CVS HEAD before entering the initial report in order to make sure that the problem is still there.

I've placed the sample that you've requested at http://85.130.21.195:8000/gst-bug-345513-head.mp4 which is on my computer. I suppose you're quite aware of it but I just want to tell that I've tried mplayer on the sample and it doesn't play.
Comment 3 Wim Taymans 2006-06-21 14:36:17 UTC
yeah, file is pretty broken, the stream info is at the end.
Comment 4 Edward Hervey 2006-06-21 14:53:06 UTC
Having the stream info at the end is perfectly valid in quicktime containers. qtdemux handles that correctly AFAIK.
Comment 5 Wim Taymans 2006-06-21 15:14:28 UTC
I know :) only there is no stream info because it was cut off with:

$ head --bytes=5m foo.mp4 > foo-head.mp4

I was just saying that the cut file from comment #2 is not enough to debug this properly.
Comment 6 Tim-Philipp Müller 2006-06-23 13:20:28 UTC
Lubomir: any chance you could make the last 1MB available as well?

 $ tail --bytes=1m foo.mp4 > foo-tail.mp4

and tell us the exact size of the file in bytes as output by

 $ ls -l foo.mp4

?

Comment 7 Lubomir Marinov 2006-06-23 16:37:26 UTC
Sure.

The last 1MB: http://85.130.21.195:8000/gst-bug-345513-tail.mp4
The size of the file in bytes: 622988557

Thank you for your persistence of interest.
Comment 8 Tim-Philipp Müller 2006-08-10 17:21:01 UTC
Sorry for the long delay in responding. Could you make the tail available again, I seem to have misplaced it (or never downloaded it, not sure).

Comment 9 Lubomir Marinov 2006-08-10 17:41:43 UTC
(In reply to comment #8)
> Sorry for the long delay in responding. Could you make the tail available
> again, I seem to have misplaced it (or never downloaded it, not sure).
> 

I'll try to make the required information available. Because the tail never got downloaded, there was no request for a long time and the movie was taking ~600MB of my drive, I deleted it the day before yesterday. I've just started re-downloading it and I'll need some time to finish the download because there aren't many seeders.
Comment 10 Lubomir Marinov 2006-08-11 05:36:39 UTC
(In reply to comment #8)
> Sorry for the long delay in responding. Could you make the tail available
> again, I seem to have misplaced it (or never downloaded it, not sure).
> 

http://85.130.8.235:8000/gst-bug-345513-tail.mp4

Please, do not hesitate to request more information.
Comment 11 Tim-Philipp Müller 2006-08-11 08:56:05 UTC
Thanks for sticking with us :)

Unfortunately, I've underestimated the length of the stuff at the end. Any chance you could provide the last 5 MB instead of only the last 1MB?

$ tail --bytes=5m foo.mp4 > foo-tail.mp4

Comment 12 Lubomir Marinov 2006-08-11 14:18:07 UTC
(In reply to comment #11)
> Thanks for sticking with us :)
> 
> Unfortunately, I've underestimated the length of the stuff at the end. Any
> chance you could provide the last 5 MB instead of only the last 1MB?
> 
> $ tail --bytes=5m foo.mp4 > foo-tail.mp4
> 

http://85.130.8.235:8000/gst-bug-345513-tail-5m.mp4
Comment 13 Wim Taymans 2008-10-03 16:32:13 UTC
most likely fixed by now, please reopen if the problem remains.