Jump to content

"Intel HD Graphics 3000" - Test - 3D + VA "Next Gen"


craig_s

Recommended Posts

Also,

habe mir grad nen sogenannten Business oder "Büroknecht" Laptop zugelegt weil ich die vielen Ports die nur diese haben (eSata, ExpressCard) brauche, ein 15 Zoll "Dell Vostro 3550", Vorjahresmodell, gabs gerade günstig als Ausstellungsstück bisschen aufgemotzt in der Bucht. Hatte mir nicht zuviele Gedanken gemacht wegen Nultimedia, na ja, so nen kleinen Traum wegen der Ati..

 

Mit Core i5-2450M @ 2.5-3.1 GHz, 32nm - Sandy Bridge, HM67 B3 - 8GB Ram

 

die Grafik teilt sich eine Radeon HD 6630M mit ner in der Sandy-Bridge integrierten, stromsparenden "Intel HD Graphics 3000" - 2011 ziemlich häufig die Kombination.

Bei der Intel stellte sich später raus das sie DXVA2 + HDMI 1.4 kann.

 

Erst mal den Dell seine eigene Win7 Home Premium Cleaninstall DVD brennen lassen, Treiber + Soft gesammelt, Festplatte formatiert und Win7 neu aufgespielt, schön sauber..

 

 

 

Nach Anfänglichem Frust weil ich immer dachte die HD 6630 müsste es können kam spät die Erleuchtung:

den GPU-Umschalt-Quatsch kann man abstellen und benutzt als "DVB-Junkie" nur noch die Intel.

 

Treibervers. (letzte die bei Dell zu bekommen ist): 8.901.1.1000 vom 05.11.2011

Energiesparplan im Notebook: Ausbalanciert

Intel Graphics Power Plan: Balanced -> also nicht mal Maximum, bei allen Tests!

 

Alle massig Testclips die ich hier habe erledigte sie erstaunlich sauber in HW-Deinterlacing und VA, sogar einem speziell guten - viel lässiger und akkurater als alle AMD Karten die hier durchkamen. CinChs ORF 720p UVD-Fehlerkorrektur-video läuft übrigens auch glatt durch. Andere mit richtig schwerem Fehler hat der LAV schnell korrigiert, besser als der PDVD 10.

 

 

3D

Nach weiteren Versuchen (mit falscher Abspielsoftware) lief dann sogar auch völlig sauberes Blu-ray 3D!! Spuckewegbleib! :| Flimmerfreier als mit ner HD5850!

Geht momentan aber nur und ausschliesslich mit PowerDVD 12 Pro oder Ultra. TMT 5 versagt sowie auch Stereoscopic Player (SSIF). Wie sich herausstellte haben die Cyberlinks ziemlich intensiv mit Intel geklüngelt...

 

 

Die AnandTech haben Käsescheibchen

scheints nie richtig verstanden und offenbar auch die Zeichen der Zeit nicht - die *hier* gezogenen Schlüsse sind alle falsch, wie oft hab ich erklärt das diese Winzigkeiten in "normalem" Video üüüberhaupt nicht zu sehen sind, Haarspalterei die zu nichts führt. Das die Linien mit der Intel viel störungsfreier und ohne weichlichen Nachzieh-Effekt durchlaufen (mit allen DXVA-fähigen Decodern) haben sie scheints übersehen. Hier gilt nicht mehr "je langsamer das Deinterlacing desto besser" wie bei Ati und Nvidia.

 

---> die Linien in den folgenden Bildern sind so fein das Browser (Firefox), OS und Monitore bzw. deren Zusammenspiel sie minimal stauchen können - schon sieht man Wellen statt Linien. In dem Fall hilft es sich die Seite im Internet Explorer anzusehen oder in Firefox "Rechtsklick auf das Bild" > "Grafik anzeigen".

 

Intel HD Graphics 3000:

 

VA_intel_3000.png

 

so sah es bisher mit Ati und Nvidia aus, nachziehende Ränder

 

VA_Ati.png

 

 

 

Energie

Und dann der Strom der nicht wirklich fliesst, habe vor's Netzteil nen Strommesser gehängt (praktisch, der misst neben dem allgemeinen Verbrauch noch CPU- und GPU-Last gleichzeitig), Testbedingungen:

 

- Aero ausgeschaltet (bei mir sowieso immer wegen Design)

- ohne DVB Karte, die hat externe Strohmversorgung.

- interner Monitor aus weil Bild über HDMI an AV-Receiver und dann TV

- interne AMD Grafikkarte mittels Dell-Treiber komplett deaktiviert

 

- so zieht der 15 Zoll-Dell-Krüppel mit der Intel im Idle gerade mal um 7 Watt !

 

