NOTE: I am not an expert with video decoding, but hopefully some of the following will be of use in improving your video playback... On Mon, Jul 09, 2018 at 09:19:34PM +1000, Russell Coker wrote:
[...] I've started seeing the following errors in the kernel message log when using mplayer while running kernel 4.16.0-1-amd64. When I play a 720p video (EG one downloaded from SBS on demand with youtube-dl) it works fine (although usually having that kernel error), but a FullHD video downloaded from YouTube causes extremely poor performance (hangs of a second every few seconds and jittering of the video) and is unusable.
What kind of GPU do you have? an AMD Radeon, obviosly from the dmesg output but what model ("lspci | grep VGA" if you're not sure) Are you using VAAPI or VDPAU with mplayer? VDPAU was originally nvidia-specific video acceleration API but for many years now there's been open source libs to support intel and amd GPUs. I use nvidia GPUs with the proprietary nvidia driver so vdpau stuff "Just Works"...and I don't have any direct experience using vdpau with other hardware or drivers, so consider the following a pointer in roughly the right direction rather than detailed instructions: You'll need to install at least the following packages if they're not already installed: apt-get install vdpauinfo libvdpau1 libdrm-amdgpu1 libvdpau-va-gl1 libvdpau-va-gl1 allows some programs using the VDPAU API to use OpenGL and/or VA-API acceleration. To see what kind of video acceleration is supported by your hardware & radeon driver, run "vdpauinfo". You may need to run it as "VDPAU_DRIVER=va_gl vdpauinfo" to set the env var before running it (see /usr/share/doc/libvdpau-va-gl1/README.Debian) This should show at least mpeg-2, mpeg-4, and probably h.264 acceleration. If it does, edit your ~/.mplayer/config to add vo=vdpau, vc=ffh264vdpau,ffmpeg12vdpau,ffodivxvdpau,ffwmv3vdpau,ffvc1vdpau,ffhevcvdpau The 'vc=' line will probably need tweaking to match your hardware & drivers. Playing with mplayer's cache settings might help too - e.g. 'cache = 8192'. BTW, what kind of video formats are used by the 720p and Full HD videos? If the 720p is mpeg4 or h.264 while the Full HD is h.265 that may explain the problem - AFAIK, HW-accelerated h.265 decoding isn't supported on anything except the proprietary nvidia driver with a geforce 900 series GPU or newer (e.g. GTX-9xx or GTX-10xx). Without HW acceleration, it falls back to software decoding, much slower than using the GPU HW. You may be able to configure mplayer to use more CPU cores/threads to speed it up (e.g. with 'lavdopts=threads=2' in ~/.mplayer/config). or use mpv instead of mplayer, which IIRC does multi-threading by default. Try running 'mediainfo' on the video files. 'apt-get install mediainfo' if it's not already installed. This will tell you what kind of container it is, and what kind of video & audio codecs were used (and also if it contains any text streams for subtitles) Also worth considering: if your machine struggles to play Full HD video, but has no problem with 720p then don't make it play Full HD - stick to 720p or less. lower resolution that plays without stuttering or pausing is infinitely better than high-res that doesn't play smoothly. Anyway, when you run mplayer from the command line, check its output to see what it's using. if vdpau is enabled and working on your system, You should see it mentioned in mplayer's terminal output. e.g. on my system: [...irrelevant junk deleted...] libavformat version 57.71.100 (internal) libavformat file format detected. [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0 VIDEO: [H264] 720x404 0bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Forced video codec: ffh264vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 57.89.100 (internal) Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU)) ========================================================================== Clip info: encoder: libebml v1.3.3 + libmatroska v1.4.4 creation_time: 2018-06-28T04:53:20.000000Z Load subtitles in /home/cas/video/ ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, floatle, 0.0 kbit/0.00% (ratio: 0->384000) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) ========================================================================== AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 720x404 => 720x404 H.264 VDPAU acceleration Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 720x404 => 720x404 H.264 VDPAU acceleration A: 1.8 V: 1.8 A-V: 0.001 ct: 0.031 0/ 0 16% 2% 0.5% 8 0 98% You may also want to try using smplayer. It's no more or less capable than mplayer, but may be easier to configure. smplayer certainly - it's a GUI wrapper around mplayer (or mpv) with configuration dialogs...which is a lot easier to make sense of than mplayer's extraordinarily dense man page (the info's all there in man but doesn't make much sense unless you already know a lot about video playback and codecs and acceleration, which I don't...my video knowledge is cherry-picked googling and cargo-culting until it kind of works. Worse, this stuff changes all the time so it's very hard to keep current with what works and what doesn't).
This isn't a total surprise, presumably the defaults were set for a reason and mplayer causes the X server to do some things that it doesn't do in other situations. Maybe I would have the same kernel issue if I tried 3D gaming, but I haven't done that much in recent times.
I really need to get more RAM.
what you're describing really doesn't look like a memory shortage. Your original post back in April showed around 5GB of RAM free. Chromium can be a bloated pig (on my system, it's currently using 9.5GB of RAM and often uses 13GB or more (At the moment, I have about a dozen chromium windows with a total of 112 tabs open), but if that were your problem you would see very little free RAM, very little RAM used by buffers/cache, and LOTS of swap in use. None of that seems to be the case from your original message.
[3175207.254191] radeon 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [3175207.254196] radeon 0000:01:00.0: swiotlb: coherent allocation failed, size=2097152 [3175207.254199] CPU: 5 PID: 1199 Comm: Xorg Not tainted 4.16.0-1-amd64 #1 Debian 4.16.5-1 [3175207.254201] Hardware name: System manufacturer System Product Name/P8H61-M LE, BIOS 0703 06/22/2011
This "swiotlb buffer is full" message seems to be a kernel bug introduced around Jan 2018. https://bugs.freedesktop.org/show_bug.cgi?id=104082 i've only quickly scanned that page but it seems like it's just a warning rather than a serious problem - something about the kernel not being able to allocate a single 2MB chunk of memory so having to fall back to multiple 4K blocks instead. maybe try upgrading to linux-image-4.16.0-2-amd64 (upstream kernel version 4.16.16 rather than 4.16.5) craig -- craig sanders <cas@taz.net.au>