Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
63 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 63

more...

Support us!

Recent OS4 Files
OS4Depot.net




« 1 2 (3) 4 5 6 ... 15 »


Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2006/12/27 21:09
Posts: 86
@kas1e

As far as yuv-rgb conversion goes, from what i can gather from the source code is that avcodec already returns the video frame buffer in ARGB32.
I tried to change it so Compositing does the conversion but resulted in a good big crash (kas1e might have more details).

while Hardware compositing returns successfully i am now blitting the video buffers to a bitmap ,then compositing to the bigger bitmap and blit again to a buffer suitable for cairo rendering.
I was hoping the overhead added by this would be magnitudes lower than to scale the data by cpu,seems i was wrong or i need to remove a few steps still, for instance allocating/freeing both src,dst bitmaps for each frame.

If the data alignment is correct, i may also lock the destination buffer to pass the image data directly to cairo without blitting it to another buffer again.

If someone's willing to try changing this to see if it behaves better please do so, i can't commit for this week to the task.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
I would propose everyone to use git branches so you could easily share the changes for comments and ideas.

Did you try something like: https://github.com/kas1e/Odyssey/blob/ ... owbbrowserclass.cpp#L3884

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2006/12/27 21:09
Posts: 86
@Ami603

Meanwhile I've found where it asks the desired pix format, it is found at :
Odyssey-master/odyssey-r155188-.23/Source/WebKit/OrigynWebBrowser/Api/MorphOS/owbbrowserclass.cpp, line 3923:

from:
if(data->video_element)
{
data->video_element->player()->setOutputPixelFormat(AC_OUTPUT_RGBA32);
}

to:
if(data->video_element)
{
if(data->video_mode == SRCFMT_YCbCr16)
{
data->video_element->player()->setOutputPixelFormat(AC_OUTPUT_YUV422);
}
else if(data->video_mode == SRCFMT_YCbCr420)
{
data->video_element->player()->setOutputPixelFormat(AC_OUTPUT_YUV420P);
}

// data->video_element->player()->setOutputPixelFormat(AC_OUTPUT_RGBA32);
}

(copied from the part where it sets up the overlay window)

I think this is the part that was missing for getting the correct yuv format and let compositing do the conversion.
Please be aware that i am not familiar with yuv bytesize stuff and that might need some adjustments on Odyssey-master/odyssey-r155188-1.23/BAL/Media/WebCore/MorphOS/BCMediaPlayerPrivateMorphOS.cpp

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:

Btw, are compositing supported by older cards we have like radeon9250, etc? If I remember right it supported as well? (i mean adding compositing acceleration will work everywhere and on new Radeon, and on old ones) ?

IIRC, nobody has implemented composited video in the old atiradeon.chip driver. So, an overlay fallback might still be worth writing for the old cards.

Quote:
Just to understand it more, you mean "Use CompositeTags() to do the YUV=>RGB conversion when blitting to the screen" is that "yuv=>rgb conversion and scaling on the fly"?

I.e. just using CompositeTags() by itself mean YUV->RGB conversion will be done, and programmer need to not worry about, and not specify any special flags to fucntion about ?

Yes. You give it a YUV input bitmap and an RGB destination, and the conversion just happens (if the driver supports it). There are extra flags to control a few options (e.g., the YUV=>RGB matrix to use), but the basic operation is as simple as a regular RGB=>RGB CompositeTags().

@Ami603
Quote:
As far as yuv-rgb conversion goes, from what i can gather from the source code is that avcodec already returns the video frame buffer in ARGB32.
I tried to change it so Compositing does the conversion but resulted in a good big crash (kas1e might have more details).

The avcodec library will convert to ARGB32 *if* you ask it to. You'll want to disable that if you want to take advantage of composited video.

Likewise, you'll want to avoid feeding the result back into Cairo, because that means copying the RGB frame from VRAM back into RAM, which is going to be rather slow.


EDIT: I see from your followup post that you'd already found out how to get the video's actual pixel format from avcodec...

Hans

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@All
Don't forget plz to add changes via #ifdef __amigaos4__ , for making later porting of 1.25 version easer (to things can be just mostly copy+paste) as well as have ability to build it cross-platform still will help. Morphos parts can be keept or via #ifndef __amigaos4__ , or via #ifdef __morphos__

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2006/12/27 21:09
Posts: 86
@kas1e

got mail

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill (and Hans?)

We go with Ami603 pretty far now. The only file we touch now is owbbrowserclass.cpp, in the hope to create the same how it for morphos.

Currently what we have, is that pressing on fullscreen button works, open the fullscreen, switch back works, etc, But when we trying to do bitmap copy we crash in that Blit() method.

(press open in new tab for fullsize):

Resized Image

