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