Videos mit GPU Unterstützung konvertieren. Aber Wie?

[De-M-oN]

Der x264 Benchmark ist witzlos. bei 3.19 wird eine x264 version von 13xx (vergessen welche genau) verwendet, die so dermaßen uralt ist, das diese noch nicht mal CABAC besitzt.

Aktuelle Version ist 1995!

Und ja in der Zeit hat sich verdammt viel getan.

http://mirror02.x264.nl/x264/changelog.txt

Der 4.0er Benchmark wäre da schon wesentlich aussagekräftiger mit ner 1913 Version wenigstens

http://www.techarp.com/showarticle.aspx?artno=520

 

[mumpel]

Is' ja auch egal. Was man da ganz einfach sieht ist, dass beim Encodieren mit den beiden Programmen das Ergebnis ganz gut mit der Anzahl der Kerne skaliert. Also ist paralleles Encoden möglich und bringt auch eine Menge. Das steht zum Teil im Widerspruch zu Tom Kellers Aussage.

 

[Tom Keller]

@ Tom Keller:
Interessante Theorie, dass mit GPU-Computing Video-Encoden schlecht parallelisiert werden kann. Nur widerspricht das etwa der Praxis: https://www.computerbase.de/2011-01/test-intel-sandy-bridge/28/#abschnitt_x264_hd_benchmark_319 und https://www.computerbase.de/2011-01/test-intel-sandy-bridge/24/#abschnitt_mainconcept_h264avc_pro

Keine Ahnung, was du damit zeigen willst . Ja, Video-Encoding ist schlecht parallelisierbar... NICHT unmöglich parallelisierbar. X264 unterstützt ja schließlich auch Multithreading und kann die Arbeit (meines Wissens) auf bis zu 16 CPU-Kerne aufteilen. Allerdings macht es einen Unterschied, ob man 16 CPU-Kerne zur Verfügung hat, oder mehrere Hundert Streamprozessoren. Schon die Multithreading-Unterstützung von x264 war schwierig umzusetzen - denkst du, dass die Arbeitsaufteilung bei noch mehr parallelen Recheneinheiten einfacher wird ?

 

[De-M-oN]

und kann die Arbeit (meines Wissens) auf bis zu 16 CPU-Kerne aufteilen.

Ja kann x264.

http://img684.yfrog.com/img684/7954/x26416cores.png

(screenshot ist nicht von mir)

 

[Merlin-.-]

Schon die Multithreading-Unterstützung von x264 war schwierig umzusetzen - denkst du, dass die Arbeitsaufteilung bei noch mehr parallelen Recheneinheiten einfacher wird ?

Nach meinem primitiven Verständnis von Videoencoding geht es darum
1. Jedes Einzelbild zu kodieren und dabei
2. immer den Kontext des Einzelbilds zu berücksichtigen (n Bilder vorher und nachher im einfachsten Fall)

Schritt 1 ist perfekt parallelisierbar. Ich sehe da keine Grenze bis dahin, dass jeder Kern ein Bild berechnet und am Schluss alle zusammengeklebt werden.

Schritt 2 ist dann wohl das Problem. Wie man die Informationen, die man über die Einzelbilder gesammelt hat, auf die betrachtete Sequenz verrechnet. Sprich: Wie beeinflusst, das was ich über die Bilder im Kontext rausgefunden habe, das aktuelle Bild?

Soweit mir bekannt, passiert die "Kontextanalyse" im ersten "pass" und im zweiten Druchgang werden die Einzelbilder kodiert (ohne Kontext).
Stimmt das soweit? (wohl kaum, bin noob)

Jedenfalls dürfte der 2nd pass dann perfekt parallelisierbar sein, wohingegen der 1st pass schlecht parallelisierbar (da sequentieller Natur) sein sollte.

 

[Tom Keller]

Nach meinem primitiven Verständnis von Videoencoding geht es darum
1. Jedes Einzelbild zu kodieren und dabei
2. immer den Kontext des Einzelbilds zu berücksichtigen (n Bilder vorher und nachher im einfachsten Fall)

Schritt 1 ist perfekt parallelisierbar. Ich sehe da keine Grenze bis dahin, dass jeder Kern ein Bild berechnet und am Schluss alle zusammengeklebt werden.

Schritt 2 ist dann wohl das Problem. Wie man die Informationen, die man über die Einzelbilder gesammelt hat, auf die betrachtete Sequenz verrechnet. Sprich: Wie beeinflusst, das was ich über die Bilder im Kontext rausgefunden habe, das aktuelle Bild?

Grundlegend arbeiten ALLE MPEG-basierten Kompressionsalgorithmen so:

http://encodingwissen.de/grundlagen/videokompression.html

H.264/MPEG-4 AVC macht da prinzipiell keinen Unterschied, sondern setzt in Punkto Komplexität (logischerweise) noch einen drauf:

http://encodingwissen.de/x264/technik.html

Da Intra- und Interframe-Kompression ineinander greifen, und vor allem die Interframe-Kompression ja von den Bezügen der Frames untereinander "lebt", lässt sich der GESAMTE Vorgang nur schwer parallelisieren.

X264 nutzt seit einiger Zeit Frame-basiertes Multithreading. Wie der Name schon zeigt, werden dabei mehrere Frames gleichzeitig encodet. Dafür muss x264 aber sicherstellen, dass für jeden Makroblock Bewegungsvektoren aus den Teilen der Referenz-Frames genutzt werden, die schon encodet wurden.

Diese Parallelisierung ist die momentan denkbar beste. Andere Möglichkeiten, das Videoencoding auf mehrere Threads aufzuteilen, existieren zwar... haben aber teilweise (im Vergleich zum Single-Thread-Encoding) negative Auswirkungen auf die Komprimierbarkeit:

http://forum.doom9.org/showthread.php?p=881706

In diesem Thread steht es (auch wenn der schon älter ist) übrigens auch nochmal deutlich - von einem Entwickler beschrieben - drin: Videokomprimierung ist von Natur aus ein eher serieller Vorgang. Genau das macht nunmal die Parallelisierung so schwer...

Soweit mir bekannt, passiert die "Kontextanalyse" im ersten "pass" und im zweiten Druchgang werden die Einzelbilder kodiert (ohne Kontext).
Stimmt das soweit? (wohl kaum, bin noob)

Ja. Siehe:

http://encodingwissen.de/codecs/encoding-methoden.html

Im ersten Durchgang (1st Pass) sammelt der Encoder Daten über die Komplexität und andere Eigenschaften des Videos und trifft einige grundlegende Entscheidungen über die Encoding-Strategie. An welchen Stellen I-, P- und B-Frames gesetzt werden, wird z.B. hier entschieden. Das Ergebnis des 1st Pass ist eine kleine Datei mit mehr oder weniger menschenlesbaren Analysedaten. Ein Video entsteht erst im zweiten Durchgang (2nd Pass) aus dem Quellmaterial und den gesammelten Daten.

Allerdings sollte man bedenken, dass das Multi-Pass-Encoding heute (im Zeitalter immer größer werdender Speichermedien) eine eher untergeordnete Rolle Rolle spielt.

Jedenfalls dürfte der 2nd pass dann perfekt parallelisierbar sein, wohingegen der 1st pass schlecht parallelisierbar (da sequentieller Natur) sein sollte.

Nein. Denn du hast ja beim eigentlichen Encoding das Problem, dass die Informationen aufeinander aufbauen. Mal angenommen, du encodest ein H.264-Video mit --ref 16 - dann kann z.B. jedes P-Frame seinen Bildinhalt aus den Makroblöcken von 16 Referenz-Frames "zusammenstellen". Das heißt aber, dass diese 16 Referenz-Frames vorher berechnet sein müssen, damit das P-Frame erstellt werden kann! Und als Referenz-Frames können z.B. auch B-Frames herhalten (bei der Benutzung von --b-pyramid)... die sich inhaltlich aber wiederum auf andere I-Frames, P-Frames und B-Frames beziehen können. Das heißt, dass zuerst die letztgenannten Frames encodet werden müssen (bzw. die dort enthaltenen, weiter verwendeten Makroblöcke müssen zur Verfügung stehen)... erst DANN können die besagten, als Referenz genutzten, B-Frames (welche sich darauf beziehen) erstellt werden... und erst DANACH das besagte P-Frame.

Man sieht schon: da liegt (gezwungenermaßen) eine Reihenfolge vor, die eingehalten werden MUSS!

 

[Merlin-.-]

OK, hab das Meiste Deiner guten Links gelesen.

Soweit ich das verstehe, wird der Prozess umso sequentieller je mehr Kreuzbezüge man zwischen den frames will. D.h. je effizeinter der x264-ähnliche Encoder, desto schlechter parallelisierbar?

Daher könnte GPU-Encoding so schlecht sein, weil eigentlich sequentielle Prozesse näherungsweise parallelisiert werden und die Näherungen prinzipiell schlecht sind.

Demnach bräuchte man einen grundlegend neuen Ansatz, um 32/64/128/.../GPU Threads zu ermöglichen, ohne Effizienz einzubüßen.

( Text leider etwas abgekürzt, da vorher mein Browser nach dem Abschicken einen Fehler meldete :-( )

 

[mumpel]

Ich verstehe nicht ganz, warum nicht im ersten Schritt parallel alle B-Frames berechnet werden, danach parallel alle B- und I-Frames zwischen den B-Frames seriell? Dazu müsste man wahrscheinlich den Encoder komplett neu schreiben, aber es würde die Arbeit bis zu einem bestimmten Punkt gut parallelisierbar machen. Vielleicht nicht für 1.000 Streaming-Prozessoren, aber für mehr als 16 Kerne auf jeden Fall.

Andererseits: Würde das Encoding aus so vielen B-Frames für möglich bestehen, würde die Dateigröße zwar größer werden, die Qualität aber steigen. Warum bieten die GPU-Encoder dann aber nur so schlechte Ergebnisse an? Zumal der Zusammenhang zwischen schlechter Qualität und schwieriger Skalierbarkeit für mich noch nicht einleuchtend ist. Selbst wenn man nur bis zu einem bestimmten Punkt parallelisieren kann, warum tun es die GPU-Encoder nicht und machen statt dessen schlechte Qualität? Oder: Wieso wird die Qualität mit steigender Parallelisierung schlechter? ... Ihr wisst, was ich meine

 

[Merlin-.-]

Selbst wenn man nur bis zu einem bestimmten Punkt parallelisieren kann, warum tun es die GPU-Encoder nicht und machen statt dessen schlechte Qualität?

Ich vermute mal sehr stark, dass ein Stream-Prozessor viel langsamer als ein CPU-Kern ist. Von daher wäre ein GPU-Encoder sinnlos, wenn er nicht viel viel mehr Kerne nutzen könnte als ein CPU-Encoder.

Ich kann mir vorstellen, dass die schlechte Quali daraus resultiert, dass (wie auch immer) sequentielle Prozesse näherungsweise(!) parallell berechnet werden und dort wohl viele Fehler entstehen.
Oder umgekehrt dadurch, dass man weniger Bezüge zu anderen frames herstellt und dadurch weniger sequentiell arbeiten muss, aber eben wieder ineffizienter wird.

 

[mumpel]

CUDA und Stream rechnen nicht ungenau. Das wäre ja fatal! Im Gegenteil: Es gibt sogar Super-Computer, die auf CUDA setzen. Von daher rechnen die schon korrekt. Die Frage ist nur, warum die "schlechte Bildqualität errechnen".

Wenn man weniger Bezüge zu anderen Frames herstellt, also mehr Voll-Frames, Referenzbilder, B-Frames oder wie die Dinger heißen mögen, dann wird die Bildqualität immer besser, bis dahin, dass jedes einzelne Bild alleine für sich steht und keinen Bezug zum vorherigen und nachkommenden hat. Das ist dann sowas wie eine Einzelbildsequenz und hat die höchste Qualität (kommt natürlich noch auf die Kompression des einzelnen Videobildes an). Mit der damit verbundenen Dateigröße. Motion-JPEG arbeitet, glaub ich, so.

 

[Merlin-.-]

CUDA und Stream rechnen nicht ungenau.

Hat ja niemand behauptet. Meine Vermutung war, dass die Algorithmen Näherungen berechnen. Dass ein sequentieller Algorithmus pseudo-parallellisiert wird. D.h. er ist dann zwar parallel, aber macht nicht mehr genau dasselbe wie der sequentielle, z.B. weil er das was der sequentielle analysieren müsste, einfach mal schätzt.

Und ja, die Quali würde besser, wenn man weniger Bezüge hat. Aber denk dran, die Größe muss in etwa gleich bleiben. Ergo muss die Qualität schlechter werden.

 

[Tom Keller]

Ich verstehe nicht ganz, warum nicht im ersten Schritt parallel alle B-Frames berechnet werden, danach parallel alle B- und I-Frames zwischen den B-Frames seriell?

Wie soll das gehen? Du kannst die B-Frames nicht berechnen, wenn du VORHER nicht die Makroblöcke genau DER Referenz- (P- und I-) Frames berechnet hast, auf die sich diese B-Frames beziehen. Nehmen wir mal folgendes Beispiel:

Das Frame B2 bezieht sich dabei auf P1 und P2 als Referenz. P1 und P2 wiederum werden sich auf das allererste I-Frame beziehen. Das hieße: ZUERST muss das I-Frame encodet werden, dann erst P1 und P2 und ERST DANACH existieren die Informationen um B2 zu erzeugen.

In der Realität ist das alles noch einen Tick komplizierter, da P2 auch noch Bildinhalte aus B3 übernehmen kann, weshalb vorher eventuell noch B3 berechnet werden muss.

Die Komplexität steigt aber, wenn auch B-Frames als Referenz genutzt werden können. In diesem Beispiel:

... benutzt das Frame B2 (neben P1 und P2) auch B1 als Referenz. Sprich: es müssen nicht nur P1 und P2 berechnet werden, BEVOR eine Berechnung von B2 möglich ist, sondern es müssen zuerst P1, P2 UND B1 berechnet werden, bevor die Informationen zur Berechnung von B2 vorliegen.

Und das sind alles extrem simple Beispiele mit 2 bzw. 3 Referenzen. Stell dir das ganze mal mit 8 oder 16 Referenzen vor. Das wird dann seeeeehr verschachtelt .


Und falls du I- und B-Frames in deiner Frage verwechselt haben solltest: auch ALLE I-Frames im voraus zu berechnen geht nicht. Zumindest nicht, ohne gigantische Mengen an RAM zu verbrauchen.

Andererseits: Würde das Encoding aus so vielen B-Frames für möglich bestehen, würde die Dateigröße zwar größer werden, die Qualität aber steigen. Warum bieten die GPU-Encoder dann aber nur so schlechte Ergebnisse an?

Hast du mal gesehen, um wie viel größer eine Datei wird, die NUR aus I-Frames besteht??? Mal ein kleines Rechenbeispiel mit MJPEG (das ja nur I-Frames erzeugt):

Ein unkomprimiertes YV12-Video in 1920x1080 Pixeln und 30 Minuten Länge bei 25fps ergäbe:

1920 (Pixel) x 1080 (Pixel) x 12 bit (YV12) = 24.883.200 Bit = 3.110.400 Byte (je Einzelbild)

30 Minuten = 1.800 Sekunden

1.800 Sekunden x 25 (Bilder je Sekunde) = 45.000 (Einzelbilder gesamt)

45.000 (Einzelbilder gesamt) x 3.110.400 Byte (je Einzelbild) = 139.968.000.000 Byte = 130,36 Gigabyte

MJPEG komprimiert in guter (nicht bester Qualität!) etwa im Verhältnis 1:7. Das ergäbe ca. 18,62 Gigabyte für NUR 30 Minuten FullHD-Video! Und die Qualität wäre zudem deutlich SCHLECHTER als bei H.264, das ca. 80% effektiver komprimiert!

Die relativ geringen Dateigrößen bei der Verwendung von H.264 werden nämlich GERADE durch die Verwendung von P- und B-Frames und multiple Referenzen erreicht. Nimmst du das weg, bleibst du auf vergleichsweise riesigen Dateien sitzen - und gerade die will man ja bei der Videokompression für Endformate vermeiden.

Wieso wird die Qualität mit steigender Parallelisierung schlechter?

Siehe hier:

http://forum.doom9.org/showthread.php?p=881706

So video compression is naturally serial, and you have to make some approximations if you want to split it into many threads.

The "approximation" I refer to is that the encoder (either with support from the standard, or just as an implementation decision) must choose to ignore some possible redundancies, in order to independently process some pieces of the encoding task that could have depended on eachother. If you don't exploit that redundancy, then your compression algorithm doesn't compress quite as well as the original serial one. And it is no coincidence that the same features help both error resilience and threading: Error resilience is also about adding a controlled amount of redundancy back into the compressed stream.

Different threading models use different pieces of redundancy:

• x264's slice-based threading fails to exploit some spatial redundancy between blocks within one frame.
• xvid's mb-row threading is lossless, but only works because mpeg4asp's entropy coder fails to adapt its probability model to the observed data.
• my proposed sliceless threading method depends on the fact that a given macroblock is usually predicted only from a nearby block in the previous frame, or a neighbor in the current frame. If typical motion vectors were large, then sliceless threading would also waste bits. It also depends on the fact that h264's entropy coder doesn't adapt to anything beyond the current frame.
• B-frame threading depends on the fact that (most) B-frames are not used in inter-prediction. It only works in sections of the video that use B-frames, and doesn't scale beyond about 2 threads.
• GOP-level threading is lossless, but depends on the fact that you already have to spend bits on I-frames in order to get fast seeking and some minimal error resilience. It also takes a rediculously large amount of RAM if you want to fit it into a standard stream-like API.
• ELDER's threading has a small impact on the precision of ratecontrol, and has to choose between extra I-frames (wasted bits), or a little duplicate work (wasted time). It also doesn't fit at all into a stream-like API.
• Sub-macroblock threading might be possible if thread synchronization were fast enough. But it would duplicate quite a bit of work, since it would bypass some of x264's early termination conditions. And it wouldn't scale beyond 2-4 threads.

Frei übersetzt (ich versuch's mal):

Videokompression ist also von Natur aus seriell, und man muss daher einige Angleichungen vornehmen, wenn man sie in mehrere Threads aufteilen will.

Mit "Angleichungen" meine ich, dass der Encoder (entweder als Standard-Unterstützung oder als alternative Implementierung) einige mögliche Redundanzen ignorieren muss, um unabhängig Einzelteile der Encoding-Aufgabe durchzuführen, die voneinander abhängig sein könnten. Wenn du diese Redundanzen nicht beseitigen kannst, dann komprimiert dein Kompressionsalgorithmus nicht so gut, wie der serielle. Und es ist auch kein Zufall, dass die selben Features beidem, Fehlertoleranz und Thread-Aufteilung, helfen: denn auch bei der Fehlertoleranz geht es darum, eine kontrollierte Menge an redundanten Daten in den komprimierten Stream zurück zu führen.

Verschiedene Threading-Modelle haben verschiedene Redundanzen:

• X264s slice-based Threading liefert räumliche Redundanz zwischen Blöcken innerhalb eines Frames.
• Xvids MB-Row Threading ist verlustlos, aber funktioniert nur, weil der MPEG-4 ASP Entropie-Encoder sein Wahrscheinlichkeitsmodel nicht an die beobachteten Daten anpassen kann.
• Meine vorgeschlagene Sliceless-Threading-Methode basiert darauf, dass ein Makroblock üblicherweise nur basierend auf einem nächstgelegenen Makroblock im vorherigen Frame, oder einem Nachbar im gegenwärtigen Frame vorherbestimmt wird. Wenn die typischen Bewegungsvektoren zu groß wären, dann würde Sliceless-Threading ebenfalls Bits verschwenden. Es beruht ebenfalls auf der Tatsache, dass der H.264-Entropie-Encoder sich an nichts außerhalb des gegenwärtigen Frames anpasst.
• B-Frame-Threading beruht auf der Tatsache, dass (die meisten) B-Frames nicht für Interframe-Vorhersagen genutzt werden. Es funktioniert nur bei den Teilen des Videos, welche B-Frames benutzen, und skaliert nicht über 2 Threads hinaus.
• GOP-Level Threading ist verlustlos, aber beruht auf der Tatsache, dass du schon einige Bits für I-Frames verschwendest, damit ein schneller Suchlauf und eine gute Fehlertoleranz möglich ist. Es benötigt ebenfalls eine riesige Menge RAM, wenn du es in einem Standard-Stream-Anwendungsinterface umsetzen willst.
• ELDERs Threading hat einen geringen Einfluss auf die Präzision der Datenratenkontrolle und muss zwischen extra I-Frames (verschwendete Bits) oder teilweise doppelter Arbeit (verschwendete Zeit) wählen. Es passt außerdem in kein Stream-Anwendungsinterface.
• Sub-Makroblock-Threading wäre eventuell möglich, wenn die Thread-Synchronisierung schnell genug wäre. Aber es würde diverse Arbeitsschritte verdoppeln, da es einige von x264s frühen Abbruchbedingungen umgeht. Und es würde nicht über 2-4 Threads hinaus skalieren können.

 

[mumpel]

Danke für die Ausführlichkeit! Und ja, ich habe P- I- und B-Frames verwechselt. Ich habe nur versucht, mich logisch dem Thema zu nähern, ohne das technische Detailwissen zu besitzen.

Also kann man festhalten:
Die GPU bezieht ihre Performance gegenüber der CPU vor allem durch ihre Parallelisierbarkeit. Die ist aber bei der Video-Encodierung aufgrund ihrer Komplexität und Abhängigkeit nicht gegeben. Zwar skaliert sie auf den wenigen Kernen der CPU (im Vergleich zur GPU) ganz gut, darüberhinaus aber nicht weiter. Deshalb ist es mit den aktuellen Encodern und GPUs nicht möglich, die gleiche Video-Qualität bei reduzierter Rechenzeit zu erreichen.

Vielleicht fällt aber in Zukunft findigen Köpfen eine Möglichkeit ein, entweder das Encoding deutlich stärker zu parallelisieren oder die Leistungsfähigkeit einzelner Streaming-Prozessoren deutlich zu erhöhen. Ersteres bedeutet ein komplettes Umdenken in der Art und Weise, wie Videos codiert werden. Letzteres ist eher unwahrscheinlich, weil die Richtung der GPU- und CPU-Entwicklung auf Parallelisierung und mehr Kerne ausgerichtet ist.

 

[Salvation]

lol
wieso kommt hier eigentlich keiner auf die idee einen einfachen trick anzuwenden welcher auch bei FAVC verwendet wird...
man startet einfach den encoder zwei mal und der erste macht frame 0-1000 und der zweite 1001-2000 ... zum schluss werden diese einfach zusammengeklebt... )

so wird der stream beliebig unterteilt in die anzahl kerne und an den trennstellen gibts halt saubere i-frames....
die idee bei FAVC entstand übrigens weil der encoder selber nicht multithreaded war.

ok ein nachteil wäre wohl der steigende ram-verbrauch..

 

[Merlin-.-]

Die Idee ist gut, aber auch nicht unbegrenzt steigerbar... ^^
Irgendwo will man ja Abhängigkeiten zwischen den Frames ausnutzen, die man ja verliert, wenn man mehrmals startet.

Aber danke für den Tipp... werde es so mal von Hand machen, wenn ich mal eine ETA von vielen Stunden angeizeigt bekommen sollte... :-)

 

