OpenCL / GPU Encoder

Zitat

Das Optimum wäre natürlich eine angepasste eac3to, aber auch hier bin ich bisher nicht fündig geworden.

eac3to:
- ist ClosedSource
- ist Windows only (es sei den man nutzt Wine&Co)
- hat keine eigene Encoderbibliothek (nutzt libav&Co und DirectShowEncoder)
-> unwahrscheinlich, dass sich da was tun wird

-> unwahrscheinlich, dass sich da was tut

Für FLAC gibt es einen OpenCL basierten Encoder: http://cuetools.net/wiki/FLACCL

Ansonsten wüsste ich auch von keinem OpenCL (oder Cuda) basierten Audio Encoder.
-> Falls Du welche findest, bitte posten!

Cu Selur

Dafür kann aber (wie 'Selur' schon schrieb) eac3to nichts . Denn: eac3to decodiert/encodiert ja selber nix. Es spannt halt "fremde" DirectShow-Decoder bzw. externe Decoderbibliotheken für die Decodierung ein und reicht den decodierten Ton an Standalone-Encoder(bibliotheken) weiter. Sprich: Decodierung und Encodierung wird da von externer Software erledigt, die rein gar nichts mit eac3to zu tun hat und auf deren CPU-Optimierungen 'madshi' (der Programmierer von eac3to) deshalb auch keinen Einfluss hat.

Wobei ich mich jetzt frage: würde ein OpenCL- oder CUDA-basierter Audioencoder überhaupt SO viel bringen? Zumindest bei der Videoencodierung wurde doch meines Wissens immer wieder betont, dass eine Parallelisierung (aufgrund der Linearität des Vorgangs) nur schwierig umsetzbar ist - und wenn, dann auch nicht unbegrenzt skalierbar. Dementsprechend nützen z.B. die ca. 1000 Streamprozessoren einer modernen Grafikkarte nicht besonders viel, da sich das Videoencoding funktionell gar nicht auf so viele Rechenprozesse aufteilen lässt. Erst recht nicht bei komplexen Videokompressionsalgorithmen wie z.B. H.264.

Sieht das denn beim Audioencoding wesentlich anders aus :hm: ?

Laut den Statistiken die bei http://cuetools.net/wiki/FLACCL zu sehen sind bringt es bei FLAC schon einiges, kommt aber sicher wie immer auf das Audioformat an.

tom: In bestimmten Fällen könnte man z.B. die Bearbeitung abschnittsweise auf die Cores verteilen.

Denke da z.B. daran eine WAV nach AC3 zu wandeln. Solang man sich an die framelength des Ausgabeformats hält wären die Teilstücke unhörbar aneinanderhängbar.

Und ich denke eine derartige "Paralellisierung" könnte madshi implementieren.

Persönlich hat mich die Geschwindigkeit von eac3to aber nie gestört. Im Gegenteil, für meinen Einsatzzweck (wav->ac3) ist es sehr schnell (aber auch qualitativ nicht optimal, wie ich mir sagen lassen musste).

nö

Kann er auch gar nicht : beide (sowohl eac3to als auch der WAV to AC3 Encoder) benutzen Aften für's AC3-Encoding. Ersterer die Standalone-Version (sprich: die aften.exe)... letzterer die Encoder-Bibliothek (sprich: die libaften.dll). Ein merklicher Geschwindigkeitsunterschied ist daher zu bezweifeln (es sei denn, man benutzt eine sehr alte Version der EXE).