Opened 11 years ago

Last modified 10 years ago

#1363 new defect

-cache works very badly with non-interleaved files

Reported by: toralf.foerster@… Owned by: reimar
Priority: normal Component: core
Version: 1.0rc2 Severity: normal
Keywords: Cc: reimar, basinilya@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


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

Change History (5)

comment:1 Changed 11 years ago by reimar

  • Cc Reimar.Doeffinger@… added
  • Summary changed from mplayer works with "-noache" and w/ "-cache 8192" but not w/ "-cache 819" to -cache works very badly with non-interleaved files

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.

comment:2 Changed 11 years ago by toralf.foerster@…


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) ?

comment:3 Changed 11 years ago by 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.

comment:4 Changed 10 years ago by basinilya@…

  • Cc basinilya@… added

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.

comment:5 Changed 10 years ago by 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...

Note: See TracTickets for help on using tickets.