Several Genesis (Phil, Tony, Mike) Live Music Concerts Video Lags, then Snaps Back In.

drewbp · December 30, 2020 at 7:57 PM

I have several Genesis Live Concert Videos, all from the box set, that will fall out of sync. All the videos from this box set seem to do this same thing, And on 2 separate RPi4s. One with 2GB on WiFi and the other with 4GB wired ethernet. I do not have this problem in Kodi, on the PC that holds all the videos.

i enabled "sync playback to display", and now every so often, the sync will snap back together, and then fall out of sync again.

**Klojum** · December 30, 2020 at 9:01 PM Official Post

Please provide a full debug log.

How to post a log (wiki)

1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)

use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

drewbp · December 31, 2020 at 2:42 AM

http://ix.io/2KmL

**Da Flex** · December 31, 2020 at 4:28 AM Official Post

Yeah, that error is visible at the log:

Code

2020-12-30 20:04:22.687 T:3011665936  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 29.970, 3D: false
2020-12-30 20:04:22.689 T:3011665936  NOTICE: Display resolution ADJUST : 3840x2160 @ 30.000000 Hz (16) (wei-ght: 0.000)
2020-12-30 20:11:42.195 T:2394477424  NOTICE: CVideoPlayerAudio::Process - stream stalled
2020-12-30 20:11:46.789 T:2989454192 WARNING: ActiveAE - large audio sync error: -1040.734258
2020-12-30 20:11:46.839 T:2989454192 WARNING: ActiveAE - large audio sync error: -1038.823835
2020-12-30 20:11:46.889 T:2989454192 WARNING: ActiveAE - large audio sync error: -1036.845208
2020-12-30 20:11:46.939 T:2989454192 WARNING: ActiveAE - large audio sync error: -1036.899898
2020-12-30 20:11:46.990 T:2989454192 WARNING: ActiveAE - large audio sync error: -1034.976967
2020-12-30 20:11:47.040 T:2989454192 WARNING: ActiveAE - large audio sync error: -1033.747706
2020-12-30 20:11:47.090 T:2989454192 WARNING: ActiveAE - large audio sync error: -90476.128866
2020-12-30 20:28:06.076 T:2394477424  NOTICE: CVideoPlayerAudio::Process - stream stalled
2020-12-30 20:28:06.238 T:2989454192 WARNING: ActiveAE - large audio sync error: -4911932.189470
2020-12-30 20:28:24.990 T:2419655536 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

Display More

Switch de-interlacing off. Read here how to do it: Click!

Try that setting with and without sync-to-display.

drewbp · December 31, 2020 at 4:50 AM

Thanks. Trying now. Its weird that it is every, and only the DVDs from this box set from Genesis that is doing it.

drewbp · December 31, 2020 at 4:54 AM

That does seem to have fixed the problem. I will report back as I watch several of the movies. Interlace off, and sync to display on.

drewbp · December 31, 2020 at 6:09 AM

So the real final solution to this situation is that I will have to remember to switch between settings for these particular movies.

When I started watching non problematic movies, they started exhibiting the same problem. So interlacing off, and sync to device on for the problem shows, and interlacing back on and sync to device off for everything else.

Thanks again for your help.

**Da Flex** · December 31, 2020 at 4:44 PM Official Post

Nice ! You could convert problematic movies into another format and / or wait until the issue has been fixed on LE.

drewbp · April 7, 2021 at 8:25 PM

So an update on this problem. I have moved to Kodi Matrix beta running on my Pi4. Unfortunately, I thought that the updated version would solve some of these issues. A more detailed description of what I see happening is, the video starts close to sync, and over time, gets further and further out of sync, to the point where I am a second or more out of sync. This manifests itself, in that when I press pause, the video takes the out of sync, amount of time, to actually pause. I have tried most of the suggestions listed on the above link. This is a very apparent situation on the Godfather 3 movie that I am experimenting with.

I am currently running a nightly build of Libreelec from a couple of days ago, using the Confluence skin, but have tried the default as well. 1920x 1080p refresh rate 30, nothing in the whitelist. I don't see a sync to screen in the settings anywhere, and interlace is greyed out.

As previously mentioned, this is on a RPi4 4gb wired, and 2gb wireless. No issues on the PC version of Kodi at all.

drewbp · April 7, 2021 at 10:03 PM

Latest Log uploaded.

http://ix.io/2Vlc

**Da Flex** · April 8, 2021 at 12:02 AM Official Post

Yes, that sync error is visible at the log. The rest of the log looks good, so I'm thinking it's a decoding bug (WMA pro / DTS). A dev should have a look at this, I have no idea about a hot fix.

Code

...
2021-04-07 14:20:09.319 T:942      INFO <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder wmapro
2021-04-07 14:20:09.319 T:942      INFO <general>: Creating audio thread
2021-04-07 14:20:09.319 T:945     DEBUG <general>: Thread VideoPlayerAudio start, auto delete: false
2021-04-07 14:20:09.319 T:945      INFO <general>: running thread: CVideoPlayerAudio::Process()
2021-04-07 14:20:09.319 T:945     DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 1
2021-04-07 14:20:09.319 T:942     DEBUG <general>: Prepare - Start position set to last stopped position: 482000
2021-04-07 14:20:09.320 T:811     DEBUG <general>: EGL Debugging:
                                                   Error: EGL_BAD_SURFACE
                                                   Command: eglSwapBuffers
                                                   Type: EGL_DEBUG_MSG_ERROR_KHR
                                                   Message: dri2_swap_buffers
