Video playback lag after upgrading from 13.2

English Install/Boot/Login
1

After upgrading from 13.2 on my old 32 bit Acer TravelMate 2410 all video playback lags terribly including for the same videos which previously played in 13.2 flawlessly. I use smplayer in xfce as I always have. I tried mpv Media Player - same result. I tried also the “Videos” application however it gives only sound output.

In case that matters:

acer:~ # /sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
        Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
00:1d.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
acer:~ # /usr/sbin/hwinfo --gfxcard
16: PCI 02.0: 0300 VGA compatible controller (VGA)              
  [Created at pci.378]
  Unique ID: _Znp.EtexH6ajTw4
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Intel 915 GM"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2592 "915 GM"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x006a 
  Revision: 0x03
  Memory Range: 0xb0080000-0xb00fffff (rw,non-prefetchable)
  I/O Ports: 0x1800-0x1807 (rw)
  Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
  Memory Range: 0xb0000000-0xb003ffff (rw,non-prefetchable)
  Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled)
  IRQ: 10 (no events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00008086d00002592sv00001025sd0000006Abc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: intel
  Driver Info #1:
    XFree86 v4 Server Module: intel
    3D Support: yes
    Extensions: dri
  Config Status: cfg=new, avail=yes, need=no, active=unknown




21: PCI 02.1: 0380 Display controller
  [Created at pci.378]
  Unique ID: ruGf.Wg8LTupicC7
  SysFS ID: /devices/pci0000:00/0000:00:02.1
  SysFS BusID: 0000:00:02.1
  Hardware Class: graphics card
  Model: "Intel Mobile 915GM/GMS/910GML Express Graphics Controller"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2792 "Mobile 915GM/GMS/910GML Express Graphics Controller"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x006a 
  Revision: 0x03
  Memory Range: 0x20000000-0x2007ffff (rw,non-prefetchable,disabled)
  Module Alias: "pci:v00008086d00002792sv00001025sd0000006Abc03sc80i00"
  Config Status: cfg=new, avail=yes, need=no, active=unknown




Primary display adapter: #16

This is an old computer but these videos and thousands of others have always played without problems on it, so it is definitely a software issue.

How can I fix this?

2

It might be useful to show your smplayer config

cat ~/.config/smplayer/smplayer.ini

In particular the configured video output driver in use.

3

I haven’t changed any settings in smplayer for a long time (long even before upgrading) but there you go: http://paste.opensuse.org/e4756cd6

It doesn’t seem to be an issue with smplayer as mpv Media Player lags too and obviously there is a problem with the so called Videos player in xfce. BTW I found that right clicking a video and choosing to open with MPlayer does NOT lag. I guess the issue might be related to how the player interacts with the graphical environment. Any ideas?

4

You’re using the xv driver which should be ok. I don’t have any definitive solutions, but I did find this smplayer forum thread describing similar issues and some useful suggestions too. For example, this post describes what you’ve observed about MPlayer vs smplayer. A suggestion was made to try increasing cache, or disable it completely if that doesn’t work. It is probably a good idea to post this issue in that forum as well to widen the support net.

You might need to examine the MPlayer logs. If run directly from the CLI eg

mplayer /path/to/video_file

capture the output. Maybe that will provide clues too.

5

mplayer works fine. Nothing strange in the text output too.

The question is why the other players don’t and why this happened after the update to Tumbleweed. Obviously it is related, right?

I tried to turn on the debug log of smplayer and in one place I see similar thing to what you show on that link:


[02:01:47:476] MPVProcess::parseLine: 'Run command: set, flags=9, args=[sub-visibility, yes]'
[02:01:47:477] MPVProcess::parseLine: 'Set property: sub-visibility=yes -> 1'
[02:01:47:656] MPVProcess::parseLine: ''
[02:01:47:657] MPVProcess::parseLine: 'Audio/Video desynchronisation detected! Possible reasons include too slow'
[02:01:47:657] MPVProcess::parseLine: 'hardware, temporary CPU spikes, broken drivers, and broken files. Audio'
[02:01:47:657] MPVProcess::parseLine: 'position will not match to the video (see A-V status field).'
[02:01:47:657] MPVProcess::parseLine: ''

The reason is not ‘too slow hardware’ because the same hardware was able to play the same videos on 13.2, even with output to 1920x1080 using external VGA cable on a big 50" TV. The video files are not broken either.

Other lines which mention the word hardware and error:


[02:01:45:648] MPVProcess::parseLine: 'libva info: VA-API version 0.39.4'
[02:01:45:649] MPVProcess::parseLine: 'libva info: va_getDriverName() returns -1'
**[02:01:45:650] MPVProcess::parseLine: 'libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)'**
[02:01:45:678] MPVProcess::parseLine: '[vo/vdpau] VDPAU is most likely emulated via VA-API.'
[02:01:45:679] MPVProcess::parseLine: '[vo/vdpau] This is inefficient. Use --vo=opengl instead.'
[02:01:45:680] MPVProcess::parseLine: '[vd] Container reported FPS: 29.970030'
[02:01:45:680] MPVProcess::parseLine: '[vd] Codec list:'
[02:01:45:681] MPVProcess::parseLine: '[vd]     mpeg4 - MPEG-4 part 2'
[02:01:45:681] MPVProcess::parseLine: '[vd] Opening video decoder mpeg4'
**[02:01:45:681] MPVProcess::parseLine: '[vd] Not trying to use hardware decoding: codec mpeg4 is not on whitelist, or does not support hardware acceleration.'**
[02:01:45:681] MPVProcess::parseLine: '[vd] Using software decoding.'
[02:01:45:681] MPVProcess::parseLine: '[vd] Requesting 2 threads for decoding.'
[02:01:45:681] MPVProcess::parseLine: '[vd] Selected video codec: mpeg4 (MPEG-4 part 2)'
[02:01:45:683] MPVProcess::parseLine: '[vo/vdpau] Assuming 76.000000 FPS for display sync.'

So what is next?

6

The output supplied is part of the discovery process, and some further experimentation may be required. Hopefully, others can chime in with advice. You might try posting in the smplayer forum as well.

With respect to the mpv output, it is probably worth trying the hint given…


[02:01:45:679] MPVProcess::parseLine: '[vo/vdpau] This is inefficient. Use --vo=opengl instead.'
7

Alrighty! That works a little better but still laggy. Any other options to test? I tried all output drivers but nothing improved.

I have been wondering… is there any GL acceleration of XFCE itself that may be conflicting / slowing down the player itself? I remember having seen this effect on other older machines with KDE where some key combination like alt+shif+f11 (IIRC) used to disable it and then things worked better. Is there such thing in XFCE?

8

Some of what I’ll write, you’ll likely already be aware of, but I’ll include it here for others too.

This is an old computer

Install vainfo (its in vaapi-tools) … once you have it installed, and provided you have libva installed (which it appears you do from other otuput you provided), then it will return the hardware decoding capabilities of your gpu … if anything, this chipset might support mpeg2 hardware decoding

but these videos and thousands of others have always played without problems on it, so it is definitely a software issue.
It is indeed

It doesn’t seem to be an issue with smplayer as mpv Media Player lags too
smplayer is, of course, simply a frontend to a playback engine. See: Options > Preferences > General > General > Multimedia engine

As the susepaste output, as well as the smplayer debug log output, you provided shows, mpv is the selected engine, so its unsurprising the two function the same.

and obviously there is a problem with the so called Videos player in xfce.
I’m not familiar with it, but no doubt it is a configuration issue. I’m sure someone familiar could provide assistance with that.

I found that right clicking a video and choosing to open with MPlayer does NOT lag. I guess the issue might be related to how the player interacts with the graphical environment. Any ideas?
It has to do with how the encoded video file is decoded and then how that bitstream is displayed on screen

mplayer works fine. Nothing strange in the text output too.
But it will give you definitive information about the decoding and output process that is taking place

The question is why the other players don’t
its simply a configuration issue

and why this happened after the update to Tumbleweed. Obviously it is related, right?
Yes, most likely

I tried to turn on the debug log of smplayer and in one place I see similar thing to what you show on that link:
The output is illuminating, even if its only fragments

The reason is not ‘too slow hardware’ because the same hardware was able to play the same videos on 13.2
No, the reason is too slow hardware. That its doing something does not mean that its doing what you desire it to do. The way its currently configured, its trying to do something that your system just doesn’t have the strength to perform. You simply need to reconfigure it.

[02:01:45:649] MPVProcess::parseLine: ‘libva info: va_getDriverName() returns -1’
[02:01:45:650] MPVProcess::parseLine: ‘libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)’
libva (aka va-api or vaapi) is looking for a vaapi decoding driver for your hardware and finds none. You’re missing vaapi-intel-driver