MPC-HC + LAV Filters (ausser bei VC-1, da kann der LAV Video nicht in DXVA2, da nehm ich LAV Splitter + PDVD10, die könnens.

LAV Video läuft mit Quicksync und DXYA2 (native) gleichermaßen gut, letzteres verbraucht aber weniger Watt also alle Tests bei denen LAV Video beteiligt war -> DXVA2 (native).

 

Interessant, die in MPC-HC wählbaren EVR Varianten können bis zu 6W sparen s. u.: EVR ~(Vista/Net3) / ~(Custom Presenter)

 

- 1080i "MPEG2 / H.264 / VC-1 Käsescheibchen , 720p H.264 (von der Intel skaliert auf 1920*1080 Fullscreen) -> ~17 / ~23 W

- 576i Mpeg2 (SD, von der Intel skaliert auf 1920*1080 Fullscreen) -> ~16 / ~20 W

- 1080p Blu-ray 3D über PDVD 12 -> ~ 18W - (da zieht der 46" LED-TV mit voller Beleuchtung aber 140W, das nur nebenbei..)

 

- der sparsame DVBViewer mit DVB-Streaming alle Formate SD und HD ~ 16 - 19W

 

CPU-Last je nach (DXVA) Renderer und Video-Auflösung 4-12%, CPU Coretemp 50-58°C

 

 

 

DVBViewer

war übrigens schnell installiert (Settings aus nem anderen PC übernommen) und hat sofort 1a funktioniert (FireDTV S2 + FireDTV C über Firewire Express Card). Ich bin kein DVBViewer Junkie und hab überhaupt nicht alle Spielarten durchprobiert, nur mal alle SD und HD Formate ne Weile beäugt.

1 Altbekanntes Problem: PDVD10 klötzt mit ZDF-HD wenn man von Das Erste HD rüberschaltet. Passiert aber nicht mit LAV 0.51.3 oder MS DTV-DVD Decoder.

 

Viel rumgeschaltet, auch mal PiP probiert, lief alles flüssig.

 

 

HDMI Audio

läuft auch über die Sady Bridge (Intel Display Audio): HD-Audio Bitstreaming, alle Formate (s. Bild) bis 24bit / 192kHz, 8 Kanal. Spuckewegbleib_5-7... :|

Alles mit Testclips über LAV Audio Decoder gecheckt.

 

 

Gute Güte ich überleg halt, wenn das mit allen Sandy-Bridge Prozessoren mit HD Graphics 3000 so läuft braucht es bald keine speziellen Media PCs mehr zu geben? Wenn dann jeder kleine Büro-Rechner ohne dezidierte Grafikkarte es besser kann?

Krass, krass. krass, kopfkratz.

Was mich ärgert, die blöden Testseiten listen meterweise jedes +/- Frame in Spielen, aber so nen einfachen Test macht keine. Da hätt ich mir auch noch ein günstigeres Modell suchen können ohne nutzlose, kastrierte Ati. :angry:

 

EDIT, Bewertung nachgereicht:

 

Komponente 		Details 					Teilbewertung 	Gesamtbewertung

Prozessor 		Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz 	7,0 		 5,9

Arbeitsspeicher (RAM) 	8,00 GB 					7,4 		Ergibt sich aus
Grafik Intel(R) 	HD Graphics Family 				6,4 		der niedrigsten
Grafik (Spiele) 	1696 MB insgesamt verfügbarer Grafikspeicher 	6,4 		Teilbewertung 
Primäre Festplatte 	24GB frei (37GB gesamt) 			5,9

 

to be continued..

Edited by craig_s
Link to comment

Die Intel Quick Sync Technologie ist in der Tat beeindruckend. Ich habe hier auch ein Ultrabook mit Sandy Bridge und HD 3000 und plane die Anschaffung eines HTPC basierend auf Ivy Bridge. Das schöne bei Quick Sync ist, dass eigentlich alles in ASIC's abgebildet ist und die CPU bzw. Shader-ALU's so gut wie nicht beansprucht werden. So eine Fixed Function Hardware ist natürlich optimal energieeffizient. Diese ASIC's haben einen wahnsinnigen Durchsatz. Man kann bis zu 5 H.264 1080i Streams parallel verarbeiten, d.h. dekodieren, deinterlacen und scalen.

 

Intel hat sich vor Jahren den Videospezialisten Oplus eingekauft, die bis dahin Videoprozessoren für LCD, Plasma usw. entwickelt haben. Diese Technologien sind dann in Sandy Bridge/Ivy Bridge eingeflossen. Hier eine kleine Lektüre, wie zum Beispiel der Scaler arbeitet.

 

Ein weiteres Plus ist das Quick Sync API (Media SDK), was auch von LAV genutzt wird. Damit wird das Video wieder in den Hauptspeicher zurückkopiert. Und das mit vergleichsweise (vgl. DXVA-CB) wenig Overhead. Man kann Video also theoretisch in Software (CPU) nachbearbeiten und hat freie Wahl beim Video Renderer.

 

Der H.264 Encoder ist auch klasse. Leider gibt es dafür noch keine offene bzw. freie Implementierung. Wäre sicher ne coole Sache für Streaming mit dem RS.

Link to comment

Wobei bei den Scaling-Geschichten fraglich ist in welcher Umgebung die überhaupt eingesetzt werden können.

 

Im DVBViewer mit EVR CP derzeit nicht.

In MPC-HC mit EVR CP auch nicht.

 

 

@craig_s: SD Deinterlacing war okay? Ich hab schon gelesen, dass HD Deinterlacing von Intel super funktionieren soll, aber das es schwächen bei SD-Quellen gibt.

 

Bei den Intel Sandybridge "soll" (Status imho unklar) es ja noch Probleme bei der Ausgabe von 23,976hz Quellen geben.

Von daher war die AMD GPU vielleicht doch nicht ganz umsonst.

Quicksync als Decoder (ink. Deinterlacing) und 23,976hz Ausgabe über die AMD GPU sollte möglich sein.

 

Ab Ivybridge soll das auch mit Intel funktionieren (Status imho unklar). :bye:

Link to comment

Gilt das alles jetzt auch für eine HD2500?

 

Der 35 Watt Ivy Bridge I3 der kommen soll, hat ja nur eine HD2500...

 

Die 55 Watt Ivy Bridge CPUs ziehen wohl deutlich mehr Strom nehme ich an?

 

Ich hab keine Lust auf so nen Stromfresser in meinem nächsten HTPC :-)

Link to comment
Gilt das alles jetzt auch für eine HD2500?

Ja. Wie gesagt hängt Quick Sync nur sehr wenig von CPU und GPU ab (zumindest die Dekodierfunktion), weil es sich dabei um einen fast eigenständigen Co-Prozessor handelt, der sowohl auf der HD 4000 als auch der HD 2500 sitzt.

 

Der 35 Watt Ivy Bridge I3 der kommen soll, hat ja nur eine HD2500...

Richtig.

 

Die 55 Watt Ivy Bridge CPUs ziehen wohl deutlich mehr Strom nehme ich an?

Es handelt sich dabei um die maximale Leistungsaufnahme. CPU's werden heute hauptsächlich in Hinblick auf den mobilen Markt entwickelt. Dementsprechend ausgeklügelt sind die Stromsparmechanismen. Ich traue mich zu behauten, dass sämtliche Ivy Bridge CPU's im HTPC-Betrieb ca. gleich viel Strom aufnehmen. Der Unterschied ist, dass die größeren Varianten mehr rechnen können und dann natürlich auch mehr Strom aufnehmen.

Link to comment
SD Deinterlacing war okay? Ich hab schon gelesen, dass HD Deinterlacing von Intel super funktionieren soll, aber das es schwächen bei SD-Quellen gibt.

Wie gesagt hab alles durchprobiert, hat viele Stunden gedauert, selbstverständlich läuft SD in VA ganz normal durch. Auch TV-Stream im DVBViewer.

 

Bei LAV ists übrigens bei H.264 und MPEG2 egal ob man DXVA2 (native) oder Quicksync einstellt, läuft beides mit voller HW-Unterstützung (gleich niedriger Verbrauch in Watt). Bei CopyBack, Cuda und none zwar immernoch VA aber der Verbrauch geht von ~ 16W auf ~ 23W.

 

Bei den Intel Sandybridge "soll" (Status imho unklar) es ja noch Probleme bei der Ausgabe von 23,976hz Quellen geben.

Nein und nein! Sind wohl Gerüchte, evl. von anderen Setups?

 

 

Es handelt sich dabei um die maximale Leistungsaufnahme. CPU's werden heute hauptsächlich in Hinblick auf den mobilen Markt entwickelt. Dementsprechend ausgeklügelt sind die Stromsparmechanismen. Ich traue mich zu behauten, dass sämtliche Ivy Bridge CPU's im HTPC-Betrieb ca. gleich viel Strom aufnehmen. Der Unterschied ist, dass die größeren Varianten mehr rechnen können und dann natürlich auch mehr Strom aufnehmen.

Korrekt! Man sollte auf jedenfall drauf achten das der Core ix Prozessor die Turbo-Boost Technik beherrscht, dann regelt er sich bei niedriger Beanspruchung und dementsprechenden Einstellungen die man in den Energieoptionen vorgenommen hat, von selber auf ein Minimum runter. (Geht auch bei Desktop PCs).

 

Die Grafikleistung bei Video-"Lächerlichkeiten", selbst BLU-ray 3D juckt das überhaupt nicht, das ist ja das geniale. Erst bei Spielen ist "Höchstleistung" gefragt.

 

Glaube aber nicht das mit "in Hinblick auf den mobilen Markt entwickelt". Mehr Druck macht die Erderwärmung.

Link to comment
Mehr Druck macht die Erderwärmung.

War vor ein paar Jahren nicht anders. Trotzdem hat es mal einen P4 gegeben ;) .

 

