Mplayer 6.4 userguide for AmigaOS4.1

LiveForIt-Mplayer 6.x requires: AmigaOS4.1 Final and Radeon™ HD v2.4 drivers from Hans/A-EON, to take full advantage of COMP, COMP_YUV and COMP_YUV2.

News_Release_RadeonHD24.pdf
www.vesalia.de
amigakit

If you do not plan to upgrade just yet, stick with the older LiveForIt-Mplayer version 5.5. or be forced to use cgx_wpa, SDL or p96_pip.

Some useful information that only relates to LiveForIt-Mplayer 6.4 for AmigaOS4.1

Video outputs mplayer for AmigaOS4.1 supports:

Comp
This video output is written by Kjetil Hvalstrand and is based on cgx_wpa output, but was changed to use composition instead of WritePixelArray(), and enabled the video output to have scalable windows, and full-screen mode that allowed the video to stretched to fit screen mode. the video output convert yuv420/yv12 bitmaps into 32bit ARGB bitmaps using the CPU, just like CGX_WPA.

Comp_yuv
This is based on Comp, but was rewritten to use new color spaces yuv420p that is now supported by 
Radeon HD 2.4 drivers for AmigaOS4.1, this basically enables this video output to not need to convert into ARGB format,
in addition DRI support was added for codecs that supports this, and we have accelerated video to graphic card using DMA from new Graphic library 54.153. this video output supports window scaling and full screen mode.

Comp_yuv2
Same as comp_yuv but mplayer do not wait for vsync to complete, window refresh has been moved into its own thread, so mplayer can continue doing some thing else, while it waits for vsync.

Cgx_wpa
This video output was originally written by DET Nicolas, and Fabian Coeurjoly, to use CyberGraphicsX on MorphOS and AmigaOS, AmigaOS4.x uses Picasso96 so this heavy modified version of the original, most of the code is the same. the video output support window mode, but you can't re-size the window, the video also support full-screen, but no scaling to fit the screen. 

P96_PIP
This is the good old Picasso96 overlay video output from Jorge Strohmayer, originally it did not support double buffering, I added double buffering to video output, this video output support window mode and full screen.
the video output does not support DRI nor DMA transfer.

PIP
PIP is experimental video output from Jorge Strohmayer, full screen mode is not working atm, and PIP is there for not included in mplayer build by default. some optional color spaces is supported.

SDL
(Simple DirectMedia Layer), is a none native GUI system that sits on top of graphic.library,
SDL should support overlay, but this is not implemented on AmigaOS4.1, SDL is there for slow to render graphics, SDL video output support CPU scaled video output in window mode, but not in full screen.


Using video outputs:

Options for comp/comp_yuv/comp_yuv2.


Mplayer mymovie.avi –vo comp_yuv2:help

Shows a list of video output options.

Mplayer mymovie.avi –vo comp_yuv2:monitor=0

This opens up mplayer on monitor 0 or first monitor, when going full screen, no need for screen promotion in Workbench.

Mplayer mymovie.avi –vo comp_yuv2:monitor=1

This opens mplayer on monitor 1 or second monitor.

Mplayer mymovie.avi –vo comp_yuv2:nodma

Disables DMA, this can be used for debugging.
Image is now writes directly to VRAM,
(If codec support DRI, then video output will be black, when DMA is disabled.)

Mplayer mymovie.avi –vo comp_yuv2:nodri

Disables DRI rendering, forces mplayer to draw images using slices.
(Many codecs do not support DRI)

Mplayer mymovie.avi –vo comp_yuv2:pubscreen=dopus.1

This should open mplayer window on public screen dopus.1


Options for P96_PIP 

This one does not have any options.


Most common options for PIP
 (not compiled into mplayer by default).

Mplayer mymovie.avi –vo pip:mode=0

display video in YUV410 format (default)

Mplayer mymovie.avi –vo pip:mode=1

