Es klingt fast zu schön, um wahr zu sein: Bei dem kostenlosen UT-Codec handelt es sich um einen Lossless Codec für Windows, der in diversen Farbräumen (YUV422, YUV420, RGB und RGBA!!) arbeitet, und dabei besonderen Wert auf die Decoding -Geschwindigkeit legt. Gegenüber HuffYUV ist er dank sehr guter Multiprozessor-Unterstützung bis zu 4 Mal schneller beim Entpacken von Videoclips, was ihn gerade als Intermediate-Codec zum HD-Schnitt interessant macht. Wir haben uns den UT-Codec einmal kurz näher angesehen und geprüft, ob und wie er seine theoretischen Vorteile gegenüber nativem AVCHD/MPEG4-Editing ausspielen kann...
Kompressionsverhältnisse
Zuallererst werfen wir kurz einen Blick auf den Platzverbrauch des UT-Codecs. Da dieser jedes Bild separat (= nur Intra-Frame) verlustfrei komprimiert, kommen natürlich mächtige Datenraten zustande, die weit über üblichen komprimierten Formaten liegen. Die Datenraten des für lossless 1920x1080i50-Videoclips lagen dabei in unseren in erstens Tests immerhin durchschnittlich mindestens bei 2:1 gegenüber einem echten uncompressed Strom:
RGB ca. 65 MB/s
YUV422 ca. 35MB/s
YUV420 ca. 28 MB/s
(alles inkl PCM Audio 16Bit 48 Khz Stereo)
Dies sind natürlich nur bildabhängige Näherungswerte. Je weniger das Bild verrauscht ist, desto geringer wird die Datenrate (was sich übrigens auch positiv auf die Prozessorauslastung beim Dekomprimieren auswirkt). Man sieht auf jeden Fall, das dies Datenraten sind, die moderne 3,5-Zoll Festplatten auch in der Praxis dauerhaft liefern können. Für ein sehr lineares Schnittprojekt mit einer Hauptspur kommt man auf jeden Fall auch mit einer Festplatte aus. Wer mehr Spuren braucht, kommt dann natürlich nicht um einen RAID-Verbund herum.
Encoding Auswahl
Der Codec selbst bietet nicht viele Einstell-Möglichkeiten. Auf jeden Fall klingt erst mal gewitzt und ungewohnt, dass man bereits beim Encodieren einstellen kann auf wie viele Prozessorkerne der Decoding-Prozess später verteilt sein soll. Dabei wird das Bild in entsprechend viele Teile zerlegt, die später dann zum decodieren auf die verschiedenen Prozessor-Kerne verteilt werden. Man muss sich also schon beim Encodieren entscheiden, wie viele Threads der Clip später benutzen soll:
In der Praxis hat sich die Prozessoranzahl in der Performance auf unserem Quadcore beim Schnitt jedoch kaum niedergeschlagen...
