Mplayer Altivec test version for G4 and PA6T-1682M

@mufa

Thanks, that works. However simply defining a -vo mode first stops the diagonal lines altogether.

the lines dont appear on all vids, one that it does occur on is an mp4 854x480 version of big buck bunny.

Anyone know with -vo SDL, how I can stop some videos opening in fullscreen on my 9250? I want them to open on my 6850.

@tommysammy

Sorry to say it looks like 720p (HDReady) to me, judging from size of the window.

http://www.auby.no/files/video_tests/

try to download

Monsters.mkv and Birds.mkv and compare the size of the window.

Don't try full screen whit your current version, it won't find a resolution that works, and it will run for every in a loop trying to find one

@LiveForIt

Quote:


Actually, using DMA is even more important with PCIe. PCIe has a huge penalty for transferring data in small blocks like, for example, 32-bit words. The only way to achieve efficient high-speed transfers is using DMA. Have a look at this document, and you'll see what I mean.

Right now, there is no DMA support for the A1-X1000, although that should change at some point. Using an altivec based copy routine, we max out round 400 MiB/s (link). Using a double-precision float based routine drops that to round 200 MiB/s, and a 32-bit routine would be approx 100 MiB/s. IIRC, the theoretical max is 4 GiB/s, although this is never achieved.

To see what a difference DMA makes, have a look at this result for the Sam460ex (NOTE: it has a 4x PCIe slot, with a theoretical max of 1 GiB/s). For a more extreme case, look at this result for a Sam440-flex + Radeon HD 6770.

Directly writing to VRAM helped on old machines like the A1-XE that had slow RAM. In that case, writing it in slices allowed you to copy from the CPU cache straight to VRAM, bypassing the slow RAM. This may well outweighed the speed boost of using DMA on these machines. However, our newer machines have much larger RAM bandwidth, and with the PCIe bus the performance boost from using DMA is much larger. Even with PCI cards, DMA can double the transfer rate (link).

So, please use p96WritePixelArray()to copy the frames to VRAM. Or allocate a user-private bitmap in RAM, and use BltBitMap(). Both of these will use DMA where available (currently Sam440 & Sam460ex), and fast per-platform copy routines elsewhere. By all means, provide backup routines where it makes sense (e.g., A1-XE), but don't think that you can outrun DMA.

Hans



P.S. If you're worried about having to copy from libavcodec's internal buffer to yet another buffer, have a look at the FF_BUFFER_TYPE_USER flag mentioned in this doc.

@LiveForIt

Quote:

Those two files use the high profile of H.264 which is very processor intensive. AFAIK, playing that profile in 1080p is multi-core territory, so those are unlikely to play smoothly.

By contrast, I tried watching several seconds of a 1080p DIVX of Big Buck Bunny (I really should get some more videos ), and it did play smoothly. Only just, though.

Hans

@ddni
Quote:

