Topic: AV Sync - inconsistent results (Read 13273 times)

6233638 · « **on:** February 27, 2015, 06:42:26 am »

I can never get audio and video in proper sync. Sometimes it appears to be perfect. Other times it is noticeably out of sync.
So I ended up buying a hardware latency tester.

This works really well to dial in sync. You let it run for maybe 30 seconds, adjust MC by the average value and you basically have perfect sync.

Except it's not consistent in MC.
<snip> See further posts for updated test results.

JimH · « **Reply #1 on:** February 27, 2015, 07:03:20 am »

Are you using any DSP?

6233638 · « **Reply #2 on:** February 27, 2015, 07:05:23 am »

Same results with/without DSP.

Hendrik · « **Reply #3 on:** February 27, 2015, 07:17:41 am »

What kind of device would that be? I've been wondering if there is a decent hardware solution for testing that.

6233638 · « **Reply #4 on:** February 27, 2015, 07:34:03 am »

Quote from: Hendrik on February 27, 2015, 07:17:41 am

What kind of device would that be? I've been wondering if there is a decent hardware solution for testing that.

It's this device: http://sync-one2.co.uk/

Hilton · « **Reply #5 on:** February 27, 2015, 07:50:51 am »

Quote from: 6233638 on February 27, 2015, 07:34:03 am

It's this device: http://sync-one2.co.uk/

That's very cool!

6233638 · « **Reply #6 on:** February 27, 2015, 10:54:44 am »

I received a 20 minute test file, which ensures that VideoClock is 100% settled by the end of it, and have done some additional testing.

VideoClock itself seems to be very stable.
Once it settles, I'm only seeing deviation of ±1ms at most - it is often less than 0.5ms (the display reads zero, but flips between positive and negative)

But while the relative sync is very stable, the absolute sync is not.
If I seek/pause/stop/resume playback, sync can vary as much as ±40ms from the previous offset - which is noticeable.

Hendrik · « **Reply #7 on:** February 27, 2015, 11:34:01 am »

Can you share the 20 minute file? Good sync videos are nice for testing these things.
FWIW, I ordered one of those gadgets myself, since I've been looking for a solid way to test AV sync in real-world conditions.

6233638 · « **Reply #8 on:** February 27, 2015, 12:41:22 pm »

Quote from: Hendrik on February 27, 2015, 11:34:01 am

Can you share the 20 minute file? Good sync videos are nice for testing these things.
FWIW, I ordered one of those gadgets myself, since I've been looking for a solid way to test AV sync in real-world conditions.

While I PMed you the link I was sent, it turns out that it compresses to <1mb when you use 7zip (or RAR5) compression, so I'll upload it here for anyone that wants it.

I've spoken to the developer again and he hopes to have additional 20-minute videos rendered out and posted on the site some time tomorrow. (I've requested 25/30/60 FPS)

jmone · « **Reply #9 on:** February 27, 2015, 01:40:47 pm »

Here is some test patterns I made at different frame rates. THey also show a unique PNG image for each frame (so you can see if you get any judder etc) and a Beep each second - If any are useful I can make them longer etc

https://db.tt/UjYc0h2M (50MB)

edit - I can make it "flash white" on the beep so it should work with the meter as well

Hendrik · « **Reply #10 on:** March 02, 2015, 04:26:47 am »

I received my Sync-One2 this morning (ordered Friday afternoon, I like fast shipping), and I've been testing MC a bit.
One thing I noticed, while I can reproduce the "absolute" sync differences you mentioned, it seems to be mostly visible when using madVR in RO HQ.

Using RO Standard with EVR, the sync is always <= 10 ms for me, while with madVR it can go as high as 30 ms easily, and thats on a 60Hz screen for testing, I bet it could be worse on 24 Hz because every frame is just longer.
I only tested for a short time, but it seems to be consistent. I can reproduce the offset very reliably with madVR, and not at all with EVR (considering <= 10 as "fine")

Can you maybe confirm that?

PS:
A bit of an absolute offset is unavoidable with the current system, as while we can sync to the refresh rate of the screen, we currently cannot sync to the absolute refresh position.
That means unless the screen refresh matches the reference time "0" perfectly, there is always going to be room for a sync offset of half the frame time, since we just cannot know when the screen refreshes and shows the next frame. We assume it happens at 0, 1, 2, etc, but it might be at 0.5, 1.5, 2.5 ... we only know the interval, not the position.

