And it's crackling, right? I think timestamps in gst-ffmpeg are messed up, I
didn't look into that in detail yet. It's better than it used to be, though.

No cracking in the audio at all. Audio is perfect it just leads video by a
couple seconds for me. I can try with different kernels tonight to see if that
as any effect on the audio...

It is specific to this movie, and probably related to the crackling audio. I
can't say why. This is a nice stresstest for alsasink, btw. :).

audio is crackling for me too, with alsasink and esdsink

which audiosink do you use Darren ? (that produces no cracks)

I have the exact same problem.  I'll try cvs -- but I have MUCH worse problems
on almost every video I've ever tried.

Interestingly, I set up a brand new box with the latest gstreamer on FC3 and I
do get the crackling on it. Right next to it I have an older FC2 machine running
older code which doesn't crakle. I don't know what audiosink is being used (is
it output to a log somewhere?) I'm running totem on FC3 and I'd guess it is alsa
sink on both boxes. The interesting thing about the crackling on the new box is
that it only comes from the right channel speaker. It seems the left channel
plays perfectly but the right channel seems to be playing the sound in ~1 second
chunks about 5 times too fast. Ronald may be onto something when he mentioned
above the timestamps may be messed up on the right channel. If I turn the right
PCM volume all the way down the right channel (and the crackling sound goes away). 
My FC2 box that doesn't crackle doesn't play the right channel sound either
(right speaker is totally silent--only on this .mov) and it's currently running
gstreamer 0.8.7-0 and plugins 0.8.5-0. While I'm running gstreamer 0.8.7-4 and
plugins 0.8.6-0 on the crackling FC3 box.

This reminds me of a emms bug... Hmm...

Look at

gst-launch filesrc location=~/Media/bugs/menace00.mov ! qtdemux .audio_00 ! {
queue ! ffdec_adpcm_ima_qt ! audioconvert ! audioscale ! alsasink device=dmix }
{ qtdemux0.video_00 ! queue ! ffdec_svq1 ! ffmpegcolorspace ! xvimagesink }

which crackles, whereas

gst-launch filesrc location=~/Media/bugs/menace00.mov ! qtdemux .audio_00 ! {
queue ! ffdec_adpcm_ima_qt ! audioconvert ! audioscale ! alsasink device=dmix }

works perfectly. Note that the same goes if you remove audioscale/audioconvert.
Also, osssink works fine (with video). Valgrind shows no interesting debugs
inside ffmpeg... I can't get too much interesting data from alsasink, but I
suppose that's where we should look. Maybe this is because we use very small
sample buffers?

Ths file is no longer in the mplayer repository. Setting as NEEDINFO for now..
can someone provide it? thanks!

 http://gstreamer.freedesktop.org/media/incoming/menace00.mov

Cheers
 -Tim

the crackling has gone, but the AV synch problem is still there.

Just to keep this bug alive, the problem persists with current CVS head.

the edit lists are ignore by the qt demuxer.

        * gst/qtdemux/qtdemux.c: (gst_qtdemux_init),
        (gst_qtdemux_handle_src_query), (gst_qtdemux_find_index),
        (gst_qtdemux_find_keyframe), (gst_qtdemux_find_segment),
        (gst_qtdemux_move_stream), (gst_qtdemux_perform_seek),
        (gst_qtdemux_do_seek), (gst_qtdemux_change_state),
        (gst_qtdemux_activate_segment),
        (gst_qtdemux_prepare_current_sample), (gst_qtdemux_advance_sample),
        (gst_qtdemux_loop_state_movie), (gst_qtdemux_loop),
        (qtdemux_parse_trak):
        Added full edit list support.
        Avoid overflows in prologue image detection code.
        Avoid roundoff errors in timestamp calculations.