Stuttering/Laggy video playback when going from 8.90.006 to 8.90.007 on Haswell based Chromebox

1st Official Post

    First time posting a problem. I hopefully have followed the wiki instructions correctly. Apologies in advance if I have not. Logs posted here Pastebin log

    I have two Haswell based Chromeboxes (using the latest UEFI firmware from mrchromebox.tech), both work very well with 8.90.006 and all previous 8.90 alpha builds, but both have long delays pauses/stuttering/lag in video playback after updating to 8.90.007. Running kodi18-b5 on a Windows 10 box on same network connected to same NAS and the windows 10 box plays video flawlessly. Downgraded one of the chromeboxes back down to 8.90.006 and video playback returns to normal.

    • Official Post

    Can you double-check if hardware acceleration is active while viewing your "39 steps" movie?

    Press the letter 'o' during video play.

    Code
    14:28:18.223 T:139708148455168  NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10

    For some reason, plenty of "content creators" are using 10-bit video streams, and your hardware is probably having a hard time keeping up the decoding via the CPU, as your GPU cannot do 10-bit video via hw acceleration.

    Video decoder: ff-h264-vaapi (HW)

    Settings->Player->Video UI says VAAPI enabled.I watched the System CPU usage during 4 long lags, during the 1st, 3rd and 4th lag both cores stayed in the 20-40% range, during the 2nd lag, CPU #0 was pegged at 100% while CPU #1 stayed in the 20-40% range for the most part.

    I created this MKV(H264) rip many years ago. Having same video issues with DVD rips (MKV/MPEG2) as well. Again, same Haswell/Chromebox hardware, playing same MKV/H264 video, running LibreElec 8.90.006 plays flawlessly.

    • Official Post

    "MPEG-4 part 10" refers to a section of the H.264 specification. It does not mean 10-bit video (which is a problem on most hardware). If you look at the ffmpeg analysis a few lines before CDVDVideoCodecFFmpeg::Open in the log:

    Code
    14:28:18.222 T:139708148455168    INFO: ffmpeg[7F10568F9700]:     Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

    I've no idea what the problem is, but ^ that shows standard 8-bit H.264 video not 10-bit, so that's not the issue.

    Code
    Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: AER: Multiple Corrected error received: 0000:00:1c.0
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:   device [8086:9c14] error status/mask=00001000/00002000
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:    [12] Timeout               
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:   device [8086:9c14] error status/mask=00001000/00002000
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:    [12] Timeout

    This is already discussed in Milhouse testbuld thread on forum.kodi.tv.

    Only work around so far is using kernel 4.18 or older.

    Thanks. I had been sticking to the official alpha builds, not the bleeding edge Milhouse builds. Very helpful to know there are others with the same issue. I'll follow the saga over at the Milhouse TestBuild forum going forward. Thanks Klojum, chewitt and mglae for responding and for the info.

    Edited once, last by Drebbe (November 17, 2018 at 3:25 PM).