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

I have been investigating the issue, for some time.
Trying to figgier 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 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 auto 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.
I also 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.
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.