HTPC: NUC vs. DQ77KB/i3-3225 (sorry, lang)

[0xdeadbeef]

Zum einen hat das NUC mit Gigabit-Ethernet (also meins) zwei HDMI-Ausgänge, zum anderen schleift das das von mir genannte Gerät nach meinem Verständnis das HMDI-Signal durch. Wobei noch dahingestellt sei, was Nordhesse genau machen will. Bei verschlüsselten Blu-Rays dürfte das sowieso nicht funktionieren. Dann wäre es aber eh mal Zeit für einen AV-Receiver.

Und warum sollte das "Java drumrum" eine Abweichung (von was auch immer) produzieren? Das Programm schaltet auf die angegebene Auflösung und Frequenz und mißt dann mit dem bestmöglichen Zeitauflösung die Zeit zwischen zwei VSyncs aus. Solche Messungen sind natürlich bei präemptiven Multitasking (egal in welcher Programmiersprache) nicht sonderlich genau, aber die Mittelwertbildung gleicht das hinreichend aus. Wo soll denn da bitte ein Unterschied zur "offiziellen" Meßmethode sein?

Nebenbei bemerkt sind Messungen von exakten 23.976 über einen PC ohnehin unrealistisch, weil normale Quarze nur eine Genauigkeit um die 50ppm haben. Selbst bezahlbare Oszis haben keine wesentlich höhere Genauigkeit. Alles zwischen 23.975 und 23.977 darf man also guten Gewissens als 23.976 annehmen.
Ehrlich gesagt frage ich mich ohnehin, ob die ganze Theorie von Mikrorucklern wegen einer leicht falschen Frequenz nicht sowieso Unsinn ist und auf der falschen Vorstellung von superexakten Frequenzen basiert. Wenn man das zuende denkt, könnte kein DVD- oder BD-Player der Welt eine zweistündigen Film ohne mindestens 8 ausgelassene oder verdoppelte Frames abspielen. Hat denn wirklich irgendjemand mal diese Ruckler alle 5 Minuten gesehen, oder ist das alles reine Theorie?

 

[omnium]

Ehrlich gesagt frage ich mich ohnehin, ob die ganze Theorie von Mikrorucklern wegen einer leicht falschen Frequenz nicht sowieso Unsinn ist und auf der falschen Vorstellung von superexakten Frequenzen basiert. Wenn man das zuende denkt, könnte kein DVD- oder BD-Player der Welt eine zweistündigen Film ohne mindestens 8 ausgelassene oder verdoppelte Frames abspielen. Hat denn wirklich irgendjemand mal diese Ruckler alle 5 Minuten gesehen, oder ist das alles reine Theorie?

you made my day!

 

[0xdeadbeef]

Obwohl das etwas offtopic ist, noch mal eine kleine Beispielrechnung: wenn Intels HD-Grafikkarten 23.973 statt 23.976Hz ausgeben, ergibt das eine Abweichung von ca. 5µs pro Frame:

(1/23.973 - 1/23.976) = 0.0000052194187263 -> ca. 5.219 µs​

Auf einen Frame hochgerechnet sind es etwa 125µs Abweichung pro Sekunde -> 125ppm:

23.976*(1/23.973 - 1/23.976) = 0.0001251407833813 -> ca. 125 µs​

Hochgerechnet auf einen zweistündigen Film ist das eine Abweichung von ca. 0.9 Sekunden:

23.976*(1/23.973 - 1/23.976)*2*60*60 = 0.9010136403453886​

Wer sagt also, daß ein 2h-Film mit einer Intel-Grafikkarte nicht einfach 0.9 Sekunden länger dauert? Die minimale Änderung der Abspielgeschwindigkeit und damit auch der Tonhöhe wäre vollkommen unwahrnehmbar und eine Abweichung von 125ppm ist im industriellen Einsatz durchaus normal. Das sind Abweichungen, die selbst für asynchrone serielle Protokolle völlig unproblematisch sind.

Warum sollte ein HDMI-Receiver bzw. ein TV/Beamer sich nicht (natürlich in einem gewissen Rahmen) auf die Frequenz der Quelle synchronisieren? Genau das haben VGA-Monitore auch gemacht und warum soll das bloß wegen digitaler Übertragung plötzlich anders sein?

 

[RobertDD]

Du hast den Thread aber schon gelesen, oder?

Ja habe ich.
Ich hatte mich damit auf deine aussage hier bezogen.

