GNOME Bugzilla – Bug 321351
extracted AAC output is played too slow
Last modified: 2006-05-03 21:49:30 UTC
I would like to have the original audio in a file of its own from this trailer (120MB) http://images.apple.com/movies/us/hd_gallery/gl1800/kingdom_of_heaven_m720p.mov and to do that I use gst-launch filesrc location=file.mov ! qtdemux .audio_00 ! ffmux_mp4 ! filesink location=file.m4a When file.m4a is played in Totem it is played much too play. mplayer can't play the file, so I can't compare. But if I play the movie in mplayer with mplayer -vo null kingdom_of_heaven_m720p.mov so no video is outputted, I measure the time when the word "no" is said in the sentance: "There are here." "There is only one man." "No, they are here." to 160 seconds in player and 139 seconds in Totem. This is done using a stop watch. My computer is too slow to play high definition video, so when played with video in mplayer the audio is correct, but the video is very out-of-sync. Totem seams to been in sync, but the audio is played too slow. These are the GStreamer related packages I have installed: $ rpm -qa|grep gstreamer gstreamer-python-debuginfo-0.8.2-0.gst.1.4 gstreamer-python-0.8.2-0.gst.1.4 gstreamer-ffmpeg-0.8.6-0.gst.1.4 gstreamer-plugins-video-0.8.11-0.gst.1.4 gstreamer-0.8.11-0.gst.1.4 gstreamer-plugins-extra-video-0.8.11-0.gst.1.4 gstreamer-devel-0.8.11-0.gst.1.4 gstreamer-tools-0.9.4-0.gst.1.4 gstreamer-plugins-debuginfo-0.8.11-0.gst.1.4 gstreamer-plugins-extra-debuginfo-0.8.11-0.gst.1.4 gstreamer-plugins-extra-audio-0.8.11-0.gst.1.4 gstreamer-plugins-audio-0.8.11-0.gst.1.4 gstreamer-plugins-extra-dvd-0.8.11-0.gst.1.4 gstreamer-plugins-0.8.11-0.gst.1.4 gstreamer-ffmpeg-debuginfo-0.8.6-0.gst.1.4 gstreamer-plugins-devel-0.8.11-0.gst.1.4
I can't reproduce it.. are you sure? With current gst 0.10 cvs: - i hear "No, they are here" after 140s With mplayer: - i hear "No, they are here" after 140s (you can also seek with the arrows and you'll see timestamp information in mplayer's output) With xine: - it segfaults :/ It seems to work fine!
I can reproduce it with 0.8. Is it the ripped m4a file you are measuring on? Are you using a stop watch? We can't relay on the timer in Totem, if the bug is infact the timer.
I'm not using the m4a file because there's no ffmux_mp4 in gst0.10 (yet). The fact is that mplayer tells me that "no, they are here" is after 140s not after 160s as you were reporting on your original bug. Or maybe i've not understood correctly the report..
If I play the mov file in Totem with 0.8 "no, they are here" measures 1:40. If I play the m4a file in Totem with 0.8 "no, they are here" measures 1:60. I think that's the reporters problem. Louise?
It is the m4a that is played much too slow in Totem.
For me, with current CVS of 0.10 and totem ... * kingdom_of_heaven.mov - The 'no they are here' is at 140 seconds (02m20s) * kingdom_of_heaven.m4a (created using the above GStreamer-0.8 pipeline) - the 'no they are here' is at 140 seconds with mplayer 0.99+1.0pre7try2+cvs20060117-0ubuntu5 ... * kingdom_of_heaven.mov - The 'no they are here' is at 140 seconds (02m20s) * kingdom_of_heaven.m4a (created using the above GStreamer-0.8 pipeline) - doesn't play - complains about missing average bitrate in header Is this as it should be?
Yes, just that =) 140 seconds is current!
So this bug can be closed then, right?
Yes, plese close it. And thanks for the help =)
Reopening, this file doesn't play correctly.
Now setting as a duplicate; the remaining problem is noted in bug #334748 (the audio bitstream has the wrong sample rate, the demuxer is correct but this is ignored). The result is that we get frequent skipping when playing back this file, though it does remain in sync. *** This bug has been marked as a duplicate of 334748 ***