Without copying, we actually have all functionality works, we can go to/from fullscreen, the video didn't interrupt and works when we switch between window and fullscreen (just in fullscreen all black as no copy done, but music can be heard). So all we need is a correct copy (see amigaos4 ifdefs in DEFSMETHOD(OWBBrowser_VideoBlit) ).


But we already can see that CPU loading reduced a lot (x3 times), so decoding of frames surely happens and faster much. Bitmaps are allocated just once now, and the render must go directly to VRAM without running inside Cairo. And no conversion to RGB as well as compositing do so, so we can hope that pure blitting should't take away more resources and we can expect pretty good and big speedup in compare with "cairo window"

Now, Ami603 just runs out of time, and we need your help (and help from others of course), to just check the new owbbrowserclass.cpp file and find out what we do wrong there :). Vicente do the bitmap copy differently, so we need to find out wtf.

There is a new file (with our incorrect copy):

http://kas1e.mikendezign.com/a/owbbrowserclass.cpp

Everything was done via amigaos4 ifdefs, so should be easy to follow.

We pretty close!

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

I've taken a quick look at the code. Is it the actual BltBitMap() call that's crashing? Or OWBBrowser_VideoBlit()?

If it's the latter, then the problem is most likely that the code assumes that the U & V planes are completely separate, whereas Picasso96 stores them in an interleaved format.** So, the following won't work properly:
CopyMem(sCb, pCb, (ptCb * h) >> 1);
CopyMem(sCr, pCr, (ptCr * h) >> 1);
This will read beyond the boundaries of the source frame, and write beyond the end of the destination bitmap because stCb != ptCb, and stCr != ptCr.

Interleaved format is like this:
YYYYYY
YYYYYY
YYYYYY
YYYYYY
UUUVVV <<== EDIT: Could also be VVVUUU. Make no assumptions
UUUVVV

instead of:
YYYYYY
YYYYYY
YYYYYY
YYYYYY
UUU
UUU
VVV
VVV

Where, Y, U, & V, are pixels for each of the channels. Notice how UBytesPerRow == VBytesPerRow == YBytesPerRow, and each row contains both U & V data. I recommend adding a check for this, and using different code to do the copy. Try disabling the if(stY == ptY...) section, which will force it to use the "else do" code below. If that works, then switching to something like the following should work for Picasso96's interleaved format:

// Copy the Y channel
CopyMem(sYpYptY h);

