Re: [Magiclantern-devel] Great work with the player! Does this list work?

[Nicholas H. <nic...@er...>]

On Tuesday 05 April 2005 19:26, Gábor Kovács wrote:
> Hi everybody!
>
> I just wanted acknowledge the great the work you guys are doing. You
> started quite a large project doing all the non codecs parts from sketch.
> There's plenty of work ahead with many challenges and fun. As a first time
> media player developer I've been there :)

Maybe we could do better by trying to port BetaPlayer or something else to 
palm, but well...that's not what we're doing right now. :)  Having lots of 
fun right now.  Rarely get the chance to just code, and to hack my way 
through interesting challenges like this. :)

> If possible be as general from the begining as possible. Example don't
> limit the format information about a media just as a combined one video and
> one audio format structure. Be prepaired for multiple streams.
>
> Use some sort of virtual function tables for objects with common interface
> but different functionality (like io, format splitter or codecs). Using a
> switch statments in every function is much more difficult the manage and is
> slower.

I've had that in mind, but went ahead with hard-coding avi support for the 
first stage.  I have generally been careful that the data structure for each 
component is generally only accessed within the one file.  Of course I ended 
up making an exception for the format structure, but even that that's only 
accessed from one other 'class'.  I've had in mind to do something like the 
virtual function table idea and I suppose I should have another look at it 
soon.

> Make your own optimized YUV color space displaying code. On today devices
> without hardware overlay support just displaying the YUV frames is about
> 50% of the cpu time of the hole video decoding. It's very important that
> this part of the code is very optimized. I would suggest to combine your
> own color space converter rigth into the displaying code (using XviD with
> just YUV output)

I haven't done any real performance testing yet, so I haven't observed where 
the time is being spent.  The video display is extra inefficient in that it's 
actually currently doing YUV->RGB24->RGB16.  

You wouldn't happen to have some nice ARM assembly I could just drop in lying 
around or anything like that? :)

> I'am not an expert PalmOS developer, but I read on many forums that
> switch between m68k and ARM mode is slow (flushing CPU instruction cache).
> I would say go with an ARM only player, but this makes debugging much
> harder. Still in longterm I see no other options. It would help a lot to
> create a desktop test version of the player (for me it was easy with WinCE
> and desktop Win32, but I think it would help in this case too at least with
> the codecs and general player functions)

I agree about moving to pure ARM code.  As I've gone, I've tried to make sure 
I made few assumptions about the processor type in most of the code (where I 
didn't have to).  I probably couldn't have started off with doing pure-arm, 
but I'm a bit more familiar with the tools now so I'll probably make the move 
as the next major stage of development.

I have already sometimes run some of the backend code on the desktop - 
especially the format decoder, to facilitate debugging of some bits.  Making 
more of a test harness in the future would probably be a good idea.  But 
probably won't do a full working version or anything like that.

> Btw does this list work? :)
> I subscribed to it early, but didn't receive any mails yet...

Yep it seems like it works.  You're the first to use it.


Nicholas