Glaube aber nicht das mit "in Hinblick auf den mobilen Markt entwickelt".

Desktop-Verkäufe sind stark rückläufig. Notebooks/Ultrabook/Tablets beherrschen den Markt, wo die Akkulaufzeit eine wesentliche Rolle spielt.

 

Bei den Intel Sandybridge "soll" (Status imho unklar) es ja noch Probleme bei der Ausgabe von 23,976hz Quellen geben.

Dazu muss ich mir mal ein paar Gedanken machen und etwas zusammenschreiben. Ich glaube, das ganz Theme mit 0.00X Abweichung wird komplett überbewertet, bzw. sind die immer wieder durchgeführten Messungen mit MPC-HC und die daraus abgeleiteten Konsequenzen nicht korrekt.

Link to comment

Korrekt! Man sollte auf jedenfall drauf achten das der Core ix Prozessor die Turbo-Boost Technik beherrscht, dann regelt er sich bei niedriger Beanspruchung und dementsprechenden Einstellungen die man in den Energieoptionen vorgenommen hat, von selber auf ein Minimum runter. (Geht auch bei Desktop PCs).

 

Du meinst sicherlich nicht Turbo-Boost, sondern EIST. Das sind zwei unterschiedliche paar Schuhe, obwohl dabei im Gründe an der gleichen Schraube gedreht wird.

 