display video in YUV420 format

Mplayer mymovie.avi –vo pip:mode=2

display video in YUV422 format


Using AREXX with mplayer:

Start mplayer from shell.

Now you can send ARexx commands like this.

Rx Arexx/Volume100.rx

this script sets mplayers volume to 100% volume.

Rx Arexx/GetTimeLength.rx

Get length current film played.

Rx Arexx/GetPercentPos.Rx

Get percentage position in the film.

Rx Arexx/Help.rx

Get a list of ARexx commands from mplayer.

Q+A

What is DRI?
DRI is short for Direct Rendering Interface, when a codec support DRI, the codec asks the video output for image buffer, instead of allocating a buffer of its own in Codec, as result mplayer don't need to copy image slices from the codec buffer to video output.

What is DMA?

DMA is short for Direct Memory Access, DMA allows hardware to copy or access memory with out using the CPU. you can find more about it on Wikipedia:

http://en.wikipedia.org/wiki/Direct_memory_access

What is VSync?

VSync enables the program to sync to refresh rate, so you don't get a half drawn image, before it displayed.

LCD monitors use 60Hz refresh rate, older CTR monitors some time up 100hz refresh rate.
60Hz equals 60 frames per second; most videos are record at 25 FPS (frames per second).

LCD monitors have static picture, the image is changed at 60Hz, while the older CTR has to paint the pixels repeatedly this can make the screen flicker (as you can see the pixel turn on and off), if the refresh is 60Hz or lower, with higher refresh rate you trick the eye to not see it.

For general questions about mplayer you can find the Linux man pages on MplayerHQ useful

http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

MPlayer for AmigaOS4 is going full HD 1080p

Mplayer is going full HD 1080p, well at least we can play not so demanding codices, this big improvement from only being able to play 720p HD ready movies.

Here comes the story of the new MPlayer, I was approached by Matthew Leaman, about the work did with composition in the MPlayer version your using, he asked me if I was interested in working on "Composition accelerated video support" as he calls it, I just calls it YUV bitmap's. 

At the same time I was working on porting over my work form old MPlayer to new MPlayer 1.1.1 (2014) source code from MPlayerHQ.

When I accepted the challenge I got some example code from Hans, and got access to what I need to start adapting the code into mplayer video output "comp", it was relatively easy to adapt the code for mplayer.

First version with composition video bitmaps, cut time/cpu needed to display the video in half.

Hans asked me if it was possible to support DRI, so spent some time investigating, this was bit more work as need to adapt code from mplayer Xv video output and combine it with comp_yuv. This did not work out of the box, so to speak, Mplayer expected none Interleaved YUV420p bitmaps, but AmigaOS4.1 only supported Interleaved, so I removed the restriction and got it working.

The DRI gives a major speed up on any Codec that supports it, like MPEG video you find on DVD's and its also lot of older MPEG videos on the net.

Sorry don't have any numbers but speed difference was major.

Trever tested Mplayer and wondered about DVD playback, so looked into that did some testing and extermination, tried to find some bottlenecks, this work was big undertaking, things did not add up and mplayer benchmark was giving me nonsense numbers.

In the end, I decided to test MPlayer LibDVDCSS and do some benchmarking on that, so wrote a small program that only benchmark it, this is when I noticed that numbers where showing slow speed, so having excluded the rest of MPlayer from my test, I was able to focus on improving Libdvdcss and getting the speed up, what I quickly understood was that Mplayer was only reading 1 block, almost never tried to read more then 1, the result was the mplayer had to seek to a lot instead of just reading a chunk of data.

Then communication went silent for a while, Hans had been taking a bit about DMA, but I did not know if they where working on it.

So just before Amiwest I got a e-mail again about DMA being enabled, Steven Sollie provided SDK and OS files need and work started to get MPlayer to support DMA, there was some alignment problems.

MPlayer with DMA support was just ready for Amiwest, just two weeks before.

