Video freezes and stutters when using totem (audio continues fine)

Thanks for the bug report. Can you please also attach the following information?...

1. Text output from 'lspci -k'

2. Text output from 'mpv bbb_sunflower_1080p_60fps_normal.mp4'

3. Text output from running 'dmesg' after the lag problem has just happened.

4. Please clarify what you mean by "lag". Do you mean the audio is playing back earlier than the video? Or do you mean the frame rate is low?

5. While the "lag" problem is occurring, please also run 'top' in a terminal window and tell us if any process is using high CPU.

Oh I see you already provided 'lspci -k'. Thanks.

6. Please also see if you can disable the AMD GPU in your system BIOS and test with just the Intel GPU. Does the problem then go away? (I have a suspicion there is a problem with gnome-shell hybrid GPU support)

OK, clarification on "lag" - during video playback, the picture will "freeze" at random points, then jump forward to a new position when it continues to play. This "freeze" will last anywhere from < 1 second up to 10 to 15 seconds. The video that would normally be played during this "freeze" is never played, it is simply skipped over. Sometimes, during these lag moments, I notice that video playback will resume if the mouse cursor is moved (whether that is coincidence or cause I do not know - but moving the mouse cursor does not always cause resumption of playback). When video playback continues, it is usually resynchronized with audio (there was no pause, freeze, or lag in the audio output, only in the video). It does not always occur at the same point in playback, even in the same video file.

Here is output from mpv during playback of the test video. I did not catch "dmesg" or "top" during the lags - I will give that another try later today when I have a few minutes to look into it.

tracy@tracy-hp:/mnt/VM$ mpv bbb_sunflower_1080p_60fps_normal.mp4
Playing: bbb_sunflower_1080p_60fps_normal.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 60.000fps)
 (+) Audio --aid=1 --alang=und (*) (mp3 2ch 48000Hz)
     Audio --aid=2 --alang=und (*) (ac3 6ch 48000Hz)
File tags:
 Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
 Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
 Composer: Sacha Goedegebure
 Genre: Animation
 Title: Big Buck Bunny, Sunflower version
AO: [pulse] 48000Hz stereo 2ch s16
Using hardware decoding (vaapi).
VO: [opengl] 1920x1080 vaapi[nv12]
AV: 00:06:26 / 00:10:34 (60%) A-V: 0.000 Dropped: 26

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:10:34 / 00:10:34 (100%) A-V: 0.000 Dropped: 636

Exiting... (End of file)
tracy@tracy-hp:/mnt/VM$

Note that /mnt/vm is a partition on an SSD drive attached to the internal SATA bus, so there shouldn't be any I/O delays causing the problem.

Same here. I have Intel® Ivybridge Desktop graphics only.

lspci -k
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: ivb_uncore
 Kernel modules: ie31200_edac
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
 Kernel driver in use: pcieport
 Kernel modules: shpchp
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: i915
 Kernel modules: i915
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: mei_me
 Kernel modules: mei_me
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: ehci-pci
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
 Kernel driver in use: pcieport
 Kernel modules: shpchp
00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4)
 Kernel driver in use: pcieport
 Kernel modules: shpchp
00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: lpc_ich
 Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel driver in use: ahci
 Kernel modules: ahci
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8 series motherboard
 Kernel modules: i2c_i801
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
 Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
 Kernel driver in use: r8169
 Kernel modules: r8169
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)
05:00.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01)
 Subsystem: Qualcomm Atheros AR9227 Wireless Network Adapter
 Kernel driver in use: ath9k
 Kernel modules: ath9k
05:01.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]
 Subsystem: ASUSTeK Computer Inc. Virtuoso 100 (Xonar D1)
 Kernel driver in use: snd_virtuoso
 Kernel modules...

VLC work fine for me

OK, so I went into the BIOS settings for the machine, and the only options for the video configuration is to set video switching to either dynamic or fixed. Dynamic (which was selected) allows the system to switch between the video card "on demand", while fixed (which is now selected) requires the OS or the user to manually switch between video cards.

After setting the video configuration to fixed, I booted into Ubuntu and retried the mpv test with your video. I noticed only one brief lag (too fast to even let me try doing top or dmesg). Here is the output from mpv, which shows only a single dropped frame (which would be unnoticable for most people watching a video):