// Now copy U & V
do {
    
CopyMem(sCbpCbw2);
    
CopyMem(sCrpCrw2);

    
sCb += stCb;
    
sCr += stCr;

    
pCb += ptCb;
    
pCr += ptCr;

    
-= 2;
while (
0)


Just a few side comments:
- The BltBitMap() call should use the srcbm/destbm size rather than msg->width/msg->height
- Some video codecs allow you to set the Y, U, & V destination buffers, which would allow you to decode directly into srcbm (after getting it working first...)
- I see no reason to use vertex arrays for compositing. Standard rect compositing should do just fine

Hans


** This has tripped multiple people up in the past. I wish Picasso96 had gone with completely separate planes, but it didn't.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Hans
It crashes in OWBBrowser_VideoBlit() function, on line 4229 , which is CopyMem(sY, pY, w);

And block looks like this (which if scroll down in new file past the os4 ifdef, almost copy of the same part on morphos):

.
                else do
                {
                    
CopyMem(sYpYw);

                    
pY += ptY;
                    
sY += stY;

                    
CopyMem(sYpYw);  <------- THERE CRASH
                    CopyMem
(sCbpCbw2);
                    
CopyMem(sCrpCrw2);

                    
sY += stY;
                    
sCb += stCb;
                    
sCr += stCr;

                    
pY += ptY;
                    
pCb += ptCb;
                    
pCr += ptCr;

                    
-= 2;
                } while (
0);

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Hans
We just tried to comment out that block with copy and add like you show, i.e.

#ifdef __amigaos4__
{
    
GETDATA;
    
struct Window *window = (struct Window *) getv(_win(obj), MUIA_Window);
    
APTR memory;
    
uint32 bytesPerRow;
    
struct PlanarYUVInfo yuvInfo;

    
APTR lock LockBitMapTags(data->srcbm,
        
LBM_BaseAddress, &memory,
        
LBM_BytesPerRow, &bytesPerRow,
        
LBM_PlanarYUVInfo, &yuvInfo,
        
TAG_END);

    
//kprintf("blitoverlay %d %d %dn", msg->width, msg->height, msg->linesize);

    
if(msg->src && msg->stride && lock !=NULL)
    {
        
int w msg->width & -8;
        
int h msg->height & -2;
        
int x 0;
        
int y 0;

        switch(
data->video_mode)
        {
            case 
SRCFMT_YCbCr16:    // YUV422
            
{
                
UBYTE *dYUV;
                
UBYTE *sYUV;
                
ULONG dtYUVstYUV;

                
sYUV msg->src[0];
                
stYUV msg->stride[0];

                if(!
sYUV || !stYUV)
                    break;

            
//    dtYUV = GetVLayerAttr(data->video_handle, VOA_Modulo);        /// LINEA?
            //    dYUV = (UBYTE *)GetVLayerAttr(data->video_handle, VOA_BaseAddress); // ORIGEN
            //    dYUV += (y * dtYUV) + x;    // PRIMER PIXEL

                
if (stYUV == dtYUV && == msg->width)
                {
                    
CopyMem(sYUVdYUVdtYUV h);
                }
                else do
                {
                    
CopyMem(sYUVdYUVw);
                    
dYUV += dtYUV;
                    
sYUV += stYUV;
                } while (--
0);
            
                break;
            }

            case 
SRCFMT_YCbCr420:    //YUV420P
            
{
                
APTR pYpCbpCr;
                
UBYTE *sY, *sCb, *sCr;
                
ULONG ptYstYptCbstCbptCrstCr;
                
ULONG w2 >> 1;

                
&= -2;
                
&= -2;
                
sY   msg->src[0];
                
sCb  msg->src[1];
                
sCr  msg->src[2];
                
stY  msg->stride[0];
                
stCb msg->stride[1];
                
stCr msg->stride[2];

                if(!(
sY && sCb && sCr && stY && stCb && stCr))
                    break;

                
ptY  yuvInfo.YBytesPerRow;            // GetVLayerAttr(data->video_handle, VOA_Modulo) >> 1;
                
ptCr yuvInfo.UBytesPerRow;            // ptCb = ptY >> 1;
                
ptCb yuvInfo.VBytesPerRow;
            
            
/*    pY = (UBYTE *)GetVLayerAttr(data->video_handle, VOA_BaseAddress);
                pCb = pY + (ptY * msg->height);
                pCr = pCb + ((ptCb * msg->height) >> 1); */

                
pY  yuvInfo.YMemory;                // += (y * ptY) + x;
                
pCb yuvInfo.UMemory;                // += ((y * ptCb) >> 1) + (x >> 1);
                
pCr yuvInfo.VMemory;                // += ((y * ptCr) >> 1) + (x >> 1);

                // Copy the Y channel
                
CopyMem(sYpYptY h);

                
// Now copy U & V
                
do {
                    
CopyMem(sCbpCbw2);
                    
CopyMem(sCrpCrw2);

                    
sCb += stCb;
                    
sCr += stCr;

                    
pCb += ptCb;
                    
pCr += ptCr;

                    
-= 2;
                    } while (
0);

                break;
            }
        }
        
UnlockBitMap(lock);
        
BltBitMap(data->srcbm00data->dstbm00msg->widthmsg->height0xC00xFFNULL);
        
WaitBOVP(&(window->WScreen->ViewPort));
        
vertexcomposite(data->dstbm,window->WScreen->RastPort.BitMap,msg->width,msg->height,data->vleftdata->vright,data->vtop,data->vbottom1);

    }

    return 
0;
}
#else


As result complete freeze, and even on serial nothing come up, like very very weird things happens :)

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

I'm getting some strange YUV memory addresses and bytes per row values after locking the private bitmap. Also base address is NULL. Possibly my own bugs but just mentioning this in case this happens there, as well. Have to test the original example from Hans later.

Try debugging the parameters you are using and be aware that kprintf is only defined to DebugPrintF in some files - this bit me yesterday and I got some confusing serial logs.

From the serial:

Quote:

frame->data 0x629D4D00, frame->linesize 0x629D4D20
blitoverlay width 640 height 360 stride 0x629D4D20 src 0x629D4D00
BitMap base address is NULL
Locked RAM bitmap
sY 0x62284020, sCb 0x622BC420, SCr 0x622CA520
pY 0x54000000, pCb 0x021728D4, pCr 0xFFFFFF88. ptY 4294967176, ptCb 4294967176, ptCr 69
Dump of context at 0xEFE097C0
Trap type: DSI exception
Exception Syndrome Register (ESR): 0x00800000
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
DSISR: 00800000 DAR: 54000000


   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

Try debugging the parameters you are using and be aware that kprintf is only defined to DebugPrintF in some files - this bit me yesterday and I got some confusing serial logs.


Yeah for next beta i want to fully get rid of include of clib/debug_protos.h , kprintf() and libdebug.a. Just thinking how to do it better : replace just everywhere kprintf in all files, or, to add some #define kprintf DebugPrintF in some .h file which will be included in all files where kprintf() is called. That of course will be still "kprintf" writen, which can be misleading, but then no need to change a lot code. But dunno what is better for portability later.