[02:01:45:678] MPVProcess::parseLine: ‘[vo/vdpau] VDPAU is most likely emulated via VA-API.’
[02:01:45:679] MPVProcess::parseLine: ‘[vo/vdpau] This is inefficient. Use --vo=opengl instead.’
its telling you that mpv is trying to use vdpau to output (the “vo”) the decoded bitstream. it informs you that this is inefficient, and to use opengl to output.

the vidoe decoding (the “vd” stuff) shows you that its using software decoding

Alrighty! That works a little better but still laggy. Any other options to test? I tried all output drivers but nothing improved.
In smplayer, besides selecting the engine (see above), you want to look at the options at:

Options > Preferences > General > Video > Output driver … in your case (i.e. with your hardware), set it to vaapi or xv

Options > Preferences > Performance > Decoding > Hardware Decoding … I’d set it on auto

And, as mentioned, install the vaapi-intel-driver <– you might not even be able to make use of any hardware decoding, but we’ll see

I have been wondering… is there any GL acceleration of XFCE itself that may be conflicting / slowing down the player itself? I remember having seen this effect on other older machines with KDE where some key combination like alt+shif+f11 (IIRC) used to disable it and then things worked better. Is there such thing in XFCE?
I’m not familiar with xfce’s composting abilities

9

I’ll just tuck a note in here that mplayer available in openSUSE doesn’t have vaapi support built in.

OTOH, mpv does.

10

Installed vaapi-tools. Tried all video output drivers - nothing works well enough.

smplayer is, of course, simply a frontend to a playback engine. See: Options > Preferences > General > General > Multimedia engine

When selecting multimedia engine to be mplayer videos don’t play at all. Black screen.

But it will give you definitive information about the decoding and output process that is taking place

There it is:

http://paste.opensuse.org/0d2cdfbd

its simply a configuration issue

How come? The same configuration in 13.2 worked. Now it doesn’t. I haven’t changed any settings in smplayer?

No, the reason is too slow hardware. That its doing something does not mean that its doing what you desire it to do. The way its currently configured, its trying to do something that your system just doesn’t have the strength to perform. You simply need to reconfigure it.

But again the question remains: why the same hardware with the same settings was not too slow in 13.2?

Options > Preferences > Performance > Decoding > Hardware Decoding … I’d set it on auto

Tried that too. No change.

And, as mentioned, install the vaapi-intel-driver <– you might not even be able to make use of any hardware decoding, but we’ll see

It is installed.

11

yes, but you didn’t provide the output from the tool.

Tried all video output drivers - nothing works well enough.
yes, because your system is not configured properly. In any regard, you needn’t have tried them all as:

  • some -vo of mplayer are broken
  • some are hideously ancient
  • some are useless … really, what purpose does an asci representation provide?
  • some have nothing applicable to your hardware
  • some have special uses (for example, directfb, which is kind of a psuedo display server … in any regard, last I checked it was broken)
  • …

When selecting multimedia engine to be mplayer videos don’t play at all. Black screen.
yes, not surprising … the mplayer or smplayer log from View > logs would likely convey exactly why … but don’t bother.

In general, mpv is a much better engine to use with smplayer. IMO mplayer is good from cmdline for testing

There it is:

SUSE Paste

And its informative – very first thing that pops out is that it can’t utilise Xv and so fallsback to the x11 output driver. As you then observed, xvinfo shows that no Xv capability exitsts.

That points us to exactly where we want to go.

The remainder of the tests aren’t useful because the underlining issue has now been brought to light (configuration issue) and also for the bullet list of reasons I stated above.

