Hi all,

> Does turning sink off just result in the sink rendering it as soon as
> it gets data?

Essentially, yes. Data is played when it arrives when sync=false. When
sync=true, it uses the timestamps on the buffers to wait for right time
for playback. If the playback is stuttering this is usually because of
a) starvation, something is not feeding data fast enough b) bad
timestamps c) not enough CPU power to decode things. a) is unlikely with
a default jitterbuffer of 3secs in rtspsrc c) is also unlikely if it's
smooth with sync=false. So, it's likely b) bad timestamps. Make sure you
have a recent ffmpeg package (reordered buffers had bad timestamps in
earlier versions). The payloader is probably fine, even for slightly
older versions.

I think also it is unlikely a) or c), because my dev box is an el-cheapo Intel PC (where it works), and the test machine is a fairly new Dell server (where it doesn't work), so it has a lot more CPU power...

I'll investigate b) though, especially since hardy ubuntu packages are likely a bit older than the most recent versions of things...

Just another thought I had while drifting off to sleep last night... :-)

One of the major hardware differences between my dev box (working) and the test machine (stuttering), is that my dev box has a sound card, whereas the test machine does not.  Could it be that one of the gstreamer elements/clocks is trying to access the clock on the soundcard, and therefore failing because of course there isn't one?

Having said that, I have done a couple of other tests on the test machine:

1) playback from a quicktime movie file containing mp4v video, no audio - playback is smooth.
2) playback from a quicktime movie file containing h264 video + some sort of mpeg audio - playback is smooth also, although get the following message: "** Message: don't know how to handle audio/mpeg..." which I guess is expected seeing as there is no soundcard.