[MPlayer-dev-eng] [PATCH] cache fill adjustment

[Ivan Kalvachev]

Attila Kinali said:
> Heyo,
>
> Man, you are late, i could have used this patch in april :)
>
>
> On Mon, Jul 12, 2004 at 02:11:01PM +0300, Ivan Kalvachev wrote:
>
>> I have left the default extension of cache size minum. But I think
>> There is not a problem to set it about 1GB (the cache system need a sing
>> calculations, and from 4GB  it drops to 2. With one bit
>> safe for overflow ->1GB. For people with enough ram and CD-ROMs it is
>> enough.
>> BTW DVD's are usually bigger than 4GB.
>> The limit of 4GB comes from 32 bit pointer arithmetic.
>
> How about making this integer size dependend ?
> Ie using 2^62 as limit on 64bit machines ?
>
> I know very few people have already a 64bit machine, but we
> should not restirct ourselfs to the past. Beside that removing
> that limit will take time (ie will be never done)

You can remove it if you want. I had added an allocations check
(why it was missing before! mplayer segfault wihtout it, even with 32MB
limit!) So you can "safely" put any value in there.

Another more trivial problem. When you have an big cache and small prefill
(min fill actually), when you seek, with small quantity it sees that you
are seeking in a future cache location, and supress stream seek. Instread
it waits cache to be filled to that position.
The problem is that with bigger cache it may hang on filling for minutes
while resume(seek) will take only 2-3 seconds.

BTW. I have one rader stuped question. E.g. mplayerplug-in have an
disk cache system, where it downloads the file while playing it.
Do you think that such thing would be a nice feature. Of course it would
requare and second file that holds the valid (readed) regions and the
empty one. Don't forget that http:// and ftp:// streams are mostly seekable
atm.

Probably (when we have time), we should move dump stream to mencoder, and
modify mplayer dump comands to write the actually played streams.

Wish You Best
   Ivan Kalvachev
  iive