[Mplayer-dev-eng] SLOW HARDWARE

[Nick Kurshev]

Hi, Arpi!

On 2001-07-18 23:13:56 you wrote:

>
>> 2. Superficial analysis shows me that mplayer too frequently calls read() function
>> to read next bit from file. There was report that on FreeBSD mplayer works faster
>> than on Linux. In this connexion maybe it would be better to add mmap technology
>> to read from memory, instead file directly. In this case system will read from
>> file only 4K blocks that is much faster of calling read() function for each byte even
>It is not true. CUrrently mplayer reads file by 2048 byte blocks. Check
>stream.c...
>It uses 2kB buffer, and read bytes from this buffer. if it's empty, it reads
>2048 bytes from teh file (or 2324 bytes from VCD sector).
>
>I'm already working on the new cache system, it will be integrated to
>stream.c. It supports big buffers, and also backward caching.
>Check TOOLS/cache2.c. It has nice simulation included :)
>(random reads, and simulated low input bandwith)
>
>I think it will solve this problem.
>
>Btw for an average DivX, it is not a real problem.
>A 800kbit tipical file uses 100kbyte/s, divided by 2k it's 50 read() per sec.
>
>> from buffer. (You will be able to read from memory an each byte even in codecs).
>> Am I wrong?
>mapping big files (even 600MB, but what about >2Gb files?) to memory
>will be hard...
>
Not sure! I think that for DVD (imho >2Gb does mean that?) it would be better
to use mmap64 with simplest logic of checking boundary. For "normal" streams
you could apply 'mmap' without additional checking. Anyway mmap is only way
to do stream reading a very easy thing and it requires much less efforts from your part
(I mean: development of new cache2.c) and from program part (I mean computing
of complex logic of caches).

Best regards! Nick (2001-07-21 09:06:37)


_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng