[jack0w]

@liquidskin76

Your comments have struck a chord with me - I've had some more time of late to and I definitely fall into the category of "thought it was perfect but now notice it seems to be slightly out of sync!" Hence my searching and coming across this thread last night.

Whilst I am noticing slight sync issues, I wasn't able to determine exactly how far out it is. It's also fair to say I'm not using the latest nightly - just one I believed to be pretty stable and with AE.

Your comment about containers interest me - I've been exclusively using MKV created with MakeMKV. I will give it a try in another container and see if I notice a difference.

Also with regards to comment about vsync: I did try last night, very briefly so don't read too much into this until I can confirm my initial quick check! But I did think sync was improved with it off, though as expected I had video tearing with it off.

Only other comment is I do see the missed counter almost constantly increasing, though did read elsewhere that this counter is broken, not sure if that is still accurate - can anyone confirm one way or the other?

I will do some more comprehensive testing, including trying a newer nightly build, and post my findings.

Also don't mean this post as a criticism at all as really appreciate all the hard work of the Dev's! Just hoping to offer some useful information that may help troubleshooting this issue.

Additionally is this the best thread in which to post my findings, or should I put it in the Windows AE Support thread?

Thanks again to Dev's for all their hard work

[Stefanhvt]

This is for sure the best thread to post in. I think it's time to get some clearity on this issue after all these years. What I wan't to add is the following:

1. Not all people notice sync issues. But after it hits there atention for the first time, they are no longer able to miss it. It's a consiousness based issue.

2. Second. I hear people talking about missed frames. But what about the incapability of video cards to display 23.976 FPS stable? This question is of more importance. I see the video switching from 23.98 to 24.00 and from 23.98 to 23.95. But mayby it's even more? Who knows. In this case it's definitely a hardware issue.

3. The most strangest thing of all is the experience of video getting in and out of sync without me touching the system settings. The first evening it played in sync, I thought. The next evening it was totally of. Now this is only possible because of one thing. I am to obsessed with it. Keep in mind people that the longer you charge your brain to spot this, the more you will see and your sensitivity will grow more and more.

[jack0w]

2. Second. I hear people talking about missed frames. But what about the incapability of video cards to display 23.976 FPS stable? This question is of more importance. I see the video switching from 23.98 to 24.00 and from 23.98 to 23.95. But mayby it's even more? Who knows. In this case it's definitely a hardware issue.

That jogged my memory! I also noticed that the FPS isn't completely consistent, but that's not only with 24p content in my case. I was watching 60/50hz content last night when I spotted that. Whether or not it has any bearing at all on sync is another matter though!

In the event it does have an influence, perhaps there is some way to cap the FPS for particular types of content?

Just thinking aloud as have no coding experience, or clue if it actually matters!

[liquidskin76]

I'm into video encoding, and creating video backups from my BD/DVD collection so i'm well placed to carry out tests as i also still see the 250ms delay on AE builds. I did lots of testing a while back, however would like to recheck some stuff. Leave it with me, i'll do that tonight and update on it then.

If memory serves me right, basically, i saw differences in sync based on av container. For example, an M2TS file from a BD folder backup was fine on sync, however when the audio/video from that same BD folder was muxed to MKV using either MakeMKV or MKVMerge, sync was out.

If i give the MKV a 250ms audio delay (during mux using MKVMerge), then sync was good at 24p. Can't remember the sync issue when audio was decoded by XBMC to lpcm.

Now, as an interesting (and totally unrelated!) side note... not sure how audio is handled when played at 60Hz using 2:3 pull down, however even with that 250ms audio delay muxed into the MKV file, XBMC played it in perfect sync at 60Hz! I was expecting it to be out by 250ms!! Anyway...

Another interesting (and very very relevant) side note... again if memory serves me right, i saw the exact same sync problem using mpc-hc and refresh rate switching.

As well as testing sync on decoded audio, i'll also test sync with display set manually to 24Hz, and with refresh rate switching disabled.

Anyway, i'll get testing again tonight to confirm, and post an update. What i'd like to know is what container people are using when they see the sync issue? Is it only MKV?

Cheers

---

I believe providing files for devs to test with won't be of any help. I've already covered that with dddamian, and on a file i had sync issues with, he didn't.

Cheers

Ok, glad i tested again as some of the above was incorrect...

Doesn't matter on av container. I see the same sync issue on m2ts and mkv. Audio decoding (instead of bitstreaming) still has sync issue. Plus, with display manually set to 24Hz, and with refresh rate switching off, i still see sync issue (so that rules out the switching process being the cause).

Anyway, here the most important thing i've confirmed (xbmc devs can breath easy )... issue is also present (for me at least) using mpc-hc using lavfilters. So it's not just limted to xbmc.

Here's another thing to think about... at a glance and at a distance, sync looks acceptable. It's only when checking up close on actors lips that you really see it, plus when you add the 250ms audio delay only do you notice how much better sync is.

So maybe it's there and some people just don't notice it, or it's a hardware combo (maybe av receiver) issue thats the reason why some have it and some don't? Who knows!