[Tom Keller]

Ich glaube, so ähnlich macht es ja auch x264 beim Multithreading: es werden die Abschnitte zwischen IDR-Frames als einzelne Threads abgearbeitet (<= ohne Garantie auf Richtigkeit). Das Problem bei H.264 ist nämlich, dass nicht nur Abhängigkeiten innerhalb aller Frames zwischen zwei I-Frames bestehen, sondern auch Abhängigkeiten über I-Frames hinaus erstellt werden können. I-Frames darf man daher bei H.264 nicht als "Grenze" zwischen zwei Abschnitten betrachten, sondern nur IDR-Frames:

http://encodingwissen.de/x264/technik.html#refs

Daher hat "Merlin-.-" absolut recht. Würde man das zu weit steigern, werden die GOPs gezwungenermaßen immer kürzer... und damit sinkt die Codiereffizienz.

 

[Willnochreisen]

Sorry, dass ich das hier ausgrabe. Aber ich wollte mal sehen was sich getan hat.


Zur Zeit wandel ich alle Filme per Mediacoder und INTEL QuickSync um.
1080er Material bei 6000kbit average, high profile und 192bit MP3. 2-Pass wird leider nicht unterstützt, aber bei 6000 ist die Qualität für unseren Hausbedarf völlig ausreichend. Ein 2 Stunden-Film auf meinem Netbook mit 17Watt CPU. wird in 20-30 Minuten umgewandelt. 2-3x Geshwindigkeit. 720er Material mit 6-8x Geschwindigkeit und DVD Material in H264 bei 13X geschwindigkeit.

