On Mon, Mar 10, 2008 at 4:06 PM, Tim Chick <[EMAIL PROTECTED]> wrote: > OK, the c1000 and c3x000 NATIVE resolution is > > 480x640 - 480 WIDE by 640 HIGH, NOT 640 wide by 480 high. > > So when you encode a video at 640x480, and try to play with -vo pxa, it > will try to open a framebuffer of size 640x480, which is too big, as > the biggest supported is 480x640.
Thank you for this bit of information, I did not know it. By the way, theoretically it should be even possible to produce rotated image at the decoding stage, but it may take too much efforts and better solutions may exist. > I put in some fairly OK rotation support into the mplayer pxa driver, > but this is software 0 there is no hardware support. How do you know that it is OK? What fraction of memcpy performance do you get in your benchmarks? My YV12->YUY2 scaler is generally within 70% of memcpy performance on Nokia 770 for example. So I can say it is pretty fast ;-) Theoretically the scaler can be modified to also support rotation in process, but I need to think about it a bit more. Anyway, it's not like I'm going to *sell* anything to you, take it or leave it :-) > I *ONLY* bothered with this in 240x320 mode, as the zaurus DOES NOT have the > cpu to play > 480x640 movies at a good frame rate - so there is no point. What about playing lower resolution videos such as 640x360 for example? Having arbitrary resolution support may be not a bad idea as long as the resolution of video remains reasonably small to have enough resources for decoding and displaying it. > You should get very good results with video of 320x240 size, encoded > just about any way, with more or less any audio format, as long as the > bitrate is 44.1kHz or 48kHz. If the audio is 32kHz it will play really > badly - check this by putting the -noaudio (might be -nosound, can't > remember) flag to mplayer. This is fixable by using you .asoundrc to > software resample from 32kHz to 44.1kHz before giving to the hardware. > I have tested using .asoundrc to do this and it works. I think you can > also get mplayer to do this in software too. If 32kHz is bad, you can hack alsa output driver to report that this sample rate is not supported. In this case mplayer will resample it as needed. In any case, it is better to use the sample rate properly supported by hardware. [...] > Now for the 640x480 video. There are 3 problems: > 1 - the video overlay uses uncached memory. What is the problem with uncached memory? Do you have any serious need to read from framebuffer? Actually, if it gets cached, that will only introduce cache pollution with unneeded data when writing data to it (that is if xscale uses write-allocate cache, ARM9 and ARM11 do not seem to have this feature). On x86, there is a special instruction for writing to memory bypassing cache to solve cache pollution problem and improve performance for large transfers. So in my opinion uncached memory should have no negative effect on the performance. Have you compared the performance of your rotation code for output buffer in normal memory vs. framebuffer? > The frame buffer driver needs to be updated to allow the use of cached > memory with double > buffering and a mechanism to flush the cache. Don't understand the double buffering part, could you please explain it with a bit more details? _______________________________________________ Angstrom-distro-users mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users