Guess i'll be adding a 250ms delay on my mkv backups.

Cheers

[EDIT] you know what, a 150ms delay is an improvement. Maybe dddamian can adjust AE sync on 24p by 125/150ms, so it's at a half-way point for both groups of users. My thinking is 125/150ms might not be noticable for the guys who don't have the problem, and an improvement for the guys who do?

[jack0w]

Here's another thing to think about... at a glance and at a distance, sync looks acceptable. It's only when checking up close on actors lips that you really see it, plus when you add the 250ms audio delay only do you notice how much better sync is.

So maybe it's there and some people just don't notice it, or it's a hardware combo (maybe av receiver) issue thats the reason why some have it and some don't? Who knows!

I completely agree with the first comment, will give 250ms a try and see how things look.

With regards to AV receiver perhaps there is something in common - what are you using? I'm using an Onkyo 507.

Also found a comment from DDDamien in another thread about a lip sync feature being part of the HDMI spec that not all manufacturers adopted - going to see if I have this option and if it has any influence.

Will report back my findings!

[sim888]

Keep in mind people that the longer you charge your brain to spot this, the more you will see and your sensitivity will grow more and more.

Yep, couldn't agree more....my lip syncing skills are so finely tuned now, i think i could start a new career

Side note - i tried the TV Pc/Game settings, and that didn't seem to have any improvement, so am back to the global delay setting for 24p
am giving some custom modelines a go to see if that works though....

[DDDamian]

I'm into video encoding, and creating video backups from my BD/DVD collection so i'm well placed to carry out tests as i also still see the 250ms delay on AE builds
I believe providing files for devs to test with won't be of any help. I've already covered that with dddamian, and on a file i had sync issues with, he didn't.

Cheers

[EDIT] you know what, a 150ms delay is an improvement. Maybe dddamian can adjust AE sync on 24p by 125/150ms, so it's at a half-way point for both groups of users. My thinking is 125/150ms might not be noticable for the guys who don't have the problem, and an improvement for the guys who do?

I wouldn't do that - mine would look bad Far better the built-in adjustments we have, especially as they can be made defaults or adjusted according to frequency ranges.

Also found a comment from DDDamien in another thread about a lip sync feature being part of the HDMI spec that not all manufacturers adopted - going to see if I have this option and if it has any influence.

Will report back my findings!

The above is a real shame - it was meant to accomodate delays from video processing (and indeed audio processing) in hardware. For steady-state errors (like the 250ms ppl seem to run across) this was the spec's answer to a very real issue.

As far as the hunting or varying fps - the normal method is to time off the audio clock, not the video clock. XBMC provides alternatives, but that's the norm. For those who know a little about control algorithms there's a PID loop running in the player level that might be worth a look-see one day.

And god no - please never let me catch the sync-stink disease

[liquidskin76]

I'm into video encoding, and creating video backups from my BD/DVD collection so i'm well placed to carry out tests as i also still see the 250ms delay on AE builds
I believe providing files for devs to test with won't be of any help. I've already covered that with dddamian, and on a file i had sync issues with, he didn't.

Cheers

[EDIT] you know what, a 150ms delay is an improvement. Maybe dddamian can adjust AE sync on 24p by 125/150ms, so it's at a half-way point for both groups of users. My thinking is 125/150ms might not be noticable for the guys who don't have the problem, and an improvement for the guys who do?

I wouldn't do that - mine would look bad Far better the built-in adjustments we have, especially as they can be made defaults or adjusted according to frequency ranges.

I thought that might be the case. Like you said, there's the built-in options so we can always adjust there i suppose. Didn't actually take a look at a SD 25fps backup so maybe a 125/150ms adjustment there is badly obvious?

Also found a comment from DDDamien in another thread about a lip sync feature being part of the HDMI spec that not all manufacturers adopted - going to see if I have this option and if it has any influence.

Will report back my findings!

The above is a real shame - it was meant to accomodate delays from video processing (and indeed audio processing) in hardware. For steady-state errors (like the 250ms ppl seem to run across) this was the spec's answer to a very real issue.

As far as the hunting or varying fps - the normal method is to time off the audio clock, not the video clock. XBMC provides alternatives, but that's the norm. For those who know a little about control algorithms there's a PID loop running in the player level that might be worth a look-see one day.

And god no - please never let me catch the sync-stink disease

I'm on a Sony STR-DH820, and i'm sure it's has this feature. Thought it was on, however maybe not. I'll double check.

Oh, that sync-stink disease... smells terrible it does!

---

It's not a desease. It's for advanced brains

There's nothing advanced about my brain! It's not quite running at 23.976Hz, and it has a slight audio delay!!!

[liquidskin76]

Anyway, here the most important thing i've confirmed (xbmc devs can breath easy )... issue is also present (for me at least) using mpc-hc using lavfilters. So it's not just limted to xbmc.

Can anyone else confirm this? Don't worry about refresh rate switching in mpc-hc, just set your TV manually to 24Hz and test.

Cheers

---

One other thing i'll test when i get chance... i'll run audio/video direct to my tv from the htpc, and decode audio to 2ch. See how it is with the av receiver out of the loop.

