mdk

One mutex short

05 Jul 2005 » permalink

GStreamer rocks in terms of design, but this an uncharted territory yet. It seems I'm slowly moving forward, but along the way I bump all the time on strange issues and (perhaps?) bugs. I decided to skip them right now and not waste time on things I that can be (temporarily) driven around. Ronald gives a helping hand, but I can’t bug him all the time ;)

I did some “proof-of-concepts” recently and now I'm wrapping that into a decent libGdv code. It looks like I managed to achieve a nice, not-a-single-frame-dropped timeline interface. Actually it’s somewhat better than the Totem thing in terms of playback:

• If you do a short play/pause/play sequence, it doesn’t “skip” anything. Totem tends to skip a few frames of video (or some audio) to re-synchronize the playback. This is so even for the interleaved frame-based codecs like DV or MJPEG.
• It supports a cool seeking with preview (paused mode). That’s very smooth. You can move the slider (or anything for that purpose) and the video is dynamically updated. It works so fast that you can (by moving the slider at the proper rate) “play” the movie/composition/timeline. In Totem 1.0.3 that I have here that’s not possible (the clip display is updated only when you start the movie).
• Playback is buffered — not only on the file-reading side but also on the display side. The pipeline can process things ahead of the playback.

All this comes at the cost of a certain start/stop latency. Play to pause is instant. But pause to play has a small latency (around 1/5th of a second). That’s noticable. It’s partially my implementation, and partially GStreamer itself. Anyways, I think that for a video editor that’s acceptable.

Note: It’s a shame but the SoC photo gallery triggers the infamous nvidia bug on my box (it happens very rarely on my machine). Perhaps something can be done about that? I suppose I'm not the only one that suffers.