[maemo-developers] [maemo-developers] Re: YUV formats, Re: Building xserver from source [was Bluetooth Mice]

[From: Charles 'Buck' Krasic]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Frantisk,

Thank you for sharing that information!  (Jussi too).   Using 420 may
bring some additional improvement over 422.   I hope to integrate that
into my code later today.   The YUV framebuffer support has been a
major progress for my player.

Sadly I don't exactly have a hello world.   You may look inside the
following file for how I use the ioctls:

   
http://qstream.org/viewcvs/trunk/qvid/src/video_out/qvid_video_out.c?view=markup

I'd also suggest you look at the following which helped me start:

    http://maemo.org/lxr/source/osso-af-utils/src/fb-progress.c

If you actually went to the trouble to build my whole project, this is
the program I used to do most basic testing on the 770 (as close to a
hello world as I have):

   
http://qstream.org/viewcvs/trunk/qvid/src/avi_play/test_yuv.c?view=markup

My enthusiasm for implementing Xvideo in xserver-omap has faded
again.   I have concluded that writing directly to the framebuffer
from the application is the most efficient way to go.   It has the
least memory copies, and the least context switches.

 Also,  as I told Siarhei, I spent a whole weekend on this stuff, and
got a scaler implemented and working on the DSP, but it turned out to
be many times slower than just doing the scaling on the ARM side.   
This may be partly do to slow memory transfers (ARM -> DSP + DSP ->
ARM), but my mainly I think implementing even basic algorithms on the
DSP really needs major optimization to get good performance.     I
only had the time to implement the algorithm using the DSP C
compiler.   I just don't have expertise in DSP to do assembly level
optimization.   I was communicating with the DSP directly from my
application, and did not start any actual xserver hacking.

Given that image scaling YUV->YUV on the ARM is reasonably fast, I'd
suggest the most important use for the DSP is audio decoding.    If
somebody would just discover/reveal a little more information about
the gstreamer mp3 element, it would help so much.  Particularly how/if
the element supports reporting an accurate time position, to allow the
ARM side to keep the video in sync.   Without that, I'm sticking to
esound output in my player right now.

If anyone is interested my DSP YUV code, they can have a look here:

   
http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/mmap.c?view=markup

The arm side of things is in the qvid_video_out.c file above.

Cheers,

- -- Buck

Frantisek Dufka wrote:

>
> Hi Buck,
>
> got also a mail from Siarhei Siamashka: "I have seen a user
> 'buck68' at #maemo irc channel the day before yesterday and he also
> tried to find information about using YUV colorspace and accessing
> framebuffer from DSP (for making libxv). He said he had figured out
> YUV422 maemory layout, but had troubles with YUV420."
>
> Looks like both persons are you so here is a piece of infromation I
> got recently
>
> Jussi.Laako at nokia.com wrote:
>>> So with some packed format it is not bad. Can you say which
>>> packed format it uses exactly (for both 422 and 420 modes)?
>>
>> Here they are:
>>
>> YUV422 format is packed and the memory layout is:
>>
>> U11 Y11 V11 Y12 U13 Y13 V13 Y14 ... U21 Y21 V21 Y22
>> U23 Y23 V23 Y24 ...
>>
>> YUV420 format is packed and the memory layout is:
>>
>> U11,12,21,22 Y11 Y12 U13,14,23,24 Y13 Y14 ... V11,12,21,22
>> Y21 Y22 V13,14,23,24 Y23 Y24 ...
>>
>
> I hope it helps you with hacking libxv. I'll try to hack direct fb
> access for YUV into mplayer but it may take a while. If you already
> have some hello world working examples for testing those ioctls I
> am definitely interested :-)
>
> Frantisek


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFE60CTPrrWIMa4SMsRAvyXAKC1Zl3fDeoSzS8mL6IDdkpbbgiHkwCgmZGf
F1Q2P9CaNOF000OoYK4fiik=
=Yklo
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: krasic.vcf
Type: text/x-vcard
Size: 403 bytes
Desc: not available
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20060822/31122f97/attachment.vcf