Just before Amiwest Andy sent me a e-mail, and exchanged few e-mail's

The funny thing was I did not know DVDNAV menu worked, I guess I typed the wrong command line :-)

Anyway I always used DVD option in MPlayer to play DVD's, from my experience it plays smoother, because you can enable cache, so that MPlayer don't need to wait for disk io.

This is what your going to get in the new MPlayer:

* comp_yuv and comp_yuv2 uses YUV420p bitmaps (NEW)

Enabled mplayer to take advantage of "Radeon HD" yuv420p support, this removed the need to convert yuv420p video to (32bit) ARGB bitmap format be-fore displaying it.

* comp_yuv and comp_yuv2 support DRI (NEW)

I spent some time reading and investigating Xv (X-Windows video) video output in MPlayer, to take advantage of DRI.

* MPlayer can now playback DVD's on X1000 at good speed (NEW)

AmigaOS4 does not read ahead blocks, this caused major slowdown in MPlayer, so hacked in read ahead buffering into MPlayer, to speed it up.

* Mplayer can playback file larger then 2Gb (NEW)

AmigaOS4 SDK does not support typedef off_t as 64bit, changed MPlayer to workaround the problem. 

* Mplayer can playback DVD's copied to hard-drives (NEW)

I have spent some time fixing path problems and getting this working, the support for native files and directories is intended for Linux mount points, but a bit of work it also works on AmigaOS4.1 directories.

You might experienced some crashed with AAC audio codec in old MPlayer, the AAC codec was replaced by MPlayerHQ developers so, no more crashed in that one.

It has not been easy not being able to say anything to anyone, in the forums, as people where used to get regular updates, but In the end I think every one is going to be happy.

Yesterdays problems, is todays success.

After finishing my blog yesterday, I decided  to use another technique to solve my problem.

So I know the read speed was not good, I wanted to isolate the problem, or try to exclude a problem by testing, individual components.

So I wrote a small test program for libdvdcss, by doing this I hit nail on the head, this was where speed problem was.

First run it showed about 64kb/s a bit more then when I was benchmarking from mplayer.

Corrected a few mistakes and I was at 200kb/s.

The experimented with my read ahead cache implantation, and I was soon at 800kb/s.

With bit more work I managed to get it up to 24000 kb/s, this is really close to the copy speed I got yesterday from DVD to HD.

So I think we can say the speed problem is solved.

The problem with mplayer is that it tries to read one by one block, but CD has spin up, it has to find the sector where block is located, and this for every time you read one block, this is not efficient.

sb600sata.device or sata device driver for X1000, does not try to pre buffer, this is the problem. So this is way I need to do that in mplayer/libdvdcss.

So what I try to do is, avoid any one block reads by pre fetching blocks, as mplayer mostly reads blocks in sequential order this pretty easy to do, so next reads is going to be really quick, until the read offset is outside the buffer and it has to fill the pre fetch buffer.

Also because its in memory, I do not need to foreword the IO read to the DVD read process I created, it can simply just copy the data from the buffer, so no need to wait for task switch, signals and stuff like that.

I call my pre buffering stuff "Evil" because it was quickly proto typed, as future note it should be moved into the dvdcss struct, so etch dvd device can have its own pre fetch buffer.

Anyway its not a problem for mplayer as I think there is only one process reading at any given time, from one device, I'm shore this might not be case for other operating systems.

Way I think this is not problem is because libdvdcss is not a shared library, the the pre fetch buffer is pretty mush private to mplayer as its static linked.

The mystery of the slow DVD speed and Mplayer for AmigaOS4.

I have been investigating the issue, for some time.

Trying to find out of problem was caused by read errors, and trying to locate the problem.

What I have done is fix cache and device io in Mplayer as it was broken, I was hoping by doing this the problem was going to go away.

But what it did was, it enabled mplayer to pre buffer 999999 bytes, but as soon as the buffer runs out mplayer is back to crawl speed.

