-cache works very badly with non-interleaved files

[toralf.foerster@…]

for the given downloaded and locally played file (revision dev-SVN-r28058-4.1.2) under a stable Gentoo system.

tfoerste@n22 ~ $ uname -a
Linux n22 2.6.27-gentoo-r7 #1 Fri Dec 26 18:15:21 CET 2008 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux

[reimar]

The file is badly muxed, it is non-interleaved (i.e. all audio data is in one piece at one place and all video data in piece at another).
-cache can not work with such files because the whole cache must be dropped and then reloaded again for each video/audio frame.
Anyway the video does play for me in all cases, but with -cache 819 it barely manages to play one frame per second, with -cache 8192 it almost plays in real-time while with -nocache it only takes 10% CPU.
I changed the summary but I doubt this will be fixed, since these files are essentially broken and a workaround exists.

[toralf.foerster@…]

Thx,

contacted the contact info of the appropriate web page. OTOH I'm wondering whether mplayer in such cases should automatically try to change the cache size instead of giving me an output like "your system is to slow" (or at least the hint should be given) ?

[swistakers@…]

Current SVN snapshot still has the same issue. Maybe the video is broken, but IMO it's usability bug that should be fixed. The idea of switching automatically to -nacache is not bad.

[basinilya@…]

Do you agree that even though the cache is designed to optimize linear
reads, it shouldn't make random access that slow? The overhead of
cache is too high and that points to unoptimized code.

[reimar]

I think this is a case of the cache being optimized for low CPU usage.
The default cache mode using a separate process probably will not be that easy to fix without causing other issues, but I sure won't mind anyone trying...