Judging from the values i'm seeing however, it appears that EVR works properly and the offset is usually within this half-frame-time margin (8ms on 60Hz), and madVR tends to have a whole frame difference occasionally, 16.6ms + our margin, sometimes even more.

6233638 · « **Reply #11 on:** March 02, 2015, 02:37:24 pm »

That was quick!

I will have to go back and test EVR again. It seemed like I was having the same degree of variation with EVR as madVR, but that was before I had longer test files that allow VideoClock to completely settle.
The full set of test files are now available here: http://sync-one2.co.uk/support/test-files/

I only had access to 24 FPS test files when doing my initial tests, so perhaps the maximum variance is ±1 frame (which would be ±41.7ms at 24 FPS) and sync would be tighter at other rates.

I understand that there is the potential for some variance due to external factors, but aside from this issue when seeking (or pausing/resuming/starting a new file) the sync in my system seems to be very consistent.
Once VideoClock has settled, I can change inputs on the display, switch it in/out of different modes which affect the latency, or change inputs on my DAC, and the sync numbers don't change when I return to the original settings. It's only when using the playback controls in MC that the sync seems to have this variance.

I really need to do further testing to see whether this is specifically an issue with Media Center, an issue with MC+madVR, or a general madVR issue.

Even if it's not possible to achieve perfect sync 100% of the time, if the variance could be reduced to ±0.5 frames, that could make all the difference.

And as mentioned here, it would be nice if there was an additional sync offset for full-screen playback.
I believe you have (or had) a Sony TV like mine where the PC/Game modes offer full 4:4:4 chroma, but limited processing.
And there's a "Theatre" button on the remote which switches it over to the Cinema mode, which uses 4:2:2 chroma but enables the full processing options. (which means full local dimming and backlight scanning on my set)
If I set my sync value for full-screen playback (where it is more critical) then it means that windowed playback in the Game/PC modes are early by 41/72ms, and that's quite noticeable.

6233638 · « **Reply #12 on:** March 03, 2015, 07:54:12 am »

Well I've just been through a lot of testing now, and you're correct that madVR does seem to be worse than EVR for sync.
However madVR in Media Center is considerably worse for sync than madVR in other players like MPC-HC.

If I use EVR with or without VideoClock, variance is very small. (typically within ±8ms)
If I use madVR with VideoClock, variance is kept within the range of about ±40ms
If I use madVR without VideoClock, sync gradually drifts during playback as expected (about +1ms every 3-4 minutes) and variance after seeking can be as much as ±300ms!

However, if I use madVR in MPC-HC just outputting directly to my DAC (no ReClock) the variance is kept within ±8ms or so - which is tight enough that it's going to be half a frame out of sync at most, at 60 FPS, and a fraction of a frame at 24 FPS.

For what it's worth, something that I have noticed in the past with madVR, which I think may be related, is that MC's playback controls never seem to be quite "in sync" with madVR.
For example, if I switch to a new video and immediately pause it, Media Center will be in a "paused" state, but the video is actually playing.
This is most obvious if you use large queue sizes and enable the "delay playback" options in madVR.

Hendrik · « **Reply #13 on:** March 05, 2015, 05:40:05 am »

I did some tests without VideoClock this morning, and it seems to work pretty good.
Occasionally the sync is totally off when starting the video, but it usually corrects itself within a couple seconds. I could probably make it more aggressive.

But after those couple seconds, it usually sits on a range of -10 .. +10, until drift moves it out of that range again slowly.

For the video clock case, its supposed to do a hard re-sync if it gets more thana couple ms out of sync (by fudging the reference clock), and anything below it will try to compensate by changing the playback speed.
I'm not sure yet how this could cause higher sync offsets with madVR.

Hendrik · « **Reply #14 on:** March 05, 2015, 07:20:16 am »

After further investigation into VideoClock, it seems to be working perfectly.
The computed delay is spot on, and I can also see the computed delay difference match up perfectly with the display of the device.

For some reason, madVR just seems to have a 1-2 frame offset in there sometimes.
I reproduced it in all madVR modes, exclusive, overlay, windowed old and new (although it did seem to be more common in the two windowed modes, but that might be a red herring)

At this point, I don't know what could be wrong on our end, the clock behaves perfectly from what I can tell.
If there would be an inherent bug in the clock, it should show up all the time, and also in other renderers, but that is not the case. Its also not entirely wrong, but a perfect multiple of the frame time, which makes me suspicious again..

