HTPC auf Ivy Bridge Basis

[CiNcH]

OK, funktioniert jetzt. Ich muss den Onboard RealTek-Chip einschalten. Scheinbar läuft HDMI-Audio auch darüber...

[CiNcH]

OK, funktioniert jetzt. Ich muss den Onboard RealTek-Chip einschalten. Scheinbar läuft HDMI-Audio auch darüber...

Ein gemeinsamer Oszillator für Video und Audio dürfte somit gegessen sein.

[craig_s]

Hey CiNcH, ich schliesse mich Tüftlers Worten an, deine Ausführungen sind hochgradig lehrreich und inspirierend! Und schon immer gewesen.

Lass dich bloss nicht vom Wege abbringen, auch wenn ich manchmal rumfrozzel:

 

Ein gemeinsamer Oszillator für Video und Audio dürfte somit gegessen sein.

Alter Pessimist! Erst mal probieren nich waa..

 

Habe Jahrelang Video über HDMI (Ati) und Audio über SPDIF (Realtek) im Homecinema gehabt ohne jede Audiodrift.

Dann alles über HDMI (Ati) auch keine Audiodrift.

Jetzt auch alles über Intel HDMI auch keine Audiodrift - auch im Intel-Laptop gibts nen 2. Audiochip (IDT) der selbstverständlich seinen Treiber braucht.

 

Hab ne ganze Weile gebraucht um dahinter zu kommen, die mysteriöse Audiodrift die die AVS HTPC Leute öfter anprangern kommt von etwas das die immer als selbstverständlich voraussetzen und daher selten erwähnen: in USA und Rest der Welt? wollen die immer das ein HTPC so bunt aussieht wie ein Mediaplayer. Und auch nur mit Fernbedienung bedienbar. Nur dann darf es sich HTPC nennen. Für mich ein Greuel bzw. interessiert mich nicht, ich hab nur PCs die auch gut MM abspielen können.

 

Langer Rede kurzer Sinn, die ham alle irgend so'n XBMC oder wie hiess das andere, Jriver? am laufen oder sonstige komische MM-Oberflächen. Damit bekommen sie offenbar öfter die Audiodrift weil immer wenn ich nachhakte kam sowas dabei raus. Also mit "stinknormalem" Windows-Desktop krieg ich keine Audiodrift gebacken

 

 

Folgendes Review hat mich zum Testen veranlasst... klick (mit 30i MPEG-2 habe ich allerdings eher weniger am Hut)

Habe jetzt 2 Tage getestet und es stimmt schon, madVR kann gut überlasten aber nur beim Skalieren, hoch oder runter egal.

Bei skaliertem HD-Material geht die GPU gerne über 80% rauf, dann fängt das Ruckeln an. Kommt auch auf einige Settings innerhalb madVR an. Meine vorigen Tests kamen alle ohne Skalieren aus, da läuft es auch mit Lanczos/Spline 4 problemlos. Selbst mit zusätzlich ReClock. Einzelheiten würden ne ganze Seite füllen, ist mir jetzt zu mühsam und wär ja auch nur für die HD3000..

 

Auch weil das Quali-Erlebnis einfach nicht erscheinen will, habe sogar auwändigst mit Screenshot-Überlagerung der gleichen Frames gearbeitet (der kochende madVR vs. allerlei "unwürdige" 13 Watt Rederer) nur so hat man eine Chance feine Unterschiede zu sehen, auch mit versch. Monitoren verglichen,

-> die Unterschiede sind so minimal das man sie wirklich einfach vergessen kann. Lohnt sich nichtmal das hochzuladen.

 

Was mir immer öfter Kopfschütteln verursacht - die Szene, ja die Jünger/Sekte hüpfen händeklatschend dem Pfeifer von Hameln hinterher, jeden Ungläubigen verdammend, sogar hier:

 

In all this talk about madVR, let us not forget the efficient QuickSync / native DXVA2 decoders in combination with EVR-CP. With low CPU usage and moderate GPU usage, these combinations deliver satisfactory results for the general HTPC crowd.

..will sagen wer "es" nicht hat ist automatisch zweitklassiger Pöbel..

Oh Wichtigtuer dieser Welt kommt raus, ihr seit umzingelt...

Edited September 18, 2012 by craig_s

[Innuendo]

Ein gemeinsamer Oszillator für Video und Audio dürfte somit gegessen sein.

 

Im Gegensatz zu Realtek/ATI (alter htpc) funktioniert Realtek/HD4000 an meinem AV Receiver von Onkyo via hdmi ohne sehr kurze (Korrektur) Tonaussetzer im 3-5min Takt. Ist aber nur mein Eindruck, dass beim Z77 ein gemeinsamer Taktgeber vorhanden ist/sein könnte.

AC3Filter läuft bei mir manchmal nach einiger Zeit asynchron, vornehmlich bei live Sendungen. LAV Audio bleibt lipsync, dafür ist das Klangbild anders.

 

Innu

[nuts]

Es gibt auch keinen A/V Drift, da sich Directshow an die Audio-Clock hängt.

 

Ob das Mediacenter bunt ist tut nichts zur Sache. Eher wie potentielle Probleme dort behandelt werden.

JRiver verwendet imho LAV+madVR während XBMC ein ganz eigenes System verwendet (und dort sind auch nicht nur Idioten unterwegs ...).

 

Es geht eher darum zu verstehen wie sich die Hardware verhält und wie man bestmöglich damit umgehen kann.

[CiNcH]

Die Framezeitpunkte basierend auf der Graph Reference-Clock (HDMI Audio Renderer) driften von den VSync Zeitpunkten. Man sieht das in MPC-HC in den Statistiken des EVR Custom. Die grüne Kurve bewegt sich von der roten langsam weg.

 