Nicht das jemand sich eine CPU mit Turbo (dei Bezeichnung hat es ohnehin in sich) kauft, um Energie sparen zu können, und dabei hätte es mit EIST gereicht. Eine Funktion die praktisch alle Intel CPUs seit 4-5 Jahren beherrschen.

Edited by blasgl
Link to comment

Ich werde mir wahrscheinlich den i3-3225 wegen der HD 4000 holen. Etwas Shader-Power in der Hinterhand ist doch schön und wenn sie gerade nicht benötigt wird, nimmt der Prozessor deswegen auch nicht mehr Leistung auf. Da werde ich aber erstmal den Multiplikator runtersetzen, dass er unter Last (nicht Turbo) bei um die 2.5GHz läuft. Mit meinem jetzigen C2D sehe ich, dass er auch im HTPC-Betrieb ab und zu in den Lastbereich springt. Das möchte ich etwas eindämmen, weil mit Sicherheit nicht so viel Rechen-Power benötigt wird (der i3-3225 macht unter Last defaultmäßig 3.3GHz) und so die Leistungsaufnahme unter Last reduziert werden kann. Die Spannung werde ich natürlich auch auf ein Minimum reduzieren, bei dem das System mit Prime noch stabil läuft.

Link to comment

Dazu muss ich mir mal ein paar Gedanken machen und etwas zusammenschreiben. Ich glaube, das ganz Theme mit 0.00X Abweichung wird komplett überbewertet, bzw. sind die immer wieder durchgeführten Messungen mit MPC-HC und die daraus abgeleiteten Konsequenzen nicht korrekt.

Sehe ich auch so.

Nur hat der Clarkdale stur 24,000hz ausgegeben (selbst überprüft mit externem VP) und das funktioniert einfach nicht (ohne reclock oder ähnliches).

Das ist ein Intelproblem seit die GPU's bauen.

 

Auch SB war davon zumindest teilweise betroffen was Intel auch selbst zugibt:

http://www.bit-tech.net/hardware/cpus/2011/10/10/all-about-ivy-bridge/6

 

Es gab dann zahlreiche Testseiten, die anhand der letzten Nachkommastelle periodische Ruckler ausgerechnet haben.

UAC und Treiber sollen darauf auch Einfluss gehabt haben. Diese Entwicklung hab ich dann nicht mehr verfolgt, da sehr wirr und für mich mangels passender hardware uninteressant.

Edited by nuts
Link to comment

Etwas Shader-Power in der Hinterhand ist doch schön und wenn sie gerade nicht benötigt wird,

 

nimmt der Prozessor deswegen auch nicht mehr Leistung auf.

 

Da werde ich aber erstmal den Multiplikator runtersetzen.dass er unter Last (nicht Turbo) bei um die 2.5GHz läuft. Mit meinem jetzigen C2D sehe ich, dass er auch im HTPC-Betrieb ab und zu in den Lastbereich springt. Das möchte ich etwas eindämmen, weil mit Sicherheit nicht so viel Rechen-Power benötigt wird (der i3-3225 macht unter Last defaultmäßig 3.3GHz) und so die Leistungsaufnahme unter Last reduziert werden kann. Die Spannung werde ich natürlich auch auf ein Minimum reduzieren, bei dem das System mit Prime noch stabil läuft.

 

Ich verstehe nicht, was Shader-Power mit Multiplikator mit Lastbereich zu tun hat.

 

Und berichte mal, wieviel Spannungsreduktion du mit dem 22nm-Teil schaffst. Bzw. wieviel Watt-Leistung das am Ende ausmacht. Falls du das messen kannst :bye:

Link to comment
Ich verstehe nicht, was Shader-Power mit Multiplikator mit Lastbereich zu tun hat.

Nichts. Ich will nur die CPU etwas langsamer machen und die Spannung reduzieren.

 

Es gab dann zahlreiche Testseiten, die anhand der letzten Nachkommestelle periodische Ruckler ausgerechnet haben.

Nur mal ein paar Gedanken dazu....

 

Nehmen wir an, wir verwenden ReClock... Graph-Clock basiert hier auf dem VSync, d.h. die Uhr, die für die Ausgabe zuständig ist (evtl. mit krummen 23.973Hz) ist hier auch für die Verarbeitung bzw. die Timestampgenerierung zuständig. D.h. es kann hier keinen Drift und somit keine Ruckler geben. Das habe ich schon mit meinem Renderer untersucht, bzw. habe ich da eine Radeon HD 6570 und deren Audio-Controller verwendet, die synchron mit dem VSync läuft, weil Audio- und Videoausgabe auf demselben Taktgeber basieren. Der Renderer verschluckt sich hier nie, weil die generierten Timestamps im DirectShow-Graph absolut synchron mit dem VSync laufen, weil gleiche Uhr. Egel wie krumm der VSync ist, solange die anderen mit demselben Takt laufen, spielt es keine Rolle.

 

