On Tue, 2005-08-02 at 16:45 +0200, Dirk Meyer wrote: > > provide a unified API for both backends. You just tell it which one you > > want to use, or let it auto-detect (i.e. dvd:// will use xine, foo.avi > > will use mplayer). Perhaps CanvasMovie is a misnomer. > > But it should be possible to choose a player.
Right, hence the "tell it which one you want to use" part. :) > Maybe. But we shouldn't remove too much power. E.g. the reason for the > big number of deinterlacer in mplayer is that some people prefer > deinterlacer a) and some b). We should support some way for the user > to choose (config file?) Yeah. We can't completely hide all the details of the underlying player. But we can put the appropriate abstractions in place and make it tunable. So you can define at runtime what the "high quality deinterlacer" is for the xine backend, for example. I also had the idea of doing dynamic adjustments with xine based on cpu load. So if the user has selected TomsMoComp deinterlacer, but the CPU is maxing out and it's dropping frames, fall back to LinearBlend, and then half frame rate, and then use cheap mode, etc. 'course kaa will need some way to get current cpu load. :) > position. BTW, remember audio playback where you have no window. And > maybe show goom at an evas object (and pygoom for mplayer). I'm probably going to need to call kaa.metadata.parse() on the file before hand anyway. (Should _that_ be done asynchronously too? After all, it could take longer than 100ms.) So I'll know if the file has no video stream, and if it doesn't, I don't need to bother creating a window. Anyway it's not a difficult problem to solve. > It would be nice to have a 800x600 screen for freevo and when we start > a 640x480 mplayer, everything is scaled down to fit and scaled up > again after playing. Well, think of html. The images don't get scaled between different resolutions, but the overall layout does scale. That's my goal. > I want to move some gui elements between display canvas objects. That's more difficult than it sounds. :) But I know it's a requirement. The new kaa.canvas should have this feature. The high level Objects need to know how to construct themselves on an evas canvas. This is also needed because it should be possible to create an object before it is associated with a canvas. But you can't do that with evas, so it has to be implemented at a higher level. Anyway, the point is it should be possible. And not only that, with relative coordinates, it should Just Work. So if you have a container whose size is 50% and is centered that's on a canvas that's 640 pixels wide, the container is 320 pixels wide. Reparenting the container onto a canvas that's 800 pixels wide should automatically reflow all the container's children to reflect the new position and size. None of that is done yet. But that's the sort of thing I had in mind. If you have some ideas, now's the time to speak up. :) > -vf export is no problem for small cpus. So we could be sure it is > always the correct aspect. I guess you mean -vf expand. It should be possible to maintain aspect with vf_expand. I'll need to know the movie dimensions and aspect ratio before starting MPlayer, however. That's where kaa.metadata comes in. (Bug report: kaa.metadata fails to get the display size and/or aspect ratio of my matroska files.) So, just thinking aloud here, given the movie width, height, aspect, and given target_aspect, we have ... adjust = aspect / (width / height) new_height = width / target_aspect * adjust And load -vf expand=width:new_height Of course, without software scaling, if we're playing a VCD that's 352x240, which gets expanded to 352x264, that means our OSD canvas is that big. Jason.
signature.asc
Description: This is a digitally signed message part
