On Thu, Jan 22, 2009 at 11:33:06AM -0500, Jason Tackaberry wrote:
> 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.Hmmm, I hope this is NOT the intended behaviour :) Usually you can prevent this by setting the CLUTTER_VBLANK environment variable to "none" and/or disabling vblanking for your graphics adapter (drirc or nvidia-settings, depends on your hardware). However, videos might have tearing effects when vblanking is disabled, but otherwise you wouldn't be able to have for example an animated logo or newsticker as video overlay. > 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. Setting a higher priority (G_PRIORITY_DEFAULT) is what I do for my application, as playing videos smooth is most important for me. But in this case, you might have choppy animations. Perhaps somebody should take a look at the pigment library. IIRC this works pretty fine there... > 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. Nice approach. Maybe I'll this too. Is there already some example code in kaa/freevo? > 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.) Start hacking on clutter-gst ;) So long :wq buz -- GnuPG Fingerprint: 2FFF FC48 C7DF 1EA0 00A0 FD53 8C35 FD2E 6908 7B82
signature.asc
Description: Digital signature
