On Mon, 2004-07-12 at 21:52 +0200, Dirk Meyer wrote: > Wow! The imagedemo needs to be a freevo plugin, this is so cool and > looks much better than my bmovl plugin.
The imagedemo specifically, or the canvas in general? Or maybe you mean the OSD demo? imagedemo isn't especially useful for anything except to maybe demonstrate the canvas. :) > So a suggestion: integrate it into Freevo :-) That's why I released it. Hopefully someone will. And if freevo uses bmovl2, there will be more reason for it to be accepted upstream. > A small bug report: the demo expects the stream to start at 0 > seconds. This is not correct for my dvb recordings so I don't see the > current position. Check latest mmpython how to get the start position > of a movie before it starts to play. Yeah, the timeshifting stuff has that problem too. But it's not terribly difficult to fix. Thanks for the pointer to mmpython. > I don't think of using mplayer as osd for everything, but what you did > here looks so cool (I'm repeating myself). At least for mplayer we > need this (who will write a bmovl2 plugin for xine?). Maybe we can In theory bmovl2 should be pretty portable. I think the main problem with porting is going to be making it so bmovl2 can still respond to commands while paused, because in this sense it does not act like a typical video filter. It required modifying MPlayer's mainloop because this is non-standard behaviour for a video filter. I imagine similar changes would need to be made to xine, ogle, or whatever, unless their designs are very forward-thinking. :) > find an interface to draw stuff that works with mplayer and pygame. If pygame should have no problems using bmovl2. In fact, one could probably easily make a class that implements the same of methods the canvas uses from pyimlib2. Another approach would just be to modify the canvas code itself to call pygame directly to do image manipulation. The image operations are pretty well contained in the CanvasImage class (with a couple exceptions). I wrote pyimlib2 because pygame seemed to require initializing a display of some sort, and I couldn't figure out how to get around that. Another benefit of writing pyimlib2 is that I could add some custom code to generate YV12A (which is not a fourcc code, it's something I made up, and it's basically just planar 4:2:0:4) and also be able to mmap raw image data. bmovl2 will work with straight RGB[A] over the fifo, but the performance gains from mmapping YV12A are appreciable. > you like the idea of merging mebox into Freevo, we should discuss your > needs to the osd api on freevo-devel. MeBox isn't really anything that can be merged. At least, most of the code I've already written is now available, or it's pretty much redundant for freevo. (Reinvented wheels.) Mostly MeBox is a collection of ideas in my head, and a lot of wishful thinking about what I could do with my free time if I had more of it. :) But the truth is that I'm less interested in using the end product as I am in developing it. To be honest, I use freevo and am mostly pretty happy with it. So MeBox isn't as much about scratching itches as it is about solving problems that are interesting to me. For example, I wrote an asynchronous VFS to handle file ops and metadata because I wanted to see just how fast and how responsive I could get it. Not very useful for Freevo (since it already has a vfs) but an interesting problem to solve. :) So my main goal is to have fun hacking this thing that I may end up never using, but coding it in such a way that parts can be dissected and hopefully recycled into other projects like Freevo. It'd be really cool to see Freevo use bmovl2 and/or the time shifting code. > My idea: stuff like popup boxes don't need to know if they write on > the menu or on mplayer. That's actually how my idea started, but then it got extended to "why should anything care what it's being drawn to?" Why should I have to stop watching this movie in order to schedule that episode of Angel that's about to start in 5 minutes? With all UI operations done through the canvas, I'm pretty insulated against lock-in. Using mplayer as a platform for everything has benefits and is kinda interesting, but I don't try to convince myself that it isn't anything but a huge hack. Nevertheless, the distinct layers in the design make this hack somewhat less ugly and, in some strange way, even graceful. It's one of the reasons I called it the "MeBox Canvas" rather than "MPlayer Canvas." I tried to imply that the canvas architecture isn't tied into MPlayer, but rather MPlayer+bmovl2 is just one of the displays it supports. (And the only one right now.) But I digress. A lot. :) Cheers, Jason.
signature.asc
Description: This is a digitally signed message part
