Jason Tackaberry wrote: > 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. :)
Nice idea. >> 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.) For files on hd, it only needs a very short time. But for files on rom drives it could take a while (e.g. spin up or read problems). So maybe do this in a thread. >> 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 don't think it will work for freevo. > (Bug report: kaa.metadata fails to get the display size and/or aspect > ratio of my matroska files.) I have no matroska files. Send me one (small) file and I will take a look at it. > 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. And when freevo has a big image to show, it won't find with your html-style. I would prefer dynamic resizing. Dischi -- Press any key to continue or any other key to quit...
pgpmrNy2hcNoK.pgp
Description: PGP signature