tracy@tracy-hp:/mnt/VM$ mpv bbb_sunflower_1080p_60fps_normal.mp4
Playing: bbb_sunflower_1080p_60fps_normal.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 60.000fps)
 (+) Audio --aid=1 --alang=und (*) (mp3 2ch 48000Hz)
     Audio --aid=2 --alang=und (*) (ac3 6ch 48000Hz)
File tags:
 Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
 Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
 Composer: Sacha Goedegebure
 Genre: Animation
 Title: Big Buck Bunny, Sunflower version
AO: [pulse] 48000Hz stereo 2ch s16
Using hardware decoding (vaapi).
VO: [opengl] 1920x1080 vaapi[nv12]
AV: 00:10:34 / 00:10:34 (100%) A-V: 0.000 Dropped: 1

Exiting... (End of file)
tracy@tracy-hp:/mnt/VM$

So, at this point, it looks like the dynamic switching was the basic problem. However, of interest to me is why this didn't present in earlier versions (I have run 16.04, 17.04, and 17.10 (Wayland), none of which exhibited this problem).

So, given this, is there something specific that you want in the way of system information, or are we going to write this off to a (relatively minor) BIOS incompatibility with something introduced in 18.04? (I can live with the manual switching, at this point, if that's what it comes down to...)

Sorry, follow-up. The lags/freezes still occur in totem - I will run it again and do the dmesg and top runs you requested, if that will help

When run in totem, during the first "significant" lag (> 1 second), I ran dmesg (output copied below) and top. Top showed totem and gnome-shell as the only processes using more than 10% of the processor.

Dmesg output copied below:

tracy@tracy-hp:~$ dmesg
[ 0.000000] Linux version 4.15.0-22-generic (buildd@lgw01-amd64-013) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 (Ubuntu 4.15.0-22.24-generic 4.15.17)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic root=UUID=773579df-8683-4bb4-97e9-54d7a44ffac8 ro quiet splash vt.handoff=1
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000009ce3efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000009ce3f000-0x000000009cebefff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000009cebf000-0x000000009cfbefff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000009cfbf000-0x000000009cffefff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x000000009cfff000-0x000000009cffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000009d000000-0x000000009f9fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffd80000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000025fdfffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] random: fast init done
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/165A, BIOS F.1B 10/05/2011
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] e820: last_pfn = 0x25fe00 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-FFFFF write-protect
[ 0.000000] MTRR...

Thanks.

What you are experiencing is worse than I have ever seen. We do have a catch-all bug 1698270 to cover similar issues, but I am not aware of it ever being as bad as you describe.

Maybe this problem is specific to the VAAPI decoding that is common to both totem and mpv... Does the problem go away after running this?;

  sudo apt remove mesa-va-drivers

If the problem then continues, how about after also running this?;

  sudo apt remove i965-va-driver

By the way, I also set up Ubuntu 18.04 on a very similar HP machine last night (Intel Sandy Bridge + Radeon graphics) and can not reproduce any problems.

Ah! Your kernel log mentions the AMD video decoder here:

[ 1223.799908] [drm] UVD initialized successfully.

So it's possible that's the cause of the main problem. Can you please reintroduce the bug and run 'vainfo'? Does 'vainfo' report different information after you switch your BIOS?

If that is the problem then the workaround should be:

  sudo apt remove mesa-va-drivers

I don't see any changes in vainfo from before the change to the BIOS to after. I have posted both versions here, in case I missed something.

I haven't yet tried removing the mesa drivers or the i965 driver - I will try that later today, as time permits.

vainfo from before any changes (as posted under the "call for testing")

tracy@tracy-hp:~$ vainfo
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel® Sandybridge Mobile - 2.1.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc

vainfo after changing BIOS setting:

tracy@tracy-hp:~$ vainfo
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Sandybridge Mobile - 2.1.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple : VAEntrypointVLD
      VAProfileMPEG2Main : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main : VAEntrypointVLD
      VAProfileH264Main : VAEntrypointEncSlice
      VAProfileH264High : VAEntrypointVLD
      VAProfileH264High : VAEntrypointEncSlice
      VAProfileH264StereoHigh : VAEntrypointVLD
      VAProfileVC1Simple : VAEntrypointVLD
      VAProfileVC1Main : VAEntrypointVLD
      VAProfileVC1Advanced : VAEntrypointVLD
      VAProfileNone : VAEntrypointVideoProc

OK, so I tested the removal of the items requested (still with BIOS set to fixed). After

> sudo apt remove mesa-va-drivers