madVR errechnet eine Refreshrate von 23.9724Hz und eine "clock deviation" zur Reference Clock von 0.00148%. Das bedeutet, dass alle 4.18 Minuten ein Bild verworfen wird. VBIOS ist 2137.

 

In dem Fall könnte man mit einem Custom Timing die VSync Intervalle doch verschieben und könnte so "clock deviation" evtl. minimieren.

[nuts]

Entspricht auch meinem Ergebnis. Alle ~4min muss synchronisiert werden (bin nicht sicher ob da nur 1 Bild verworfen wird).

Ich werde mich aber damit erst wieder beschäftigen wenn Intel RGB 0-255 über Hdmi ausgeben kann.

Edited September 18, 2012 by nuts

[CiNcH]

Ich häng bei Gelegenheit nochmal die AMD Radeon HD 6570 rein. Ich bin mir sicher, dass da kein Drift war.

 

bin nicht sicher ob da nur 1 Bild verworfen wird

Kommt auf den Sync Algo an. Bei schlechten kann es sein, dass auf Grund des Jitters abwechslungsweise 1 Bild verworfen und ein VSync Slot übersprungen wird, und das solange, bis Render- und VSync-Zeitpunkte nicht mehr nahe aufeinander liegen. Wird das nicht behandelt, kommt es natürlich zu sehr unschönem Ruckeln.

[nuts]

Ich glaube im MPC-HC EVR Custom ist das nicht optimal gelöst.

Zumindest nach den Kurven alle 4min.

Tut aber auch nichts zur Sache.

 

Mit meiner HD6570 passt das so gut, dass madVR schnell in den hohen Stundenbereich (drop/repeate) springt.

Ein theoretischer Wert. Passieren tut da nichts.

[CiNcH]

OK, also 2 weitere Unschönheiten bei Ivy Bridge... keinen gemeinsamen Oszillator für die Audio- und Video-Ausgabe, sowie eine recht krumme VSync Clock, weswegen recht oft nachsynchronisiert werden muss. Naja...

[craig_s]

Die Framezeitpunkte basierend auf der Graph Reference-Clock (HDMI Audio Renderer) driften von den VSync Zeitpunkten. Man sieht das in MPC-HC in den Statistiken des EVR Custom. Die grüne Kurve bewegt sich von der roten langsam weg.

 

madVR errechnet eine Refreshrate von 23.9724Hz und eine "clock deviation" zur Reference Clock von 0.00148%. Das bedeutet, dass alle 4.18 Minuten ein Bild verworfen wird. VBIOS ist 2137.

Das mit 23.972xHz ist doch schon spätestens seit April bekannt und ich meine das hier auch schon mal verlinkt gesehen zu haben.

 

Anandtech, Intel's Ivy Bridge: An HTPC Perspective (8 Seiten)

 

Das das mit theoretischem frame drop alle 5.xx Min nicht hinhaut sondern kürzer ist habe ich hier* schon mal beschrieben:

 

babgvant hatte die HD4000 hier und folgende Posts mit ~3,5min gemessen.

Das beste was die HD4000 im Moment im EVR anzeigt ist 23.973, das wären theoretisch 1/(23.973-23.976) = 5:33 min (333.33 sec).

Das 23.976-Käsescheibchen zeigt aber keine Theorie sondern die Realität im aktuellen Gesamtsetup.

Da die HD4000 im Gegensatz zu meiner HD3000 (spezieller Bug meines Laptops) bei gesetzten 23Hz offenbar keine "zwischen-Drops" produziert stimmen hier auch die Sprünge der grüne Kurve des EVR-OSD (-Statistiken).

 

Die HD3000 schaffte schon 2011 nur die 23.973 Intel hat sich in dem Punkt leider nicht verbessert:

Let's set this straight - No one can do 24p consistently well

 

Wegen Ivy OC/Undervolting hier* noch ein interessanter Artikel.

Edited September 18, 2012 by craig_s

[CiNcH]

Naja, die Frage ist halt immer wie die Renderer intern arbeiten und wie bzw. wann sie synchronisieren. In meinem Renderer mache ich es zum Beispiel so, dass ich nicht mit dem Frame-Timestamp bzw. der Reference Clock rendere, sondern mit dem nächstgelegenen VSync Slot. Wenn dieser Zeitpunkt sich mehr als ein Frame-Intervall vom Frame-Timestamp weg bewegt hat, regle ich nach, sprich es wird entweder ein Frame verworfen oder ein VSync Slot übersprungen. Mittels Hysterese verhindere ich das vor- und zurückspringen. A/V-Asynchronität ist in diesem Fall maximal ein Frame-Intervall.

[nuts]

Da die HD4000 im Gegensatz zu meiner HD3000 (spezieller Bug meines Laptops) bei gesetzten 23Hz offenbar keine "zwischen-Drops" produziert stimmen hier auch die Sprünge der grüne Kurve des EVR-OSD (-Statistiken).

Ich glaube der EVR CP verhält sich bei zu langsamer Clock anders als bei zu schneller (23hz vs 24hz).

Daher die "Zwischen-drops".

Die HD3000 schaffte schon 2011 nur die 23.973 Intel hat sich in dem Punkt leider nicht verbessert:

Let's set this straight - No one can do 24p consistently well

Naja wie der Gegentest von cinch und mir zeigt ist dieser Thread von der Schlussfolgerung her nicht richtig (ich hab aber keine Lust mit 3:2 geschädigten Amis über Ruckeln zu diskutieren).

Edited September 18, 2012 by nuts