6233638 · « **Reply #15 on:** March 05, 2015, 07:52:01 am »

Quote from: Hendrik on March 05, 2015, 07:20:16 am

After further investigation into VideoClock, it seems to be working perfectly.
The computed delay is spot on, and I can also see the computed delay difference match up perfectly with the display of the device.

It's good to have that confirmed - VideoClock did seem to produce stable results for me if I left playback alone.
It's just that if I get VideoClock to read 0ms offset and then play another video or seek, it can be ±40ms from that.

Quote from: Hendrik on March 05, 2015, 07:20:16 am

For some reason, madVR just seems to have a 1-2 frame offset in there sometimes.
I reproduced it in all madVR modes, exclusive, overlay, windowed old and new.
At this point, I don't know what could be wrong on our end, the clock behaves perfectly from what I can tell.
If there would be an inherent bug in the clock, it should show up all the time, and also in other renderers, but that is not the case.

Well that's frustrating. Madshi says that he doesn't see where it could be an issue on his end, and you're saying that things look fine on your end. $:-\$

Certainly, 1-2 frames is in the region of variance that I'm seeing as long as VideoClock is enabled.
Is there no way to MC to detect this? (I assume you're just using the latency tester to measure the 1-2 frame offset)

What I can say is that it's definitely not a good idea to enable the "delay playback" options.
I will have to test again it to confirm things (note to self: write everything down so you can refer back to it several days later…) but I think those options combined with a queue size of 128 is what may have been causing the huge ±300ms variance when VideoClock was disabled.
While it was not causing that to happen in MPC-HC, Madshi says the "delay playback" options are a bit of a hack, so I can see why it might behave differently in other players and just won't use those options from now on. (I have done tests with/without those options though)

I have a big list of things that I want to test but I just don't know that I'm going to have an opportunity to do that sort of testing this week.
If I could get it down to ±10ms like you seem to have, that would be absolutely fine. Then the maximum variance is still only half a frame at 24 FPS.

Quote from: Hendrik on March 05, 2015, 07:20:16 am

although it did seem to be more common in the two windowed modes, but that might be a red herring

Interesting. I only use windowed mode, and use the old rendering path there.
Testing all the combinations of exclusive/overlay/windowed was next on my list of things to do.

madshi · « **Reply #16 on:** March 05, 2015, 08:34:07 am »

I'm a bit confused now. Does the problem occur when having VideoClock enabled or disabled? From the doom9 thread it seemed with VideoClock enabled there was no (big) problem, but with it disabled, after a seek there was sometimes a very big desync? If that's the case then why has Hendrik tested with VideoClock enabled? That really confuses me.

And then 6233638's original comment (in the doom9 thread) was that with the "delay playback" option enabled the desync was much less of a problem. And now suddenly it seems to be the opposite?

The "delay playback" option definitely is a hack, but then, I believe madVR still carefully listens to the master clock. So I don't really understand why the "delay playback" option would cause desync. FWIW, technically the "delay playback" option works by hooking and blocking the graph's "IMediaControl::Run()" API. madVR practically "swallows" the Run() call. Then some time later, when all of madVR's queues are full, madVR itself calls "IMediaControl::Run()". This is surely a hacky solution, but it shouldn't screw with the clock, I believe, because the "Run()" call is blocked very early, so no part of the graph should already start running. The clock should only start running once the "IMediaControl::Run()" API is finally fully executed. When that happens, all filters in the graph should be notified by the graph via the IMediaFilter::Run() method, and part of this notification is the "start" time of the reference clock, which madVR then uses to calculate which video frame should be presented at which VSync interrupt:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd406920(v=vs.85).aspx

Is it maybe possible that within MC you're calling the graph's "IMediaControl::Run()" and then you also somehow manually start the audio playback already at the same time, without waiting for the graph to notify your audio renderer about the start? So when the Run() call is delayed, this would effectively delay video playback, but not audio playback? The "bug" would then be that audio playback start would be handled outside of and unconnected to the DirectShow control. Just wildly guessing here, though.

6233638 · « **Reply #17 on:** March 05, 2015, 09:10:27 am »

Quote from: madshi on March 05, 2015, 08:34:07 am

I'm a bit confused now. Does the problem occur when having VideoClock enabled or disabled? From the doom9 thread it seemed with VideoClock enabled there was no (big) problem, but with it disabled, after a seek there was sometimes a very big desync? If that's the case then why has Hendrik tested with VideoClock enabled? That really confuses me.

Sorry, I know this whole thing is a big of a mess. I shouldn't be posting until I have completely certain results. (or as certain as they can be)

Having VideoClock disabled seems to be allowing for those massive desyncs of up to 300ms.
I really need to do more testing to find the specific conditions under which this occurs.
I think the cause was a queue size of 128 combined with the "delay playback" options but I need to collect more data on that. Most of my testing has been done with VideoClock enabled.

When VideoClock is enabled, the maximum sync variance I have seen is 80ms.
I want to clarify things though; when I have been saying that I've been getting up to ±40ms variance after seeking, I've been making a note of the highest/lowest values and what I should have said is that I'm seeing a variable sync somewhere within a range of 80ms.

It doesn't start at 0, and potentially become 400ms after 10 seeks. The worst it ever seems to get with VideoClock enabled is 2 frames out of sync. (about 80ms)

Quote from: madshi on March 05, 2015, 08:34:07 am

And then 6233638's original comment (in the doom9 thread) was that with the "delay playback" option enabled the desync was much less of a problem. And now suddenly it seems to be the opposite?

Prior to purchasing the latency tester, it appeared that enabling the "delay playback" options improved lip-sync.
Now that I have an objective way of testing, that does not seem to be the case.

What was probably happening, is that more times than not, opening the madVR config, enabling the "delay playback" options coincidentally shifted it to a better sync than it had previously been at.

Quote from: madshi on March 05, 2015, 08:34:07 am

The "delay playback" option definitely is a hack, but then, I believe madVR still carefully listens to the master clock. So I don't really understand why the "delay playback" option would cause desync.

The reason that I suspect it might be causing the massive audio desync in MC, is because it does "desync" the controls.

If I go fullscreen with a video and hit pause, I often end up in a state where MC displays a "paused" status, while madVR is still playing the video.
Disabling the delay options prevents this from happening.

madshi · « **Reply #18 on:** March 05, 2015, 09:35:38 am »

IMHO you're testing too many variants at the same time. We're getting loads of data, but no common test ground, so it's nearly impossible to draw any useful conclusions from the data we got.

If I may suggest: Try to isolate the situation where you're getting the biggest / most obvious problem (that 300ms desync). Then let's all test with only this one situation with only this one specific set of settings, and then let's try to find the cause of that one problem. Once it's found and fixed, maybe if we're lucky, all other problems might already be fixed, too. Or if not, let's then look at the next biggest problem that is left then. I'd suggest this "working down from the biggest to the smallest problem" approach because the biggest problem is often also the easiest to reproduce, isolate and fix.

6233638 · « **Reply #19 on:** March 05, 2015, 10:15:35 am »

You're right. I was approaching this from the perspective of trying to find settings that produce good sync.
Rather than trying to find what's causing specific problems, or how to reproduce them.

I'll hold off posting anything more until I have solid information.

Trumpetguy · « **Reply #20 on:** March 05, 2015, 11:37:56 am »

What 6233638 is describing looks very much that same as I have experienced and reported (although in a significantly less scientific and comprehensive way), in these two threads:

Thread for build 20.0.70:
http://yabb.jriver.com/interact/index.php?topic=95567.msg658488#msg658488

Thread for build 20.0.79:
http://yabb.jriver.com/interact/index.php?topic=95888.msg660703#msg660703

So far, it seems that I am stuck with 20.0.66, which at least give reasonable sync when playing bd rips (mkv). I have only started seeing this problem in the later builds, never in previous builds of MC20 or 19 (or 18, for that matter).

Hendrik · « **Reply #21 on:** March 05, 2015, 11:47:47 am »

6233638 is describing a absolute sync offset, you are describing a drift in sync. Those are totally different things.
Considering that sync is generally fine for everyone else, I'm not sure what to tell you.

FWIW, the only thing that ever changed in those versions regarding sync was with resampling, and that part was thoroughly tested, quite scientifically at that, and is now in perfect sync with its actual behavior. Even more so than before.
Previous to those builds, there could be a minimal sync diference between resampling and not resampling, now its exactly the same.

Maybe your sync settings just need updating? Sync may have changed since earlier builds, but only for the better. However if you have old settings, you may need to tweak them to account for our fix.

Trumpetguy · « **Reply #22 on:** March 06, 2015, 03:21:04 am »

Hendrik, the discussion in this thread is way over my head, so I guess you're right

What I thought I read out of the earlier posts was that there were situations where the sync offset (without VideoClock) suddenly was increased to 300ms, then gradually improve. Which is similar to my observations.

However, I'll check for other factors in my end now. First thing is to check my rather old and rather packed hard drives.

mojave · « **Reply #23 on:** March 06, 2015, 10:43:23 am »

I just ordered a Sync-One2.

6233638 · « **Reply #24 on:** March 17, 2015, 07:47:09 am »

Well I was able to get some testing done over the weekend.
Unfortunately, a lot of that was spent chasing down the cause of a delay that I was seeing in the new FSE path, which turned out to be a driver config issue.

Most of my testing was done at 60Hz with VideoClock enabled, and I was able to confirm that most of madVR's output modes behave the same, with the exception being Windowed Overlay.
A lot of this is not new, but simply confirmed what I had been seeing before.
When starting/resuming playback, there is as much as a 2 frame offset for audio sync when VideoClock is enabled. I never saw a variance which exceeded this amount.
This offset is not an exact number (e.g. 17/33ms) but can be anything in the region of 0-33ms.
Very rarely, probably less than 5% of the time, audio can actually be ahead of the video by as much as two frames, but seeking almost always results in audio being delayed again so that is less of a concern.

Overlay mode seems to be the exception here, as the variance almost always seemed to be 1 frame at most, rather than 2.
So that may be a temporary solution until this is resolved, but I really don't like using the overlay mode.
For a number of reasons, I would prefer to be using the old Windowed mode rather than anything else. There is no delay for it to respond to playback controls, it doesn't have to switch in/out of modes when full-screen, and you can alt-tab or take screenshots like any other application. Overlay mode also does things like disable shadows in Windows while it is active.

As for the extremely high latency values I was seeing with VideoClock disabled, well that was just due to me being impatient.
With VideoClock disabled, and using the old Windowed path (as it's my preference) I would often see sync errors >200ms after seeking.
These errors would be stable - but only for about 10 seconds. After 10 seconds it seems to "resync" and then I get a far more reasonable result: an offset of less than 1 frame.
So I'm actually seeing less variance with VideoClock disabled after this "resync" than normal playback with VideoClock enabled.

I don't know how helpful any of this is.
What I'll probably do next is install ReClock and see how using that in MPC-HC compares to MC+VideoClock.

I'd just like to add that it's very frustrating. The best solution I've found for now is to play the sync video, keep track of the offset over something like 50 different seeks so that I have an idea of where exactly the boundaries of this 2 frame offset are (since I'm now sure that it is always going to be 33/83ms at most) and then add a correction so that the audio is never early; but often 1-2 frames late.

As long as the audio is never early, it's a lot more difficult to notice sync errors when just watching a video.
It's better that the audio be 1-2 frames late, than trying to set it so that the average is 0ms for example. But that is obviously far from ideal, especially at 24Hz.

madshi · « **Reply #25 on:** March 17, 2015, 09:21:41 am »

Good to hear the max desync is no more than 2 frames, but of course it would be much better to always have exactly the same AV sync offset. I think testing with a different media player is a good idea. If the same issue occurs there, too, then that might point to MC being innocent. Since you found no big difference between all the various madVR rendering modes (except Overlay), I'd suggest from now on to concentrate on one specific madVR rendering mode. That should reduce the number of tests you need to do.

6233638 · « **Reply #26 on:** March 17, 2015, 09:35:45 am »

Quote from: madshi on March 17, 2015, 09:21:41 am

Good to hear the max desync is no more than 2 frames, but of course it would be much better to always have exactly the same AV sync offset.

Well it looks like there have been changes in the latest build of MC, so I'll report back on whether that has improved things.
I'm not sure that I'll be able to do in-depth testing until the weekend again.

Quote from: madshi on March 17, 2015, 09:21:41 am

Since you found no big difference between all the various madVR rendering modes (except Overlay), I'd suggest from now on to concentrate on one specific madVR rendering mode. That should reduce the number of tests you need to do.

Yes, that was why I did all that testing - I wanted to see if there was any variance between the various display modes, to see whether the issue was restricted to one of them or if all were affected equally.

Trumpetguy · « **Reply #27 on:** March 22, 2015, 12:06:03 pm »

Quote from: Hendrik on March 05, 2015, 11:47:47 am

6233638 is describing a absolute sync offset, you are describing a drift in sync. Those are totally different things.
Considering that sync is generally fine for everyone else, I'm not sure what to tell you.

FWIW, the only thing that ever changed in those versions regarding sync was with resampling, and that part was thoroughly tested, quite scientifically at that, and is now in perfect sync with its actual behavior. Even more so than before.
Previous to those builds, there could be a minimal sync diference between resampling and not resampling, now its exactly the same.

Maybe your sync settings just need updating? Sync may have changed since earlier builds, but only for the better. However if you have old settings, you may need to tweak them to account for our fix.

After some time outside my HT, I managed to test this yesterday. And you are right, it is the static offset that has changed during the past weeks. For some reason. And it is different with RO and ROHQ. With ROHQ I changed the audio delay from 0 (which it has been for the past few years) to 35ms and got a very good and stable sync.

However, the clock deviation reported on screen by MadVR does change intermittently. It starts at about 0.5% and drifts down to <0.001%, then suddenly jumps up again. Now, I thought this was linked to perceived a/v sync, but it seems not to be. It seemed (for one movie, at least) that the 35ms static offset (24Hz display) did the trick.

6233638 · « **Reply #28 on:** March 22, 2015, 12:13:58 pm »

The clock deviation is the difference between the refresh rate of the display and the framerate of the video.
I could be wrong, but I don't think it should have any impact on audio sync as long as you are using VideoClock and have let it settle.

If 0ms was the "correct" value and you're seeing the same 1-2 frame variance at 24Hz, you should offset it by 42ms rather than 35. (1000 ÷ 24 = 41.66..)

But until we can get to the root of what's causing this 1-2 frame offset, it will never be correct.
And I have not had the opportunity to check the sync in other applications this weekend yet.

kstuart · « **Reply #29 on:** March 22, 2015, 03:23:00 pm »

I always use SP/DIF to external decoder when viewing Video, so I assume that my situation is always equivalent to your "Videoclock OFF" measurements (even thought I do use HQ/madVR) ?

Trumpetguy · « **Reply #30 on:** March 22, 2015, 04:19:48 pm »

Quote from: 6233638 on March 22, 2015, 12:13:58 pm

The clock deviation is the difference between the refresh rate of the display and the framerate of the video.
I could be wrong, but I don't think it should have any impact on audio sync as long as you are using VideoClock and have let it settle.

If 0ms was the "correct" value and you're seeing the same 1-2 frame variance at 24Hz, you should offset it by 42ms rather than 35. (1000 ÷ 24 = 41.66..)

But until we can get to the root of what's causing this 1-2 frame offset, it will never be correct.
And I have not had the opportunity to check the sync in other applications this weekend yet.

I never use VideoClock. A long time ago I concluded that 15 paths convolution and videoclock was not a good combination. I don't really understand whether it is a theoretically possible combination or not. But that is rather OT.

I'll give 42 a try. After all, 42, the rumor says, is the ultimate answer to life, the universe and everything.

kstuart · « **Reply #31 on:** March 22, 2015, 06:11:08 pm »

What is 6 times 9 ?

mojave · « **Reply #32 on:** May 26, 2015, 08:56:00 am »

I used the Sync-One2 on Saturday to set the lipsync in a home theater. With Videoclock and 22 channels of convolution, the lipsync varied by as much as +/- 70 ms and I could never get it to stabilize. As soon as I turned Videoclock off, the lipsync was stable.

Hendrik · « **Reply #33 on:** May 26, 2015, 09:04:41 am »

Quote from: mojave on May 26, 2015, 08:56:00 am

I used the Sync-One2 on Saturday to set the lipsync in a home theater. With Videoclock and 22 channels of convolution, the lipsync varied by as much as +/- 70 ms and I could never get it to stabilize. As soon as I turned Videoclock off, the lipsync was stable.

It may be stable momentarily, but drift apart if audio and video clock don't match perfectly.
I've not had any luck trying to figure out what might be wrong, but combined with the fact that EVR didn't seem to drift much, I'm still not sure if there isn't just a bad reaction between the clock adjustments being done and madVR somewhere.

6233638 · « **Reply #34 on:** May 26, 2015, 10:30:12 am »

I have been meaning to revisit this, especially with the latest version of madVR, but that's disappointing to hear.

mojave · « **Reply #35 on:** May 26, 2015, 02:39:59 pm »

Hendrik, your post today on AVS made me wonder if switching back to using JRiver's display mode switching instead of madVR's will make any difference.

flac.rules · « **Reply #36 on:** May 26, 2015, 03:17:54 pm »

Great work 633638, I really hope you guys can get to the bottom of this, it is quite noticable, and in the "core functionality" of the program

6233638 · « **Reply #37 on:** May 26, 2015, 03:44:16 pm »

Quote from: mojave on May 26, 2015, 02:39:59 pm

Hendrik, your post today on AVS made me wonder if switching back to using JRiver's display mode switching instead of madVR's will make any difference.

I suppose it's worth testing, though using MC's switcher is not an option for me since it is unaware of whether madVR is performing IVTC and whether certain content should be presented at 24/60Hz or 25/50Hz since it switches based on the framerate of the file rather than the deinterlaced output.
There's no way to tag files to output a specific refresh rate in MC either.

Hendrik · « **Reply #38 on:** May 26, 2015, 03:44:52 pm »

Quote from: 6233638 on May 26, 2015, 03:44:16 pm

There's no way to tag files to output a specific refresh rate in MC either.

Edit the FPS field.

Results are likely to be "cleaner" with MCs switcher, since it will switch before even starting to assemble the playback chain, while madVR can obviously only switch after everythign is setup - including the audio renderer and its refresh rate-based algorithm.
For a proper test, this whole factor should be eliminated and no refresh rate switching be performed.

6233638 · « **Reply #39 on:** May 26, 2015, 03:59:54 pm »

That doesn't really work for me because I have views which sort by FPS and I need to know the source FPS in the file.
If I'm looking specifically for a PAL DVD or an NTSC DVD I need to know what the source framerate is, rather than both being listed as "24 FPS".

MC's switcher seems to change the refresh rate as soon as a video starts playing, rather than only switching when entering full-screen mode.
The desktop is unusable at 24Hz, which means that I can't use MC's switcher.

And it's still unaware of IVTC so when I hit a shortcut to change a video between video/film mode deinterlacing, the refresh rate does not change.
That way I would have to test every video and manually tag them before playback, instead of just being able to hit a key while the video is playing.

Hendrik · « **Reply #40 on:** May 26, 2015, 04:03:43 pm »

You can't have everything, either you get a clean read of the screen refresh by switching it before playback, or you do it later and potentially confuse its algorithm with a change. If you are testing a sync offset, don't use the second.

PS:
You asked for a way, i gave you a way. I cannot help it that its inconvenient for you.

6233638 · « **Reply #41 on:** May 26, 2015, 04:52:29 pm »

I thought VideoClock got the refresh rate directly from madVR?
Surely it will be able to detect when the refresh rate has changed (i.e. 60→50 or 60→24, rather than a gradual drift of say 60±0.5Hz) and "reset" its calculation?

If you have to specify that the framerate of a video is something other than what it really is, that seems like a hacked workaround than a proper solution - especially when knowing the true framerate of the file can be important.

When I next get a chance to test the AV Sync (I have been meaning to check it again with the DX11 presentation path) I'll see if it makes a difference to use the MC switcher, but if you have been using it all this time anyway it seems unlikely to matter.

Hendrik · « **Reply #42 on:** May 27, 2015, 06:29:29 am »

I've been testing AV sync again this morning to test an idea I had, but I couldn't really reproduce any big issues anymore (usually < 10ms offset, which i consider pretty good). Especially after playing for half a minute or so, the sync would slowly get better, and eventually settle.
I did update my madVR to 0.88 though and have been using the D3D11 path. I only tested on my desktop PC though which cannot do 24Hz properly for testing though.

I didn't plan for enough time to re-test every combination to figure out if madVR 0.88 in general or maybe just D3D11 works better, so I'm just leaving this here for the time being.

PS:
madVR isn't perfect when playing content on mis-matched rates, so if possible at all, testing should use a matching rate (FPS==Hz) at all times, or at the very least integer multiples (30/60, 25/50, etc).

PPS:
Thinking about it some, it may actually help a bit if you move the Tempo/Pitch DSP to be the last active DSP in the chain, at least after any other DSP which introduce a processing delay, like convolution or room correction.
If someone could confirm this does help for them, i may adjust the default DSP order as well.

Delay calculation gets quite complex when in the middle of the DSP chain the "length" of the audio is adjusted through speedup/slowdown.

6233638 · « **Reply #43 on:** May 27, 2015, 10:51:44 am »

Quote from: Hendrik on May 27, 2015, 06:29:29 am

Thinking about it some, it may actually help a bit if you move the Tempo/Pitch DSP to be the last active DSP in the chain, at least after any other DSP which introduce a processing delay, like convolution or room correction.
If someone could confirm this does help for them, i may adjust the default DSP order as well.

Delay calculation gets quite complex when in the middle of the DSP chain the "length" of the audio is adjusted through speedup/slowdown.

Hmm, that is a good point.
Unfortunately though, dithering must be performed as the last stage in processing, and Voxengo Elephant adds something in the region of 25-30ms if I recall correctly.
I can use another plug-in which dithers stereo content in <1ms but for multichannel content I haven't found anything other than Elephant.
Of course if Media Center's own dither was fixed, it would eliminate the need to use an external plug-in for this.

I'm not convinced that other VST Plug-Ins like Redline Monitor are such a good idea before the tempo/pitch DSP either, but that is <1ms so it shouldn't matter.
Same thing for convolution really. Doesn't altering the tempo/pitch invalidate the filter?

That said, I'm pretty sure that I disabled all my plug-ins when testing before, but it's worth a look at.

Hendrik · « **Reply #44 on:** May 27, 2015, 11:10:18 am »

A small 20-30ms delay isn't going to make a difference, because even with a 5% variance for PAL processing it would only make a 1-2ms difference in the end result.
However, convolution can have significant latency, which would be noticeable.

kstuart · « **Reply #45 on:** May 27, 2015, 11:19:43 pm »

Does using D3D11 with madVR change the "performance" - i.e. GPU and/or CPU use ?

kalston · « **Reply #46 on:** May 28, 2015, 01:26:14 am »

Quote from: 6233638 on May 27, 2015, 10:51:44 am

Hmm, that is a good point.
Unfortunately though, dithering must be performed as the last stage in processing, and Voxengo Elephant adds something in the region of 25-30ms if I recall correctly.
I can use another plug-in which dithers stereo content in <1ms but for multichannel content I haven't found anything other than Elephant.
Of course if Media Center's own dither was fixed, it would eliminate the need to use an external plug-in for this.

I'm not convinced that other VST Plug-Ins like Redline Monitor are such a good idea before the tempo/pitch DSP either, but that is <1ms so it shouldn't matter.
Same thing for convolution really. Doesn't altering the tempo/pitch invalidate the filter?

That said, I'm pretty sure that I disabled all my plug-ins when testing before, but it's worth a look at.

Have you tried the TB Dither VST http://www.toneboosters.com/tb-dither/? I'm pretty sure it has a very low latency. (Only limitation of the trial version is that the settings are not saved when you close the player, so it's worth a try)

I haven't had any AV sync issue lately (I would say ever since the MC changes) and I did have some before but I'm not sure if it's following MC or madVR changes (or both).

6233638 · « **Reply #47 on:** May 28, 2015, 11:03:47 am »

Quote from: kalston on May 28, 2015, 01:26:14 am

Have you tried the TB Dither VST http://www.toneboosters.com/tb-dither/? I'm pretty sure it has a very low latency. (Only limitation of the trial version is that the settings are not saved when you close the player, so it's worth a try)

I have tried it - i seem to recall that it only works on 2 channels and not 6/8.
Or if it wasn't that (I think that's what the issue was) there was some other issue that caused me to stick with another plug-in.

flac.rules · « **Reply #48 on:** May 28, 2015, 11:56:33 am »

Would it be possible to have some latency-testing-function inbuilt in the program? Like the "audio-path", that measures latency on the different steps?

Hendrik · « **Reply #49 on:** May 28, 2015, 11:59:35 am »

Quote from: Elvis133 on May 28, 2015, 11:56:33 am

Would it be possible to have some latency-testing-function inbuilt in the program? Like the "audio-path", that measures latency on the different steps?

Latency of the internal processing is largely irrelevant (unless you use the WDM driver or similar things, in which case you want to disable anything to get close to zero latency), so i'm not sure I see the point?

INTERACT FORUM

Author Topic: AV Sync - inconsistent results (Read 13273 times)