I tried running the video in totem. Same problem as before - random lags/stutters/freezes, usually < 1 second, but a few that were longer (longest was about 2.5 seconds this time around).

So then I tried

> sudo apt remove i965-va-driver

then ran the video in totem. If anything, the problem became worse - the lags were more prevalent, and the longest was > 3 seconds.

So I went back to mpv and ran the video there. There were minor stutters (not long enough to call them lags - I would estimate they were mostly < 0.25 seconds) scattered through the video at random, but none long enough to really cause me to say "this is unwatchable". However, I did notice increased CPU usage - the system became noticably warmer to the touch while the video was playing, and the fan kicked on high to cool it (previous instances I didn't notice the fan kicking on - perhaps it did, and I just didn't notice it. I have copied below the terminal output for mpv, in case any of it is relevant (I didn't notice much different than the past - just a warning about a decoder not supporting hardware). I can re-run and see if I can catch a lag long enough for me to start dmesg if you like. Just let me know what would help you most from this point.

tracy@tracy-hp:/mnt/VM$ mpv bbb_sunflower_1080p_60fps_normal.mp4
Playing: bbb_sunflower_1080p_60fps_normal.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 60.000fps)
 (+) Audio --aid=1 --alang=und (*) (mp3 2ch 48000Hz)
     Audio --aid=2 --alang=und (*) (ac3 6ch 48000Hz)
File tags:
 Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
 Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
 Composer: Sacha Goedegebure
 Genre: Animation
 Title: Big Buck Bunny, Sunflower version
VO does not support requested hardware decoder, or loading it failed.
AO: [pulse] 48000Hz stereo 2ch s16
VO: [opengl] 1920x1080 yuv420p
AV: 00:10:34 / 00:10:34 (100%) A-V: 0.000

Exiting... (End of file)

Also, should I reinstall the i965 and mesa drivers, or leave them uninstalled for further testing? (I will definitely leave them uninstalled until I hear otherwise, or for a day or so at any rate...)

Yes, please do reinstall:
  sudo apt install i965-va-driver
That will restore hardware-accelerated video decoding, and keep the system cooler :)

It now sounds like you have a general graphics/CPU/disk performance problem and this bug is not really specific to video playback. I assume this is a real and not virtual machine...

Next please benchmark the disk you are playing from. You can do that in the 'Disks' app, or on the command line by running:

  sudo hdparm -t /dev/sda # or whatever the device is

I reinstalled the i965-va-driver.

Here is the output of the hdparm command for the drive that currently houses the video file:

tracy@tracy-hp:~$ sudo hdparm -t /dev/sdb
[sudo] password for tracy:

/dev/sdb:
 Timing buffered disk reads: 352 MB in 3.01 seconds = 117.06 MB/sec

I moved the video file to a different drive, and tried it in totem again. Same problem. Here's the hdparm output for that drive:

tracy@tracy-hp:~$ sudo hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 1198 MB in 3.00 seconds = 399.32 MB/sec

CPU benchmarking

tracy@tracy-hp:~$ sysbench --test=cpu run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second: 861.57

General statistics:
    total time: 10.0012s
    total number of events: 8620

Latency (ms):
         min: 1.14
         avg: 1.16
         max: 3.55
         95th percentile: 1.21
         sum: 9999.07

Threads fairness:
    events (avg/stddev): 8620.0000/0.00
    execution time (avg/stddev): 9.9991/0.00

tracy@tracy-hp:~$ sysbench --test=cpu --num-threads=16 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 16
Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second: 4668.70

General statistics:
    total time: 10.0023s
    total number of events: 46707

Latency (ms):
         min: 1.55
         avg: 3.42
         max: 49.71
         95th percentile: 17.63
         sum: 159900.51

Threads fairness:
    events (avg/stddev): 2919.1875/110.55
    execution time (avg/stddev): 9.9938/0.01

tracy@tracy-hp:~$ sysbench --test=cpu --num-threads=16 --cpu-max-prime=100000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 16
Initializing random number generator from current time

Prime numbers limit: 100000

Initializing worker threads...

Threads started!

CPU speed:
    events per second: 199.77

General statistics:
    total time: 10.0494s
    total number of events: 2008

Latency (ms):
         min: 39.76
         avg: 79.86
         max: 156.43
         95th percentile: 92.42
         sum: 160358.07

Threads fairness:
    events (avg/stddev): 125.5000/1.94
    execution time (avg/stddev): 10.0224/0.01

tracy@tracy-hp:~$