Was ich mir evtl. vorstellen kann ist, dass es ein Problem sein kann, wenn die Grafikausgabe mit 23.973 Hz läuft und der TV intern mit exakten 23.976 Hz. Kann sowas sein? Dann könnte man vlt. erahnen, wie oft es im TV zu einem Glitch kommt. Aber auch nicht wirklich, weil der wahrscheinlich auch seine Toleranzen hat. Der Renderer bekommt sowas aber nie mit. Der arbeitet nur mit dem VSync der Grafikkarte. Die ganzen "Experten" wollen das Problem ja an der Glitch-Anzeige im Renderer festmachen. Das wäre dann aber eine andere Ursache als asynchron laufende Ausgabe in Grafikkarte und im TV.

Link to comment

Dem TV ist das völlig egal ob er 23,973 oder 23,976 bekommt, solange das innerhalb des Spezifikationen liegt was er annehmen kann (und das dürfte in dem Bereich immer gegeben sein).

 

Meine Gedanken dazu:

Für die Bitstream-Ausgabe muss man sich doch für die Directshow-Uhr direkt an die Quelle hängen, da sonst zwangsläufig drops/repeats auftreten und der VSync muss der Quelle entsprechen.

 

Ob in der MPC-HC Anzeige jetzt 23,978 oder was auch immer steht ist imho nicht so wichtig (eh fraglich wie exakt das ist).

Ich würde eher die Kurven vergleichen. Ohne zusätzliche Synchronisierung (sync renderer usw.) schneiden sich die Kurven zwangsläufig wenn da etwas nicht stimmt (und dann ruckelts ;) ).

Edited by nuts
Link to comment
Für die Bitstream-Ausgabe muss man sich doch für die Directshow-Uhr direkt an die Quelle hängen, da sonst zwangsläufig drops/repeats auftreten und der VSync muss der Quelle entsprechen.

S/P-DIF ist üblicherweise auf der Soundkarte. Die Uhr wird somit von einem anderen Taktgeber getrieben wie der VSync auf der Grafikkarte. Da hat man natürlich Probleme bei der Synchronisation. Deshalb fahre ich hier analog.

 

Bei HDMI sieht das anders, wie in obigem Fall mit der Radeon HD 6570 beschrieben (gilt für PCM- und Bitstream-Formate). Audio- und Video-Einheit sind auf demselben Chip und werden von einem gemeinsamen Taktgeber getrieben. Zudem wird auch die Graph-Clock von diesem Taktgeber getrieben.

Link to comment

Imho muss man das aber unabhängig voneinander betrachten.

Bei der Bitstream-Ausgabe kann die Geschwindigkeit nicht geändert werden! => Relation zur Quelle muss gegeben sein.

 

Der VSync hängt sich da jetzt nicht automatisch dran, sondern hängt von der gewählten Einstellung ab (23hz, 24hz, 60hz usw.).

Am VSync selbst lässt sich doch auch nichts drehen oder? Mal von den Ansätzen über Powerstrip abgesehen?

 

Eines der schwierigsten Themen bei der Mediawiedergabe am PC.

 

P.S. Mit Reclock und PCM Ausgabe lässt sich das natürlich schön umgehen.

Edited by nuts
Link to comment

Du meinst sicherlich nicht Turbo-Boost, sondern EIST. Das sind zwei unterschiedliche paar Schuhe, obwohl dabei im Gründe an der gleichen Schraube gedreht wird.

 

Nicht das jemand sich eine CPU mit Turbo (dei Bezeichnung hat es ohnehin in sich) kauft, um Energie sparen zu können, und dabei hätte es mit EIST gereicht. Eine Funktion die praktisch alle Intel CPUs seit 4-5 Jahren beherrschen.

Gebe offen zu von EIST noch nie was gehört zu haben, ahnte aber schon das es noch mehr als TurboBoost geben muß schliesslich dümpelt auch mein anderer i7 720QM (1,6 – 2,8 GHz) Laptop schon seit 2 Jahren im Idle mit 933 MHz vor sich hin bei 26W. Wie Cinch sich scheints erinnert bin ich damals direkt von nem P4 mit Wasserkühlung umgestiegen der zog glaube so um 120W, da waren 26W schon sehr erholsam.

 

Da ich eigentlich nie auf dem PC Ferngucke war es mir wichtiger für diverse Rechenaufgaben genug Reserven zu haben und da ist Turbo Boost praktisch, zieht immer genau so viel wie gerade gebraucht wird.

Das ein alter i7 mit immer aktiver Ati mobile HD5850 im Idle "satte" 10 Watt mehr zieht als ein "moderner" i5 (wenn Ati HD6630 aktiviert) ist mir in dem Fall gelinde gesagt völlig Wurscht.

Link to comment
Desktop-Verkäufe sind stark rückläufig. Notebooks/Ultrabook/Tablets beherrschen den Markt, wo die Akkulaufzeit eine wesentliche Rolle spielt.

Alter Rechthaber! Und warum haben verzweifelte (Groß-)Eltern, ihren Kindern die kleinen Spielzeuge geschenkt? Genau, wegen der rapide steigenden Stromrechnung. Habe allein 3 Beispiele in der Familie. Die hatten sich alle so kleine Verbrauchsmesser besorgt.