2021-04-07 14:20:09.322 T:811     DEBUG <general>: CDRMAtomic::FlipPage - Execute modeset at next commit
2021-04-07 14:20:09.323 T:942     DEBUG <general>: SeekTime - unknown position after seek
2021-04-07 14:20:09.323 T:942     DEBUG <general>: CVideoPlayer::FlushBuffers - flushing buffers
2021-04-07 14:20:09.323 T:945     DEBUG <general>: CDVDAudio::Pause - pausing audio stream
2021-04-07 14:20:09.323 T:944     DEBUG <general>: CDVDVideoCodecDRMPRIME::Reset - flush buffers
2021-04-07 14:20:09.345 T:945     DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_SYNCHRONIZE
2021-04-07 14:20:09.345 T:944     DEBUG <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_SYNCHRONIZE
2021-04-07 14:20:09.345 T:942     DEBUG <general>: CVideoPlayer::SetCaching - caching state 2
2021-04-07 14:20:09.346 T:945     DEBUG <general>: CDVDAudio::Pause - pausing audio stream
2021-04-07 14:20:09.346 T:942     DEBUG <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2021-04-07 14:20:09.346 T:942     DEBUG <general>: Prepare - starting demuxer from: 482000
2021-04-07 14:20:09.352 T:811     DEBUG <general>: CWinSystemGbmGLESContext::PresentRender - Sending display reset to all clients
2021-04-07 14:20:09.352 T:811      INFO <general>: VideoPlayer: OnResetDisplay received
2021-04-07 14:20:09.352 T:945     DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 0
2021-04-07 14:20:09.352 T:944     DEBUG <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_PAUSE: 0
2021-04-07 14:20:09.359 T:811     DEBUG <general>: ffmpeg[(nil)X]: [image2] Custom AVIOContext makes no sense and will be ignored with AVFMT_NOFILE format.
2021-04-07 14:20:09.396 T:942     DEBUG <general>: CVideoPlayer::HandleMessages - player 2 reported state: 0
2021-04-07 14:20:09.396 T:826     DEBUG <general>: OnAVChange: CApplication::OnAVChange
2021-04-07 14:20:09.396 T:942     DEBUG <general>: CVideoPlayer::HandleMessages - player 1 reported state: 0
2021-04-07 14:20:09.399 T:942     DEBUG <general>: CheckPlayerInit - dropping packet type:1 dts:479317000.000000 to get to start point at 482000000.000000
2021-04-07 14:20:09.401 T:942     DEBUG <general>: CheckPlayerInit - dropping packet type:2 dts:481397000.000000 to get to start point at 482000000.000000
2021-04-07 14:20:09.401 T:944     DEBUG <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback
2021-04-07 14:20:09.403 T:942     DEBUG <general>: CheckPlayerInit - dropping packet type:2 dts:481439000.000000 to get to start point at 482000000.000000
2021-04-07 14:20:09.405 T:942     DEBUG <general>: CheckPlayerInit - dropping packet type:2 dts:481480000.000000 to get to start point at 482000000.000000
...

Display More

**popcornmix** · April 8, 2021 at 12:35 PM

The problem is the codec (VC-1) which isn't hardware decoded and ffmpeg doesn't support multithreading.

(You typically see one core at 100% with 2 fairly idle) Some 1080p files struggle to keep up. Overclocking could help.

I did profile and found about 30% of the decode time is spent in two loop filter functions.

There's optimised assembly on x86, but arm only has C code. It's something we'd like to improve.

ghtester · April 8, 2021 at 1:50 PM

Quote from popcornmix

ffmpeg doesn't support multithreading.

So is this a limitation of Arm build? Because AFAIK in general ffmpeg supports multithreading and there should be the -threads parameter for that purpose.

**Da Flex** · April 8, 2021 at 8:41 PM Official Post

After conversation with dev's, I can say that the ability of ffmpeg's multi-threading depends on the codec. It's currently not available for VC-1. Parallelizing VC-1 decoding is a heavy task. So my suggestion is to re-encode videos by MPEG-2 (software decoding) or H264/265 (hardware decoding).

drewbp · April 9, 2021 at 1:54 AM

So I would like some further explanation. I have many HD movies encoded into my computer that have no problem playing back at all. They are ripped with the same software. With the same settings. Most play just fine, with not even a hint of a problem. What is it about these particular encoded videos that creates this problem?

I am not expecting an answer that completely explains my specific problem, I just don't understand the majority of my Blu Ray encoded videos playing fine, and these several not being okay.

Thanks.

**Da Flex** · April 9, 2021 at 2:45 AM Official Post

You talk about music videos, and I assume the audio data rate is higher at those. A single RPi core can't handle the decoding of such data rate anymore. -> re-encode or overclock

**Da Flex** · April 9, 2021 at 4:06 PM Official Post

Just to make this complete: HEVC (aka H265) is suggested by dev CvH as the best long-term solution for encoding. If you want to play your video library on multiple platforms, go for that codec. (RPi 4 can hardware-decode it.)

At second place comes H264. (RPi 4 can hardware-decode it.)

MPEG-2 is third place. (RPi 4 can only software-decode it. RPi 3 can hardware-decode it by license purchase.)

VC-1 is working on powerful hardware (x86 PC's), but can overcharge weaker hardware, like RPi's, due to missing multi-threading. (RPi 4 can only software-decode it. RPi 3 can hardware-decode it by license purchase.)