[maemo-developers] DVD content playback possible or not? Re: Wishlist (was:Re: N800 and USB host mode)

[From: Siarhei Siamashka]

On Friday 09 March 2007 12:20, Daniel Stone wrote:

> On Fri, Mar 09, 2007 at 09:45:03AM +0100, ext Hanno Zulla wrote:
> > > Right now, the biggest bottleneck in video decoding is RFBI bandwidth
> > > (i.e. the bus between OMAP and the LCD controller we use), being too
> > > slow to push more than ~15fps through at 800x480.  Beefing up the
> > > processor-side decoding doesn't help.  We've been working on this and
> > > the next firmware update will give you significantly faster video (with
> > > a couple of caveats).
> > >
> > > So it's mostly just down to the large image display, which more or less
> > > suffers from the same problem.  I don't think it would give us much
> > > benefit at all.
> >
> > So from the hardware side, it is definitely no-matter-what-you-try
> > impossible to play DVD video content on the N800, even if there was help
> > from the DSP?
>
> Not really.  The next firmware release has gone to great lengths to
> improve video performance by doing scaling on the LCD controller, as
> well as the colourspace conversion.  I think you'll be pleasantly
> surprised. ;)

Thanks, that's a very good news. We all are looking forward for this firmware
update. By the way, is it possible to get an early access to the updated
kernels in the future for the purpose of testing and ensuring compatibility?

I wonder what improvements the new framebuffer driver will bring to us. As 
far as I understand the situation with the current firmware, the problem is 
in having to do planar->packed YUV conversion at ARM core and 
synchronous screen update for anything involving planes.

Graphics system in Nokia 770 could perform YUV screen updates 
asynchronously with DMA consuming only ~20% cpu resources for
640x480 24 fps video output (these ARM core resources were used for 
planar->packed color format conversion and scaling).

N800 is a bit different with a more complicated framebuffer driver with a
support for more hardware features (such as a very high quality hardware
scaler),  but its graphics chip does not seem to support planar YUV color
formats, so something else (ARM core?) should do the conversion wasting the
same ~20% of resources. By the way, did you consider trying to use DSP 
at least for unscaled planar->packed color format conversion? It should
provide some improvement at least theoretically.

And a few questions about the future frambuffer driver. I know that the pixel
doubling feature should be fixed in the next firmware. Will this driver also
support YUV color format for regular screen updates (without using planes)
just like N770? I would prefer some kind of stateless API that would not 
allow to screw up the device when something gets wrong (having some 
planes enabled at abnormal exit makes it impossible to work with the device
and requires a reboot).

And one more minor question is about YUV format constants in framebuffer.
OMAPFB_COLOR_YUV422 constant for N770 specifies the same color 
format as OMAPFB_COLOR_YUY422 for N800, why did you have to introduce 
a new constant?

All in all, while video output issues can be solved, CPU performance for video
decoding is still another bottleneck. It is even worse bottleneck than video
output as you can skip displaying of some frames, but you can't skip decoding.
The latest build of mplayer for maemo (mplayer_1.0rc1-maemo.10) accesses
framebuffer directly, so its video output performance is comparable to that of
N770. Unfortunately  while cpu usage for video output reduced greatly to a
reasonable level and is not a bottleneck anymore, video decoding performance
is still a bottleneck and N800 is only about 30% faster than N770 for video
(N800 handles 30fps videos in mplayer approximately the same as N770 handles
24fps videos). Surely, armv6 optimizations for video decoding can provide some
improvement, but we have a long way of incremental improvements ahead.

Did you try to do something about tearing in the next firmware? While I tried
to workaround it, nothing could eliminate it completely but only resulted in
some additional slowdown. So the latest build of mplayer has tearsync
completely disabled and is optimized for performance only. It goes without
saying that we will have to do something about it in the the future for sure.

Is IVA really unusable on N800? What kind of cpu does it have inside? If 
it is done by TI, we can probably suppose that it is TMS320C64x (at least I
have seen information that IVA2 is a lower clock and more power efficient
version of DaVinci which uses TMS320C64x).