Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 19 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 4 hrs ago - more...
| The Following User Says Thank You to lcuk For This Useful Post: | ||
 |
|
2008-07-06
, 14:22
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#22
|
Thanks for the enlightenment. It's always a bit of a pisser to find that a single wrong assumption is enough to capsize an idea.
But I'm resilient (or stubborn -- depends on your perspective).
Putting SDL aside for the moment. I'm interested in effectively utilizing the YUV (Xv?) on the tablets.
After looking over the Xv manpage I found the functions XvGetStill and XvGetVideo that accept drawable data, clip the data, and spit it out the hardware. I'm assuming that they accept the 'drawable' in YUV format. This is what I assume libQbase is doing.
So does the developer concern shclimself (or shclurself -- to be genderless and politically correct) with the chunky planes? How large are each individual Y, U, and V value?
Feel free to answer none of these questions. Seriously, I won't take offense at all. I'm intensely curious and it can get annoying.
Mapping the YUV to the the "2.5 resolution" chunky plane is the confusing bit. Are you suggesting that because of the 2.5 resolution, somehow more than one value would have to be stored for each mapped colour? Or is it simply a problem of splitting the result among the different planes?
The inverse operation, though, is quite terrible (as you rightly suggested). The lookup problem can be mitigated somewhat by bit shifting each Y, U and V components to achieve a smaller approximation (and index) of the original colour and then mapping that YUV result to its RGB equivalent. The many shifts for each pixel would likely have steep computational consequences, and would have to be tested to determine what the consequences are. This is all moot as thankfully YUV to RGB isn't the primary concern.
This would be useful for a great many of cases, but something would have to be done for applications that quickly want to write individual pixels. I remember some 'demos' of ray tracers implemented in SDL and the sort that would certainly require pixel level control.
I fully endorse just jumping in and trying something out without collecting all of the facts. Unique solutions tend to be developed that way and a deeper understanding of what you're working with can be gained.
How do you type on the N810? Using the built in keypad? How well does this work? I suspect using a wireless bluetooth keyboard would drain the battery (though the keyboard would likely be sending information to the bluetooth receiver more than the other way around, so I could be wrong).
}:^)~
YARR!
Cappie
But I'm resilient (or stubborn -- depends on your perspective).
Putting SDL aside for the moment. I'm interested in effectively utilizing the YUV (Xv?) on the tablets.
Originally Posted by lcuk
This is mildly mind-asploding. Are you saying that in order to set a YUV 'pixel' one has to write to three separate memory blocks of varying size (or equivalently three offsets of the same block)? Or is this automatically done using XVideo extension?
Now, sdl and automatic translations - your pondering is slightly off.
YUV data is actually 12bit, but it is not stored in a single short integer 16bit memory block. The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 1/2 resolution chunky planes for chroma channels each of ((w/2)*(h/2)).
After looking over the Xv manpage I found the functions XvGetStill and XvGetVideo that accept drawable data, clip the data, and spit it out the hardware. I'm assuming that they accept the 'drawable' in YUV format. This is what I assume libQbase is doing.
So does the developer concern shclimself (or shclurself -- to be genderless and politically correct) with the chunky planes? How large are each individual Y, U, and V value?
Feel free to answer none of these questions. Seriously, I won't take offense at all. I'm intensely curious and it can get annoying.
Originally Posted by lcuk
Actually, 16bit to 24bit isn't that bad *if* it is indeed a mathematical function (one to one). The total size of the lookup would be 65Kcolours * 3Bytes (24bits) == 196K lookup.
This means that to specify a color you need the full 24bit YUV value.
The colors are fully detailed but the number of pixels to draw on aren't.
So to get maximum coverage your rgb16->yuv table would have to store the whole 65k * 3 192kb
To use a table for the inverse would require mapping the whole 16.7million possible YUV colors for a pixel to a 16bit short per pixel...
Mapping the YUV to the the "2.5 resolution" chunky plane is the confusing bit. Are you suggesting that because of the 2.5 resolution, somehow more than one value would have to be stored for each mapped colour? Or is it simply a problem of splitting the result among the different planes?
The inverse operation, though, is quite terrible (as you rightly suggested). The lookup problem can be mitigated somewhat by bit shifting each Y, U and V components to achieve a smaller approximation (and index) of the original colour and then mapping that YUV result to its RGB equivalent. The many shifts for each pixel would likely have steep computational consequences, and would have to be tested to determine what the consequences are. This is all moot as thankfully YUV to RGB isn't the primary concern.
Originally Posted by lcuk
So true.
Now, looking specifically at SDL, most games etc will load their assets as images and just be dealing with blitting them onto the screen at specified locations based on the game control code.
Loading an SDL image will create an SDL bitmap in a compatible format for the display mode you have created.
This means that any ImageFileRGB->ImageYUV would be done once at loading as long as the blit routines could work with YUV surface and YUV image..
This would be useful for a great many of cases, but something would have to be done for applications that quickly want to write individual pixels. I remember some 'demos' of ray tracers implemented in SDL and the sort that would certainly require pixel level control.
Originally Posted by lcuk
Nor should it be! I'm impressed by your work and understanding. I'd love to contribute, if only with ideas.
This is not been a priority for me, I have learnt more about coding my way and did not understand enough about x11 or sdl when I started all this, it would certainly be interesting if it could be done.
I fully endorse just jumping in and trying something out without collecting all of the facts. Unique solutions tend to be developed that way and a deeper understanding of what you're working with can be gained.
Originally Posted by lcuk
That's amazing, and exactly what I want to hear. Even most lappies running basic applications can't boast life like this. As long as I don't have to constantly worry whether my tablet is going to die on me, I'm well happy.
I find the battery on my 810 to be quite resiliant, I dont play music on it or use it for wifi during the daytime and I keep my screen off maximum brightness and I am able to pull out and use my nokia for coding/compiling/sketching/looking/playing/reading whenever I need it.
During linuxtag I was sketching and doodling the whole trip and my nokia outlasted others, we all went out to the pub and my nokia which hadnt been charged all day was the only one still working and able to play numpty (at full "performance" speed might I add)..
How do you type on the N810? Using the built in keypad? How well does this work? I suspect using a wireless bluetooth keyboard would drain the battery (though the keyboard would likely be sending information to the bluetooth receiver more than the other way around, so I could be wrong).
}:^)~
YARR!
Cappie
 |