tracy@tracy-hp:~$ glmark2
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR: Intel Open Source Technology Center
    GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile
    GL_VERSION: 3.0 Mesa 18.0.0-rc5
=======================================================
[build] use-vbo=false: FPS: 1893 FrameTime: 0.528 ms
[build] use-vbo=true: FPS: 1793 FrameTime: 0.558 ms
[texture] texture-filter=nearest: FPS: 1735 FrameTime: 0.576 ms
[texture] texture-filter=linear: FPS: 1720 FrameTime: 0.581 ms
[texture] texture-filter=mipmap: FPS: 1772 FrameTime: 0.564 ms
[shading] shading=gouraud: FPS: 1576 FrameTime: 0.635 ms
[shading] shading=blinn-phong-inf: FPS: 1570 FrameTime: 0.637 ms
[shading] shading=phong: FPS: 1400 FrameTime: 0.714 ms
[shading] shading=cel: FPS: 1341 FrameTime: 0.746 ms
[bump] bump-render=high-poly: FPS: 882 FrameTime: 1.134 ms
[bump] bump-render=normals: FPS: 1796 FrameTime: 0.557 ms
[bump] bump-render=height: FPS: 1670 FrameTime: 0.599 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 857 FrameTime: 1.167 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 370 FrameTime: 2.703 ms
[pulsar] light=false:quads=5:texture=false: FPS: 1580 FrameTime: 0.633 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 416 FrameTime: 2.404 ms
[desktop] effect=shadow:windows=4: FPS: 835 FrameTime: 1.198 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 658 FrameTime: 1.520 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 676 FrameTime: 1.479 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 719 FrameTime: 1.391 ms
[ideas] speed=duration: FPS: 1014 FrameTime: 0.986 ms
[jellyfish] <default>: FPS: 881 FrameTime: 1.135 ms
[terrain] <default>: FPS: 95 FrameTime: 10.526 ms
[shadow] <default>: FPS: 674 FrameTime: 1.484 ms
[refract] <default>: FPS: 238 FrameTime: 4.202 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 1663 FrameTime: 0.601 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 1473 FrameTime: 0.679 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 1654 FrameTime: 0.605 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 1644 FrameTime: 0.608 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 1435 FrameTime: 0.697 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 1368 FrameTime: 0.731 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 1621 FrameTime: 0.617 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 1465 FrameTime: 0.683 ms
=======================================================
                                  glmark2 Score: 1226
=======================================================
tracy@tracy-hp:~$

Most of that info doesn't mean much to me, but hopefully it will help narrow things down and at least let you point me in the right direction....

Thanks, but there's no need to benchmark the CPU itself. We already know the CPU model. What does concern me about CPU usage is whether gnome-shell or some other process is using considerable CPU during playback. Do you find that?

Also, please run 'xrandr' and send us the output. Gnome Shell is unfortunately not very efficient at drawing high resolution yet (using standard GPUs like that in the i7-2630QM). So if your screen is greater than 1920x1080 then that could also be a problem.

Totem and gnome-shell both are running between 10% and 30% each (they bounce back and forth during playback). The next highest usage (according to top) is 8% and under. Is there a way to capture CPU usage during playback that will be representative of actual usage?