Mönsch, das ist doch alles mitnander verwoben. Und bis das lästige Thema Erderwärmung die Volksseele, Politiker und Stromrechnungen zum Kochen brachte das dauerte eben ne Weile. Sowieso in USA.

 

 

Es gab dann zahlreiche Testseiten, die anhand der letzten Nachkommestelle periodische Ruckler ausgerechnet haben.

Gebe zu bedenken das "moderne" Fernseher auch noch kräftig mitrechnen.

Habe extra wegen euch jetzt nochmal mehrere Sitzungen mit 1080p24 hinter mir, der MPC-HC zeigt immer brav 23,976 an und es ruckelt gar nichts.

 

Dann sogar noch im TV die Zwischenbildberechnung abgestellt, man sieht dann das klassische 24Hz ruckeln aber nichts darüber hinaus. PDVD12 kann bei Blu-ray auch ordentlich auf 23Hz (wird im Grafikkarten-Menü angezeigt) umstellen.

Tut mir leid, hätte gerne mehr Probleme gehabt um hier mitreden zu können..;)

 

 

Was ich mir beim AV-Receiver wünschte wäre eine automatische Umstellung der Audioverzögerung bei incoming 24Hz. Weil da der TV das Bild ca. 200ms mehr verzögert als bei 50/60Hz. Kann der AVR aber leider nicht. Müsste immer manuell umstellen, bin ich aber öfter zu faul dazu.

 

Je nach Film schaue ich 24Hz deshalb auch gerne mit 60Hz im TV. Der rechnet so genial um bzw. hat so viel Kapazität zum Zwischenspeichern das nur bei seltenen Schwenks selten ein einziger Ruckler zu sehen ist. Damit kann ich gut leben und fällt sowieso keinem ausser mir auf.

Edited by craig_s
Link to comment
Bei der Bitstream-Ausgabe kann die Geschwindigkeit nicht geändert werden! => Relation zur Quelle muss gegeben sein.

Stimmt. Ich gehe zwar immer von der Situation aus, bei der Quelle und Ausgabe mit mehr oder weniger derselben Geschwindigkeit angegeben sind. Bei HDMI bestimmt die GPU den Takt für alles. Sie gibt ihn für Audioausgabe, Videoausgabe und auch die Verarbeitung im Graph (Timestamps) vor. Somit sind alle glücklich, zumindest bei Dateiwiedergabe. Das gilt dann sowohl für PCM als auch Bitstream über HDMI. In diesem Fall muss keine Geschwindigkeit angepasst werden.

 

Bei Streaming kann es sein, dass ein zur Streamgeschwindigkeit (Uhr des Enkoders) synchronisierter Source-Filter zum Einsatz kommt (z.B. DVBSource, wenn die DVB Clock aktiviert ist). Hat man dann auch noch eine dedizierte Soundkarte, hat man 3 Uhren die zwangsweise voneinander Driften, GPU-Uhr für die Videoausgabe, Soundkarten-Uhr für die Audio-Ausgabe und Graph-Uhr für die Verarbeitung bzw. Timestampgenerierung (e.g. DVB Clock). In so einem Fall ist es auch bei subtilen Abweichungen erwünschenswert, dass die Audiogeschwindigkeit angepasst wird, was, wie du auch schon gesagt hast, mit Bitstream nicht leicht realisierbar ist. Im DVBSource kann man aber die DVB Clock abschalten. Da kann es dann halt passieren, dass es im DVBSource zu Buffer Overflows (Stream schneller als Verarbeitung und Ausgabe) oder Underruns (Stream langsamer als Verarbeitung und Ausgabe) kommt. Im Normalfall sollte das aber erst nach ein paar Stunden ununterbrochener Wiedergabe auf einem Kanalpassieren, je nach Puffergröße und Abweichung der Uhren halt.

Link to comment

Bei HDMI bestimmt die GPU den Takt für alles. Sie gibt ihn für Audioausgabe, Videoausgabe und auch die Verarbeitung im Graph (Timestamps) vor. Somit sind alle glücklich, zumindest bei Dateiwiedergabe. Das gilt dann sowohl für PCM als auch Bitstream über HDMI. In diesem Fall muss keine Geschwindigkeit angepasst werden.

Naja theoretisch. Bei Intel (Clarkdale, SB) scheint es da ja noch verschiedene Probleme zu geben (s. Link).

Der gleiche Taktgeber bedeutet nur, dass die unterschiedlichen Uhren nicht mehr driften.

Gleichschnell sind sie deshalb nicht zwangsläufig.

 

Die Directshow-Clock kann sich z.B. auch stur an den VSync heften.

Dann kann man die Audiogeschwindigkeit (PCM, analog) an den VSync anpassen und es ruckelt nie.

Oder man wiederholt oder verwirft Pakete (bitstream), was zu hörbaren Artefakten führen kann.

Oder man macht gar nichts und der A/V Sync ist nichtmehr gegeben (imho sehr unschön).

edit\

Oder es passt ziemlich genau, dass keine Probleme auftreten (oder nur nach sehr langer Zeit).

Hier scheint Intel ja was verbessert zu haben.

 

Muss man sich alles nochmal im Detail anschauen wenn die Ivy's verfügbar sind.

 

 

P.S. @craig_s: hat dein AVR kein auto-libsync? Ich meine der soll bei Hdmi-Verbindungen Verzögerung durchs Processing ausgleichen.

