Resuming playback, audio momentarily muted - keyframes?

try it also without HEVC Skip fix… I turning it off, continue watching the same show, and seems to it helps, even there are some timeouts though (maybe its related to pausing, maybe not, I dont have notebook right now to proper debug and watch tv…)

    19-03-08 14:48:28.274 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:15:34.092 T:4091158544 WARNING: Previous line repeats 3141 times.
    2019-03-08 15:15:34.092 T:4091158544  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 23.976, 3D: false
    2019-03-08 15:15:34.093 T:4091158544  NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (16) (weight: 0.000)
    2019-03-08 15:15:34.254 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:19:13.574 T:4091158544 WARNING: Previous line repeats 306 times.
    2019-03-08 15:19:13.574 T:4091158544  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 23.976, 3D: false
    2019-03-08 15:19:13.574 T:4091158544  NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (16) (weight: 0.000)
    2019-03-08 15:19:13.721 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:19:39.085 T:3405697904 WARNING: Previous line repeats 31 times.
    2019-03-08 15:19:39.085 T:3405697904  NOTICE: CActiveAEStream::AddData - messy timestamps, increasing interval for measuring average error to 6000 ms
    2019-03-08 15:19:48.316 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:20:29.364 T:4091158544 WARNING: Previous line repeats 80 times.
    2019-03-08 15:20:29.364 T:4091158544  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 23.976, 3D: false
    2019-03-08 15:20:29.364 T:4091158544  NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (16) (weight: 0.000)
    2019-03-08 15:20:29.715 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:21:43.112 T:3405697904 WARNING: Previous line repeats 55 times.
    2019-03-08 15:21:43.112 T:3405697904  NOTICE: CActiveAEStream::AddData - messy timestamps, increasing interval for measuring average error to 6000 ms
    2019-03-08 15:25:22.004 T:3449758576 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    2019-03-08 15:58:41.838 T:3405697904 WARNING: Previous line repeats 615 times.
    2019-03-08 15:58:41.838 T:3405697904  NOTICE: CActiveAEStream::AddData - messy timestamps, increasing interval for measuring average error to 6000 ms

But If i understand correctly, HEVC seek fix was enabled by default on previous 8.99.2, and I didnt experience this before.

1 Like

For me, this happens even when a pause a video and replay it. Do you experience the same? A delay of few seconds in the audio after the video has started.

That “ActiveAE -large audio sync error” is something I noticed in my log - in the example I posted the sync error is over 8 seconds - hence the 8 second mute on resume. The only thing I found looking through the xbmc source is a small change between Kodi 17.6 and Kodi Leia. See below:-

"if (m_pDemuxer)
{
if (m_pDemuxer->SeekTime(starttime, true, &startpts))
{
FlushBuffers(starttime / 1000 * AV_TIME_BASE, true, true);
CLog::Log(LOGDEBUG, “%s - starting demuxer from: %d”, FUNCTION, starttime);
}
else
CLog::Log(LOGDEBUG, “%s - failed to start demuxing from: %d”, FUNCTION, starttime);
}
"
In kodi 17.6 version of this file (https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/VideoPlayer.cpp), the line below is not present.
FlushBuffers(starttime / 1000 * AV_TIME_BASE, true, true);

I don’t know what this line does but it may hold a clue.

FYI, PR11713 basically changed the line of code from:-
" if (m_pDemuxer->SeekTime(starttime, false, &startpts))"
to
" if (m_pDemuxer->SeekTime(starttime, true, &startpts))
in 2 places. See the commit below:-

This changed the behaviour to seek backwards for the nearest video keyframe to resume playback from, instead of seeking forwards as it had done in the past.

I’m thinking it’s a either a native kodi issue or something LE9.0 introduced, as it also has the same issue since early days of Leia.

Hyphotetically, if this would be Kodi related, it would affect 18.1, because I didnt notice this on CE 8.99.2 + Kodi 18. This suggest opposite though.

But this is hard one, because there are quite much things related, and the error message is a bit general… And also, as you can see, in my previous post, I experienced very little delay normalny when jumped to Leia (which could be consequence of PR you mentioned) which doesnt have any negative consequences in logs I believe, but this AE sync errors seems to be bounded with bigger delay symptom…