My video resolution is 1920 x 1080 - it is the default resolution for this screen (17" laptop LCD - no touchscreen capabilities).

I should note that I get this problem regardless of whether I run totem full screen or in a small (320 x 200) window... (I realize that the size of the window isn't the determining factor, but I would think that a smaller window would be less likely to show the problem than a full screen - but that doesn't seem to be the case here.)

tracy@tracy-hp:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 381mm x 214mm
   1920x1080 60.06*+ 60.01 59.97 59.96 59.93
   1680x1050 59.95 59.88
   1600x1024 60.17
   1400x1050 59.98
   1600x900 59.99 59.94 59.95 59.82
   1280x1024 60.02
   1440x900 59.89
   1400x900 59.96 59.88
   1280x960 60.00
   1440x810 60.00 59.97
   1368x768 59.88 59.85
   1360x768 59.80 59.96
   1280x800 59.99 59.97 59.81 59.91
   1152x864 60.00
   1280x720 60.00 59.99 59.86 59.74
   1024x768 60.04 60.00
   960x720 60.00
   928x696 60.05
   896x672 60.01
   1024x576 59.95 59.96 59.90 59.82
   960x600 59.93 60.00
   960x540 59.96 59.99 59.63 59.82
   800x600 60.00 60.32 56.25
   840x525 60.01 59.88
   864x486 59.92 59.57
   800x512 60.17
   700x525 59.98
   800x450 59.95 59.82
   640x512 60.02
   720x450 59.89
   700x450 59.96 59.88
   640x480 60.00 59.94
   720x405 59.51 58.99
   684x384 59.88 59.85
   680x384 59.80 59.96
   640x400 59.88 59.98
   576x432 60.06
   640x360 59.86 59.83 59.84 59.32
   512x384 60.00
   512x288 60.00 59.92
   480x270 59.63 59.82
   400x300 60.32 56.34
   432x243 59.92 59.57
   320x240 60.05
   360x202 59.51 59.13
   320x180 59.84 59.32
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
tracy@tracy-hp:~$

Thanks.

If the pauses are now very brief with your BIOS in "fixed" mode, and if mpv is performing slightly better than totem, then I suggest this is now a duplicate of bug 1698270. Bug 1698270 is not fully resolved and requires more investigation.

The pauses are very brief using mpv - using totem I still get pauses in excess of 5 seconds at random points during playback. However I am willing to accept that this would constitute a duplicate of 1698270, and will wait for any updates there.

One more thing:

Wayland sessions might perform better, so please try mpv in a Wayland session. Unfortunately Totem probably won't work there (bug 1770725).

I've checked iowait using iotop during lags and revealed no spikes or something like that. So it's not a performance problem at all. I believe gstreamer is just dropping frames due to some bugs.
I had 17.10 installed and had no issue that time.

Also when I was on 17.10 beta, there was an update that broke totem (black screen instead of video). Problem appeared after the issue was fixed.

Sergei, "performance" is a general category of problems that includes dropped frames. For example, in gnome-shell I have separated those issues:
  https://trello.com/c/Q6JYXPPs
from the ones that incur measurably high hardware usage:
  https://trello.com/c/pe5mRmx7

A low frame rate is still a performance problem even if it's not stressing the hardware.

Before we merge this bug into bug 1698270 I would like to hear Tracy's response to comment #25.

Then I expect we will need/want to get more of the above lists of gnome-shell performance issues fixed before we can confidently say this issue exists purely within video playback.

P.S. If the problem is purely a video playback issue then my suspicion is that some component is implementing frame dropping incorrectly. If it is implemented using double buffers then you can easily starve the screen of new frames while repeatedly (racily) replacing the backbuffer. The right approach then is to use 3 buffers and the mailbox algorithm. The mailbox algorithm is nothing new, but that's what Vulkan calls it anyway: https://software.intel.com/en-us/articles/api-without-secrets-introduction-to-vulkan-part-2

If I am reading this commentary, and that in https://bugs.launchpad.net/ubuntu/+source/clutter-1.0/+bug/1698270 it's looking like uninstalling totem and changing to another player might be the best answer, am I correct?

Thanks!

Sorry for the long delay in responding - had to wait for some other things to finish so I could switch from Xorg to Wayland. The same types of pauses/lags/freezes happen to me under Wayland using mpv as were happening under Xorg. They may be slightly less frequent (subjective judgment, no actual counts done), but they still occur.

Also, I find that I am unable to close mpv under Wayland. Alt-F4 does nothing, nor does going to the Window menu and choosing Quit. The video continues, and I am not sure exactly what else to use to close it (other than just waiting for it to finish running) - I don't know much about mpv. Closing wasn't a problem under Xorg - either of the two methods mentioned above worked there. Just throwing that out there for consideration.

In response to my previous comment, switching to SMPlayer improves the symptom, but does not seem to resolve it.

BTW, the following shows up in the terminal output for mpv under Wayland (I don't recall seeing this under Xorg)

[vo/opengl] retrieving framebuffer depth: OpenGL error INVALID_OPERATION.

Charlie, yes I would recommend using mpv instead of totem. mpv will perform better and is the only other video player that will take advantage of Intel hardware acceleration properly [2]. I do _not_ recommend gnome-mpv [1] and also do _not_ recommend vlc because it seems to be lacking in hardware acceleration. I have no experience with SMPlayer, but please see also [2].

Tracy, the mpv close issue is bug 1720835.

I think we should merge this into bug 1698270 now.

[1] https://community.ubuntu.com/t/hardware-accelerated-video-playback/304/4
[2] https://wiki.ubuntu.com/IntelQuickSyncVideo