Any lip-sync issue in KODI 17.6 was a non-issue for me with, say, it possibly being a consistent 0.25 or 0.50 ms off. It was an easy fix when Audio Offset was working as it should. With the Audio Offset no longer behaving properly and with no apparent a/v sync timing consistency, however, fixing it now with a blanket audio offset is a pathway to insanity. I find myself watching the lips more than the movie and often rewinding a scene multiple times just to stay connected with the plot.
The only shows I can enjoy without too much bother are my recently purchased 4K versions of Planet Earth II and Blue Planet II. With the Vero 4K the HDR to SDR conversion looks great on my Epson 5030UB and, thankfully, monkeys and fish don’t talk. When they do, however, I am compelled by the need for inner zen to rely upon the peacemaking abilities of my Odroid C2 for The Planet of the Apes and for Aquaman.
Watching Lips is indeed annoying… especially since it is actually a poor indicator if the audio is really in sync… only some syllables like „pi/pe/pa/pu/po“ are a good measurement, most others are subjectiv to how the actor/actress speaks.
Anyway, lip sync does not have to be perfect to work… it just has to be within 40ms… because in case of 23.976 frames content, even perfectly synced audio can be up to 40ms early. One frame of 23.976 content is 41ms. Let look at the last frame before the hammer hits the anvil. The next frame would be the hammer on the anvil. But the sound of it hitting will occur somewhere between those 41ms… in worst case it hits the anvil 1ms after the last frame… so in theory we have the sound of the hammer hitting the anvil 40ms before we actually get a frame that shows that.
Of course the higher the framerate, the smaller this windows gets. But if the team needs any target offset, it should be 40ms max… if that is achieved, I would call it perfect because it would fall under the margin of error that comes with a low framerate of 23.976. Sure some would argue that anything up to 100ms is very hard to notice, but people would NOW look for that anyway, hence the annoying lip sync check everytime you start a video.
@sam_nazarko, any progress on this issue? Any potential fixes you’d like me to try?
Not yet — as mentioned, I’ll give you an update when progress has been made
Thanks
Sam
Thanks for your patience.
I think I now have a solid fix for this. I’ve sent you a fix to try. Once I get a few more confirmations I’ll make this available as a test build.
Just working on fixing crashes on seeking now.
I just had a quick look at the test build at 2-3 affected files and they are now in sync. Can‘t say much more as its too late for me to really go looking deeper. But the sync seems to be much much better, so whatever you did in that regard should go into the july update if it comes with no new issues. Going to watch some new films and tv series this weekend, so I probably can add more feedback.
Thanks for confirming.
I’ll continue to refine things for the release.
Sam
I did the tests again because I actually had sync to display enabled (dunno why), so passthrough was disabled.
Now there is actually a difference between passthrough enabled and not. With sync to display (no PT) it is really perfect, with passthrough I had the audio slightly lagging, 70-80ms maybe. Better than before for sure and I might be able to live with it. But again, just tested two files I knew are affected. Lets wait what other users say.
When the audio is passed through, there will not be any delay. It is passed through bit for bit.
I will build these changes and make them available in the staging repository in the interim while I work on skipping
Sam
Testing more today… I will do naked eye tests only since I actually want to enjoy the content.
Skipping seemed to be indeed a bit rough on the edges at times.
On a side note, it seems that this videoplayer update improved subtitle rendering as well? I think I did not saw any frames dropped the first time subtitles were rendered.
Frame ordering is improved, so this could help subtitles.
I also did some more tests (I always have audio passthrough enabled):
With the default +96ms of delay which my beamer reports to the AVR (auto-lipsync function) the audio is behind ~40ms, so I changed the AVR-delay from 96ms to 56ms and most files play sync now.
But this means on the other hand that it’s still not working the same as in Kodi 17, where the 96 ms delay was perfectly fine.
But there are still a few files that need additional tweaking of the delay (like my 4k movie with Atmos audio). Here the 56ms is not the correct value.
But we are getting somewhere… Thanks for all your effort!
Yes it seems it the audio is still 1 frame behind on affected files. Though the last videos I watched were files either not affected or no longer affected, as sync was great…
Anyway it is also a huge improvement to what we had before.
I have some further improvements for this.
How can I update to those improvements?
I’ve not made those available just yet.
Sam
All of the changes are now in the staging repository
To test this update:
- Login via the command line
- Edit the file
/etc/apt/sources.list
- Add the following line:
deb http://apt.osmc.tv stretch-devel main
- Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot
- Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
Sam
I am very pleased with my Vero 4k experience the last 10 days, I have not seen any audio delay, that I could detect with the naked eye. I stopped analyzing files frame by frame, so there might still be some slight delay but since I can not see it anymore, I am pretty pleased right now.
1 Like
I’m glad to hear this is improved.