[SnoopyDog]

Ich habe mir heute auch neue Hardware bestellt:

• Mainboard MSI Z77MA-G45 (µATX)
  
• Core i3-3225
  
• SilverStone Kühlkörper NT01-E (passiv)
  
• RAM DDR3-1600 4GB

Festplatte bleibt erst einmal die 2.5'' Seagate Momentus XT (750GB) aus dem jetzigen HTPC. Nur mit dem Zusammenbau warte ich noch ein bißchen, da ich mit einem dieser beiden Gehäuse liebäugle:

http://www.origenae.co.kr/en/htpc_s14v.htm

oder

http://www.origenae.co.kr/en/htpc_s16v.htm

Vorzugsweise das flachere, aber da sind hinten nur 6x6 cm Lüfter, für die es kaum Alternativen gibt. Und leider sind diese Gehäuse nicht gerade billig...

Ich hoffe mal, daß es mit der OnBoard-Grafik klappen wird...

Edited September 18, 2012 by SnoopyDog

[nuts]

Nicht sehr abwechslungsreich.

 

Diese 60er sollen sehr leise sein: http://www.mindfactory.de/product_info.php/info/p230228_60x60x25-SilenX-iXtrema-Pro-IXP-34-12-1900U-m-12dB-A--Schwarz.html

Die 12db bei 1900rpm sind vielleicht etwas optimistisch, aber man kann ja noch drosseln.

[craig_s]

@ cincH

 

Stimmt, die Formel 1/(23.97x-23.976) = x sec kommt laut madVR nur annäherungsweise hin. Hast du ne genauere?

Hat mir aber immer gereicht für ~Voraussage wann ich mit drops zu rechnen habe.

 

23.976-Käsescheibchen braucht aber keine Formel sondern einen der es schafft unter Umständen minutenlang mit Stoppuhr in der Hand auf den Ticker zu starren.

EVR-OSD hilft sehr damit man schon ungefär weiss jetzt kommts gleich.

 

Ich hab das Video gebaut weil der Laptop bei 23Hz über die EVR Sprünge hinaus drops produzierte.

Dafür gibt's sonst nichts um das nachzuweisen weil das EVR OSD und auch madVR davon nichts bemerken!

 

Und könnte ja auch immer mal wieder mit anderer Hardware/Treibern auftauchen.

Edited September 18, 2012 by craig_s

[craig_s]

Ich glaube der EVR CP verhält sich bei zu langsamer Clock anders als bei zu schneller (23hz vs 24hz).

Daher die "Zwischen-drops".

Wie gesagt liegt mit Sicherheit am Laptop. Entweder an der speziellen Paarung mit der zusätzlichen Ati und/oder am Laptop Treiber. Wie man weiss kochen die immer ihr eigenes Süppchen.

Leider muß ich den nehmen weil nur er kann die Ati deaktivieren. Mit org. Intel treibern kocht die sonst immer im Off vor sich hin (braucht Strohm).

 

 

Naja wie der Gegentest von cinch und mir zeigt ist dieser Thread von der Schlussfolgerung her nicht richtig

die 23.973 für HD3000 stimmen aber soviel ist sicher.

 

(ich hab aber keine Lust mit 3:2 geschädigten Amis über Ruckeln zu diskutieren).

Hat aber Spass gemacht! Ich frozzel auch gern auf englisch.. Ubrigens, wie solles anders sein, es gibt dort auch gute, extrem gute sogar. Ausserdem ist AVS ein weltweites Phänomen.

Edited September 18, 2012 by craig_s

[craig_s]

Naja, die Frage ist halt immer wie die Renderer intern arbeiten und wie bzw. wann sie synchronisieren. In meinem Renderer mache ich es zum Beispiel so, dass ich nicht mit dem Frame-Timestamp bzw. der Reference Clock rendere, sondern mit dem nächstgelegenen VSync Slot. Wenn dieser Zeitpunkt sich mehr als ein Frame-Intervall vom Frame-Timestamp weg bewegt hat, regle ich nach, sprich es wird entweder ein Frame verworfen oder ein VSync Slot übersprungen. Mittels Hysterese verhindere ich das vor- und zurückspringen. A/V-Asynchronität ist in diesem Fall maximal ein Frame-Intervall.

Du hast dir einen eigenen Renderer gebaut, nicht wahr?

"Mittels Hysterese verhindere ich das vor- und zurückspringen" - willst du damit sagen er kann die A/V-Synchronität halten ohne Drops/Repeats, wie das EVR/madVR machen?

Oder er kann die A/V-Synchronität besser/genauer halten als andere?

 

In dem Fall müsste aber erst mal geklärt werden mit welchem Setup du zuverlässig verbesserungswürdige A/V-Asynchronität bekommst. Mir ist die nur früher bei versch. Experimenten begegnet, vergessen wie das war. Im Net liest man es gelegentlich aber die Leute schreiben ja nie ihr gesamtes Setup dazu sondern nennen nur einen Decoder und Player und wenn man das dann selber probiert ist es synchron.

 

Ich häng bei Gelegenheit nochmal die AMD Radeon HD 6570 rein. Ich bin mir sicher, dass da kein Drift war.

Das Timing der Ati's die ich hier habe ist mir genau genug, auch bei 23.976, da brauch ich nichtmal ReClock. Mit "Drift" meinst du hier das Auseinander-/Zusammengehen der Linien des EVR-OSD's. Ich gebe zu bedenken das das leicht missverstanden werden kann. zB. Audiodrift ist was anderes.

Edited September 19, 2012 by craig_s

[nuts]

Ich versuchs mal zu erklären:

 

