Audio Video desync after pause

[Loeffel 3]

Hi,

I had no problems with Emby so far, but after updating to the newest version for the Synology NAS (DS1821+ DSM 7.3.2-86009, 32GB RAM, 2 NVMe configured as cache, with Emby 4.9.1.90-724081100) the Audio is desynced after pausing a video. It doesn't matters which client I use. I've tested it with my browser (Chrome and Firefox), the android app on FireTV and directly on a Xiaomi TV.

Always after pausing the video the video is about 2-5 seconds delayed.

The problem is easy to resolve, I just need to stop the video, so that I see the normal screen for the movie. Then I continue the video and everything is fine again.
This problem first occured after updating to the newest version. It is also consistent so if I pause I will have this desync.

Yours

Loeffel

ffmpeg-directstream-a20ec69f-d319-4290-91a9-3cb94e453c0b_1.txt

[Luke 42077]

HI, have you updated to Emby Server 4.9.3? Has that helped?

[Loeffel 3]

Haven't seen this version, just installed it. Need to test now. Will give you feedback.

[Loeffel 3]

Now it doesn't happen every time. Sometimes yes, sometimes not. I can't say when it happens because it doesn't depend of the video I'm watching. I had it that it happened in a video and afterwards or before in that video it doesn't happen. I even went back to the same spot (more or less) paused again and that time it didn't happen. So I'm pretty sure it isn't the video file.

[visproduction 315]

Related issue with possible solution:
 https://emby.media/community/index.php?/topic/137507-playback-issues-with-x265-10bit-media-and-subtitles/

I think network traffic, cache limits, TV app or browser limitations contribute to this problem, especially when you pause.  The original h.265 media is compressed and the sync timing code in the metadata is not continous, as it would be in an uncompressed master.  So, if you pause in the middle of a i-Frame sequence of compressed video, the next audio sync data could be several seconds further into the media playback.  The TV app or browser may not maintain the metadata of the audio sync stopped in the middle of i-Frame packet sequence or even able to figure out where the next sync is, when you press play again.  I think it waits for the next incoming audio sync point at the next i-Frame and just matches that. So it's easy to go out of sync after hitting pause.  I believe this is built in limitation to the video codec.  If you happen to hit pause, on or really close to a i-Frame (typically every 7 seconds), then you luck out and everything stays in audio sync.  Otherwise is can often go out.  Some 3rd party players like VLC, may run a resample for audio sync test, every time time play after a pause is made.  TV Apps and browsers are not so fancy.

I am guessing at much of this.  Based on my expereince of never seeing audio sync issues when editing from an uncompessed master and post production policy is never to edit compressed video, always ask for the master for quality and audio sync issues.  And if I ever try to fudge my way around this and start editing a compressed video, I get pixelation artifacts and audio sync problems.  Actually the normal approach in post, if you have to edit anything compessed, is to first make a new, uncompressed master and edit from that.  That's a little off the point.  I think the pause audio sync is a built in bug and it won't get fixed because TV and browser players don't do a double check for audio sync, like VLC does.

Edited January 27 by visproduction

[Loeffel 3]

@visproductionI would say you are right, when I always had these problems, but I never had these problems prior version Emby 4.9.1.90-724081100.

[Luke 42077]

Hi, we are looking into it. Thanks.

[Loeffel 3]

I tested a little bit with Beta 4.10.0.2-724100002. There it is better as it doesn't happen everytime now.

[Luke 42077]

Thanks for following up!