Ich denke mit einer Großen INTEL CPU deren GPU höher getaktet ist, und einer Festplatte die mit etwas mehr Dapf arbeitet ist da noch einiges mehr drinne.


Gibt es auch Programme die AMD Karten unterstützen? Hab noch eine 6870 und die hat ja im vergleich zur HD4000 brachiale Leistung, wenn sie auch nicht so für Videos optimiert wurde wie die INTEL.

Gibt es Programme die dies unterstützen? Arcsoft Media Converter 8 kann es zwar auswählen, ist aber nicht wirklich schnell. Im Gegenteil. Die GPU ist zu 15% ausgelastet und das obwohl sie nicht mal hochtaktet sondern bei 300mhz dahinvegetiert.




Was soll dieses ganze "APU" Konzept, wenn die CPU ja doch nicht von der GPU unterstüzt werden kann, da es einfach keine Programme gibt die dies unterstützen

 

[powerfx]

2-Pass wird leider nicht unterstützt, aber bei 6000 ist die Qualität für unseren Hausbedarf völlig ausreichend.

Oft wird immer noch angenommen, dass 2-Pass (oder allgemein n-Pass) eine bessere Qualität als 1-Pass bietet. Das ist falsch. Die Qualität von 1-Pass mit einer variablen Bitrate ist höher. Nur die exakte Dateigröße kann vor dem Prozess nicht genau bestimmt werden (bei n-Pass dagegen schon).

