[maemo-developers] N800 & Video playback

[From: Daniel Stone]

On Tue, May 01, 2007 at 11:51:50AM +0300, ext Siarhei Siamashka wrote:
> On Monday 30 April 2007 17:49, Daniel Stone wrote:
> > Indeed.  Unfortunately this is slightly misleading in that it only shows
> > the raw write speed.  RFBI can't deal with the sorts of speeds that your
> > hyper-optimised version is pumping out, e.g.  So it's mainly just about
> > cutting the latency into the critical path to low enough that it makes
> > no difference.
> 
> The 'framebuffer' is just the ordinary system memory, converting color format 
> and copying data to framebuffer will be done with the same performance as 
> simulated in this test. RFBI performance is only critical for asynchronous
> DMA data transfer to LCD controller which does not introduce any overhead 
> and is performed at the same time as ARM core is doing some other work
> (decoding the next frame). RFBI performance matters only if data transfer to
> LCD is still not complete at the time when the next frame is already decoded
> and is ready to be displayed. When playing video, ARM core and LCD controller
> are almost always working at the same time performing different tasks in
> parallel. I think I had already explained these details in [1]

Right.  My point is that the numbers you're showing -- while very good,
don't get me wrong -- won't necessarily have a huge direct impact on
video playback.  Particularly if you want to avoid tearing.

> So now the results of the tests are consistent - when doing video output, most
> of ARM core cycles are spent in this 'omapCopyPlanarDataYUV420' function.

Well, either that, or just waiting for RFBI transfers to complete.

> Optimizing it using 'yv12_to_yuv420_line_armv6' will definitely provide a huge
> effect, video output overhead when using Xv will be at least halved providing
> more cpu resources for video decoding.

Yes, this is one good aspect.

> > I don't have any tips, per se.  Once I get it all integrated it'll be in
> > git, but for now, the only public source is the packages.
> 
> OK, thanks. It may take some time though. I'm still using old scratchbox
> with mistral SDK here (did not have enough free time to upgrade yet). Until I
> clean up my scratchbox mess, I can only provide some patch without testing, if
> anybody courageous can try to build it :)

I'm still using Scratchbox 0.9.8.5 for day-to-day stuff ...

> Well, anyway, everything worked perfectly and I could play 640x480 video 
> on N800 with the following statistics:
> 
> VIDEO:  [DIVX]  640x480  12bpp  23.976 fps  886.7 kbps (108.2 kbyte/s)
> ...
> BENCHMARKs: VC:  87,757s VO:   8,712s A:   1,314s Sys:   3,835s =  101,618s
> BENCHMARK%: VC: 86,3592% VO:  8,5736% A:  1,2932% Sys:  3,7740% = 100,0000%
> BENCHMARKn: disp: 2044 (20,11 fps)  drop: 355 (14%)  total: 2399 (23,61 fps)
> 
> As you see, mplayer took 8.712 seconds to display 2044 VGA resolution frames. 
> If we do the necessary calculations, that's 72 millions pixels per second,
> quite close to 'yv12_to_yuv420_line_armv6' capabilities limit, so this
> function is the only major contributor to video output time. Video output
> took much less time than decoding, so it proves that video output 
> overhead can be reduced to minimum (in this test tearsync was not used
> though).

I'd be curious to see the results from this with tearsync _enabled_?
i.e., after your OMAPFB_UPDATE_WIDNOW call, issue an OMAPFB_SYNC_GFX
ioctl before you start writing to memory again.  This is basically the
limiter for us at this stage.

> When tearsync comes into action, everything gets a bit more complicated. I'm
> still investigating its impact on video playback performance.

'Not good'. :)

Thanks again for your work.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20070502/547837ab/attachment.pgp