In cinch's renderer wird nicht zur "Reference Clock" (Audio gebunden -> bei bluray 23,976) gerendert sondern zum VSync (GPU gebunden je nach Einstellung im Treiber).

Jetzt passt das ja bei Intel nicht (krumme VSync Clock) => "Clock-Drift".

Behandelt wird das in seinem renderer so:

Frame-Intervall vom Frame-Timestamp weg bewegt hat, regle ich nach, sprich es wird entweder ein Frame verworfen oder ein VSync Slot übersprungen

Im Ergebnis sind das mehr oder weniger sichtbare Ruckler (frame drop bzw. übersprungener VSync). Zaubern kann schließlich niemand.

 

A/V Sync ist immer gegeben.

A/V-Asynchronität ist in diesem Fall maximal ein Frame-Intervall.

Unwesentlich.

Edited September 19, 2012 by nuts

[CiNcH]

Gut erklärt. madVR dürfte das ähnlich machen.

 

Die Hysterese sorgt lediglich dafür, dass es bei einem Überlauf zwischen Frame-Zeitpunkt und VSync zu einem sauberen Ausgleich von einem Frame-Intervall kommt. Wichtig ist halt, dass nachdem zum Beispiel ein Frame verworfen wurde, der Algorithmus im nächsten Zyklus auf Grund von Jitter nicht gleich wieder einen VSync Slot überspringt und das ein paar Zyklen lang so hin und her geht, bis der Drift dann ausreichend dafür gesorgt hat, dass Frame-Zeitpunkt und VSync nicht mehr nahe beieinander liegen.

 

Du hast dir einen eigenen Renderer gebaut, nicht wahr?

Ich habe den EVR Custom vom DVBViewer optimiert. Vom Timing her funktioniert der je nach Umgebung suboptimal. Das beste Ergebnis hat man mit Aero + 'VSync durch Aero=aus'. Ich konnte sehr viele Probleme in anderen Umgebungen identifizieren und ausbessern. Außerdem habe ich die zeitlichen Zusammenhänge visualisiert.

 

 

Einen Bicubic Scaler über die Shader habe ich auch eingebunden. Der aktuelle EVR Custom verwendet den D3D Bilinear-Filter. Zum einen ist der natürlich für die Qualität suboptimal, zum anderen frisst er GPU-Ressourcen, was aber auch auf den Bicubic Shader zutrifft (anstatt weichzuzeichnen wie der Bilinear, überschärft der halt, was sich durch starkes Ringing bemerkbar macht). Mit 4K läuft meine HD 4000 zum Beispiel auf Anschlag mit 9W Verbrauch. Mit Scaler über EVR (bzw. den EVR-Mixer) und die FF-Hardware sind es nur noch ca. 4W. Zudem handelt es sich dabei um einen Lanczos ähnlichen Scaler mit Artefaktmaskierung. Der EVR Custom müsste dafür den Scaler des EVR Mixers triggern. Dazu muss er direkt die Zielauflösung anfordern und nicht die Quellauflösung.

[nuts]

Ist das jetzt schon raus wie man mit dem EVR CP den DXVA-Scaler verwendet?

[craig_s]

Wo/wie kann man diesen neuen Renderer probieren?

[CiNcH]

Wo/wie kann man diesen neuen Renderer probieren?

Ich habe intern mal eine Version zur Verfügung gestellt. Ich konnte dann leider auf Grund privater Probleme lange nicht mehr daran arbeiten. Ich muss mich jetzt langsam wieder hinein arbeiten. Es geht halt hauptsächlich um ein gutes Ergebnis für Live-Streams, wo es vielleicht nicht so sinnvoll ist, eine Ausgabe-Clock irgendwie zu treiben. Bei zu vielen Konstellationen sind mir Probleme mit der aktuellen Implementierung aufgefallen, e.g. Aero an/aus, 'VSync duch Aero' an/aus usw. Ich habe dann untersucht, warum es unter diesen gewissen Umständen zu Problemen kommt und wie sie zu lösen sind.

Für File empfehle ich ReClock. Der gewählte "relativ zum VSync Drop/Repeat" Algorithmus funktioniert auch damit. Natürlich sollte in dem Fall dann niemals ein Frame verworfen oder wiederholt werden. Bei Bitstream-Audio muss man dann halt wahrscheinlich mit dem Synchronisationsalgorithmus bzw. Nachregeln leben. Außer man kann irgendwie die Timings anpassen und den Drift aufwändig mit der Hilfe von madVR ausgleichen (nVIDIA und Intel bieten ja entsprechende Tools an, wie brauchbar diese sind, weiß ich nicht). Eine andere Variante wäre die Sapphire Ultimate HD 6570. Da bin ich mir sicher, dass Audio und Video auf einem gemeinsamen Oszillator basieren. Ob das dem AMD-Referenz-Board entspricht bzw. wie das mit anderen Boards aussieht, weiß ich nicht.

 

Ist das jetzt schon raus wie man mit dem EVR CP den DXVA-Scaler verwendet?

Im Grunde ist klar, wie das funktioniert. Ich hatte das dazumal schon auf der ToDo-Liste, weil ich mich dazumal schon gefragt habe, wieso der EVR Custom im DVBViewer die Quellauflösung vom Mixer anfordert und welchen Unterschied es ausmachen würde, die Zielauflösung anzufordern. Die GPU-Hersteller werben ja schon länger mit sehr guten Video Scalern. Nur war mir nie klar, wie man die verwendet, bis vor kurzem jedenfalls. Man kann nie sagen, mit welchem Algorithmus der Standard EVR skaliert, das hängt allein von der GPU und vom Treiber ab.

