(CCing freevo-devel list.) On Mon, 2006-04-10 at 10:09 +0530, sriraman g wrote: > if i am using VF_OSD for full overlay (PAL-768x576)...
First off, are you using vf_osd or vf_overlay? vf_osd was the old name for the patch, and since my last cut under the vf_osd name, there have been a lot of changes and some performance improvements. > I.E i am overlaying one movie on top of another (with some effects)..... I > found that the play back of overlayied movie is slightly jerking.. I belive > this is because when we updated entire screen with full frame rate the RGBA > to YUVA conversion takes some time.....am i right?...... If you are playing a full sized movie on top of another full sized movie, you're going to need a very fast CPU to do this smoothly. The colorspace conversion and alpha premultiplication steps do take quite a lot of time, yes. Every time you update the overlay this must be done. But your particular issue may not be CPU related. The obvious way to tell is run top while it's running. Is your CPU maxed? If so, then yes, the jerkiness is due to dropped frames. If no, then the jerkiness is a timing issue. vf_overlay does some internal trickery to allow its frame rate to update independently of the movie's frame rate. This involves adding code into mplayer's timing loops. It's hard to get this right. I've noticed recently myself there is some jerkiness in the movie during certain overlay updates -- even very simple ones. I meant to look into this but I haven't had time. > How can i sove this....... > say if want to use YUVA directly what and all changes are required to be > made in the vf_osd... If it's a CPU limiting issue there's not much you can do except get a faster CPU. Well, you could try shrinking the size of the movie you're overlaying and not using any translucency. Reducing the size of the movie will go a long way to improving performance. If you use vf_outbuf, use the outbuf slave command like: "outbuf 2 320 200" which will scale the video to 320x200 and write that to the shmem buffer. Using YUV directly and avoiding the colorspace conversion is theoretically possible, and it's something I'd like to add eventually, but it's a low priority. I say it's a low priority because it's really not useful except for situations like this movie-on-movie stuff. vf_overlay wasn't really designed to do movie-on-movie as efficiently as possible because, as you guessed, that requires 2 colorspace conversions (YUV -> RGB -> YUV) that aren't necessary in this case. I just demo movie-on-movie as a stress test for the code. By the way, you may want to subscribe to freevo-devel list (which I am CCing on this email). Others there may be interested in this and it's good to have a record. Please consider subscribing and asking questions there. Cheers, Jason. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
