Seeking in video causes freeze since Matrix

Help and Support Raspberry Pi
1

Ever since I updated OSMC to a version with Kodi Matrix (v19) I’ve been getting player freezes when I seek inside a video. Both audio and video freeze on either the frame before the seek action, or the “destination” frame. It definitely started occurring with Matrix, since it never once exhibited this behaviour on older versions of Kodi. You can find quite a lot about this in regards to other platforms and AAC streams but it doesn’t seem to be limited to just AAC, it also happens for AC3 and HE-AAC (which is quite different from “standard” AAC). Plus, audio actually sometimes starts playing again if I wait long enough (20+ seconds) while video keeps being frozen pretty much indefinitely. All my videos are h264 because my particular Pi (2B) doesn’t handle h265 very well. You don’t even have to seek with a remote, even with a physical keyboard (pressing arrow left/right once) this frequently occurs. When it does, CPU usage goes through the roof and usually I just force kill Kodi. Sometimes seeking again a couple of times, or pausing/playing about a dozen times might work too. In those cases the initial seek is usually ignored and I’m back at the previous position plus/minus any additional seeks I might’ve done. The problem doesn’t always happen, but I’d say it’s about 90% of the time.

I’m not using any video plugins besides the ones that already come with Kodi, I actually barely use any custom plugins at all. I don’t know how to get a list of only user-installed plugins but if I remember correctly it’s just some auto-subtitles, screensaver and web interface stuff. I’m also using the default skin. All my videos are hosted on good old SMB shares, automatically mounted through /etc/fstab because doing it directly from within Kodi gave me some issues (but I don’t quite remember what).

Since the RPI runs off an SD card it doesn’t survive for very long under the massive amount of logging (I’ve actually had to replace 2 SD cards within a few weeks before I turned off logging altogether and it never died again), so I used a bind mount to redirect the 2 log files (current and old) to another SMB share. I set the loglevel to 1 because I don’t see the point in also showing it on-screen (which is the only difference between 1 and 2 afaik) and 1 should already be debug-level.

The relevant messages seem to be:

2021-11-30 16:28:18.385 T:4326    DEBUG <general>: CDVDAudio::Resume - resume audio stream
2021-11-30 16:28:18.386 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120123.020676
2021-11-30 16:28:18.386 T:4092    DEBUG <general>: ActiveAE - start sync of audio stream
2021-11-30 16:28:18.389 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120123.022864
2021-11-30 16:28:18.393 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120123.023229
2021-11-30 16:28:18.395 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120123.022187
2021-11-30 16:28:18.402 T:4325    DEBUG <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_RESYNC(236720000.000000)
2021-11-30 16:28:18.468 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120073.074427
2021-11-30 16:28:18.518 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120073.078750
2021-11-30 16:28:18.518 T:4092    DEBUG <general>: ActiveAE::SyncStream - average error of 5000.000000, start adjusting
2021-11-30 16:28:18.569 T:4092  WARNING <general>: ActiveAE - large audio sync error: 120022.998125
2021-11-30 16:28:18.618 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119973.058958
2021-11-30 16:28:18.668 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119923.047864
2021-11-30 16:28:18.720 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119873.058020
2021-11-30 16:28:18.768 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119823.082969
2021-11-30 16:28:18.818 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119773.066927
2021-11-30 16:28:18.869 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119723.084219
2021-11-30 16:28:18.918 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119673.028073
2021-11-30 16:28:18.968 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119623.069843
2021-11-30 16:28:19.018 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119573.051250
2021-11-30 16:28:19.068 T:4092  WARNING <general>: ActiveAE - large audio sync error: 119523.033542
2021-11-30 16:28:19.073 T:4325  WARNING <general>: OutputPicture - timeout waiting for buffer

The large audio sync error line keeps occurring with a decrementing number until I get it unstuck, or if I kill Kodi. The same goes for timeout waiting for buffer although it’s much less frequent. The full debug log can be found here (the particular video has an AC3 audio stream). I don’t see anything related to this particular issue in the November release so I don’t think it’s been fixed yet.

2

This looks like one for the Raspberry Pi team if you can reproduce with a file on local storage.

3

Alright, I copied a couple of episodes to /home/osmc/Movies and added it as a source to Kodi. The same problem definitely still occurs. I also noticed that if I wait at least 3 minutes it will resume playing, but I never bothered to wait that long before (also happens for files on SMB, not just local).

4

I’ve been watching a different show now and it hasn’t even hung once. Here’s some output from ffprobe for it:

Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)

And another that does hang:

Stream #0:0: Video: h264 (High), yuv420p(progressive), 640x480 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Stream #0:1(eng): Audio: aac (HE-AACv2), 48000 Hz, stereo, fltp (default)

The second video here is just good old SD NTSC compared to 720p at the top of this comment and 1080p from my original post. Notice how the 720p one has 44.1 KHz audio (and doesn’t hang) while the other 2 have 48 KHz streams (and do hang).

Now, I also happen to have another show with 720p video and 48 KHz audio (and it does not hang):

Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 180k tbc (default)
Stream #0:1(eng): Audio: aac (LC), 48000 Hz, stereo, fltp (default)

I don’t have anything with 44.1 KHz HE-AAC or AC3 streams though, but at least those 2 specific codecs seem to be part of the problem.

Dunno if any of this is even helpful/relevant but I figured I might as well mention it.

5

Alright so I reverted OSMC to the latest version with Kodi 18.9 just to be sure. And indeed, there are no real playback issues as long as I enable acceleration via at least MMAL (but preferably OMXPlayer). I can even disable the setting for syncing refresh rates with the monitor so it runs at 60 Hz, which I was pretty much required to enable when on Matrix. I prefer 60 Hz though because my TV seems to switch to a different colour space on 24 fps and the one for 60 fps is just better. I messed around with the settings a lot and it just never comes close. I know “converting” it from 24 to 60 fps usually results in some stutter/duplicated frames but I also believe v18 has some blending magic to make it less noticeable? It’s perfectly watchable for me anyways. Even h265 plays back just fine, which was barely watchable on Matrix due to my Pi lacking any form of hardware acceleration for it.

I also noticed on Matrix that it can’t keep up with certain scenes. Like there’s one in Dragon Ball Super where there’s a lot going on to begin with, but there are also subtitles and even fancy lyrics stuff. Audio could easily get 10-15 seconds ahead of video and removing the lyrics helps a little but video still gets around 10 seconds behind. Kodi v18 doesn’t even break a sweat.

Guess I’ll just wait for the new video stack to be developed some more. :>