Maybe better create some cross_debug.h file, in which add debugs for krptinf, DebugPrintF, and in all the code change kprintf() on some DebugPrintf() functinon ?

Imho right way will be later, we can do like we do in dopus5, just "debug.h" file which are:

#ifndef DOPUS_DEBUG_H
#define DOPUS_DEBUG_H

#if defined(__amigaos3__) || defined(__MORPHOS__)
#include <clib/debug_protos.h>
#endif
#if defined(__AROS__)
#include <aros/debug.h>
#undef bug
#undef D
#endif /* __AROS__ */

#ifdef DEBUG
#define D(x) x
#else
#define D(x)
#endif

#if defined(__amigaos4__)
  #define bug(fmt, args...)  {DebugPrintF("[%s:%ld %s] ", __FILE__, __LINE__, __FUNCTION__); DebugPrintF(fmt, ##args);}
#elif defined(__amigaos3__)
  #define bug(fmt, args...)  {kprintf("[%s:%ld] ", __FILE__, __LINE__); kprintf(fmt, ##args);}
#elif defined(__MORPHOS__) || defined(__AROS__)
  #define bug(fmt, args...)  {kprintf("[%s:%ld %s] ", __FILE__, __LINE__, __FUNCTION__); kprintf(fmt, ##args);}
#endif

#endif /* DOPUS_DEBUG_H */


   Report Go to top

Re: Odyssey's MediaPlayer thread
Quite a regular
Joined:
2009/4/28 4:57
From Adelaide, Australia
Posts: 938
@Hans

Quote:
IIRC, nobody has implemented composited video in the old atiradeon.chip driver. So, an overlay fallback might still be worth writing for the old cards.


I have a Radeon 9250 (don't know if SE). What is the difference between the Workbench compositing, vo_comp option of mplayer, or the compositing mode in the OS4 SDL2 port, which all work with these cards, compared to the composited video you're referring to?

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2006/12/27 21:09
Posts: 86
@MickJT

Newer drivers do yuv->rgb conversion on the GPU, thus offloading the CPU for other tasks

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2796
@Ami603

Yes but you need HD card or RT card, older cards can't, I think it even crash if you do not have right graphic card.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@MickJT

Workbench: window transparency effects using alpha channel.

SDL2: scaling and rotating of textures, alpha blending. Currently support only RGBA but if YUV support was added, then somebody could use SDL to implement video player backends. IIRC OGLES2 renderer support YUV already.

Here is more about YUV->RGB: http://hdrlab.org.nz/projects/amiga-o ... on-hd-driver-version-2-x/

@kas1e

Maybe it's time to write a reminder ticket about logging improvement.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

Maybe it's time to write a reminder ticket about logging improvement.


I just working on it already, hope to made proper commit today

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

Problem with LockBitMapTags and strange plane pointers (and DSI) seems to be because CGX has also this function and it is used instead of graphics.library one! After some hacking (inline4/cybergraphics.h) there is some video without crashing. I suppose this hack also helps there?

Now this mess just needs to be cleaned up. If it was upto me, I would start replacing CGX calls with graphics.library ones and put those IGraphics-> etc there. Or at least start reducing CGX usage.

IF we cannot get the correct YUV data via CGX, of course.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
We just tried to comment out that block with copy and add like you show, i.e. ...


Just realized that my code example won't work, because it assumes that the Y channel's source and destination widths are the same. So forget that, and go back to the original "else do" code.

EDIT: It will work if you put it in the "if (stY == ptY && w == msg->width)" section, where the source and destination bytes-per-row are the same.

@Capehill
Ah, that explains why it was crashing. Best get rid of all CGX calls and rely on the graphics.library alone.

Hans

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

Problem with LockBitMapTags and strange plane pointers (and DSI) seems to be because CGX has also this function and it is used instead of graphics.library one! After some hacking (inline4/cybergraphics.h) there is some video without crashing. I suppose this hack also helps there?

Now this mess just needs to be cleaned up. If it was upto me, I would start replacing CGX calls with graphics.library ones and put those IGraphics-> etc there. Or at least start reducing CGX usage.

IF we cannot get the correct YUV data via CGX, of course.


I remember that when i start to use some graphics functions instead of CGX ones, i start to have issues in other places. As well as when toget with -D__USE_INLINE__ and IGraphics-> inside of some namesspace webcore, or namesapce wtf, i also had compiling issues.

But sure, you are right, mess need to be cleaned out, at least for owbbrowserclass.cpp for start.

Maybe we just can rename current owbbrowserclass.cpp to owbbrowserclass_morphos.cpp, and made our one without cgx usage at all (where possible) ?

It's all just too much CGX based all over the code, so it can be long task to replace it all.

   Report Go to top


« 1 2 (3) 4 5 6 ... 15 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project