Re: [Open2x-devel] SDL_GetTicks optimization

[John W. <Joh...@Di...>]

Hi Matt/All,

>I've been doing some work on hardware YUV support for SDL-GP2X (finished, 
>working great)

I thought I better send you a public thank you for the SDL YUV patch. 
As you know this has now gone into the newer SDL 1.2.11/GP2X codebase.

I did however have a few questions. In the code you mention that the only
supported YUV format on the GP2X is 4:2:2 (YUY2). I assume you arrived at
the conclusion looking at the docs for the Video Processor?

Whilst I agree it is the only format the hardware can use (as I understand
it) I have noticed in the past that there also exists the Frame Dimension
Converter, from what can surmise from the scant documentation this should
perform the same sort of role as FFMPEG's libSWSCALE. Among its functions it
claims to be able to handle in hardware conversion from 4:2:0 (YV12) to
4:2:2 (YUY2) and some funky rotation and scaling.

I was wondering if you had looked at this as part of the work you did (i.e.
is this a dead end and I just don't realise it) or if it was something that
you did not consider. 
I have not had a chance to have a play with it myself yet but on paper at
least it has merit. 

Thinking on those lines, I guess the MMSP2 post processor could also be
wired in to the stream, maybe via something exposed in the environment to
toggle its use? 

This is something I have been pondering for a while (along with getting
RGB<>YUV hardware conversion going to smooth scale SDL RGB surfaces).
I lament the mount of hardware features we just gloss over but never seem to
get very far with wiring them up ;).

Anyway, I am just musing here but personally I can see a strong attraction
of additionally adding support for SDL_YV12_OVERLAY even if the support just
internally converts it to YUY2. This would give SDL on the GP2X the enviable
position of supporting the 2 main YUV formats in hardware and could (I
think) go a long way to helping to kick start work on mplayer and other
video apps that support a SDL video output layer. Another option I guess
would be to work in some ARM ASM conversion code for the YV12 to YUY2 step
but pre-exiting implementations of this approach such as the Nokia 770 live
outside SDL in apps like mplayer (not a very generic solution). 

>My SDL_GetTicks enhancement requires access to the data->io pointer (ie the

>mmap'd "/dev/mem").  What would be the cleanest way to get access to this?

There is not really a clean way, just hack it ;). It is not like the rest of
the system is hack free and our SDL fork is a long way from being fit to
present to mainline ;).

>It seems the most efficient way is to use a global variable but that isn't 
>the cleanest.  I will probably hack in a global variable approach to start 
>with, but if anyone has any ideas to clean it up, that would be great.  (I 
>try to avoid using globals where possible)

I must agree it would not be the cleanest.

You mentioned on IRC that you had hit a snag with the GetTicks work? 
The hardware timer was resetting after 10 mins as I understand it.

Whilst there are several workarounds to this I can't see that any of them
would be that elegant, you mentioned creating a SDL_GP2X_GetTicks, this
strikes me as the cleanest approach for now but I am still slightly shocked
by your timer findings. 

Could you provide a little more info on what you tried/used etc. maybe a
wider group could shed some light on the issue and bottom out a nice way to
tackle it.

Regards,

John Willis