Griga hat das ja schon ausprobiert, hatte aber, wenn ich mich recht entsinne, noch eventuelle Threading Probleme. Außerdem hat man beim Ziehen des Video-Fensters immer Aussetzer, weil man dann das Format mit dem Mixer neu aushandeln muss. Das geht in D3D effizienter. Er hatte deshalb nach einem alternativen Weg gefragt. Aber lieber sind mir schon die Aussetzer, denn meist schaut man eh im Vollbild und wie oft zieht man das Fenster schon... Und dann ist es auch egal, wenn das Bild mal eben dunkel bleibt. Es macht halt von der Bildqualität her einen großen Unterschied bei gleichzeitig reduzierter Leistungsaufnahme, da der Scaler in der Fixed Function Hardware deutlich effizienter ist. Jedenfalls ist das bei Intel so.

[craig_s]

Ich habe intern mal eine Version zur Verfügung gestellt.

Sorry, wo ist intern? Ist der schon irgendwie im DVBV drin? Beta?

[CiNcH]

Mach zum Beispiel mal Aero an und auch 'VSync durch Aero' in den DVBViewer-Optionen. Bei einem Überlauf siehst du da genau den beschriebenen Effekt, dass wenn Frame-Zeitpunkt und VSync aufeinander liegen, die Regelung nicht sauber ist, und es zu erheblichen Rucklern kommt (Frame wird verworfen -> VSync wird übersprungen -> Frame wird verworfen -> VSync wird übersprungen -> ...), bis der Clock-Drift die beiden wieder etwas trennt.

 

Ein anderes Problem ist Aero aus. Da hatte ich immer wieder das Problem, dass wenn für ein Frame 'Present' aufgerufen wurde, D3D, welches die Ausgabe mit dem VSync zeitlich regelt (ohne dass es zu Tearing kommt), ab und zu einfach scheinbar grundlos ein VSync Slot ausgelassen hat -> Ruckler. Ich habe dann eine eigene Blockier-Funktion geschrieben, die den VSync-Status pollt und 'Present' bzw. die Ausgabe zeitlich selber regelt. Da habe ich dann keinen VSync mehr verpasst und zusätzlich konnte ich damit im Gegensatz zur D3D-Methode die CPU-Last reduzieren. Ob das auf allen System ohne Tearing funktioniert, ist die Frage.

[craig_s]

..wird ja immer mysteriöser..

Also mal so: ich glaub erst dran das grad dein neuer Renderer am Laufen ist wenn das spektakuläre OSD das auf deinen Screenshots zu sehen ist, erscheint.

Wie schalte ich das ein? Bei Ctrl-J tut sich im DVBV nix..

[nuts]

Der Renderer von cinch ist in keiner DVBV Version enthalten.

Das Testprogramm mit dem renderer wurde nur DVBV intern bereitgestellt.

 

Ich denke Tests würden dir jetzt nicht so viel nützen und bedürften einiges an Erklärung.

Edited September 19, 2012 by nuts

[craig_s]

Pöööh, vielleicht würden die Tests ja cincH was nutzen?

[craig_s]

Eine andere Variante wäre die Sapphire Ultimate HD 6570. Da bin ich mir sicher, dass Audio und Video auf einem gemeinsamen Oszillator basieren. Ob das dem AMD-Referenz-Board entspricht bzw. wie das mit anderen Boards aussieht, weiß ich nicht.

Ist doch seit langem so das ein Realtek HDMI Audio Chip auf den Ati's verbaut ist, jedenfalls war's so bis zu HD5xxx. Treiber dafür gibts von Realtek und von AMD. Der von Realtek ist gedacht für Leute die auch auf dem MB einen Realtek haben, die können dann im R.-Manager auch HDMI kontrollieren. Der Treiber war aber vor ca. nem Jahr noch etwas buggy und juhuu, endlich erinnere ich mich - damit hatte ich mal mit TMT5 + HD Audio Bitstreaming ziemlich krasse AV-Asynchronität.

 

Habe dann auf den AMD HDMI-Audio-Treiber gewechselt (der damals in den AMD-mobility Treibern nicht enthalten war) und problem beseitigt. Also Asynchronität kann grundsätzlich auch jeder Treiber verursachen. Und wie gesagt, bis zu der Zeit lief bei mir Audio über SPDIF sogar über den Realtek auf dem MB, also garantiert kein gemeinsamer Oszillator? und trotzdem Synchron. Viele Besucher meines fröhlichen Homecinemas werden das bei Bedarf bestätigen

 

 

Mach zum Beispiel mal Aero an und auch 'VSync durch Aero' in den DVBViewer-Optionen. Bei einem Überlauf siehst du da genau den beschriebenen Effekt, dass wenn Frame-Zeitpunkt und VSync aufeinander liegen, die Regelung nicht sauber ist, und es zu erheblichen Rucklern kommt (Frame wird verworfen -> VSync wird übersprungen -> Frame wird verworfen -> VSync wird übersprungen -> ...), bis der Clock-Drift die beiden wieder etwas trennt.

 

Ein anderes Problem ist Aero aus. Da hatte ich immer wieder das Problem, dass wenn für ein Frame 'Present' aufgerufen wurde, D3D, welches die Ausgabe mit dem VSync zeitlich regelt (ohne dass es zu Tearing kommt), ab und zu einfach scheinbar grundlos ein VSync Slot ausgelassen hat -> Ruckler.

Das zu testen wird noch länger dauern, sorry.

Habe auch bedenken ob solche Empfindlichkeiten leicht zu reproduzieren sind? Da kann soo viel reinhusten.. Grad gestern hatte ich spezielle Ruckler bei ner vertikalen Laufschrift, dachte endlich der Intel Sache auf die Schliche gekommen zu sein, Himmel und Hölle in Bewegung gesetzt ... ... und dann war's bloß der doofe Monitor, verdammt..

