Asm-optimized YUV->RGB conversion

Here is a link to mpeg player with asm-optimized YUV->RGB conversion. Maybe someone will help to add this code to libSDL, so all programs which will use it will be faster:

http://aminet.net/gfx/show/ripley.lha

http://amga.svn.sourceforge.net/viewvc/amiga/sdl/trunk/

Conversion is only needed when a video driver does not support requested format. I once implemented this feature into MorphOS SDL but I quickly figured out it is better leave unsupported formats unsupported. If I recall correctly problem simply was I had to convert and rescale entire gfx data on every overlay update. While it worked reasonably well for smaller sizes it was unusable with larger overlays.

on a winuae with AMD64 3000+ (real 1,8 GHZ) and play a 320*240 mpg video need 30% CPU load in window and without scale with ffmpeg.

when size the window to 1280*1024 then need incl scale 90% CPU load.

but thats only a example show on fast CPU it can work fast.
when get 50% more speed it help also on classic to be faster.

the 68k SDL do currently not support overlay.i am also not sure if the P96 or CGX support the Format ffplay do.

overlay of ffplay is in YV12.I add a func to SDL, that do play gray much faster than 16 bit color.maybe its possible to get more speed on classic and also on winuae with asm Code.

GCC produce very often command (...d3*4) instead precalc the result, because this code run on tables.

as far i know the d3*4) is not execute on 0 cost on 68060.

static void Color16DitherYV12Mod1X( int *colortab, Uint32 *rgb_2_pix,
unsigned char *lum, unsigned char *cr,
unsigned char *cb, unsigned char *out,
int rows, int cols, int mod )
{
unsigned short* row1;
unsigned short* row2;
unsigned char* lum2;
int x, y;
int cr_r;
int crb_g;
int cb_b;
int cols_2 = cols / 2;

row1 = (unsigned short*) out;
row2 = row1 + cols + mod;
lum2 = lum + cols;

mod += cols + mod;

y = rows / 2;
while( y-- )
{
x = cols_2;
while( x-- )
{
register int L;

cr_r = 0*768+256 + colortab[ *cr + 0*256 ];
crb_g = 1*768+256 + colortab[ *cr + 1*256 ]
+ colortab[ *cb + 2*256 ];
cb_b = 2*768+256 + colortab[ *cb + 3*256 ];
++cr; ++cb;

L = *lum++;
*row1++ = (unsigned short)(rgb_2_pix[ L + cr_r ] |
rgb_2_pix[ L + crb_g ] |
rgb_2_pix[ L + cb_b ]);

L = *lum++;
*row1++ = (unsigned short)(rgb_2_pix[ L + cr_r ] |
rgb_2_pix[ L + crb_g ] |
rgb_2_pix[ L + cb_b ]);


/* Now, do second row. */

L = *lum2++;
*row2++ = (unsigned short)(rgb_2_pix[ L + cr_r ] |
rgb_2_pix[ L + crb_g ] |
rgb_2_pix[ L + cb_b ]);

L = *lum2++;
*row2++ = (unsigned short)(rgb_2_pix[ L + cr_r ] |
rgb_2_pix[ L + crb_g ] |
rgb_2_pix[ L + cb_b ]);
}

/*
* These values are at the start of the next line, (due
* to the ++'s above),but they need to be at the start
* of the line after that.
*/
lum += cols;
lum2 += cols;
row1 += mod;
row2 += mod;
}
}

@bernd

(d8,An,Xi*SF) Address Register Indirect with Index and Byte Displacement is basically free (no slow down) on the 68060. A 16 bit or 32bit displacement costs a cycle which isn't too bad. The thing to watch out for is the instructions getting too long as the weakness of the 68060 is how many instructions it can fetch per cycle.

Using unimplemented instructions is probably the first thing to watch out for but the only missing integer instructions commonly used on the Amiga are the 64 bit multiply and divide. The bitfield instructions are in the 68060, contrary to what some people think. They are rarely the fastest solution and can only execute in the pOEP (1st) integer unit making matters worse for using the superscaler architecture.

Looking at the P96 docs, it looks like the YUV formats supported are...

RGBFB_Y4U2V2 2byte Truecolor CCIR601
RGBFB_Y4U1V1 1byte Truecolor ACCUPAK

You do have the P96 developer archive don't you?

no i have no dev archive, from P96.where can get it ?

i test some time ago a back up from P96, but i cant download anything.

but maybe there is a example source for P96 how overlay work.

OS4 SDL (last xusdl 1.2.13 and 1.2.11 i search) have no HW overlay.