[steelman1991]

Hi Liquid

I'm probably the wrong one to answer you, because I don't see it anywhere - not in xbmc, mpc-hc, jriver, with or without the inclusion of an AVReceiver in the chain - Onkyo 805, ATI 5670/Nvidia430/i3 - all provide me with perfectly synched video/audio.

[liquidskin76]

Hi Liquid

I'm probably the wrong one to answer you, because I don't see it anywhere - not in xbmc, mpc-hc, jriver, with or without the inclusion of an AVReceiver in the chain - Onkyo 805, ATI 5670/Nvidia430/i3 - all provide me with perfectly synched video/audio.

Hey steelman,

It's been a while! No problem.

I'm working around the problem by muxing in a 250ms delay when creating my BD backups to mkv, so it's to much of a problem for me to manage. Obviously that not's much help for others though!

Cheers mate

[Stefanhvt]

Keep in mind people that the longer you charge your brain to spot this, the more you will see and your sensitivity will grow more and more.

Yep, couldn't agree more....my lip syncing skills are so finely tuned now, i think i could start a new career

Side note - i tried the TV Pc/Game settings, and that didn't seem to have any improvement, so am back to the global delay setting for 24p
am giving some custom modelines a go to see if that works though....

To bad it did not work for you. What is the exact amount of global delay your using now ?

[meridius]

I am using xbmc 10 and I only get sync problems on 24fps with dts tracks but with 24fps video and any other audio formats I get no problems.

I have to use -200ms to to sync 24fps and dts movies.

I just hope xbmc 12 fixes this for me as I have a similar spec pc to dddamian.

dddamian did u have the same problem on xbmc 10 at all? And did your builds of xbmc 12 fix it or u still having the same problems.

[DDDamian]

@meridius - I'm in a tough position to answer that. As mentioned I've just not seen this issue period.

I try to read through this thread looking for consistent clues, whether in codecs, containers, OS's, hardware, pre or post-AE. I also watch for wider reports of it (this thread is only 30 pages and the posts are far from being all unique users). None of the devs bring this up as an issue either. Some users say it's fixed, others not. Some say it's only XBMC, others not.

Not saying by any stretch it may not be present or perceivable for some users, but a common potential scenario hasn't cropped up or developed by consensus here that might point to a root cause....

[DDDamian]

I do no notice anything, should I?

Yes, you should by your argument. The 0.0003s you use as a threshold is easily tested by moving your head 4". That's just pure physics, i.e. "reality". If you read my explanation you'd know why.

The interesting part is here. None of the devs bring this up as an issue? Now to which builds do you refer here? If your talking about the eden builds with the old audio engine than that give clues.

To all builds - in the few times it has come up it's only from devs reading forum posts and almost collectively saying "I don't see it". That does not mean it doesn't exist with some soft/hardware and muxes. A lag of 250ms is pretty large - certainly it's not built into the code, although it may be built into the mux. But for whatever reason not one dev I'm aware of sees it.

Frankly a debate like this belongs more at avsforums, not here. And we shouldn't be hijacking it with "speculation" - you have presented a case of sorts but the intent of the thread is to find a solution. You will *never* achieve 0.0003s with any player or HTPC in the foreseeable future, and even the gadget you linked doesn't adjust in those units. You have far more to gain by either buying that, tracking down the code errors or becoming a hardware developer.

More Importantly...
To get the thread back on track for those trying to find or help to find a solution I'd propose this. We're looking for some commonality - that's the only way to start tracking down a solution. A blunderbuss approach has no chance.

Use this as an example template where you definitively find sync issues only with XBMC, i.e. not present with the same file in MPC-HC, without ReClock or other complications. We're not looking to solve problems outside of XBMC-specific ones, so if you can't test on another player like MPC-HC don't post.

Setup
OS Version:
GPU:
Video Driver:
Soundcard:
Receiver:
Audio Drivers:
XBMC Build:
XBMC Settings:
Container/codecs:
Muxer Version:
Deviation:

Just copy/paste that and fill in. Then describe any other relevent observations. The hope is that we can narrow things down a bit, and this would be a practical step forward. Fill out what you can and perhaps we'll gather some hard data. Without that it's whistling in the wind.
Here is an example:

Setup
OS Version: - Win 7 x64
GPU: - ATI/AMD HD6450
Video Driver: - Catalyst 12.6
Soundcard: - HDMI output from above
Receiver: - Denon AVR3808CI
Audio Drivers: - WASAPI to AMD High Definition Audio Device 7.12.0.7706 2/23/12
XBMC Build: - 12.0 Alpha6 Git:09062012
XBMC Settings: - Sync Playback to Display: off, A/V sync method: n/a, Adjust display Refresh Rate to match Video: off (all relevent settings - those are the biggies)
Container/codecs: - MKV, h264, DTS 5.1 1500kb/s seems to be all DTS 5.1 (use MediaInfo if in doubt)
Muxer Version: - MKVMerge 3.4.0 (if known, again try MediaInfo)
Deviation: - looks like about 150ms audio lagging