maemo.org - Talk - Thoughts about OS 2008

maemo.org - Talk (https://talk.maemo.org/index.php)

- OS2008 / Maemo 4 / Chinook - Diablo (https://talk.maemo.org/forumdisplay.php?f=29)

- - Thoughts about OS 2008 (https://talk.maemo.org/showthread.php?t=11712)

Re: Thoughts about OS 2008

I've been downloading iPod/psp formatted video from google and it works much better now, it used to not work at all.

Re: Thoughts about OS 2008

I think the Media Player still can can only decode videos where horizontal and vertical dimensions are multiples of 16. I'm guessing that's why it's telling you that toad.avi is not a playable format. That aside, even if it tried to play it, 720x360 @25fps (~6.5 megapixels/sec) would be too much for the N8xx hardware also. :( Mplayer would likely do better but I doubt you'd be happy with that file as is do to hardware limitations.

Re-encoding to a smaller version works fine. Here is a quick example, 21MB 480x272 @25fps:

http://www.netfocal.com/toad-new.html

Re: Thoughts about OS 2008

Quote:

Originally Posted by lardman (Post 97343)

I would have thought this will make some difference, but if the native resolution of the video is larger than this, surely the decoding will still take a similar time as it can't be shrunk until this has been at least partially done.

It is possible to decode video at half resolution using some simplified calculations, but decoding artefacts are unavoidable. This low resolution decoding is enabled by '-lavdopts lowres=1' option in mplayer (also suggested as one of the methods to improve performance in 'Your system is too SLOW to play this!' warning).

I don't know if this trick is used in TCPMP by default for high resolution movies. Maybe it is better tuned there (both for performance and image quality) than ffmpeg's low resolution decoding mode. After all, ffmpeg primarily targets desktop systems and this low resolution mode is unlikely to get much attention.

Quote:

I'd like to know whether it really performs better due to the code/hardware accel, or if it's just down to the screen resolution.

Probably both (but I don't have any precise information to say that for certain). XScale has been longer around, Intel invested in developing some highly optimized functions including those needed for multimedia decoding (IPP library). XScale supports SIMD instructions which operate on 64-bit registers (adaptation of MMX extension for ARM core) while ARMv6 SIMD only uses 32-bit operands. ARM also tries to catch up: http://www.arm.com/news/18441.html

Re: Thoughts about OS 2008

I thought we also have SIMD instructions, the edsp stuff? No idea whether it's used by GCC though. Are there other OpenMAX libraries for things like MPEG decoding?

Re: Thoughts about OS 2008

Moonshine

Quote:

Re-encoding to a smaller version works fine.

what software did you use to re-encode? i tried the new Nokia Internet Tablet Video Converter but it choked.

Re: Thoughts about OS 2008

Quote:

Originally Posted by Rebski (Post 97854)

Moonshine

what software did you use to re-encode? i tried the new Nokia Internet Tablet Video Converter but it choked.

That file was done with Xilisoft's Video Converter:

http://www.xilisoft.com/video-converter.html

I also installed the Nokia Internet Tablet Video Converter. (On a Vista machine even :) ) It seemed to convert his clip just fine for me. Made a 19MB MP4 file:

http://www.netfocal.com/toad-new.mp4

From what I've seen on a couple clips the nokia app actually does a pretty nice job :)

Re: Thoughts about OS 2008

Quote:

From what I've seen on a couple clips the nokia app actually does a pretty nice job

That is good to hear because my experience (on Vista also) has been less than encouraging, shall we say.

I shall try it out again.

Re: Thoughts about OS 2008

Well, it already got offtopic here, but I'll try to reply to this question.

Quote:

Originally Posted by lardman (Post 97842)

I thought we also have SIMD instructions, the edsp stuff?

ARM9E core used in Nokia 770 supports 'enhanced dsp extension', that's a set of instructions capable of performing fast single cycle 16-bit*16-bit and 16-bit*32-bit multiplications and some other instructions. This is enough for many multimedia compression algorithms which do not need full 32-bit*32-bit multiplication (it is a lot slower).

ARM11 core used in Nokia N800 supports SIMD instructions which treat 32-bit registers as pairs of 16-bit values (or four 8-bit values). SIMD instructions allow to perform two 16-bit multiplications in a single cycle.

SIMD instructions from XScale use twice wider operands (64-bit) and can process more data in a single cycle. New NEON SIMD instructions from Cortex cores (OMAP3) are even wider according to documentation (128-bit): http://www.arm.com/products/CPUs/NEON.html

Quote:

No idea whether it's used by GCC though.

Yes, they can be used somewhat (edsp stuff). For example the following code:

Code:

#include <inttypes.h>



int32_t testmul1(int16_t a, int16_t b)

{

    return (int32_t)a * b;

}

int32_t testmul2(int32_t a, int32_t b)

{

    return (int32_t)(a >> 16) * (b >> 16);

}

int32_t testmul3(int32_t c, int32_t a, int32_t b)

{

    return (int32_t)(a >> 16) * (b >> 16) + c;

}

int32_t testmul4(int32_t a, int16_t b)

{

    return (a * b) >> 16;

}

compiles into

Code:

00000000 <testmul1>:

   0:   e1600180        smulbb  r0, r0, r1

   4:   e12fff1e        bx      lr



00000008 <testmul2>:

   8:   e16000e1        smultt  r0, r1, r0

   c:   e12fff1e        bx      lr



00000010 <testmul3>:

  10:   e16301e2        smultt  r3, r2, r1

  14:   e0832000        add     r2, r3, r0

  18:   e1a00002        mov     r0, r2

  1c:   e12fff1e        bx      lr



00000020 <testmul4>:

  20:   e1a02801        mov     r2, r1, lsl #16

  24:   e1a01842        mov     r1, r2, asr #16

  28:   e0000091        mul     r0, r1, r0

  2c:   e1a00840        mov     r0, r0, asr #16

  30:   e12fff1e        bx      lr

So gcc was able to insert proper instructions only in two first test cases. 'testmul3' should have used a single multiply&accumulate instruction (SMLATT), but failed and generated a much slower code. 'testmul4' should have also used a single 16-bit*32-bit multiply instruction (SMLAWB), but that's a more complicated case and we can't blame it here.

So the compiler (gcc 3.4.4) is not very clever and will lose to hand optimized assembly, especially on a bit more complicated pieces of code.

Quote:

Are there other OpenMAX libraries for things like MPEG decoding?

That news from ARM promised that they have plans to release more stuff (including MPEG decoding) a bit later.

edit: having a second look, testmul4 example is incorrect here (intermediate result overflows before shift), but anyway, I wasn't able to change this code to make compiler use optimal instruction.

Re: Thoughts about OS 2008

Quote:

Originally Posted by JeffElkins (Post 97712)

Here's an animation: http://www.elkins.org/toad.avi

It's only 32Mb. I'll leave it up for a day or so. The site is hosted by godaddy so be warned: throughput is crappy.

MPlayer on N800 (tested with OS2008) plays this video very good except for a few short scenes where it needs to drop some frames.

OS2008 package for mplayer is available in extras devel repository, check this thread for more details
http://www.internettablettalk.com/fo...ad.php?p=98115

Re: Thoughts about OS 2008

Good work Serge and thanks for the details of the edsp/SIMD instructions above.

Simon