Den 24p-Test wollte ich eigentlich machen, aber auf die Schnelle war/ist mir das Testprozedere zu kompliziert und ich habe leichte Bedenken, ein gut funktionierendes System mit Codecs und Splittern zu versauen. Gibt's da zufällig ein weniger "intrusives" Tool, das nur die Wiederholfrequenz ausmißt und sonst nichts?
Wobei, ganz ehrlich: es ist halt ein HD4000, also wird das NUC die 23.976Hz wohl auch nicht exakt schaffen. Aber wie gesagt: mir ist bei MiB3 beim besten Willen nichts aufgefallen und das ist ja eher ein Film mit viel Dynamik. Habe jetzt aber auch keine übertriebene Lust, mir zwanzig Minuten irgendwelche Pendel anzusehen.

 

[0xdeadbeef]

Nur hatte ich das Ergebnis der Messung genau in dem Posting vor Deinem bereits genannt. Und einen Link auf die MPC-HC/MadVR-Testmethode hatte sandreas schon gestern morgen gepostet - wenn es denn überhaupt nötig gewesen wäre.
Aber wie auch immer. Das NUC gibt wie alle PCs mit Intel-HD-Grafik 23.973 statt 23.976 Hertz aus, wenn man 23p einstellt. Ob das allerdings zu dem postulierten Ruckeln alle 5 Minuten führt, sei mal dahingestellt.

 

[nuts]

Naja du hast das Thema doch gar nicht verstanden.
Wenn der Encoder einen Zeitstempel von ~23,976 ausgibt und die Inteluhr @23,972x läuft hat das welche Folgen? Wenn man bedenkt, dass man bei der bitstream Ausgabe (Ton) die Abspielgeschwindigkeit nicht (!) ändern kann?

 

[0xdeadbeef]

Na ein Glück haben wir mit Dir einen HDMI-Experten gefunden, der mir das erklärt hat.
Allerdings ist der Zeitstempel (CTS) im HDMI-Signal vom Videotakt der Quelle abgeleitet. Heißt deshalb ja auch Cycle Time Stamp.
Da das Audiosignal in die Frames eingebettet wird, der Audiotakt auf Empfängerseite aus dem Videotakt rekonstruiert wird und auch die Zeitstempel in Zyklen des Videotaktes angegeben sind, erscheint es relativ naheliegend, daß ein Frequenzabweichung im Videotakt bzw. der Wiederholfrequenz zu einer Frequenzänderung im Audiosignal führt.

Wobei ich nicht behaupte, daß das meine Vermutung zwingend richtig muß. Dazu stecke ich nicht tief genug in der Materie drin und es gibt zu viele Unklarheiten bezüglich der Detailimplementierung.
Genau die gleichen Gründe sprechen aber auch dagegen, die Mikroruckler-Theorie als zwingende Wahrheit dazustellen. Alles, was ich dazu gelesen habe, basiert auf Mutmaßungen und geht überhaupt nicht auf das HDMI-Protokoll ein.

 

[nuts]

Hdmi hat damit nichts zu tun.

 

[0xdeadbeef]

Na dann ist ja alles klar. Hauptsache ich hab's nicht verstanden.
Aber da das mit dem NUC eh nicht mehr wirklich zu tun hat, belassen wir es dabei.
Zumindest in diesem Thread.

 

[nuts]

So nun etwas ausführlicher:

Der Encoder verpasst dem Mediafile einen Zeitstempel von ~23,976hz.
So liegt die Quelle nun vor und man muss damit umgehen.

Nun gelten ein paar Spielregeln bei der Wiedergabe:
1. Die Abspielgeschwindigkeit für die Audiowiedergabe kann wenn überhaupt nur geringfügig geändert werden.
2. Die Videowiedergabe muss synchron zum VSync sein
3. A/V Sync sollte erhalten bleiben
4. Um Punkt 1 und Punkt 3 zu ermöglichen richtet sich die Videoclock (Referenz für den Renderer) meistens nach dem Zeitstempel im Mediafile (entspricht der Audioclock).

Liegt der VSync nun nicht genau bei der Videoclock werden irgendwann Frames verworfen oder wiederholt.
Das resultiert dann in mehr oder weniger sichtbare Ruckler - abhänfig von der Szene im Film und auch vom Sync-Algo im Renderer.
Bei 23,976 Quellen passiert das bei Intel im Minutentakt, bei AMD (wenn überhaupt) im hohen Stundenbereich.

