Win Intel HTPCs/NUCs & Kodi-native 3D MVC Playback
(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.
Thread Rating:
  • 10 Vote(s) - 4.3 Average

Messages In This Thread
RE: Intel-specific HTPC/NUC selection w/reliable MVC 3D ISO - by noggin - 2016-04-13, 22:38
What about xvYCC / x.v.Color - by ma9ick - 2016-04-15, 14:01
June 30 download link broken? - by CooperCGN - 2016-08-02, 08:18