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 
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.
Interesting
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…
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.
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.
I have here a test version including the fix from @ukmark62 included:
https://test.coreelec.org/Portisch/CoreELEC-Amlogic-ng.arm-9.2-devel-1581274869.tar
It’s not included in nightly yet!
Thanks very much for this. Have tried this version and audio is now immediately heard upon resume.
Its good find, although not easy to pick, because DVDVideoCodecAmlogic.cpp doesnt have GetOutputPicture method.
As @umark62 tracked within opened Issue, the context for this buffer flush is here - should affect just resume point. My observations with latest Kodi@CE - video starts a bit earlier than stopped state anyway (doesnt bother me, maybe in contrary. Most important is it doesnt start later).
I think nearest keyframe before makes sense (quote from issue: “This line was not present when #11713 was first done.”)
I can confirm that big pause after resume/seek is gone with flush buffer removed. Cant comment impact on A/V sync as there is need more tests and comparations.
Please do so - we are not sure if this changes will have affect to other places in Kodi or hardware decoder.
Ill try. Although I cant make 100% statement as I change configuration from C2 to VIM3L recently, and I am still catching spot on delays (I mean for different TV modes, different sources/fps). So cant tell if some changes was just because that buffers, more like because I jumped from 3.14 to ng kernel.
So far only TV testing, no projector profile, seems to be promising…
Update: A few projector movies, still doesnt spot issues.
The patch is tomorrow in next nightly included.
About | FAQ | Terms of Service | Privacy Policy | Legal Notice