How come? The same configuration in 13.2 worked. Now it doesn’t. I haven’t changed any settings in smplayer?
That you can’t use Xv points me to video driver. We don’t have any Xorg log info, but we do have your /lspci output from above. I did not spot it earlier, but now I can clearly see that your kernel driver is not loaded. That means your proper xorg driver isn’t going to be loaded either, hence why there is no Xv when there should be.

You have likely used nomodeset in your kernel boot command, and now are using the generic fbdev driver.

show “cat /proc/cmdline” or the output of your Xorg.0.log

But again the question remains: why the same hardware with the same settings was not too slow in 13.2?
See above … i.e. configuration issue lol!

12

How do I do that?

I am not an expert, just trying all the options. If there are any other things to try in order to solve the problem please just let me know.

I still don’t understand why there should be a configuration issue. I have not changed any configuration. Is the process of upgrading from 13.2 to Tumbleweed changing it?

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-default root=UUID=.... resume=/dev/sda1 splash=verbose quiet showopts plymouth.enable=0
13

Just ran ‘zypper up’ which updated quite a few things, including kernel. Reboot and… everything works just fine now, without touching any config whatsoever :slight_smile:

14

Don’t sell yourself short, you’re doing great. As it is, you already managed to run xvinfo … now just run “vainfo”

Similarly, there’s other utility tools out there like: xvmcinfo, glxinfo, vdpauinfo, xdpyinfo … I’m beginning to detect a pattern here :wink:

I still don’t understand why there should be a configuration issue. I have not changed any configuration. Is the process of upgrading from 13.2 to Tumbleweed changing it?

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-default root=UUID=.... resume=/dev/sda1 splash=verbose quiet showopts plymouth.enable=0

Ahh, well, I had incorrectly assumed that you (for whatever reason; and I had assumed that it would have been for a mistaken reason) had changed the boot option. However, your cmdline clearly shows that was not the case. But it also gives a big clue: the kernel 4.9.0-1 kernel … if you want to (and there really isn’t need to anymore), you can look back in the forums and you will see that there was a lot of problems for users when the 4.9 kernel was first introduced just over the last couple of weeks. I can only assume that you were impacted as well, and the intel kernel driver (i915) was not loading in your case.

Good to see that the kernel update has apparently resolved your issue. Can you post the output of

/sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3
15 
# /sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A300:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
        Kernel driver in use: i915
        Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
00:1d.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:006a]
# uname -a
Linux acer.group 4.9.3-1-default #1 SMP Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) i686 i686 i386 GNU/Linux
16

Okay, the kernel driver is loaded now. I have nothing to doubt that the xorg environment is functional as well.

But, (third times a charm) we still don’t have your vainfo output … so we can’t tell you if your chipset has any hardware decoding capabilities … but given its age, I’d suspect that its only mpeg2 if any.

(BTW, if you’re wondering why there is a second graphics device entry in the lspci or hwinfo output, its related to the TV-out/s-video for your device).

17

Thanks Tyler. Here is the vainfo:

> vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
18

That is exactly the same message that I get when I don’t have the vaapi-intel-video driver installed. Are you sure you have it installed?

19

It looks like it is, just without the word “video” in the name of the package:

https://snag.gy/CUhgmz.jpg


# rpm -q vaapi-intel-driver 
vaapi-intel-driver-1.7.3-1.1.i586
# rpm -ql vaapi-intel-driver                                                                                                                       
/usr/lib/dri                                                                                                                                               
/usr/lib/dri/i965_drv_video.so

I notice the i965 index which is different from what my video adapter info says (i915). No idea if that matters.

20

Yes, sorry, my mistake, that is indeed the one I meant.

I notice the i965 index which is different from what my video adapter info says (i915). No idea if that matters.
The i915 is the kernel driver. i965 is the DRI (Mesa 3D) driver. The xorg driver is intel. Those are the three main components of the intel driver stack (there is a little more to the story, but that’s the main things that users will encounter).

Now, having said that, I want to retract my prior statement – that is not! exactly what I get when the vaapi-intel-driver is uninstalled. Instead, I get:

vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i9**6**5_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

I’m not sure why your output would say i915. Did you edit the info by chance (i.e. copy and paste error and inadvertently change the 6 to a 1 given the prior information discussed in the thread?)