so lange bei Canopus die Firecoder blu für richtiges Geld angeboten und verkauft wird, dürfte das Interesse dort für eine interne Lösung sehr, sehr
gering sein ....
Was mir immer noch nicht klar ist, unterstützt CUDA eigentlich auch die Timelineoperationen selbst oder bezieht sich die Geschwindigkeitssteigerung nur auf den finalen Renderprozess?
hannes hat geschrieben:Was enthalten uns die anderen Schnittsysteme da vor?
Die Technik wird doch von NVidia schon lange bereit gehalten.
Eine Umstellung auf eine API wie Cuda ist bei Weitem nicht trivial. Ich denke viele Hersteller experimentieren mit solchen Bibliotheken, aber wie effizient das Ergebnis ist, hängt auch davon ab, in welchem Zustand sich der bestehende Render-Code einer Schnittlösung befindet. Eine Umstellung passiert da nicht innerhalb von ein paar Tagen, da können schon einige Monate vergehen bis das alles nachgezogen wurde. Und Cuda ist eine reine NVidia-Technologie, Besitzer von ATI-Karten schauen dann in die Röhre.
Mit ein bisschen Glück werden wir mit OpenCL (http://de.wikipedia.org/wiki/OpenCL) eine entsprechende Hardware-Unabhängige Lösung bekommen, auf die die Software-Hersteller setzen können.
domain hat geschrieben:Was mir immer noch nicht klar ist, unterstützt CUDA eigentlich auch die Timelineoperationen selbst oder bezieht sich die Geschwindigkeitssteigerung nur auf den finalen Renderprozess?
hannes hat geschrieben:Was enthalten uns die anderen Schnittsysteme da vor?
Die Technik wird doch von NVidia schon lange bereit gehalten.
Öhm, zu Zeiten der CUDA-Beta und beim Release der v1 gab's gerade mal 3 Grafikkarten der GeForce 7xxx Serie oder so, die das (theoretisch) konnten, aber in der Praxis dank verbuggter Treiber doch nicht alle Features funktionsfähig verwenden konnten. Erst mit der 8xxx Serie ging das richtig los. Außerdem ist GPU-Code ganz anders gestrickt als CPU-Code, das macht man nicht mal so auf die Schnelle. Und selbst dann ist noch die Frage, ob es Sinn macht. Sehr komplexe Konstrukte, die nur ab einer sehr hohen Anzahl von Shadereinheiten funktionieren, also damit nur auf teuren Karten, nützen niemandem was. Da ist der Aufwand in der Entwicklung im Vergleich zum potenziellen Absatz solcher Karten zu groß. Und naja - GPU-Code ist immer noch weitestgehend Single-Precision. Selbst für MPEG-Kodierung muss man da im Zweifelsfall schon Kompromisse eingehen. Außerdem, und das its ja das Problem, muss ja immer noch eine Variante dabei sein, die als "software only" auf der CPU funktioniert, falls das Zielsystem CUDA nicht unterstützt. Allein die dazu nötigen Sicherheitsmechanismen, um nicht ständig den Rechner abzuschiessen, erfordern schon einiges and Geschick und Bedacht...
domain hat geschrieben:Na alles was halt beim Schneiden so anfällt inkl. Echtzeitvorschau.
Wird diese denn auch durch CUDA beschleunigt?
Also bei Loilo steht da nix davon und bei anderen Programmen müßte man das sehen. Die Frage ist aber eher akademischer Natur - für's reine Abspielen sind andere Faktoren wesentlich wichtiger als die Prozessorpower zum dekodieren. Das funzt ja selbst auf 400 Euro Billigrechnern mittlerweile.
Mylenium hat geschrieben:
Die Frage ist aber eher akademischer Natur - für's reine Abspielen sind andere Faktoren wesentlich wichtiger als die Prozessorpower
Bei einem NLE ist diese Frage aber nicht akademischer sondern rein praktischer Natur.
Ob das finale Rendern nämlich beschleunigt wird ist mir relativ egal.
Auf die Beschleunigung der Timelineoperationen speziell unter AVCHD kommt es vorwiegend an.
Die Antwort ist: ja
Das Problem ist in CPU Architekturen, dass eine GoP in den Hauptspeicher geladen, abgearbeitet und gelöscht wurde. Die MPEG2 Gops hatten aber nur ein I-Frame. Das I-Frame musste also nur so lange im Speicher gehalten werden, bis die GoP abgearbeitet war. H.264 hat aber bis zu 16 I-Frames und GoP Länge von z.B. 90. Das bedeutet, dass es nicht nur mehr Speicherbedarf für die 16 I-Frames gibt, sondern diese auch noch (statt 1/2 sec. jetzt 4 sec) im Speicher gehalten werden müssen. Auch die Menge der Referenz-Zugriffe erhöht sich entsprechend.
Es kommt hinzu, dass auch B-Frames (Slices) als Referenz für die Bewegungskompensation benutzt werden, was bisher nicht möglich war. Daher liegt der grundlegende Unterschied zwischen P- und B-Slices nur noch in der Art, in der die Makroblöcke codiert werden.
In B-Slices kann das Prädiktionssignal aus dem gewichteten Mittel zweier unterschiedlicher Prädiktionswerte gebildet werden.
B-Slices benutzen dazu zwei verschiedene Referenzbildpuffer, ein Umstand, der erhebliche Anforderungen an die Rechnerarchitektur stellt.
All dies, und noch einiges mehr, wird vom zusätzlichen DSP ausgeführt und verändert natürlich auch das Verhalten bei einem echtzeit-orientierten Bildaufbau.
Die bisher bei den Camcordern zum Einsatz gekommenen Codecs haben lediglich 4 I-Frames benutzt (auch im Hinblick auf die noch schwache Rechnerarchitektur) und dadurch natürlich auch nicht die Möglichkeiten des Codecs ausgeschöpft. Das dürfte sich aber mit den veränderten Architekturen auch ändern.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