Ich denke mit einer Großen INTEL CPU deren GPU höher getaktet ist, und einer Festplatte die mit etwas mehr Dapf arbeitet ist da noch einiges mehr drinne.

Quick Sync ist ein Hardware-Encoder. Das ist etwas völlig anderes als z.B. eine Codierung mit CUDA etc. Die Performance innerhalb einer CPU-Generation sollte sich nicht sehr stark unterscheiden. Bei Ivy Bridge z.B. kamen aber gegenüber Sandy Bridge noch einige Verbesserungen hinzu.

Gibt es auch Programme die AMD Karten unterstützen? Hab noch eine 6870 und die hat ja im vergleich zur HD4000 brachiale Leistung, wenn sie auch nicht so für Videos optimiert wurde wie die INTEL.

Weder Nvidia-, noch AMD-Karten oder -APUs haben Hardware-Encoder. Also nein. AMD hat aber den "AMD Video Converter" im Catalyst integriert, der die GPU nutzt.

Was soll dieses ganze "APU" Konzept, wenn die CPU ja doch nicht von der GPU unterstüzt werden kann, da es einfach keine Programme gibt die dies unterstützen

So gut wie jede 3D-Anwendung (z.B. Spiele) unterstützt dieses Konzept.

 

[mumpel]

Oft wird immer noch angenommen, dass 2-Pass (oder allgemein n-Pass) eine bessere Qualität als 1-Pass bietet. Das ist falsch. Die Qualität von 1-Pass mit einer variablen Bitrate ist höher. Nur die exakte Dateigröße kann vor dem Prozess nicht genau bestimmt werden (bei n-Pass dagegen schon).

