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.