On Monday 10 March 2008 18:03:28 Siarhei Siamashka wrote: > 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 don't think the zaurus hardware supports YUY2 - only YV12, but I would have to check.
> > 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. > Nope, not enough for 640x360 - again I think this has a lot to do with the extra bandwidth on the SDRAM bus of using a higher res display. > > 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. > I *want* to put the data in the write cache, other wise the CPU spends much time stalled while the video controller DMAs out memory. I'm also not sure if the write buffer is enabled on this memory, hitting performance even more. The cache will help more for the rotation code, but I think it will help for the normal copy, just to prevent the stalling due to DMA. > 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? > No, I keep meaning to get round to doing this - it could be I am completely wrong, but the benchmarks I do in mplayer always point me in this direction, and the improvement in the old cacko rom always came from increasing the bus speed, not the cpu speed. > > 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? > Well, you need double buffering for smooth tear free playback anyway. My idea is to have 2 cached areas of memory - one is displaying current frame, the other is having next frame written to it. mplayer then completes the frame, which will cause a cache flush on that region, and the two buffers to be swapped by the video driver. Thanks, Tim _______________________________________________ Angstrom-distro-users mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users
