Yes, I see no fundamental reason why, with a fast enough clock speed and some well written DSP drivers, you couldn't decode in real time, then downscale and output at standard TV res.

As the Ti specs for the OMP3[54]30 say up to 720p, this probably means they don't think the hw has sufficient grunt to decode anything more (and that's will well written DSP decoders too), rather than worrying about the output frame size.

e.g. The spec sheet mentions XGA (1024x768 pixels) output, which is smaller than a 720p frame.

The question is then whether the additional clock speed boost from overclocking is sufficient to perform the extra decoding in real time. And you also need to write some decent DSP code.

Edit: I thought we were talking about 1080p for some reason - so yes, the N900 hw should be able to decode 720p with well written drivers and a fast enough clock speed.

Sorry I should have read your post a little better - this may or may not work, it depends on what the DSP is on the N8 (whether it uses different instructions, different DSP kernel and additional coprocessors, etc). But probably not is the answer.

I also note, after looking at the Nokia N8 page, that it only claims 720p decoding anyway.

Edit: As above, for some reason I thought we were talking about 1080p - so yes, the N900 hw should be able to decode 720p with well written drivers and a fast enough clock speed. But I think you'll need to provide the drivers...

I'll have a snoop around and see what I can digg out. I'm no good at programming and my cousin is in pennsylvania, the luck sod. So yeh, if i can get his skypr I could have a few words with him and see what he could whip up. Unless anyone else thinks there upto the challenge?

I'd be happy to carry out most of the main testing on my device.

There are quite a few project's I'd love to start, but I don't know how to code in QT and I'm not really a programmer. I'm a HW engineer lol.

I have done DSP programming (on the 770, n8x0) and it's a pita - porting code should be reasonably straightforward (once you work out how to plumb whatever code you decide to use into the DSP framework - to get data in and out and work out how the threading and other data passing works).

The TMS320C6X DSPs have an 8bit type at last, so it won't be as painful as it used to be to convert code, but then you have to make sure the codec memory footprint fits in the DSP's available memory (and move different structures into faster or slower memory depending on their usage), and once you've done that, you need to modify the code to use the provided intrinsics, MACs, parallel-isations, etc, make sure the operation scheduling is optimum (probably by re-writing parts in ASM). Once you do all that you may end up with something that can decode 720p in real time.

Once all that is done, it's time to debug. I've not used the current debugging tools, but I hope they are better than the "add multiple printfs" which I had to use. In fact you'll probably find that most people write the code for an emulator which provides an interactive debugger. So this may well be a major headache for you.

It's an interesting learning experience if someone wants to take a stab at it, but make sure you're willing to do some hard graft and for a rather long time. Good luck

WRT is dead.

I tell you, it says "Arm V7 OR x86 processors (Snapdragon, A4, OMAP,ST U8500 all fall into this category)", that is evidently a list of compatible processors.

I think it will run on 256mb, maybe will have to disable some **** and recompile kernel cause it includes lots of unnecessary stuff to run out of the box, not module way.
also as for me arm is more preferred... this is sad, all hope on the maemo community, nokia managment sux.