Edited September 20, 2012 by craig_s

[CiNcH]

und trotzdem Synchron.

Klar synchron, wenn der Video Renderer anhand der Timestamps rendert! Das Problem ist, wie diese relativ zum VSync verlaufen. Wenn Renderzeitpunkt und VSync-Zeitpunkt ungünstig fallen, kommt es zu Rucklern oder Tearing. Mit Synchronisationsalgorithmus meine ich immer die Sychnoisierung zwischen Rendering und VSync, nicht A/V. Das ist das Problem der nicht synchronen Uhren. Video wird anhand der Audio Clock gerendert, aber anhand der GPU Clock ausgegeben (VSync).

[craig_s]

Das war gemeint:

 

OK, funktioniert jetzt. Ich muss den Onboard RealTek-Chip einschalten. Scheinbar läuft HDMI-Audio auch darüber...

 

Ein gemeinsamer Oszillator für Video und Audio dürfte somit gegessen sein.

Auch weiter oben hast du schön öfter AV-Asynchronität mit nicht gemeinsamer Clock quasi gleichgesetzt. Halte ich für übertrieben.

 

Die Zauberformel ist immer noch HDMI für alles (sprich Wiedergabe/Verarbeitung und A/V-Ausgabe) mit gemeinsamer Clock. Geht die Clock gerningfügig falsch, läuft eben alles geringfügig falsch, im Bereich von 0.003 Hz bei Intel. ...

[CiNcH]

Auch weiter oben hast du schön öfter AV-Asynchronität mit nicht gemeinsamer Clock quasi gleichgesetzt. Halte ich für übertrieben.

Es kommt halt auf den Algorithmus an. Man kann im Renderer auch stur anhand des VSync's rendern. Dann wird entweder Audio oder Video davon laufen, wenn es keine gemeinsame Clock gibt.

[craig_s]

Bestimmt möglich aber alle mir bekannten Renderer können gut die Synchronität erhalten, wenn die GPU schlechtes Timing hat - eben durch Drops/Repeats (Ruckeln).

 

Übrigens mein TV kann das sehr gut kaschieren soweit ich das jetzt verfolge.

zB. die drops alle ~41sec. wenn man 23.976 mit 24Hz abspielt - der cached so lange bis er ne günstige Stelle gefunden hat. Also setzt den drop nicht wärend einem Schwenk sondern plaziert ihn bei einem Schnitt wo er sogut wie nicht bemerkbar ist. Der Schwenk darf natürlich nicht zu lange dauern. Bei den lange rotierenden Deckenlüftern am Anfang von Blade Runner hat er auch kaum ne Chance, da kommt dann mal ein bemerkbarer drop. Und bei den 23.976-Slices hat er gar keine Chance

Edited September 20, 2012 by craig_s

[nuts]

Übrigens mein TV kann das sehr gut kaschieren soweit ich das jetzt verfolge.

zB. die drops alle ~41sec. wenn man 23.976 mit 24Hz abspielt - der cached so lange bis er ne günstige Stelle gefunden hat.

Der TV bekommt davon überhaupt nichts mit. Je nach Szene ist ein Framedrop aber mehr oder weniger sichtbar.

Aktivierte Zwischenbildberechnung kann auch reinspielen.

 

Das mit dem A/V Sync hast du missverstanden.

Die Diskussion war grundsätzlich wie der Sync-Algo aussehen kann/muss und welche Folgen das hat.

Das sich die meisten (alle?) Renderer nach der Audio-Clock richten wurde doch nie bestritten.

[CiNcH]

Das sich die meisten (alle?) Renderer nach der Audio-Clock richten wurde doch nie bestritten.

Der Video Renderer richtet sich nach der Referenzuhr im Graph und die wird meist vom Audio Renderer, basierend auf der Rate, bei welcher selbiger Audio Samples konsumiert, gestellt. Anhand dieser Uhr generiert der Source Filter auch die Timestamps für die Ausgabe. Der Video Renderer muss nun eine geeignete Methode implementieren, diese Frame-Zeitpunkte mit dem VSync zu synchronisieren. Wenn man ReClock einsetzt, braucht man das nicht tun, weil die gestellte Referenzuhr auf den VSync synchronisiert wird, die Frame-Zeitpunkte dann also zwangsweise synchron mit dem VSync verlaufen und nicht mehr driften. GothSync+PowerStrip ist auch ganz nett. Da kann man mit älteren ATi-Karten den VSync schieben, sprich es wird die Ausgabe zur Wiedergabe (Audio Clock) synchronisiert. Das ist mit heutigen GPU's nicht möglich, weil die Hersteller mit den benötigten Informationen nicht herausrücken. ReClock synchronisiert die Wiedergabe zur Ausgabe.

 

Dieser Drift ist aber nicht das einzige Problem, mit dem man sich zu beschäftigen hat. Man muss auch das Rendering zum optimalen Zeitpunkt starten. Das Frame muss immer vor dem VSync fertig gerendert sein und der Present-Aufruf muss zum optimalen Zeitpunkt abgesetzt sein. Sonst kommt es entweder zu Tearing oder Rucklern. Außerdem darf das Rendering von einem Frame natürlich nicht länger als einen Framezyklus dauern, optimalerweise deutlich darunter. Solche Dinge trace ich in meinem Renderer auch raus, sprich die Zeit, die in D3D benötigt wird, um ein Frame zu rendern (siehe Screenshot, Zeile 'Render Latency'), um ausschließen zu können, dass die GPU schlichtweg überfordert ist.

 

