On Thu, 2009-01-22 at 16:52 +0800, Rob Kramer wrote:
> When playing with the video-player in clutter-gst/examples, I noticed the
> texture is not updated during the period that the sample effect ('e' key)
> animates. Is this a bug/incomplete feature, or is it expected behaviour?I'm completely talking out of my ass here (qualified only inasmuch as I've casually looked at the clutter-gst code), but I'm going to guess that it's expected (as in, works as designed) because of the way clutter-gst queues frames for drawing. When clutter-gst has a new frame to draw, it attaches an idle callback at G_PRIORITY_HIGH_IDLE (== 100). When there's a timeline running, it runs at CLUTTER_PRIORITY_TIMELINE (== 30). (As with nice, lower value is higher priority.) I assume this means that while the timeline is running, it may in practice starve the video. For Freevo, we're going our own route, primarily because we want to support other backends (mplayer and xine, notably), but also because it's a design goal to have the player backend run as a separate process (media players have a way of being unstable, especially with broken content). So, for our solution, frames are delivered over shared memory, and notified via a fifo. The fifo is a descriptor that can be monitored and wake up the mainloop's select() (or poll(), whichever it happens to use), as opposed to relying on an idle timeout. (The above is a slight over simplification, but the broad strokes are right.) Theoretically, I don't think it would be too hard to implement clutter-gst this way too. In fact, it's so obviously more correct that I have to wonder if there's not a good reason the authors used an idle timeout instead, which reason has eluded me. (Please educate me, if that's the case.) Cheers, Jason. -- To unsubscribe send a mail to [email protected]