vo_sdl.c should be hacked to make window mode as default (as Mick do in his sdl buld, and as how i do with his help in latest muimplayer betas, hope he doesn't mind that i share it): in config(), at end, remove those strcmp's and co.

I.e. original:



Hack to make window mode be default by changing original on:

@kas1e, LiveForIt, Hans

So does the MUI-Mplayer for OS4 not use DMA but manual byte-copy in the cgx_wpa mode??! No wonder it can't do HD if so...

@Deniil

Well its different because its a private bitmap, not a displayable bitmap. It most likely has to convert the RGB to ARGB and copy it over using DMA. Changing from RGB to ARGB might speed it up.

@LiveForIt

I'll make a new version of MPlayer-GUI with cgx_wpa and comp. I should have done that a long time ago but just didn't get too it.

@Deniil

Well we should setup a new repo, and so ever one who wants to work on it can make improvements.
One thing, is gui stuff in mplayer is real mess, it should be moved out of the drivers, and into its own .c / .o file.

There is even a directory for it in mplayer so, where GTK and other GUI's are.

@Deniil

if I remember correct Andreas Palmate mplayer there was a standalone GUI for starting videos, you made.

@Deniil

Quote:The cgx_* modes are MorphOS/CyberGraphX code and of course not usable on AmigaOS (AmigaOS doesn't have a cybergraphics.library, except for a very minimal emulation for ancient AmigaOS 3.x/m68k software only).
It may be able to display something, but even using SDL instead should be much faster.

My old MPlayer p96_pip code was implemented on an AmigaOne XE with Voodoo3 gfx card and isn't usable that way for current systems either. It has to be reimplemented using the DMA accelerated IGraphics->BltBitmap(), IGraphics->CompositeTags(), IGraphics->WritePixelArray() or IP96->p96WritePixelArray() functions.

@joerg
Quote:

On radeonHD it is already like this: sdl output faster than cgx_wpa ones. But, on older cards (radeon92xx , etc), cgw_wpa still prettyu much faster than sdl output (at least on videos i test).

@LiveForIt

The MUI GUI code is not a mess at least, it's handled in gui/morphos/ directory along with the other toolkits...

cgx_overlay_gui has some relations to the gui system, so it has to support some specificities, but it's very minimal, actually.

@LiveForIT
As we all know, there is no "gui" for any mplayer on os4 (except muimplayer port from Fab): that Mplayer-GUI done by Deniil, are not real gui as you don't have from it any real control, its just cover command line options in friendly maner. And fab's gui done good and clean, check his sources:
http://fabportnawak.free.fr/mplayer/s ... 11.2010.r32620-src.tar.gz

@Fab
I think liveforit mean that piece of code which is not gui at all, but which have some "control" and which code are in the afxgroup's mplayer (that simple control placed over the video, like OSD or so)

@LiveForIt

Quote:

Good news, finally I got a reply from Varthall and he confirm that today you should get the access to the repository

@Denill

As you working on a new version of the GUI i have a little report for you !
When you iconify MPlayer GUI, then the icon willl be placed in a wrong position in WB

@kas1e
Quote:

Before dropping the project Andrea worked on a little Reaction GUI implementation as a test (he also showed at Pianeta Amiga 2006 or 2007), it didn't worked at 100% but it's pretty possible that then he also included into his source archive that then it was also uploaded on Google site ..

@Samo
Ask plz varti to add me as well, i have some stuff to add too

Quote:

Probably that p96_pip_stuff.c in libvo, where inital attempts was done (and maybe because of that liveforit think that gui code is here).

@kas1e

Quote:

Ok!

@kas1e

There is a lot of stuff in cgx_common, and yes there are lots of GUI stuff in p96_pip.

So its there so the GUI stuff is bit here and a bit there.

By moving the the stuff out of p96_pip, the Reaction GUI can be made usable from any output driver, or if people like use MUI GUI.

@LiveForIt
Quote:

Maybe you mean p96_pip_stuff.c ? But yep, i also remove bunch of code from p96_pip.c too for fab's port and fully get rid of p96_pip_stuff.c file (compare my p96_pip.c for port and original, its i think on 50% less). As for cgx_common, there is fab's version:
http://kas1e.mikendezign.com/temp/muimplayer/cgx_common.c
It didn't have gui code , so we need just reuse it as well.

If there is any gui related code in the version on google, we should for sure just remove it all , and put everything in gui/reaction/ , all that unfinished stuff about which samo told also should go there, then i also can add easy fab's mui code to gui/mui and we will have one normal version at last which will include everything. And if anyone will want to works on reaction based gui later, he know where all placed.

Imho place gui code to drivers itself wasn't good idea at all. Drivers should be drivers, gui in gui. Finished or unfinished does not matter of course. Once Varti will add us on project we can clean it all.

@LiveForIt
Donated a bit for your work on compositing driver: hope it will motivate to works on it more by bugfixes and speed improvements.