Ziel war und ist ein unter allen Umständen sauberes Timing. Der Qualitätsaspekt hat mich nie sonderlich interessiert, zumal mir DXVA und 8-Bit Ausgabe ausreichen. Nur das Scaling gehört optimiert, bzw. man muss es Teil vom DXVA machen und nicht nachträglich in D3D. Außerdem soll die Pixelpipeline sauber sein, und keine zusätzlich Fehler einführen. Was zum EVR Custom im DVBViewer diesbezüglich verbessert wurde ist ein exaktes Texel/Pixel-Mapping, sprich bei 1080i/p Material hat man bei 1080p-Ausgabe dann 1:1 alle Pixel unverändert am Bildschirm (außer sonst jemand in der langen Video-Pipeline baut noch scheiße, der Video Renderer jedenfalls nicht mehr ). Momentan findet da eine Transormation durch D3D statt. Außerdem wird der Sampler bzw. bilineare Filter auch dann über das Bild gejagt, wenn die Quell- der Zielauflösung entspricht, d.h. das Material wird dann unnötigerweise noch bilinear verwaschen . Das kann man jetzt schön mit Testmustern mit 1 Pixel breiten Linien anschauen. Die sind dann nicht mehr 1 Pixel breit sondern durch Interpolation entsprechend breiter bzw. verwaschen.

[craig_s]

2 Taktgeber (z.B. onboard Sound):

 

JitterX = Abweichung aufgrund des Videotaktgebers

JitterY = Abweichung aufgrund des Audiotaktgebers

 

 

Video-Clock (VSync)= Eingestellte Wiederholungsfrequenz + JitterX

 

Audio-Clock= Zeitstempel des Encoders + JitterY

 

Directshow-Clock= Audio Clock

 

 

=> auseinanderdriften Delta JitterX JitterY

Die konstante Abweichung kommt noch hinzu wenn die Video-Clock nicht synchron zur Directshow-Clock läuft.

 

 

Reclock-Ansatz (2 Taktgeber):

 

JitterX= Abweichung aufgrund des Videotaktgebers

JitterY= Abweichung aufgrund des Audiotaktgebers

 

Video-Clock (VSync)= Eingestellte Wiederholungsfrequenz + JitterX

 

FaktorZ=Differenz zwsichen Video-Clock und Audio-Clock

 

Audio-Clock= (Zeitstempel des Encoder + JitterY) * FaktorZ

Es wird also die Audio-Clock quasi mit der Video-clock überschrieben.

Dadurch ändert sich die Audio-Abspielgeschwindigkeit. Das geht logischerweise nur wenn Audi-Clock und Video-Clock relativ nahe beieinander liegen und auch nur bei der PCM-Ausgabe.

 

=> perfekt in Sync. Keine Ruckler, kein A/V-Drift

 

..und jetzt auf einmal will keiner mehr was von A/V-Drift gehört haben... Egal, schön das das jetzt mal aus dem Weg geräumt ist.

 

Was nun noch übrig bleibt sind unnötige Ruckler und schlechte Bildqualität durch Renderer.

Bei den unnötigen Rucklern kann ich teilweise zustimmen - madVR stabilisiert ab Start des Videos etwas schneller aber darüber hinaus ist mir bei viiielen Tests wenig aufgefallen. Wenn ein Ruckel-Unterschied zu EVR ist er jedenfalls gering/nicht auffällig (alles ohne ReClock).

 

Wegen Bildqualität habe ich ja schon berichtet, habe 2 Tage aufwändig madVR und zB. den aller "unwürdigsten" EVR Enhanced (DVBV, Custom nicht angehakt) gegeneinandergehalten, sowohl mit 1080i-Käsescheibchen (mit 1 Pixel breiten Linien) als auch versch. Aufnahmen und 1080p Filme und die Unterschiede im Bild waren minimalst bzw. vernachlässigbar.

 

Hast du samples, cinch mit denen du das immer sehen kannst?: "mit Testmustern mit 1 Pixel breiten Linien. Die sind dann nicht mehr 1 Pixel breit sondern durch Interpolation entsprechend breiter bzw. verwaschen."

Edited September 20, 2012 by craig_s

[nuts]

Wegen Bildqualität habe ich ja schon berichtet, habe 2 Tage aufwändig madVR und zB. den aller "unwürdigsten" EVR Enhanced (DVBV, Custom nicht angehakt) gegeneinandergehalten

Damit wird auch der DXVA-Scaler verwendet und der soll bei Intel ja ganz gut sein.

Mit EVR CP D3D bilinear (über GPU-Shader) und das ist nicht so schön.

 

P.S. Den realen A/V Drift hast du hier ins Spiel gebracht. Alles darüber hinaus ist eine Diskussion ums Problem, zu Lösungsansätzen und möglichen Folgen.

[craig_s]

Skalieren! Achso, das hab ich bis jetzt nur wenig getestet. Werd mich mal dranmachen.

[CiNcH]

Die Skalierer waren ja immer der hoch gehandelte Vorteil von madVR. Allerdings wird da auch nur mit Wasser gekocht. Im Grunde sind das alles lediglich Lehrbuchalgorithmen. Man hat die Wahl zwischen artefaktarm, dafür verwaschen, oder scharf, dafür artefaktreich. Da kommen natürlich hauptsächlich die scharfen Skalierer zum Einsatz, zumal DVD und Blu-Ray meist recht sauber sind.

