[MPlayer-users] DVD playback issue on older notebook with not so old Linux kernel

Dave Woodfall dave at tty1.uk
Mon May 18 23:57:41 EEST 2020

On 2020-05-17 20:45,
Erik Auerswald <auerswal at unix-ag.uni-kl.de> put forth the proposition:
> Hello Alexander,
> On 17.05.20 13:07, Alexander Strasser wrote:
> > On 2020-05-15 11:05 +0200, Erik Auerswald wrote:
> > > I'd like to describe a DVD playback issue I encountered, and how to work
> > > around the problem, just in case someone else runs into it.
> >
> > Did you have a look at the caching settings?
> > In particular -cache and -cache-min ?
> Yes, I did.  I am using a 64MiB MPlayer cache for DVD playback with the
> default -cache-min setting.
> I have been using these settings for years on the exact same hardware.
> The playback issues described in this thread are relatively "new".
> (I reinstalled the notebook with Ubuntu 18.04 about a year ago.)
> Using no MPlayer cache for DVD playback, e.g., for dvdnav://, does not
> work well on that notebook.

It's usually recommended not using cache  at all to play DVDs, as you
may know.  MPlayer should play directly what is coming from the drive
without caching it.

It sounds to me like your DVD player can't spin fast enough if
MPlayer can't play without cache, or perhaps it's having problems
reading the disk, and is re-reading too often.  Have you tried any
other drives?

There may also be power saving settings that keep the drive from
spinning up.  I'd look into that, and also cpufreq may need to be set
to `performance' if it's in `powersave' mode.

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

will output what CPU scaling is in use.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

will show the governors you can use.  For me it outputs:

performance powersave

You may have different governors available, depending on the kernel

echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

will set that governor.

I think toying with cgroups or swappiness is looking in the wrong

Did you say what hardware you're using?  CPU cores, speed, RAM, DVD
drive model and max speed etc?

Knowing those might give more clues.

> The playback problems usually occur late in the movie, even after
> pausing the playback (which should give the cache time to fill).
> Swap stays usually empty on that system, but directly after the first
> stutter during DVD playback, swap is used.  After each stutter, more
> swap is used.  Disabling swap has so far reliably prevent the issue.
> The stuttering "feels" just like Linux's whole system stalls on write
> back.  Since I do not have an HDD LED on the notebook, I cannot easily
> see if HDD activity and DVD playback problems coincide.  I do think that
> my conclusions are plausible (and disabling swap works for me ;).
> > [...]
> > > From reading the kernel source, it may be possible to prevent swapping
> > > by placing MPlayer into a memory cgroup with memory.swappiness for the
> > > cgroup set to 0.  I have not yet tried this.
> I have tried this, but it proved not to be sufficient.
> While putting a memory cap on the cgroup (e.g., 512MiB) and setting
> memory.swappiness=0 for the cgroup can prevent an MPlayer process placed
> there to induce swapping, sometimes the page cache contents are not
> attributed to MPlayer.  When playing large video files (not DVDs) from
> an NTFS filesystem mounted via FUSE, page cache grew beyond the cgroup
> limits.  When playing DVDs, sometimes page cache use of DVD data was
> limited by the cgroup memory controller, but once it was not (ejecting
> the DVD freed about 5GiB from the page cache, so it was DVD data).
> There is still the problem of other activity on the system beside
> MPlayer, thus limiting how MPlayer alone affects the page cache cannot
> always be sufficient.
> > > Many years ago, MPlayer developers looked into using something like
> > > madvise(2) to optimize MPlayer's memory usage, but at least back then
> > > it did not look promising.
> I was probably thinking of posix_fadvise(2).
> The situation may have changed since then, but I did not check
> (https://lwn.net/Articles/480930/).
> With MPlayer providing a specialized caching layer (unless -nocache is
> used) it may seem sensible to try to minimize page cache impact when
> -cache is used.  This could help in general, but would probably not
> suffice to reliably prevent the swap issue I have described.
> Before Ubuntu 18.04, I was using encrypted home directories instead of
> full disk encryption.  Then I relied heavily on the page cache for
> decent performance, and playing a DVD totally trashed the page cache,
> but DVD playback worked without stuttering.  The full disk encryption
> of Ubuntu 18.04 seems much more performant, because this general
> performance issue is gone.
> But I doubt that the results of MPlayer based page cache control can be
> significantly better than using a memory cgroup to constrain MPlayer.
> It would be more convenient, though.
> Additionally I tried using nocache (https://github.com/Feh/nocache),
> but that did not have any observable effect on DVD data in the page
> cache.  It did not prevent swapping and the swapping related pauses.
> Thanks,
> Erik
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users


More information about the MPlayer-users mailing list