i find only on MOS sdl code for HW overlay.(can find when search for yv12.but on cgx all seem diffrent.

switch (format)
{
case SDL_YV12_OVERLAY:
case SDL_IYUV_OVERLAY:
srcfmt = SRCFMT_YCbCr420; /* We currently only support these.. */
break;
case SDL_YUY2_OVERLAY:
srcfmt = SRCFMT_YCbCr16; /* ..and this (anything else is rejected at the beginning of func) */
break;
case SDL_UYVY_OVERLAY:
case SDL_YVYU_OVERLAY:
default:
srcfmt = 0xffffffff; /* just to avoid warning */
break;

the problem with p96 dev archive is solved, there is also a pip example in.

@bernd

Good, I guess someone got the P96 developer Archive to you. Most of the archive (minus the examples) is right here on utilitybase...

http://utilitybase.com/ref/?action=List&funcgroup=Picasso96

The CGX SDK and some others can be found here...

http://aweb.sunsite.dk/download.php

i send now the testprograms to tester with P96 Voodoo board.

on 1 system strange things happen, bestmodeid fail and return only $fffff

the openpip program does on both Voodoo not work.on
another System with a PiV it work.

it seem easy to add this to sdl, but if it not work.....

/********************************************************************* **
* This is an example that shows how to open a p96 PIP Window
* to get input events and how to paint in that window.
*
********************************************************************** */

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/picasso96.h>

#include <intuition/intuition.h>

char Template[] = "Width=W/N,Height=H/N,Pubscreen=PS/K";
LONG Array[] = { 0, 0, (LONG)"Workbench"};

struct Library *P96Base;

void main(void)
{
if(P96Base=OpenLibrary("Picasso96API.library",2)){
struct RDArgs *rda;
struct Window *wd;

LONG Width = 256, Height = 256;
char *PubScreenName = "Workbench";

if(rda = ReadArgs(Template, Array, NULL)){
if(Array[0]) Width =*((LONG *)Array[0]);
if(Array[1]) Height=*((LONG *)Array[1]);
PubScreenName = (char *)Array[2];
}

if(wd = p96PIP_OpenTags(
P96PIP_SourceFormat, RGBFB_R5G5B5, // RGBFB_Y4U2V2,
P96PIP_SourceWidth, 256,
P96PIP_SourceHeight, 256,
/* these tags are optional, but help */
WA_Title, "Picasso96 API PIP Test",
WA_Activate, TRUE,
WA_RMBTrap, TRUE,
WA_Width, Width,
WA_Height, Height,
WA_DragBar, TRUE,
WA_DepthGadget, TRUE,
WA_SimpleRefresh, TRUE,
WA_SizeGadget, TRUE,
WA_CloseGadget, TRUE,
WA_IDCMP, IDCMP_CLOSEWINDOW,
WA_PubScreenName, PubScreenName,
TAG_DONE)){

struct IntuiMessage *imsg;
BOOL goahead = TRUE;

struct RastPort *rp = NULL;

p96PIP_GetTags(wd, P96PIP_SourceRPort, (ULONG)&rp, TAG_END);

if(rp){
UWORD x, y;

for(y=0; y<Height; y++){
for(x=0; x<Width; x++){
p96WritePixel(rp, x, y, (x*256+y)*256);
}
}
}

do{
WaitPort(wd->UserPort);
while(imsg = (struct IntuiMessage *)GetMsg(wd->UserPort)){

switch(imsg->Class){
case IDCMP_CLOSEWINDOW:
goahead = FALSE;
break;
}
ReplyMsg((struct Message *)imsg);
}
}while(goahead);

p96PIP_Close(wd);
}

if(rda) FreeArgs(rda);

CloseLibrary(P96Base);
}
}




/********************************************************************* **
* This is example shows how to use p96BestModeIDTagList()
*
* tabt (Mon Aug 28 14:07:40 1995)
********************************************************************** */

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/graphics.h>
#include <proto/picasso96.h>

#include <stdio.h>

char template[]="Width=W/N,Height=H/N,Depth=D/N";

char *fmtstrings[RGBFB_MaxFormats] = {
"RGBFB_NONE",
"RGBFB_CLUT",
"RGBFB_R8G8B8",
"RGBFB_B8G8R8",
"RGBFB_R5G6B5PC",
"RGBFB_R5G5B5PC",
"RGBFB_A8R8G8B8",
"RGBFB_A8B8G8R8",
"RGBFB_R8G8B8A8",
"RGBFB_B8G8R8A8",
"RGBFB_R5G6B5",
"RGBFB_R5G5B5",
"RGBFB_B5G6R5PC",
"RGBFB_B5G5R5PC"
};

LONG array[]={ 0, 0, 0, FALSE };

struct Library *P96Base;

void main(int argc,char **argv)
{
if(P96Base=OpenLibrary("Picasso96API.library",2)){
struct RDArgs *rda;

ULONG DisplayID;
LONG width=640, height=480, depth=24;

if(rda=ReadArgs(template,array,NULL)){
if(array[0]) width =*((LONG *)array[0]);
if(array[1]) height=*((LONG *)array[1]);
if(array[2]) depth =*((LONG *)array[2]);
FreeArgs(rda);
}

if(DisplayID=p96BestModeIDTags(
P96BIDTAG_NominalWidth, width,
P96BIDTAG_NominalHeight, height,
P96BIDTAG_Depth, depth,
P96BIDTAG_FormatsForbidden,
(RGBFF_R5G5B5|RGBFF_R5G5B5PC|RGBFF_B5G5R5PC),
TAG_DONE)){
printf("DisplayID: %lx\n", DisplayID);
if(DisplayID != INVALID_ID){
printf("Width: %ld\n", p96GetModeIDAttr(DisplayID,
P96IDA_WIDTH));
printf("Height: %ld\n", p96GetModeIDAttr(DisplayID,
P96IDA_HEIGHT));
printf("Depth: %ld\n", p96GetModeIDAttr(DisplayID,
P96IDA_DEPTH));
printf("BytesPerPixel: %ld\n", p96GetModeIDAttr(DisplayID,
P96IDA_BYTESPERPIXEL));
printf("BitsPerPixel: %ld\n", p96GetModeIDAttr(DisplayID,
P96IDA_BITSPERPIXEL));
printf("RGBFormat: %s\n",
fmtstrings[p96GetModeIDAttr(DisplayID,P96IDA_RGBFORMAT)]);
printf("Is P96: %s\n", p96GetModeIDAttr(DisplayID,
P96IDA_ISP96) ? "yes" : "no");
}
}
CloseLibrary(P96Base);
}
}

Reason why OS4 SDL does not support HW overlay is that with P96 PIP API you can not create overlay surface in any sensible manner. You can create a window with overlay but you can not attach it into existing window.

YV12 and IYUV are pixel formats and reside in the YCbCr color space.

@ bernd

I get the same results here with the P96 examples on Voodoo4/Mediator. BestModID returns $ffffffff=INVALID_ID (from graphics/modeid.h). OpenPIP, OpenScreen, and WriteTrueColorData do nothing. The other 3 examples work fine. I tried some older versions of P96 and Mediator libs and I get the same results. The funny thing is that PIP works here in RIVA and MooVid. It also has to work with the Mediator TV card's PIP display so it's probably possible to work around the bugs. It looks like the bugs would be in Picasso96API.library but could be bad data passed in by the Mediator drivers. The latter would explain why the PIV works. I'll have to do some more investigating.

@matthey: i was looking for half a year to solution to this problem before i decided in the end to ask elbox about it.
the answer was immediate:

http://www.haage-partner.de/download/Amiga/AmigaXL/AOSXL-Update1.lha


you have to install picasso96api.library from this archive and probably the emulation.library to your picasso96 folder in libs.
after that bestmodeid method is working. who would think it is that simple, i suspected there was some update needed, but this one was really hidden in the uttermost darkness.

as to pip on voodoo i have the same thoughts
greetz. lol. my first post here. well have not much to say apart of that

@wawa

That's awesome! Many thanks! BestModeID, OpenScreen, and WriteTrueColorData work now. OpenPIP still does not. It may be time for a patch.

@matthey: yes. such a triviality. i told them (elbox) to put it in the faq, whoever still needs it this days. what cocncerns pip we will see. i have asked them about it too. lets see...

After some further reading and testing, I don't think there is any bug. The Voodoo3 Avenger only supports video overlay with YUV411, YUV422, RGB(1-5-5-5), and RGB(5-6-5). I changed...

P96PIP_SourceFormat, RGBFB_R5G5B5,

to

P96PIP_SourceFormat, RGBFB_R5G6B5PC,

and the PIP opened with rainbow colors. RGBFB_Y4U2V2 and RGBFB_Y4U1V1 also opened up but the colors were messed up (probably normal).

>and the PIP opened with rainbow colors. RGBFB_Y4U2V2 and >RGBFB_Y4U1V1 also opened up but the colors were messed up >(probably normal).

you mean when you use RGBFB_Y4U2V2 then it work ?
thats the mode ffplay need (its same as YV12)

As Itix told, P96 pip fit not good in SDL concept.
but i think about add a amiga only flag in setvideomode that the backend know that a pip window should open instead of a normal window.

for example when in sdl setvideomode SDL_P96PIP flag is set, then a pip window is open when user have a tooltype set sdl_video_yuv_hwaccel

this envvar is still check in sdl so it seem thats on all systems same

bernd_afa wrote...

>you mean when you use RGBFB_Y4U2V2 then it work ?

Yes. The P96 example OpenPIP opened a window with the tag P96PIP_SourceFormat, RGBFB_Y4U2V2, set. The rainbow effect that OpenPIP renders did not work however. I believe this is because the normal graphics rendering functions do not work with YUV. You will probably have to do your own YUV rendering directly into the YUV bitmap. Picasso96.h says...

"By now, the following formats are for use with a hardware window only (bitmap operations may be implemented incompletely)"

I believe the original OpenPIP failed simply because the Voodoo3 hardware did not support the format RGBFB_R5G5B5 in PIP/overlay. Looking at the datasheet/programmers manual for the Voodoo3 (Avenger chip) verified this mode is not supported. There is info on the YUV format in there as well as what formats are supported and which aren't if you would like me to send you a copy. I can test anything you want to send me too.

Hi all,

I did lot of demo with asmone and i want to develop my new babie with amydevcpp, i mix c++ and asm in a separate file.

Do you know if it's possible to have section and if it's possible to specify chip or fast section. I tried all syntax ".section" "SECTION" it seems is not possible, if you have information it will be really appreciated.

Jamie

sorry bad copy past