Der Intel-Scaler skaliert das Bild zweifach, mit einem aus beiden Welten (die scharfe Variante ist ein 8-Tap, ähnlich Lanczos4), und vereint die Ergebnisse dann, und das alles in Echtzeit in einem dedizierten energieeffizienten ASIC (man kann damit sogar multiple Quellen skalieren). Die Anti-Ringing Funktion in aktuellen inoffiziellen madVR Builds dürfte wohl was ähnliches machen, natürlich wieder mit deutlich erhöhter Beanspruchung der GPU-Shader.

Die Algorithmen in den Grafikchips werden halt auch immer besser und rechtfertigen den Einsatz von madVR meiner Meinung nach nicht mehr wirklich. Wenn dann eher auf Grund eines sauberen Timings.

Die Video Post Prozessoren der GPU's arbeiten übrigens auch alle auf einer größeren Bittiefe (üblicherweise 10 Bit), um den Fehler gering zu halten. Erst ganz zum Schluss wird auf 8 Bit heruntergerechnet.

[craig_s]

Schon abgeblockt bevor ich überhaupt mit DVBV-Skalier-Test anfangen konnte.

DVBV hat ja schon unskaliert mit versch. Renderern Probleme das Bild auf die korrekte Größe zu bringen. So kann isch net aweide (sagte Heinz Schenk).

 

Da muß erst was verbessert werden. Im untenstehenden Bild sieht man's.

(nebenbei 1080i/p ist ok deswegen ist mir das nie aufgefallen aber das muß ich ja nicht skalieren).

 

Aber 576i wird mit DVBViewer + EVR Custom/Enhanced/VMR9 in falscher Auflösung dargestellt. Mit meinem Testsample funktioniert wenigstens VMR7 (mit Ati auch System Renderer), mit dem DIVAS Testvideo von Burosch nicht mal das.

 

-> man sieht es fast nur mit Samples die 1-Pixel Linien darstellen.

Jetzt könnt man sagen "das sieht in normalem Video/TV doch eh keiner!". Stimmt aber denkt mal so - wenn das so schon losgeht, wer weiss wie es ungeprüft ausufern kann? Also cincH verlangt zurecht immer die "Extreme", oder?

 

 

..Das kann man jetzt schön mit Testmustern mit 1 Pixel breiten Linien anschauen. Die sind dann nicht mehr 1 Pixel breit sondern durch Interpolation entsprechend breiter bzw. verwaschen.

..nicht so einfach wie du siehst, erst mal muß DVBV unskaliert funktionieren. Immerhin kann man in den Screenshots bei der Zahl 576 (auf grünem Grund) eine leichte Unschärfe bei "DVBV + EVR Custom" sehen wenn man nahe genug an den Screen ranrückt (bzw. er groß genug ist). Auch im Kreis wenn man noch näher geht. Wenn DVBV dann hoffentlich mal die Auflösung korrekt darstellt wäre es etwas übertrieben diese leichte Unschärfe immernoch als "suboptimal" zu bezeichnen?

Kann man aber erst sagen wenn es einen Sinn hat mit DVBV zu skalieren.

 

"DVBV + EVR Enhanced" ist schon wieder scharf, dafür staucht diese Kombi das Bild richtig stak (beim Pfeil: Kreis ist ein Ei).

VMR7 scharf und korrekte Auflösung. Wie "MPC-HC + madVR" und alle anderen Kombis. Verdrehte Welt...

 

-> wer die Tests nachstellen will - in DVBViewer die Funktion "Zoom 100%" mit einer Taste belegen und diese auch jedes mal drücken bei Renderer oder Aero-Wechsel!

 

Alle Screenshots: Intel HD3000. Gleiche Ergebnisse aber auch mit Ati (Nvidia vermul. auch?), Intel zeigt neben EVR/madVR nur mit VMR9/7 ein Bild, bei Ati auch alle anderen Renderer.

Testsample: hier die PAL 720x576 Variante nehmen.

 

 

Graph: DVB Source - LAV Audio - MS DTV-DVD Decoder

(Decoder ist aber eigentlich wurscht, hatte mehrmals auch LAV und Cyberlink probiert).

 

 

---> die Linien im folgenden Bild haben oft winzige 1-Pixel-Abstände und es ist sehr wichtig diese hier zu sehen - in Originalgröße. Sollte man in den Bildern stattdessen wellenartige Linienfelder sehen: der Browser darf in keiner Richtung gezoomt sein! Um das abzustellen einfach in Firefox und Internet Explorer die Tastenkombination Strg + 0 (Null) drücken. Oder Strg+[Mausrad hoch-runter]

 

 

 

 

 

p.s.

das noch vergessen,

es ist nicht etwa so das "DVBV + EVR Custom/Enhanced" mit "Zoom 100%" einfach nur eine falsche Größe darstellt und man das mit leichtem Auseinanderziehen des Fensters beheben könnte. Der Versuch wird scheitern. Auch mit 200% keine Chance. Sieht man ja auch an VMR7, da stimmt die Größe.

 

"DVBV + EVR Custom" ist also weiter unten buggy wie cinch schon bemerkte. Aber auch "DVBV + EVR Enhanced" und alles schon ohne Skalieren.

 

Mit der NTSC 640x480 Version des Samples gibt es nochmal andere Sizing-Probleme. Hier stellt auch VMR7 falsch dar und verändert sogar die Größe beim Pausieren.

Hier funktioniert nur "System Default Renderer" mit korrekter Auflösung (nur auf Ati, Intel meistens schwarz).

 

Alles in allem: Irgendwas klappt da nicht bei der Kommunikation Renderer - Größendarstellung. Inwieweit die Renderer in DVBV zusätzlich falsch auflösen/unschärfen und ob das überhaupt voneinander trennbar ist - keine Ahnung.

Edited February 2, 2013 by craig_s