Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsIntel Kaby Lake: Hardware-Unterstützung für 10-Bit HEVC und VP9 bestätigt
@Pitt_G.: Die Grafik zeigt den Stand von Skylake, nicht Kaby, wenn ich nicht stark irre. HEVC Main 10 und VP9 war zu dem Zeitpunkt noch nicht vollständig in Hardware integriert und wurde über die GPU decodiert. Alles andere ohne Sternchen direkt über die CPU. Das ist was damit gemeint war wenn gesagt wurde dass Skylake "teilweise" Hardwarebeschleunigung für HEVC Main 10 hat.
Für Kaby gilt das nicht mehr, da hätte die Grafik überall ein "Yes" ohne Sternchen, bis auf VP9 Encode. Das ist nach wie vor nicht integriert, aber das wird den wenigsten abgehen.
@Pitt_G.: Die Grafik zeigt den Stand von Skylake, nicht Kaby, wenn ich nicht stark irre. HEVC Main 10 und VP9 war zu dem Zeitpunkt noch nicht vollständig in Hardware integriert und wurde über die GPU decodiert. Alles andere ohne Sternchen direkt über die CPU. ...
@Pitt_G.: Die Grafik zeigt den Stand von Skylake, nicht Kaby, wenn ich nicht stark irre. HEVC Main 10 und VP9 war zu dem Zeitpunkt noch nicht vollständig in Hardware integriert und wurde über die GPU decodiert. Alles andere ohne Sternchen direkt über die CPU. Das ist was damit gemeint war wenn gesagt wurde dass Skylake "teilweise" Hardwarebeschleunigung für HEVC Main 10 hat.
Für Kaby gilt das nicht mehr, da hätte die Grafik überall ein "Yes" ohne Sternchen, bis auf VP9 Encode. Das ist nach wie vor nicht integriert, aber das wird den wenigsten abgehen.
Steht doch auch drunter, dass es sich auf Skylake bezieht (Zitat: "Skylake beschleunigt noch nicht alles via Hardware (Bild: Intel)"), zudem ist unten rechts auf dem Bild ein IDF15-Logo
Meine Erwartungen an die Kaby Lakes sind leider ziemlich im Keller. Sie bieten eigentlich nur das, was Intel schon mit den Skylakes hätte bieten können und sollen. Sie dienen lediglich dazu, die Lücke zur neuen 10 nm-Generation zu füllen.
Nächstes Jahr wird dafür umso interessanter 10 nm CPUs, 3D Xpoint, neue Grafikkarten mit HBM2 (bzw. bessere Preise für die aktuellen Neuen), ggf. PCI-Express 4.0, vermutlich deutlich günstigerer DDR4-Ram, etc.
Wenn du im Datasheet auf Seite 32 schaust dann wird nur HEVC 8-bit für Skylake erwähnt. Ansonsten kann ich mich nur auf Artikel wie diesen beziehen.
@SaschaHa: Das haben du und ich gelesen, aber offensichtlich nicht jeder. Fakt ist dass die Grafik von Skylake im Artikel über Kaby auf den ersten Blick durchaus verwirrend ist. Ich hab die Bildunterschrift auch erst gelesen als ich mir dachte dass mir die Grafik irgendwie vertraut vorkommt.
Was angekommen ist hat mit dem speziellen Markt zu tun....Das hat mit dem Monitor nix zu tun. 10bit gibts schon bei h.264 und ist z.B. in der Anime Szene schon seit vielen Jahren Standard. Der Vorteil von 10bit encoding ist: weniger Platzbedarf bei gleicher Qualität. Der Codec unterstützt 10bit schon seit AVC.
Ich bin kein Experte. Allerdings glaube ich, dass du da was durcheinander wirbelst: 10 Bit gibt die Farbtiefe an und hat erst mal nichts mit der Größe der Datei zu tun. Im Gegensatz zu seiner Annahme ist eher mit einer größeren Datei zu rechnen. Außerdem wird die de- und en-codierung dadurch anspruchsvoller.
Um von einer 10-Bit-Farbwiedergabe zu profitieren, brauchst du definitiv einen passenden Monitor. Ansonsten kannst du die unmittelbar daraus resultierenden Vorteile nicht sehen.
Um ein Video bei gleicher Qualität stärker komprimieren zu können, braucht man einen besseren Codec und hat nichts mit der Farbtiefe zu tun.
EDIT: Tatsächlich lag ich falsch, bitte in meinem späteren Post hier lesen.
Allerdings glaube ich, dass du da was durcheinander wirbelst: 10 Bit gibt die Farbtiefe an und hat erst mal nichts mit der Größe der Datei zu tun. Im Gegensatz zu seiner Annahme ist eher mit einer größeren Datei zu rechnen.
Um von einer 10-Bit-Farbwiedergabe zu profitieren, brauchst du definitiv einen passenden Monitor. Ansonsten kannst du die unmittelbar daraus resultierenden Vorteile nicht sehen.
Um ein Video bei gleicher Qualität stärker komprimieren zu können, braucht man einen besseren Codec und hat nichts mit der Farbtiefe zu tun
Auch falsch. Völlig egal ob man die 10bit Farbtiefe auf dem Anzeigegerät auch ausgibt oder vorher auf 8bit runterdithered, verhindert man durch die Speicherung mit 10-Bit Banding-Artefakte.
Extremfall als Beispiel:
10bit Videos sind also auch mit 8bit Anzeigegeräten nicht nur sparsamer, sondern auch qualitativ besser als 8bit Videos.
Das Bild gehört zu Skylake, wo das decoding von 10 bit HEVC Material eben nur mit einem Hybrid aus CPU und GPU möglich ist/war. Kabylake hat dafür richtigen Hardware support, die Media Engine von Quicksync kann das viel effizienter und schneller decoden.
Jetzt muss Intel nur noch ihre neuen NUCs mit HDMI 2.0 ankündigen und ich kann mein NUC D34010WYK in Rente schicken. Bei 4K mit HEVC geht dem die Puste aus.
Auch falsch. Völlig egal ob man die 10bit Farbtiefe auf dem Anzeigegerät auch ausgibt oder vorher auf 8bit runterdithered, verhindert man durch die Speicherung mit 10-Bit Banding-Artefakte.
Extremfall als Beispiel: Anhang anzeigen 563154
10bit Videos sind also auch mit 8bit Anzeigegeräten nicht nur sparsamer, sondern auch qualitativ besser als 8bit Videos.
OK danke für die Klarstellung. Ich habe ein wenig recherchiert und tatsächlich sind 10-bit-Videos sparsamer. Das verstehe ich zwar nicht, aber nehme es mal zur Kenntnis.
Das gleiche mit der der 10-Bit-Speicherung und Wiedergabe auf einem 8-Bit-Panel. Die Qualität scheint tatsächlich besser zu sein.
Naja, 8bit + Dither brauchen mehr Speicherplatz als 10bit Farbkodierung wo Dither nicht mehr nötig ist. Der Overhead durch ins Video eingebrachte Dither schlicht höher als die erhöhte Farbauflösung. Würdest du Dither bei 8bit weglassen wären diese Videos kleiner als jene mit 10bit, dafür würdest du aber sehr deutlich Farbabstufungen sehen.
Wer Leistung will gießt in Hardware. Man mutet Packet Processing im Netzwerk auch keiner CPU an, außer im Soho.
Wattwanderer schrieb:
Mathe Coprozessor in die CPU verstehe ich ja. Ebenso bei ARM wo nicht genügend Energie vorhanden ist um Multimediadaten in Software zu verarbeiten oder Grafikkarten für ganz spezielle Aufgaben aber sonst?
Der Video Prozessor ist ja unabhängig von der GPU. Bei Skylake kann dieser aber kein HVEC 8bit und VP9, das wird in die GPU ausgelagert. Das wird jetzt auch in den Video ASIC gegossen.
Klar, ist eben die Frage wie schnell und energieeffizient es gelöst wird.
Master Sheep schrieb:
Der Unterschied zwischen CPU- und GPU-(En-)Codierung ist, dass die GPU das viel schneller hinbekommen kann. 4k, 10 bit 60 fps treibt auch moderne i7-Desktop-CPUs ohne Hardwarebeschleunigung an ihre Grenzen.
Naja hier geht es eher darum, was wird von der GPU über die Shader berechnet oder was über fixed Function Units. CPU ist ja außen vor. Über Software kann ich alles decodieren.
predator7 schrieb:
Werden die Intel Chipsätze für Kaby Lake auch Usb 3.1 sowie den Type C Anschluss anbieten?
Der Typ C Connector hat ja nichts mit dem Chipsatz zu tun. Den kann dir auch jeder an ein Pentium 4 Board verbauen wenn er lustig ist. Da brauchts keinen speziellen Support des Chipsatzes oder der CPU.
USB 3.1 hat es laut bisherigen Gerüchten nicht in den neuen PCH geschafft. Aber ich habe auch schon einzelne gegenteilige Gerüchte gelesen.
ottoman schrieb:
Wird dann wenigstens auch mal HDMI 2 unterstützt? Mittlerweile ist das nur noch peinlich von Intel.
Oh ja, sehr peinlich. Wer war denn schneller? AMD mit Fiji oder Carrizo? Oh ne.
Nur Nvidia hat das schon zu dem Zeitpunkt realisiert.
So ein CPU design steht schon lange vor Release. Da ist es normal, das nicht direkt alle neuen Standards unterstützt werden können.
Und ja, mit KabyLake wird auch HDMI 2.0 unterstützt.
Pitt_G. schrieb:
also das mit dem GPU decode finde ich schon interessant, heisst, das denn dass fast alle Codecs gar nicht wirklich HW beschleunigt laufen???
Mh? Da steht doch überall ein yes, also ists HW beschleunigt.
Ergänzung ()
Wattwanderer schrieb:
Weiss nicht was ich davon halten soll Software in Hardware zu gießen.
Mathe Coprozessor in die CPU verstehe ich ja. Ebenso bei ARM wo nicht genügend Energie vorhanden ist um Multimediadaten in Software zu verarbeiten oder Grafikkarten für ganz spezielle Aufgaben aber sonst?
Aha und bei 4W Kabylake SoCs die in Tablets verbaut werden ist Energieeffizienz egal?
Vor allem warum soll ich meine CPU mit >50% auslastung beim abspielen von Videos quälen um dann nichts anderes nebenher zu machen, wenn es auch durch so Mini HW-Decoder geht?
Ich wüsste nicht einmal, worin der Vorteil von 10bit bestehen sollte in den kommenden 5-10 Jahren.
Schließlich wird dafür eine Unterstüzung durch sämtliche Bestandteile der Soft- und Hardware vorausgesetzt.
Und selbst danach, wenn es theor. zumindest funktionieren würde, weil man dann endlich alle Hardware haben sollte und es auch entsprechenden Content geben würde, ich wage zu bezweifeln, dass man im Bild auch nur einen hauchfeinen Unterschied erkennen wird.
Dann lieber den Speichermehrverbrauch in eine höhere Bitrate investieren, das bringt sicher mehr, oder auf den Spewichermehrverbrauch einfach verzichten!
Also außer in der professionnellen Bildbearbeitung kann ich mir kein Vorteil von 10bit vorstellen... schon gar nicht in komprimierten Videos, ihr?
Ich wüsste nicht einmal, worin der Vorteil von 10bit bestehen sollte in den kommenden 5-10 Jahren.
Schließlich wird dafür eine Unterstüzung durch sämtliche Bestandteile der Soft- und Hardware vorausgesetzt.
Auch falsch. Völlig egal ob man die 10bit Farbtiefe auf dem Anzeigegerät auch ausgibt oder vorher auf 8bit runterdithered, verhindert man durch die Speicherung mit 10-Bit Banding-Artefakte.
Dann lieber den Speichermehrverbrauch in eine höhere Bitrate investieren, das bringt sicher mehr, oder auf den Spewichermehrverbrauch einfach verzichten!
Ja, kann ich mir absolut vorstellen weil es in der Anime-Szene schon seit mehreren Jahren Standard ist um Banding-Artefakten entgegen zu wirken und gleichzeitig ~15% Dateigröße einzusparen.
Ja, kann ich mir absolut vorstellen weil es in der Anime-Szene schon seit mehreren Jahren Standard ist um Banding-Artefakten entgegen zu wirken und gleichzeitig ~15% Dateigröße einzusparen.
Das ist wirklich verrückt.
Komplett entgegen des Wissens, was ich bisher dachte zu haben.
Insofern ist das ein guter Anlass für mich, mich demnächst mal in dieses doch etwas komplexere Thema einzuarbeiten.
Aber google scheint es zu bestätigen.
1. Banding in 3x8bit=24bit: ich war immer der festen Überzeugung, seit es keine 16bit-Bilder mehr gibt, sei das Thema Banding komplett vom Tisch! Dem ist wohl nicht so... erklären kann ich es nicht, aber es scheint so zu sein...
Man hat ja immerhin pro Farbkanal ganze 8^2=256 Farbabstufungen, was in der kompletten 24bit-Bilddatei dann schließlich zu ganzen 16,7 Millionen möglichen Farben führt.
Ein Bandingproblem würde ich da nicht mehr vermuten.
Selbst, wenn man sehr spezielle Bedingungen einführt und ein Bild nur mit EINEM Farbkanal darstellen möchte, hat man immernoch 256 Abstufungen!
Das menschliche Auge kann nur um die ca. 200 Abstufungen wahrnehmen.
Daher verstehe ich auch überhaupt nicht, wie es in Wikipedia zu diesem Bild hier kommen kann, was im Thread vorher bereits als Beispiel für eine 8-bit-Grafik gebracht wurde:
Der Gradient ist in dem Bild extrem grob und m.E. mit Sicherheit keine echte Datei mit 8bit pro Farbkanal, weil damit sollten 256 Abstufungen pro Farbe (hier rot) möglich sein und nicht nur die abgebildeten 6 Stufen.
Liegt hier evtl eine Verwechslung vor?
Kann es sein, dass es sich in Wirklichkeit um eine Datei mit weniger als 8bit pro Farbe handelt?
Dennoch bleibt der Fakt bestehen, auch wenn ich es nicht so komplett durchschaut habe:
Banding ist ein der Fotografie definitiv ein Thema unter 8bit-pro-Farbkanalbildern.
Habe auch noch mal nachgesehen, mein Lightroom arbeitet standardmäßig mit ganzen 16bit pro Kanal.
Ich denke, dafür wird sicher nicht der einzige Grund sein, dass man die zusätzlichen Reserven für die Bearbeitung benötigt (wenn man ein Bild deutlich aufhellt, dann werden die wenigen Bits, die zuvor dunklen Bereichen zugeordnet waren "gestreckt", während alle helleren Bereich komplett im Weiß absaufen bzw "abgeschnitten" werden und man erhält sehrsehr schnell sichtbares Banding) ....
Also mein bisheriger Stand ist:
eigentlich müssten 8 bit für Videos ausreichen, sofern man sie nicht bearbeiten möchte, v.A. Aufhellen/Abdunkeln wird ein großes Problem darstellen.
Möchte man Videos auch bearbeiten, dann sind 10bit jedoch nur ein Tropfen auf den heißen Stein und selbst 16 bit kommen schnell an ihre Grenzen, wie ich es täglich in der Bildbearbeitung sehen kann.
Wobei ich ehrlicherweise sagen muss, dass Nikon-Sensoren m.W. "nur" mit 12bit pro Farbkanal aufzeichnen, was noch sehr weit von den 16 bit in der Bearbeitung weg ist.
Allerdings würde ich das wirklich gerne verstehen, wieso 8bit auch für die reine Wiedergabe nicht ausreichend sein sollen.
Ihr dürft nicht vergessen, wir leben für die reine Wiedergabe von Bildern in einer reinen 8bit Welt.
Mit JPG ist es gar nicht möglich Bilder mit mehr als 8bit überhaupt zu speichern.
Und das reicht auch für die reine "Wiedergabe", ohne die Absicht irgendetwas zu bearbeiten, völlig aus.
Niemand vermisst mehr bits in jpg.
Wenn ich in google "8bit vs 10bit" eingebe, kommen immer nur Ergebnisse, die die Nachteile von 8bit in der Bearbeitung beschreiben.
2. Speicherverbrauch
Bisher war es IMMER so, dass mehr Bittiefe auch automatisch zu mehr Speicherverbrauch geführt hat!!
Das eine kann man unmöglich ohne das andere bekommen, sorry, aber das ist Mathematik!
Will man mehr Bittiefe, braucht man mehr bits!
Mehr Bits (Kompression hin oder her) verbrauchen logischerweise auch mehr Speicher!
Sorrysorrysorry, wenn jemand das Gegenteil behauptet, dann muss er mir das erst mal beweisen, sonst gehe ich entweder von Magie oder einem schlichten Täuschungsmaneuver aus.
Die als Beispiel gezeigte PDF versucht zu beschreiben, wieso man weniger SPeicher verbraucht mit 10-bit-Encoding.
Aber wenn ihr mich fragt, wird hier ein "Marketingtrick" verwenden, um zu suggereieren 10bit-Kompression würde weniger Speicher brauchen, als 8bit!
Der Trick besteht darin, dass man jeweils eine 10bit-Videodatei encodiert/decodiert, einmal mit einer 8bit-Kompression und einmal mit einer 10bit-Kompression.
Dann wird Qualität und Speicherverbrauch verglichen und die 10bit-Kompression als überlegen dargestellt.
Das mag ja auch für eine 10bit-Quelle ganz richtig so sein.
Praxisnah wäre jedoch eine 8bit-Quelle in einem 8bit-Prozess zu komprimieren, so wie es heute üblich ist und wie ich finde auch ein hervorragendes Bildresultat liefert, das m.E. keiner weiteren Steigerung mehr bedarf.
Ganz ehrlich, habt ihr euch schon mal einen gut komprimierten Film angesehen und musstet irgendwo Banding im Bild erkennen????
Jemals???
Von daher wäre das der korrekte und absolut faire Weg, dass man dann auch mit Bildqualität und Speicherverbrauch im KOMPLETTEN 8bit Prozess mit einem KOMPLETTEN 10 bit Prozess vergleicht... ganz ehrlich, eine 10bit-Datei in einem 8bit Prozess zu komprimieren ist NATÜRLICH Quatsch und führt natürlich zu mehr Speicherverbrauch als im 10bit Prozess.
Ich glaube auch nicht, dass jemand ohne technische Hilfmittel einen qualitativen Unterschied zwischen einem 8bit Video und einem 10bit Video erkennen kann.
Würde man jetzt eine 8bit Videodatei in einem 8 bit-Komprimierungsprozess und eine 10bit Videodatei in einem 10bit Komprimierungsprozess mit einander direkt vergleich, würde man m.E. keinen Qualitätsunterschied feststellen und zugleich bemerken, dass das 8bit Video deutlich kleiner ist.
Aber das ist jetzt wirklich nur mein derzeitiger Stand, kann sein, dass ich komplett daneben liege.
Falls jemand mich da aufklären könnte, wäre ich daher wirklich sehr dankbar...
Ergänzung ()
Leute vergesst, was ich oben geschrieben habe.
Ich lasse das jetzt mal so stehen, weil vom Prinzip her stimmt es ja, wenn man das "hardcode Dithering" weg lassen würde.
Heutzutage ist es jedoch scheinbar Standard, dass man 8bit-Dateien ein Hardcode Dithering hinzufügt und das schluckt je nach Quellmaterial scheinbar ordentlich Speicher und vergrößert die Datei deutlich über die erwarteten 3x8bit pro Pixel hinaus!
Bei 10bit-Dateien ist das "hardcode Dithering" komplett überflüssig.
Unterm Strich verbraucht das "hardcode Dithering" jedoch mehr Speicher, als man für die zusätzlichen 2 bit im 10bit-Prozess braucht, deswegen ist auch eine 10bit-Datei kleiner als eine 8bit-Datei mit "hardcode Dithering".
Die Mathematik bleibt dabei auch weiter im Recht, denn eine reine 8bit Datei ohne "hardcode Dithering" ist auch kleiner, als eine 10 bit Datei.
Jetzt ergibt alles einen Sinn!
Übrig bleibt für mich nur die Frage, wie wichtig Dithering überhaupt ist.
10 nm CPUs, 3D Xpoint, neue Grafikkarten mit HBM2 (bzw. bessere Preise für die aktuellen Neuen), ggf. PCI-Express 4.0, vermutlich deutlich günstigerer DDR4-Ram, etc.
