2016-04-13, 22:38
(2016-04-11, 22:37)wizziwig Wrote:(2016-04-11, 19:04)wesk05 Wrote: I have actually tested it on nVIDIA SHIELD and Pi2. I think most of it is inherent to Kodi and also system (AVR, display) specific. SHIELD was interesting in that over time (~1 min) the error got corrected by itself. Pi2 also had ~140ms error (bitstreamed and decoded audio).
I do want to mention here that the numbers that I have posted are not absolute. They are specific to my system. I did the tests only to check the variation between different Kodi builds.
How does your test device actually work? It's not clear from their website. I assume it times the delay between a sound coming out of your speakers and a strobe/flash of light coming out of your display? Most displays have an inherent lag to begin with - LCD because of pixel response or video processing.
When you look at the 'o' codec info, is there a delay displayed there? Some OpenElec builds had a very high default delay of 175ms as discussed here.
It's been a long time since I've done any testing but when i removed that 175ms delay, I saw no significant difference on my Chromebox vs. a stand-alone BD player. My method of comparison rules out any issues coming from Display or AVR delay. I simply captured the HDMI output of each player and then compared them in an editor where I could see the video and matching audio data for each frame. For reference, I also decoded the original file on a PC and extracted perfectly synced video and audio tracks. The HDMI output was within 1 frame of reference. This was for a single 24p AC3 bitstreamed test file. Can't guarantee all other files and formats were equally in-sync.
I keep meaning to do this with VALID. I'd need to ingest a VALID test clip in FCP or Avid and trust that the Kona capture cards we use don't do anything nasty (the audio will come in embedded in the HD-SDI) If I then play out the recording via HDMI at 1080i25 (or possibly 720p50) and assuming our HDMI to HD-SDI converters only add a small delay (and I don't route through a synchroniser) I could get a basic VALID answer (ignoring AC3) for PCM stereo.
(VALID is a neat test signal that allows for accurate A/V sync delay to be measured. It's a modified colour bar test signal accompanied by an audio signal. You then feed that into a VALID analyser and it displays the A/V relative delays/errors. It's a system broadcasters use to check their systems for A/V errors, and to ensure remote sources are in-sync, among other things.)
There is a separate system for checking monitor delays - which are a separate matter.