I have tried to compile the latest version of mplayer and ffmpeg, and the problem remains. I have tried to read from the filesystem instead of depending on the IO system, by fixing that part of the code as it was broken as well, but there is no luck there, reading a DVD is not like reading a file.

I measured the read speed, at device IO in libdvdcss/device.c and found the 38KB/s read speed, so in other words, the read speed is low, it should be around 1.49MB/s, so we are not even close, to be playable.

I made some tests to see what best copy speed was, I copied a 972Mb file in 372 sec, or 2.6Mb/s, so this is not a hardware problem, the problem most be with DVD://1 DVDNAV://1 -dvd-device option.

I can play the a VOB file from a DVD disc, with some cache, but only this way I get good speed, with out cache its just as slow as the DVD://1 DVDNAV://1 options.

I have taken the time to look at the status line in mplayer, it says some thing like:

A: 13.1 B: 3.2 A-V: 9.981 ct: 0.051 77/155 39% 24% 10192.1% 153 0

So what this status line says is that A: is for audio, it represent the time played for audio, and V: for video, A-V: is the out of sync number it should be 0, 77/155 is decoded vs the not yet decoded frames in buffer, 29% is codec, 24% is the video, and 10192.1% is the audio,

the the biggest problem looks to be related to audio, but its not really, the high number comes because the audio buffer is empty and the audio cache has to be filled, so I tried to trace the it up stream, from main loop in mplayer.c, but it was not easy.

So then I remembered about debug features in AmigaOS4.1, so I decided to collect some information using stacktrace feature.

There was a problem it required the task I wanted to be halted, while using back trace, but that was lucky not a issue for me, as device io code was moved into a different task of its own, to prevent problems with treading in mplayer, and task that issues the read waits for signal for data to be ready, so I was happy about that, if not might not have tried this.

Anyway here is stack traces I made, using Exec debug interface.

Stack:

kernel : NULL

kernel : NULL

mplayer : dvdcss_seek

mplayer : css_seek

mplayer : UDFReadBlocksRaw

mplayer : DVDReadBytes

mplayer : ifoRead_PGC

mplayer : ifoRead_PGCIT_internal

mplayer : ifoRead_PGCI_UT

mplayer : ifoOpen

mplayer : open_s

mplayer : open_stream_full

mplayer : open_stream

mplayer : main

newlib.library.kmod : NULL

newlib.library.kmod : NULL

newlib.library.kmod : NULL

mplayer : _start

dos.library.kmod : NULL

kernel : NULL

kernel : NULL

Stack:

kernel : NULL

kernel : NULL

mplayer : dvdcss_seek

mplayer : css_seek

mplayer : UDFReadBlocksRaw

mplayer : fill_buffer

mplayer : stream_read_internal

mplayer : stream_fill_buffer

mplayer : cache_stream_fill_buffer

mplayer : demux_mpg_fill_buffer

mplayer : ds_fill_buffer

mplayer : ds_get_packet_pts

mplayer : decode_audio

mplayer : mp_decode_audio

mplayer : main

newlib.library.kmod : NULL

newlib.library.kmod : NULL

newlib.library.kmod : NULL

mplayer : _start

dos.library.kmod : NULL

kernel : NULL

kernel : NULL

Stack:

kernel : NULL

kernel : NULL

mplayer : dvdcss_read

mplayer : css_read

mplayer : UDFReadBlocksRaw

mplayer : fill_buffer

mplayer : stream_read_internal

mplayer : stream_fill_buffer

mplayer : cache_stream_fill_buffer

mplayer : demux_mpg_fill_buffer

mplayer : ds_fill_buffer

mplayer : ds_get_packet_pts

mplayer : decode_audio

mplayer : mp_decode_audio

mplayer : main

newlib.library.kmod : NULL

newlib.library.kmod : NULL