Wie erklärst du dir dann, dass 1-Pass bei gleicher Qualitätseinstellung ein sichtbar schlechteres Bild abliefert als 2-Pass?

So gut wie jede 3D-Anwendung (z.B. Spiele) unterstützt dieses Konzept.

Ich denke, er meint die Unterstützung der iGPU in normale Produktiv-Programme. Für Spiele ist die Performance der APUs ja eh viel zu gering. AMD sagt aber, dank ihrer tollen CPU-GPU-Kombi arbeitet man besser/schneller/flüssiger als mit einer schnellen CPU. Und da muss ich aus Erfahrung recht geben: Das ganze GPU-beschleunigte läuft nicht wirklich auf breiter Front. Es gibt hier und dort einzelnen Support, aber selbstverständlich und problemlos ist das alles nicht. Im Zweifelsfall bist du mit einer schnellen Intel CPU besser dran, als mit einer AMD APU - ausgenommen Spiele.

 

[Tom Keller]

Wie erklärst du dir dann, dass 1-Pass bei gleicher Qualitätseinstellung ein sichtbar schlechteres Bild abliefert als 2-Pass?

"Powerfx" bezieht sich damit auf qualitätsbasiertes(!) 1-Pass-Encoding (mit variabler Bitrate) - bei x264 z.B. über die Vorgabe eines "CRF" (= "Constant Rate Factors") möglich. Das ist was anderes als bitratenbasiertes 1-Pass-Encoding, wo mit einer fest vorgegebenen Durchschnittsbitrate encodiert wird. Bei qualitätsbasiertem 1-Pass-Encoding hast du aber (anders als bei bitratenbasiertem) KEINE Möglichkeit, eine exakte Zieldateigröße zu treffen - das Ergebnis wird halt so groß, wie es die Qualitätsvorgabe verlangt (abhängig von Laufzeit und Komprimierbarkeit der Bildinhalte).