btw. for me, after HEVC Skip fix uncheck, my logs doesnt have those AR sync errors (watching one specific TV series 1.5h or something).

It’s definitely a strange one as Kodi 18.1 on Windows and Android are fine.I only see the problem on CoreELEC 9 with resume (and only when the gap between previous keyframe and resume time is noticeable).

it could be something Amlogic specific. And also, more things could change in CE between 8.99.2 (which I think has HEVC Skip fix enabled and I didnt notice longer audio delay) and 9.0.1.

CE devs do amazing work to allow good h265 HW dec. playback as wide as possible (especially appretiated custom settings), but apparently this is quite hard job I guess… h265 seems to not be so much standartized as h264 and some issues could be AML specific; so Intel platform doesnt have those - doesnt pops out so quickly.

I experienced longer delays on 9.0.1, not before… I dont know what early Leia days means, but on the other side I cant remember from which version I started to use CE… but feels like quite a time already… :slight_smile:

I just tried it on a Rockchip device RK3328 (using LE9) and the same issue occurs there also.

is it possible to try LE9 version with Kodi 18, on the same HW?

Btw., for me it seems that h265 has a little different audio/video sync than h264 (I mean, the value of audio delay, setuped for the actual config-hdmi cable length-devices are differs for h264 files and h265).

Still doing testing, its less noticeble when connected directly to the TV, but more noticeable, when using AVR between. So far I didnt find the root cause…

Not sure I understand the question - LE9 is Kodi 18. The image I installed on the Rockchip device is from here:- https://yadi.sk/d/oje0RHxPqpEqqQ/20190306

This developer (balbes) has been developing his own versions since LE8 (Kodi 17). Usually, the differences between official and his versions are minor.

I have both LE9 (Kodi 18.1) and CE9 (Kodi 18.1) on two different sd cards and can run them on any S905 or S905x box.

Just to confirm, my issue is only on resume (and the audio comes back once the resume time is reached). I have no other audio/video sync issues.

Ah, sorry for confusion, I thought LE9 also releases versions with 18 and 18.1… so I wonder if this could be by Kodi itself or not… to prove/disprove my thoughts, that I dont see that on AML with CE 8.99.2 with Kodi 18.

Maybe I misunderstood also. LE9.x is for all 18.x versions, similarly CE9.x is for all 18.x versions.

All I can say is that LE8.x (which started with Kodi 17.0 and went through to Kodi 17.6) does not have this audio resume issue.

so didn’t work, have been off all the time :frowning:

I managed to find a possible fix to this. Namely, in the kodi VideoPlayer.cpp file, I removed the line:-
FlushBuffers(starttime / 1000 * AV_TIME_BASE, true, true); (See my earlier post).
and remade the image from a forked CoreELEC - that’s the only change from CoreELEC master.

Now, the audio is heard immediately upon resume. So far I’ve not had any issues.

2 Likes

Interesting

1 Like

Great. Hopefully, the devs can test this in their nightly builds.

Paging @TheCoolest and @Ray . It is quite annoying and it would be great if this fix works and can be incorporated into the nightlies for testing.

Maybe kodi team is already aware & fixed it for Android:

CE doesn’t use AndroidMediaCodec.
Looks like that line of code clears the buffers, it’s possible that it has been put there for a reason, and may cause issues with different types of content.

Yes, I know…:roll_eyes:
But the problem there (too much flush after resume, causing side effects on decoders) could also be the rootcause for this problem.
In https://github.com/CoreELEC/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/DVDVideoCodecAmlogic.cpp, we have the same Flag handling (line 418-421), which was deleted there.
Maybe worth to make a shot in the dark and try this instead of changing core VideoPlayer.cpp, which indeed may have other side effects.
Maybe peak3d could help here, too, as this needs detailed understanding of AV processing.

4 posts were split to a new topic: Audio delay

Hi I’m still facing this issue, I think it is related to passtrough as I faced simillar issue in the past when using passtrough. Thing is if I disable eAC3 passtrough sound is all messed up.