newlib.library.kmod : NULL

mplayer : _start

dos.library.kmod : NULL

kernel : NULL

kernel : NULL

So I hope this information is useful to find out where the problem comes from, if not it gives a good overview of where problem might be located I hope.

The problem with mplayer is to get a overview, anyway if anyone knows about free vitalization tool, to get some overview of this source code it might be rally useful.

http://cs.smith.edu/dftwiki/index.php/Visualization:_Old_Blog

AmigaONE-X1000 HDReady...

AmigaONE-X1000 HDReady...

I have been thinking about writing some thing about the fastest Mplayer from me, and about latest utf8.library, I guess I should say something.

Your AmigaONE-X1000 is now HDReady, you can now play 720p video whit out problem, thanks to a changes in vo_cgx_wpa driver, and the new vo_comp, the problem whit old vo_cgx_wpa driver is that it uses RGB, and not ARGB, the Radeon HD cards needs ARGB, so the result was that graphic needed to be converted before being sent over.

The second problem was that it was using software scaling, this slow and CPU intensive, by using hardware acceleration to do the scaling we can scale windows to full screen and back, whit using all the CPU power.

And I wanted to compile a fully AltiVec enabled version of MPlayer. The vo_cgx_wpa and vo_comp is also useful for Sam460 users, it does help to reduce CPU load. How it all came about:

Back story:

well it started because I realized Ka1e needed help, whit MUI-MPlayer, he was begging Hans to emulate overlay, Hans did not want to spend time on obsolete technology. Nor did he have time for that, so this is way I did take on this challenge.

History for Mplayer for AmigaOS4.

The MPlayer project for AmigaOS4 started whit me I think, at least for AmigaOS4, the MorphOS version already existed before I tried to compile it. more importantly my attempt showed it was possible to compile it.

Click this link to read how it all started

I did not manage to compile it because some fork() stuff, but Andrea Palmate'(‎'afxgroup'), did and so it became his project, Varthall and Abalabanb started a project a project on code.google.com.

Now I'm going to tell you some thing not every one knows, or at least where few. After Andrea Palmate successful ported MPlayer to AmigaOS4, I requested the source code from him, and worked on a plugin for IBrowse 2.4, but due to complications and way I decided to do it failed, this project ended in yuv420 to ARGB routine and some stuff, that project is dead now.

http://www.amigasoft.net/pages/mplayer/mplayer.asp

While I never got MPlayer IB2.4 plugin to work as good as I hoped for the work on IB2.4 plugin did end up in plugin for Audio, this probably the route I take if where to redo it.

http://www.os4depot.net/index.php?function=showfile&file=network/browser/np_audio.lha

So I'm well familiar with MPlayer well before I started on this projected. While I was not one to implement MPlayer I was the one who initiated it on AmigaOS4, so it bit funny to see whit project coming back to me, or at least partly.

Today this is no longer needed for a IBrowse plugin whit HTML5 the web browser does no longer need a plugin to play videos, thanks to the Excellent work of Fab and Ka1e.

What is future for me and Mplayer, I have not yet decided, I have some ideas, more likely its going to be fix up mplayer-amigaos at code.google.com at least. Now that Me and Ka1e has joined the code.google.com mplayer-amigaos effort, I like to see is FAB and Andrea Palmate joining the mplayer-amigaos code.google.com effort, so this becomes team work, so whit don't end up whit different MPlayer whit bug that's already fixed in different MPlayers and so. Even if all mplayer can be based on common code base, it might be possible to have unique versions of MPlayer I believe.

https://code.google.com/p/mplayer-amigaos

Its always good to experiment.

While things does not always work out some time you learn something that can be of use latter, this is a example of this at lest for me. I can also take the Basilisk II as an Example, Basilisk was first please I used Composition for scaling window content, part of that code made into Mplayer vo_comp. I have also been using Composition in Excalibur, to do alpha blending also.