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

[From: Daniel Stone]

On Fri, Mar 09, 2007 at 10:34:52PM +0200, ext Siarhei Siamashka wrote:
> On Friday 09 March 2007 12:20, Daniel Stone wrote:
> > 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?

It's a kernel and large X server update.  Unfortunately I'm not in a
position to be able to release them to the public.

> 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.

The LCD controller takes in a planar format, so we indeed avoid that
conversion.  The bottleneck, though, isn't CPU or memory load, but the
bus between the display controller and the LCD controller.  So it
doesn't matter where we do the conversion, we just have to minimise the
load.  Sending 12bpp (i.e., pre-scaled) video over instead of 16bpp
post-scaled is obviously a pretty huge win.

> 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).

Yeah, it does, but due to the way this is implemented in hardware, it's
difficult to juggle.  Doing any kind of scaling enables an overlay,
which you have to explicitly overlay.  Not doing this will leave you
with a weird-looking display until you reboot, or blank the screen and
unblank.

The X server does all this for you -- the semantics are, uhm,
'nightmarish'; the LCD controller can't do colourkeyed video, only a
single cliprect.  The Xv support already has this worked out, including
automatic migration of your videos when a menu gets popped out or
whatever.  And it quite rightfully expects that it's the only thing
managing the framebuffer, so your planes may well get stomped.  You
really want to use it.

(Is there any special reason why you want to do it directly?  If so, let
me know, and I'll see if I can introduce support for what you're trying
to do in the X server.)

> 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?

Don't ask me.

> All in all, while video output issues can be solved,

As much as they can with respect to the hardware, which I don't think is
as much as you're making out.

> 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.

We aren't able to hit a situation where the CPU is an absolute
bottleneck, except maybe with some absurdly complicated codec.  I
haven't seen this arise yet.

> Did you try to do something about tearing in the next firmware?

Yes.

> 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).

I'm not sure, as I haven't played with the IVA.  But believe me when I
say that right now the bottleneck is the bus between the display
controller and the LCD controller.  You can do the maths on the maximum
transfer rate if you don't believe me ...

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/20070310/c7679f8e/attachment.pgp