|
2008-07-06
, 15:03
|
|
Posts: 1,635 |
Thanked: 1,816 times |
Joined on Apr 2008
@ Manchester, England
|
#23
|
theres quite a lot here and I don't know how to insert quotes and stuff properly, so if the formatting is off bear with me.
Even a wrong idea expressed in the right way can yeald positive results.
Yes, 3 memory locations, however when processing I do all operations on a single plane then move onto the next.
There are write operations which work in greyscale only, and variations added later which simply call the same macro with alternative parameters and dimensions for the remaining color planes.
It works well enough for now and allows me to use int32 writes where needed.
xv simply gives me a blank canvas to write on.
I simply call XvShmPutImage to push the already allocated blank canvas to the LCD. This call will raise an event in the X11 event chain for my window to say when transfer has completed. If I try writing to the canvas data during this time then extreme tearing occurs.
I have attemped in the past to call the same function from within SDL during its refresh process (sdl uses the same underlying shared memory setup, just a different format).
There is a discussion on here or the net in general about tearing where I attempted this but did not get expected benefits - though I missed something out there, at the time I didnt realise there could be intermediate events and needed a function to wait until the window got the event to let sdl carry on drawing, hmmm perhaps if i...
There are 3 planes, and I want an 800*480 display
Plane 1, 800 pixels wide, by 480 pixels high, 8 bit Greyscale.
Plane 2, 400 pixels wide, by 240 pixels high, 8 bit Chroma *.
Plane 3, 400 pixels wide, by 240 pixels high, 8 bit Luma *.
*if im wrong about names you should know what they are expected to be.
I'll help as much as I can because explaining things now will help in the future.
I still don't quite understand the mathematical function you are on about, if you are suggesting using a function to calc offset then do the lookup to then write it to the destination then that would be orders of magnitude longer than the quickest assembler operations on register variables - just use an optimised function to convert as required.
you can do the matrix transformation in strips anyway and grabbing data 4 pixels at a time and modifying the target pixels in bulk would help.
I will restate what I said:
The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 half resolution chunky planes for chroma channels each of ((w/2)*(h/2)).
2 in quantity, half resolution each.
Use the all cpu function to do translation between yuv->rgb.
It has to be as much of a concern as rgb->yuv. they are yin and yang functions and to make one good you will have the skills to make the other one well.
If somebody came to doing the functions creating the inverse at the same time would be beneficial.
Programs that require RGB attributes and who dont check that their bitmap is actually rgb dont care about it not running on yuv, and they simply wont run no matter what we try. its not the end of the world.
So am I. the only niggle for me is that I use adhoc wireless - it *does* drain the battery faster when connected, but thats only around the house and im near a wallwart, when out and on wifi its never been a problem.
When I'm tinkering i use the keyboard built in, but its not ideal for typing, so when i think ill need it I take my apple bluetooth keyboard with me. its not foldable, but its about the size of a book and can be put in the bag easily.
Never ever noticed the battery drain with bluetooth.
Gary
Thanks for the enlightenment. It's always a bit of a pisser to find that a single wrong assumption is enough to capsize an idea.
Even a wrong idea expressed in the right way can yeald positive results.
This is mildly mind-asploding. Are you saying that in order to set a YUV 'pixel' one has to write to three separate memory blocks of varying size (or equivalently three offsets of the same block)?
There are write operations which work in greyscale only, and variations added later which simply call the same macro with alternative parameters and dimensions for the remaining color planes.
It works well enough for now and allows me to use int32 writes where needed.
Or is this automatically done using XVideo extension?
After looking over the Xv manpage I found the functions XvGetStill and XvGetVideo that accept drawable data, clip the data, and spit it out the hardware. I'm assuming that they accept the 'drawable' in YUV format. This is what I assume libQbase is doing.
I have attemped in the past to call the same function from within SDL during its refresh process (sdl uses the same underlying shared memory setup, just a different format).
There is a discussion on here or the net in general about tearing where I attempted this but did not get expected benefits - though I missed something out there, at the time I didnt realise there could be intermediate events and needed a function to wait until the window got the event to let sdl carry on drawing, hmmm perhaps if i...
So does the developer concern shclimself (or shclurself -- to be genderless and politically correct) with the chunky planes? How large are each individual Y, U, and V value?
Plane 1, 800 pixels wide, by 480 pixels high, 8 bit Greyscale.
Plane 2, 400 pixels wide, by 240 pixels high, 8 bit Chroma *.
Plane 3, 400 pixels wide, by 240 pixels high, 8 bit Luma *.
*if im wrong about names you should know what they are expected to be.
Feel free to answer none of these questions. Seriously, I won't take offense at all. I'm intensely curious and it can get annoying.
Actually, 16bit to 24bit isn't that bad *if* it is indeed a mathematical function (one to one). The total size of the lookup would be 65Kcolours * 3Bytes (24bits) == 196K lookup.
you can do the matrix transformation in strips anyway and grabbing data 4 pixels at a time and modifying the target pixels in bulk would help.
Mapping the YUV to the the "2.5 resolution" chunky plane is the confusing bit. Are you suggesting that because of the 2.5 resolution, somehow more than one value would have to be stored for each mapped colour? Or is it simply a problem of splitting the result among the different planes?
The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 half resolution chunky planes for chroma channels each of ((w/2)*(h/2)).
2 in quantity, half resolution each.
The inverse operation, though, is quite terrible (as you rightly suggested). The lookup problem can be mitigated somewhat by bit shifting each Y, U and V components to achieve a smaller approximation (and index) of the original colour and then mapping that YUV result to its RGB equivalent. The many shifts for each pixel would likely have steep computational consequences, and would have to be tested to determine what the consequences are. This is all moot as thankfully YUV to RGB isn't the primary concern.
It has to be as much of a concern as rgb->yuv. they are yin and yang functions and to make one good you will have the skills to make the other one well.
If somebody came to doing the functions creating the inverse at the same time would be beneficial.
This would be useful for a great many of cases, but something would have to be done for applications that quickly want to write individual pixels. I remember some 'demos' of ray tracers implemented in SDL and the sort that would certainly require pixel level control.
Nor should it be! I'm impressed by your work and understanding. I'd love to contribute, if only with ideas.
I fully endorse just jumping in and trying something out without collecting all of the facts. Unique solutions tend to be developed that way and a deeper understanding of what you're working with can be gained.
That's amazing, and exactly what I want to hear. Even most lappies running basic applications can't boast life like this. As long as I don't have to constantly worry whether my tablet is going to die on me, I'm well happy.
How do you type on the N810? Using the built in keypad? How well does this work? I suspect using a wireless bluetooth keyboard would drain the battery (though the keyboard would likely be sending information to the bluetooth receiver more than the other way around, so I could be wrong).
Never ever noticed the battery drain with bluetooth.
Gary
| The Following User Says Thank You to lcuk For This Useful Post: | ||
|
|
2008-07-06
, 17:26
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#24
|
Thanks for the thoughtful reply. I'll keep this much shorter than previous posts as it *is* getting a bit long.
I think I understand how liqbase works a little better now. By writing the YUV data plane by plane you certainly can achieve very, very quick speeds, fewer memory operations and the benefit of Xv acceleration. This is especially true if you're saving data in a format friendly to YUV plane separation. Quite clever!
What about writing to a separate buffer/canvas? You can likely update the 2nd buffer while the first one is being processed by the hardware, and when it's done, you can quickly feed it the next one. This should eliminate the tearing effect and not require you to wait for the output before you begin drawing the next frame.
I should have articulated myself more clearly. The 'mathematical function' was in reference to a one-to-one mapping between each RGB value and YUV values, all represented in an indexable table. By 'offset', I meant 'table offset' or 'index.'
The idea is to reduce calculations for RGB colour conversion. Rather than having to do 3 floating point multiplies and 3 adds for 3 separate components of YUV for a single converted pixel (27 ops not including assignments, shifts, etc), you would only have to do only 1 memory lookup. The savings in calculation are huge even for the most optimized of functions, and the memory penalty is quite tame (196K table). Additional computation savings can be had if the conversion lookup is done via a macro rather than a function call.
Mapping the resultant Y value will be easy: the Y resolution is the same as the canvas or output resolution. Mapping the resultant U and V values reliably to a half-resolution is another story, but probably could be done a variety of ways.
Of course if there are hardware accelerated features that could perform the conversion, it would obviously be the ideal solution.
In all of this conversion talk, I didn't stop to consider if writing to the screen in native RGB was quicker than converting RGB to YUV with a lookup to write to the screen via Xv.... Go figure... If lookup conversion results in quicker speeds (Xv acceleration), it's something to look into, if not, it's been an educational ride!
Sadly without a tablet I'll not be able to find the answer to this question. Hopefully the screen writing speed bottlenecks disappear with more sane engineering on future versions of the hardware.
}:^)~
YARR!
Corruptieon
I think I understand how liqbase works a little better now. By writing the YUV data plane by plane you certainly can achieve very, very quick speeds, fewer memory operations and the benefit of Xv acceleration. This is especially true if you're saving data in a format friendly to YUV plane separation. Quite clever!
I simply call XvShmPutImage to push the already allocated blank canvas to the LCD. This call will raise an event in the X11 event chain for my window to say when transfer has completed. If I try writing to the canvas data during this time then extreme tearing occurs.
I have attemped in the past to call the same function from within SDL during its refresh process (sdl uses the same underlying shared memory setup, just a different format).
I still don't quite understand the mathematical function you are on about, if you are suggesting using a function to calc offset then do the lookup to then write it to the destination then that would be orders of magnitude longer than the quickest assembler operations on register variables - just use an optimised function to convert as required.
you can do the matrix transformation in strips anyway and grabbing data 4 pixels at a time and modifying the target pixels in bulk would help.
The idea is to reduce calculations for RGB colour conversion. Rather than having to do 3 floating point multiplies and 3 adds for 3 separate components of YUV for a single converted pixel (27 ops not including assignments, shifts, etc), you would only have to do only 1 memory lookup. The savings in calculation are huge even for the most optimized of functions, and the memory penalty is quite tame (196K table). Additional computation savings can be had if the conversion lookup is done via a macro rather than a function call.
Mapping the resultant Y value will be easy: the Y resolution is the same as the canvas or output resolution. Mapping the resultant U and V values reliably to a half-resolution is another story, but probably could be done a variety of ways.
Of course if there are hardware accelerated features that could perform the conversion, it would obviously be the ideal solution.
In all of this conversion talk, I didn't stop to consider if writing to the screen in native RGB was quicker than converting RGB to YUV with a lookup to write to the screen via Xv.... Go figure... If lookup conversion results in quicker speeds (Xv acceleration), it's something to look into, if not, it's been an educational ride!
Sadly without a tablet I'll not be able to find the answer to this question. Hopefully the screen writing speed bottlenecks disappear with more sane engineering on future versions of the hardware.
}:^)~
YARR!
Corruptieon
|
|
2008-07-06
, 17:45
|
|
Posts: 1,635 |
Thanked: 1,816 times |
Joined on Apr 2008
@ Manchester, England
|
#25
|
Captn,
I hadn't considered a fully double buffered approach like you suggest, I had it in my head that xv will give me a screen and I draw to it.
It seems obvious in retrospect and could yeald additional performance benefits (especially for the lower cpu modes).
When I next dip my head into the engine I'll take a look around and see if theres anything I can do.
Thanks for the tip, it very likely may be useful.
Why haven't you got a tablet?
I hadn't considered a fully double buffered approach like you suggest, I had it in my head that xv will give me a screen and I draw to it.
It seems obvious in retrospect and could yeald additional performance benefits (especially for the lower cpu modes).
When I next dip my head into the engine I'll take a look around and see if theres anything I can do.
Thanks for the tip, it very likely may be useful.
Why haven't you got a tablet?
|
|
2008-07-06
, 18:17
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#26
|
A boring story, really.
I decided to hold off on getting the N810 in lieu of the impending N810 WiMax edition. I'm re-thinking that decision, though. I'm not sure when a compatible WiMAX deployment will happen here in Ontario, Canada, and based on the history of the big providers, the service will likely cost an arm and a leg! If the N810WME is released soon and there's confirmation that it'll work well with the WiMAX services in my area, then I'm all for it. If not, then I'll get the N810 instead.
Procrastination or prudence?
Anyway, I know this device will be a third (or fourth -- heh heh) leg for me in that I'll always carry it around with me and get plenty of use from it. $400 seems a bargain considering the multitude of things it can do.
I'll give it another month, and then think it through again. I'm both patient and frugal (a euphemism to make me feel better about being me) so I don't mind waiting for a good purchase. In the meantime I can do without. However, not a day goes by where I find a situation that having this wonderful tool would make life easier.
When, and more importantly, why did you get yours?
}:^)~
YARR!
El Capitarino
I decided to hold off on getting the N810 in lieu of the impending N810 WiMax edition. I'm re-thinking that decision, though. I'm not sure when a compatible WiMAX deployment will happen here in Ontario, Canada, and based on the history of the big providers, the service will likely cost an arm and a leg! If the N810WME is released soon and there's confirmation that it'll work well with the WiMAX services in my area, then I'm all for it. If not, then I'll get the N810 instead.
Procrastination or prudence?
Anyway, I know this device will be a third (or fourth -- heh heh) leg for me in that I'll always carry it around with me and get plenty of use from it. $400 seems a bargain considering the multitude of things it can do.
I'll give it another month, and then think it through again. I'm both patient and frugal (a euphemism to make me feel better about being me) so I don't mind waiting for a good purchase. In the meantime I can do without. However, not a day goes by where I find a situation that having this wonderful tool would make life easier.
When, and more importantly, why did you get yours?
}:^)~
YARR!
El Capitarino
|
|
2008-07-06
, 18:28
|
|
Posts: 1,635 |
Thanked: 1,816 times |
Joined on Apr 2008
@ Manchester, England
|
#27
|
Captn
The best way I can answer that is by giving you a link to the notes I made before Linuxtag.
they explain basically everything, I began to present a pared down version at linuxtag before bottling it
http://liquid.googlepages.com/linuxtag_notes
The best way I can answer that is by giving you a link to the notes I made before Linuxtag.
they explain basically everything, I began to present a pared down version at linuxtag before bottling it
http://liquid.googlepages.com/linuxtag_notes
| The Following 4 Users Say Thank You to lcuk For This Useful Post: | ||
|
|
2008-07-06
, 19:09
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#28
|
Fantastic read! I think I perfectly mirror your feelings toward the N810, but your story is articulated in such an epic way!
For a project that I'm currently working on (proprietary non-tablet related), I too had to write a resolution independent glyph renderer! A very strange coincidence, especially since I too didn't know what I was getting myself into originally!
Good show!
If you're writing a GUI, I would *love* to shoot some ideas past you. I believe that the fanciness of compositing WMs (minus the 3D) can be implemented in software with very little code. I would love to see liqbase usher in a new alternative to the dried up desktop style guis that we've seen time and again.
Your note taker is a BIG step in the right direction. It looks AWESOME and is something I would use constantly! Blast, if only I had an N810 to test it out!
}:^)~
YARR!
St. Corrupt
For a project that I'm currently working on (proprietary non-tablet related), I too had to write a resolution independent glyph renderer! A very strange coincidence, especially since I too didn't know what I was getting myself into originally!
Good show!
If you're writing a GUI, I would *love* to shoot some ideas past you. I believe that the fanciness of compositing WMs (minus the 3D) can be implemented in software with very little code. I would love to see liqbase usher in a new alternative to the dried up desktop style guis that we've seen time and again.
Your note taker is a BIG step in the right direction. It looks AWESOME and is something I would use constantly! Blast, if only I had an N810 to test it out!
}:^)~
YARR!
St. Corrupt
|
|
2008-07-07
, 01:03
|
|
Posts: 393 |
Thanked: 112 times |
Joined on Jul 2007
|
#29
|
There are fixed point RGB->YUV approximations which should yield good results:
http://en.wikipedia.org/wiki/YUV#Num...approximations
Wonder whther CLUTs are faster or slower than a few mults and bit shifts.
http://en.wikipedia.org/wiki/YUV#Num...approximations
Wonder whther CLUTs are faster or slower than a few mults and bit shifts.
|
|
2008-07-08
, 22:20
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#30
|
Originally Posted by yabbas
Quite an interesting approach to RGB to YUV conversion. I like it!
There are fixed point RGB->YUV approximations which should yield good results:
http://en.wikipedia.org/wiki/YUV#Num...approximations
Wonder whther CLUTs are faster or slower than a few mults and bit shifts.
This is certainly a useful technique that will save on a buckload of (expensive?) floating point operations in lieu of simpler integer and shift operations for each colour channel.
I would *guess* that using a CLUT (colour look up table -- for the uninitiated) would be faster than muls, adds, and shifts (~21 ops per colour vs 1 op for lookup). Of course, this is all contingent on the length of time it takes to fetch something in RAM relative to on-chip speed for general (or specialized) calculation. The easiest way to find out, would probably be to code a converter in assembly and speed test it against a CLUT.
I can't wait to start messing about with the OMAP hardware...
}:^)~
YARR!
Copt'n Carrupt
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
I find the battery on my 810 to be quite resiliant, I dont play music on it or use it for wifi during the daytime and I keep my screen off maximum brightness and I am able to pull out and use my nokia for coding/compiling/sketching/looking/playing/reading whenever I need it.
During linuxtag I was sketching and doodling the whole trip and my nokia outlasted others, we all went out to the pub and my nokia which hadnt been charged all day was the only one still working and able to play numpty (at full "performance" speed might I add)..
Now, sdl and automatic translations - your pondering is slightly off.
YUV data is actually 12bit, but it is not stored in a single short integer 16bit memory block.
The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 1/2 resolution chunky planes for chroma channels each of ((w/2)*(h/2)).
This means that to specify a color you need the full 24bit YUV value.
The colors are fully detailed but the number of pixels to draw on aren't.
So to get maximum coverage your rgb16->yuv table would have to store the whole 65k * 3 192kb
To use a table for the inverse would require mapping the whole 16.7million possible YUV colors for a pixel to a 16bit short per pixel...
Coupled with the fact most atomic SDL operations do not require pixel based lookups or assignments makes me think this table looks a little infeasible but its good to discuss and talk through suggestions.
Looking at performing the conversion via a function would be better and I believe there are already quite rapid integer only examples available.
Now, looking specifically at SDL, most games etc will load their assets as images and just be dealing with blitting them onto the screen at specified locations based on the game control code.
Loading an SDL image will create an SDL bitmap in a compatible format for the display mode you have created.
This means that any ImageFileRGB->ImageYUV would be done once at loading as long as the blit routines could work with YUV surface and YUV image..
I think the SDL underlying structure supports YUV or was intended to originally, I seem to recall seeing branches for YUV.
If it does, I personally see no reason why a new backend interface couldn't be hacked to make SDL talk to X11+xv...
This is not been a priority for me, I have learnt more about coding my way and did not understand enough about x11 or sdl when I started all this, it would certainly be interesting if it could be done.