Edited by nuts
Link to comment

Ich hoffe, ich komme am WE mal dazu ein paar Tests mit Sandy Bridge zu machen. Das entsprechende Micro-HDMI Kabel habe ich schon...

Link to comment

Außerdem... Intel unterstützt doch Custom Timings...

 

customresolutionsadvanced.jpg

 

Damit kann man doch den VSync verschieben, indem man den Porch (sprich die Anzahl unsichtbarer Zeilen) vergrößert!?

Link to comment

Zumindest funktioniert der Ansatz (den ich am PC übrigens für den besten halte) vom EVR Sync renderer ja auch so:

http://www.ostrogothia.com/?page_id=1216

 

Also theoretisch ja.

Man muss halt sehen was letztendlich dabei rauskommt.

Die 23hz Einstellung ändert ja auch "irgendwas". Das UAC eine Auswirkung hat wird teilweise auch berichtet (wobei mir das völlig schleierhaft ist).

Ausprobieren am Wochenende! :)

Edited by nuts
Link to comment

Aber das Problem löst man dadurch wohl nicht. Die Framerate kommt IMHO deshalb zustande, weil die Clock halt falsch geht. Durch Verlängerung des Frame Intervals löst man das Clock Problem nur für Video, nicht aber für Audio, weil die Clock ja immer noch gleich schief geht. D.h. das Problem (was meiner Meinung nach keines ist, wenn im Graph eine gemeinsame Clock für alles verwendet wird) verschlimmert man dadurch.

 

Und wie du auch schon richtig gesagt hast, ist die Messung mittels MPC-HC auch fragwürdig.

Link to comment

Also UAC ist bei mir aus und Aero auch aus wegen Design.

 

Da der TV alle gängigen Framerates zu beherrschen scheint hab ich wohl auch das "Synchronization"-Menü im MPC-HC nicht gebraucht?

 

 

P.S. @craig_s: hat dein AVR kein auto-libsync? Ich meine der soll bei Hdmi-Verbindungen Verzögerung durchs Processing ausgleichen.

Hast du damit Erfahrungen? auto-libsync ist bei mir eingeschaltet, scheint aber nichts zu bewirken.

 

Ich frage mich ob das so ne ausgefeilte Technik sein kann die Lippen liest oder bemerken, dass das dahinter geschaltete Gerät gerade die fette Zwischenbildberechnung zuschaltet? Deren Verzögerung kann sich ja auch von TV zu TV unterscheiden. Oder der TV müsste dem AVR mitteilen: 'achtung, ich verzögere jetzt statt 100 -> 300ms', ob er das überhaupt so genau weiss?, hmmm...

 

Allerdings habe ich im AVR (Denon) diese "Automatische Einmessung" nicht vorgenommen weil mein Audio schon eingemessen war. Lautstärke und mehr kann man ja für alle Kanäle getrennt auch manuell einstellen.

 

Evl. verhindert das aber die Funktion von auto-libsync? Irgendwann muss ich mich wohl nochmal durch dieses schlecht dokumemtierte und hochkomplizierte Prozedere des Denon durchbeissen. Aber erst wieder in einer kalten Winternacht...

Edited by craig_s
Link to comment

Also UAC ist bei mir aus und Aero auch aus wegen Design.

 

Da der TV alle gängigen Framerates zu beherrschen scheint hab ich wohl auch das "Synchronization"-Menü im MPC-HC nicht gebraucht?

Meinst du den EVR Sync?

Der beschäftigt sich mit den hier diskutierten Problemen (Details stehen im Link ein paar Post vorher).

 

Oder der TV müsste dem AVR mitteilen: 'achtung, ich verzögere jetzt statt 100 -> 300ms', ob er das überhaupt so genau weiss?, hmmm...

So ca. sollte das ablaufen.

Die Berechnungsdauer wird konstant gehalten und dem TV oder dem AVR (je nachdem in welche Richtung es gehen soll) mitgeteilt.

Beschäftigt hab ich mich damit auch noch nicht näher, schien aber zu deinem Problem zu passen.

Link to comment

Siehe Post #1, habe immer nur mit EVR getestet, weisst ja, nur mit dem geht DXVA in Win7. In MPC-HC mit den 3 versch. EVR die man dort auswählen kann.

Tiefer in die Einstellmöglichkeiten der EVR vorgedrungen bin ich aber wenig, Bicubic brachte noch etwas Ersparnis. Alternativer Sync geht auch, nur noch Tastaturbedienung in MPC-HC ist aber lästig...

Edited by craig_s
Link to comment

Ich hoffe, ich komme am WE mal dazu ein paar Tests mit Sandy Bridge zu machen. Das entsprechende Micro-HDMI Kabel habe ich schon...

..dann probier auch mal den erweiteren Farbraum: xvYCC - "Empfohlen für digitale Displays" - erscheint im Menü nur wenn das Display es untertützt.

 

t420s-intel-gfx-general-tv-xvYcc.gif

(Bild stammt von einem Lenovo)

 

 

