Originally Posted by pankwindu
Ok, I have to try very hard to be polite here, as my frustration level is exceedingly high. I too am suffering from audio sync on The Matrix, using the 360 addon.
I am sorry about your frustration. My Sony CRT TV loses sync and drifts by up to a second also and I have to toggle its inputs to get it to sync again. So I have firsthand experience with what you are feeling.
Can you please please PLEASE confirm whether this is a player problem or an authoring problem, or both? Here are some very prominent test scenes for your engineers to verify the issue
Thanks for providing the specifics. I asked the team to try to duplicate your experience and they simply cannot -- certainly nothing remotely close to level that aggravated you. Let me explain a bit more why this is a hairy problem to troubleshoot.
The system you use is really not designed to provide perfect A/V sync. Yes, you read that right. Neither format is designed for 100% sync! They are designed for acceptable level of sync, not a precise one. Here is the problem in a nutshell. You have a digital video system and digital audio system. Like any other digital system, you have to have a reference clock that determines when you should put out a sample (or one bit out of the sample in case of serial connections). Unfortunately, there is no prefect reference in life. Even crystal oscillators drift with time and temperature. And this happens both at creation side and decode! In professional settings, we slave one clock to the other and the entire plant is run that way to assure good sync. Obviously, we can't string wires from the studio to your house
. So that solution is out.
How does one solve this problem then? First part is in the multiplexing tool where the video and audio streams are spliced together and later put on disc. The tool must figure out if an audio sample (or packet) is given to it does not match the timestamp of the video at the same time, what on earth it is supposed to do with it. Resample audio to slow or speed it up? Ignore the timing difference because the difference is small? Move some packets forward/back in time artificially? For these reasons, we call mux'ing the stream when it comes to A/V sync something of a black art. That is, there are situations where there is no palatable answer and as such, you have to figure out what to do that passes the A/V expectations of the user, even though it may not be correct from mathematical point of view.
Then we get into the player where the same problem manifests itself and then additional goop gets piled on top of it. Here again, we have the same two clocks running out of sync yet again (which may differ depending on which output you use on your player!). The player will attempt to align audio/video samples based on how fast they are being drained out of the buffer (i.e. clocked out of the machine). It is faced with the same tough choice of what to do as they drift apart. Note that any sync anomalies here are potentially additive wrt to how much was there in the encode chain.
Then we have video processors which feel completely justified in delaying video on a variable basis, depending on what they are being fed (i.e. they sometimes buffer video to process it, other times they do not). Their assumption is that some amount of delay here will not be noticed by you. Which is a fine assumption until during the same passage, you could already be at the hair edge of having sync be noticeable due to other reasons and then you have an ugly situation. Put another way, the processor may be perfectly fine by itself, but not when cascaded in a real system with other components which have their own variability.
Personally, I have seen sync issues in all of these formats. Sometimes the problem can be quite tricky. My Panasonic BD player for example, drifts in one chapter of a movie I have (I think it is Tears of the Sun) and goes off close to half a second. But if you skip back and then play again, it will reproduce sometimes! Imagine engineers trying to figure that one out, when they had no hand in making the equipment or the mux.
And on a more philosophical note, to any insider in any relevant capacity, can we get the whole general issue of audio sync bumped up a few notches in priority wherever it needs to be?
I am with you on this. Unfortunately, we don't write a mux tool for these systems so our ability to influence that item is limited unless we get a clear test case. As people have noted, we fixed quite a few sync issues that were in our ability fix/compensate for. Unless there is clear test case for problems in our code, I am not sure there is more we can do. But I certainly will advocate working harder if that is what you are asking
Even if someone could just decide to make it a standard requirement in every player/processor to allow the user to add a configurable delay to either the audio and video as necessary, after all other processing in the decoding path, so that at least as a last resort the user could correct for the apparently inevitable continuing problems?
That would be easy to do in this day and age but does not address the real problem people have, namely, dynamic sync issues where the amount of delay changes. Certainly does not address my problem with the Sony TV or the Panasonic BD player I mentioned
BTW, the above topics are quite complex and I will not attempt to drill into them further. Last time I did, I lost a few people and folks got quite aggrevated