Damit hätten wir das Basisproblem. Also was tun?
Es gibt Audiorenderer bzw. Zusatzprogramme wie z.B. Reclock, die eine geringfügige Änderung der Abspielgeschwindigkeit bewirken können.
Dabei wird die Abspielgeschwindigkeit zum VSync synchronisiert und es gibt keine Ruckler, A/V perfekt synchron und alles ist super.
Das funktioniert natürlich auch mit Intel und wurde nie bestritten.
Nachteil: Der Ton muss für die Anpassung dekodiert werden, d.h. es ist keine bitstream Ausgabe mehr möglich. Viele stört das (mich z.B.) ...

Alternativ könnte man stur zum VSync rendern und den Bezug zur Audioclock einfach ignorieren.
Dann dauert der Film wirklich etwas länger/kürzer und es ruckelt auch nichts.
Nachteil: Audio und Video laufen zwangsläufig auseinander.
Das ist imho eine sehr unschöne Lösung und ich kenne keine Anwendung / Renderer die das so macht.

Die Königslösung wäre den VSync adaptiv zur Audioclock zu ändern. Dazu gab es mal versuche mpc-hc EVR Sync Renderer (Ansatz über powerstrip), aber meist hat man wenig Zugriff auf die entsprechenden GPU-Funktionen. Powerstrip unterstützt hauptsächlich ATI/AMD Karten.
Das hat auch seine Grenzen, wäre aber z.B. für Streamingumgebungen interessant.


P.S. Da Programmierkenntnisse vorhanden sind kannst du dir gerne mal die Quellecode von mpc-hc bezüglich der Renderer (EVR Custom, EVR Sync) anschauen.

 

[0xdeadbeef]

Mag ja sein, daß das MPC-HC so macht, aber das ist sicher nicht die einzig mögliche Lösung. Und da ich MPC-HC nicht benutze, tangiert mich die Implementierung nicht wirklich. Daß ein Auseinanderdriften beim "sturen" Ansatz zwangsläufig passiert, halte ich auch nicht für gottgegeben. Es kommt eben auf die Implementierung an.

 

[nuts]

Daß ein Auseinanderdriften beim "sturen" Ansatz zwangsläufig passiert, halte ich auch nicht für gottgegeben.

Ist auch nicht gottgegeben sondern mathematisch nachweisbar. Zaubern kann niemand.

VSync = 23,972 => Videoclock = 23,972
Audioclock = 23,976 (abgeleitet vom zeitstempel)

Ausweg: Audio-Abspielgeschwindigkeit anpassen (wie oben beschrieben) oder Audiopakete verwerfen (das ist übrigens hörbar).

 

[0xdeadbeef]

Wie gesagt: rein theoretisch muß der Player nur 1:1 die undekodierten Audiodaten für einen 23.976Hz-Frame in den entsprechenden HDMI-Frame packen, auch wenn der dann in der Praxis ein paar Mikrosekunden zu lang oder zu kurz ist. Weil der Empfänger sein Taktsignal aus dem HDMI-Takt ableitet, passiert die leichte Frequenzabsenkung ganz von alleine, ohne daß der Player das aktiv machen müßte.

Mit der Methode von MPC-HC wird man dagegen praktisch in jedem Fall ein paar Frames verlieren oder verdoppeln, weil die Quarzgenauigkeit des PCs nicht reicht, um über zwei Stunden auf die Millisekunde genau zu sein (Größenordnung eher: +/- 360ms).

Aber wie auch immer: habe heute wieder einen Film (mit PowerDVD 12) gesehen und wieder nicht den Hauch eines Ruckelns bemerkt. So gesehen ist mir das Thema eigentlich sowieso relativ schnurz.

 

[0xdeadbeef]

Nicht, daß es jemanden interessiert, aber ich habe mein kleines Java-Tool (siehe weiter vorne im Thread) zur Messung der realen Bildwiederholfrequenz nochmal ein bißchen überarbeitet.
Die Threapriorität wird jetzt hochgesetzt, um Ausreißer in der Messung zu verkleinern, die Mittelwertberechnung wird jetzt für längere Meßdauer immer stabiler, außerdem scrollen jetzt am oberen Bildschirmrand Reihen von Rechtecken mit 1, 2 und 4 Pixel pro Frame durch, um einen eventuellen Pulldown in der Kette besser erkennen zu können. Und für den Fall, daß wirklich jemand mit einer Fotodiode o.ä. extern nachmessen will, kann man per Kommandozeilenparameter oder per Taste "b" zur Laufzeit am unteren Bildschirmrand einen Flimmerbalken aktivieren, der bei jedem Frame zwischen Schwarz und Weiß umschaltet. Photosensible Menschen und Epileptiker sollten sich das aber nicht ohne Not bei <60Hz antun.
Ändert aber alles nichts daran, daß mein NUC im Rahmen der Meßungenauigkeit 23.973Hz ausgibt.