Erzeugt mit meinem LED-TV einen tiefschwarzen Schwarzwert und ein irre knackiges Bild. Springt sofort ins Auge und möcht man nicht mehr missen. Musste dann aber die Helligkeit im Monitor schrittweise erhöhen weil die unteren Grauwerte sind mit dem Schwarzwert auch ein Stück abgesoffen. Bisschen Feinarbeit brauchts, lohnt sich aber!

 

Offenbar ist das eine "Sorte" Farbraum die mit der von dir zitierten "HW-Deinterlacing nur mit NV12 Farbraum"-Regel nix zu tun hat weil DXVA funktioniert unverändert.

Auch wird im Dell der Farbraum "durchgereicht" wenn die Ati zugeschaltet, auch damit geht DXVA und VA.

 

Ati's können ja auch xvYCC aber so schwarz war's noch nie. Oder ich hab nur nicht gefunden wo man das im CCC aktiviert?

Edited by craig_s
Link to comment

Was macht diese Option denn genau? Wirklich xvYCC oder nur eine Tonwertspreizung (auf 0-255)?

 

xvYCC ist ein Farbraum der so eigentlich nicht vor kommt (DVB, DVD, Bluray).

Der Decoder (wahrscheinlich NV12)und der Renderer (RGB) arbeiten damit nicht, d.h. das ist höchstens eine Transformation vor der Ausgabe (das lässt sich übrigens mit graphstudio untersuchen).

 

Wird 0-255 ausgegeben und dein TV erwartet 16-235 suggeriert das erstmal besseres schwarz, knackigere Farben usw..

"Richtig" ist das aber nicht. Eine Nebenwirkung ist, dass eben Graustufen im schwarz absaufen.

 

Gut testen kann man das mit den Testquellen aus dem AVS-Forum:

http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration

 

Soll heissen: An der Stelle muss man etwas aufpassen! Erlaubt ist was gefällt, aber ich würde (wenn möglich) am PC immer RGB 0-255 ausgeben.

 

P.S. Was der TV erwartet lässt sich je nach TV auch einstellen. Welchen hast du denn?

Edited by nuts
Link to comment

--> xvYCC Wiki hier

 

Tonwertspreizung (auf 0-255) findet bei der Intel-Soft im Monitor-Menü statt, was man dort bei "Quantifizierungsbereich" einstellen kann ("Voll" für gesamten RGB-Bereich und "Begrenzt") hat ganz andere Auswirkungen im Bild als xvYCC.

 

 

hdmidvi.jpg

 

 

Zur Anwendung: die Umschaltung auf xvYCC scheint noch ein bisschen buggy, allerdings schwer zu sagen ob das am TV oder an der Intel-Soft oder beiden liegt - sie findet öfter nicht statt, besonders wenn man 2x hin- und herschaltet bleibt xvYCC bei mir oft aus trotz Haken.

Abhilfe: im Laptop mittels Tastenkombi "Win + P" kurz zum internen Moni umschalten und wieder zurück, dann ist immer das aktiv was angehakt.

 

Mein TV: Samsung UE46D8000 - die Samsungs unterstützen xvYCC scheints schon seit geraumer Zeit, Panasonics auch.

 

Wegen "Farben nicht original" oder so brauch ich mir keinen Kopf zu machen, hänge schon seit langem tief in der Bild-Nachbearbeitung und kann mich auf meine Augen verlassen. Deswegen hab ich ja auch gleich mit Greyscale die unteren Werte wieder raufgeholt. Es ist nicht so, das mit xvYCC nun aus beige gelb wird oder so was krasses. Der Gesamteindruck der Farben ist einfach lebendiger.

 

Wie du schon sagtest, oh Zweifler, natürlich ist das Geschmackssache und vor allem eine Sache der bisherigen Sehgewohnheiten, da hat jeder andere und soll selber entscheiden was ihm guttut :)

 

 

Der Decoder (wahrscheinlich NV12)und der Renderer (RGB) arbeiten damit nicht, d.h. das ist höchstens eine Transformation vor der Ausgabe (das lässt sich übrigens mit graphstudio untersuchen)

wie?

 

"vor der Ausgabe" - oder nach dem Renderer auch möglich?

Edited by craig_s
Link to comment

Ah ok. Also xvYCC wird ausgegeben.

Greift dann die Einstellung "Quantifizierungsbereich" überhaupt noch? Kann doch eigentlich nicht sein?

 

Per Graphstudio kann man zu jedem Filter (conncect to remote graph) die Eigenschaftsseite (rechtsklick) aufrufen. Dort sind auch Infos zum Farbraum.

Die RGB-Transformation (EVR) findet im Renderer statt (auf 0-255).

Alles andere ist dann blackbox (xvYCC, YCbCr, Videolevel usw.) und nicht mehr nachvollziehbar.

Im Prinzip ist das aber eine unnötige Umwandlung. Die Displays (Panels) werden ja auch mit RGB angesteuert.

 

Soweit zur Theorie. :)

Es gibt auch Setups bei denen es sich anbietet etwas anderes als RGB 0-255 auszugeben. z.B. wenn der TV kein RGB 0-255 versteht (leider sehr verbreitet).

 

P.S. Beim Samsung lassen sich die Helligkeitslevel im Bildmenü unter "Hdmi Schwarzwert" oder "Hdmi blacklevel" oder so ähnlich einstellen (gering/low 0-255 normal 16-235).

Edited by nuts
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...