MP3 und MP4 Wandlung nutz nicht volle Rechenleistung aus.

Faster schrieb:
> Kann ich das mit Win7 Einstellungen ändern?

Nö. Wenn das codierende Programm nicht mehrere Threads benutzt, dann 
kann das von außen nicht geändert werden.

Wenn der Programmierer eine Mehrkernnutzung nicht vorgesehen hat, werden 
die anderen Kerne in Ruhe gelassen.

Bei der Rechenleistung der einzelnen Kerne ist das organisierte 
Multitasking auch wirklich Geschmacksache.

Melde Dich doch bei der Softwareentwicklung an und implementiere dieses 
Feature.
Keine Ahnung ob das überhaupt möglich ist.

Bei den kostenlosen Tools schauts schlecht aus mit 
Multithreadunterstützung.

Lame Encoder (für MP3) kann kein Multithreading:
https://superuser.com/questions/1056044/does-the-threading-option-work-with-lame-in-ffmpeg

FFMPEG mit libx264 für H.264 Video scheint Multithreading wohl nur sehr 
rudimentär zu unterstützen:
https://video.stackexchange.com/questions/15996/ffmpeg-encoding-and-core-usage

Konnte Handbrake nicht multithreaded h264 Enkodierung? :)

Mampf F. schrieb:
> Konnte Handbrake nicht multithreaded h264 Enkodierung? :)

Deswegen heisst es so.

Schwarzseher schrieb:
> Hyperthreading bringt nur dann einen echten Vorteil, wenn verschiedene
> "Prozessorteile" gleichzeitig verwendet werden können, z.B. Integer und
> Floatingpoint-Berechnungen.

Oder wenn Threads ihr Glück nicht nur in den L1-Caches finden, und 
deshalb ab und zu einige Takte aussetzen müssen.

Schwarzseher schrieb:
> Ansonsten: Starte einfach mehrere Kodiervorgänge gleichzeitig.

Ein Encoder mit nur einem Thread ist prinzipbedingt 
rechenzeiteffizienter als ein Encoder mit mehreren Threads (weil 
Overhead entfällt) und führt zu besseren Ergebnissen.

Daher ist "verarbeite einfach mehrere Dateien gleichzeitig" die beste 
Lösung.

S. R. schrieb:
> Ein Encoder mit nur einem Thread ist prinzipbedingt
> rechenzeiteffizienter als ein Encoder mit mehreren Threads (weil
> Overhead entfällt) und führt zu besseren Ergebnissen.

NACK. Man kann etliche Sachen parallelisieren ohne dass die Qualität 
leidet.

Es ist nur deutlich schwieriger die Software korrekt zu schreiben. Bei 
lame hat sich niemand die Mühe gemacht - und der stammt außerdem aus 
einer Zeit wo Desktop CPUs single-threaded waren.

MP3 sind außerdem trivial zu parallelisieren, indem man halt den Encoder 
für jede Datei einzeln startet. Da das hier ein Programmiererforum ist: 
Make kann Tasks parallel abarbeiten, d.h. Du könntest Dir ein Makefile 
zum parallelen Encoding bauen.

Heutzutage nutzt man fürs (Video-)Encoding besser die massiv parallele 
Grafikkarte als Beschleuniger.

welche Video-Auflösungen werden denn überhaupt gefahren?

PS: und Bildraten?

Jim M. schrieb:
> Man kann etliche Sachen parallelisieren ohne dass die Qualität leidet.

Wenn du einen Datenstrom so codieren willst, dass jeder Block auf dem 
vorherigen Block basiert, dann kannst du ohne weiteres nicht mehrere 
Blöcke gleichzeitig verarbeiten.

Für Parallelisierung kannst du nur mehrere Blöcke auf einen gemeinsamen 
Vorgänger zeigen lassen, oder den Datenstrom in unabhängige Stücke 
schneiden - das ist aber weniger effizient.

> MP3 sind außerdem trivial zu parallelisieren, indem man halt den Encoder
> für jede Datei einzeln startet.

Das schrieb ich bereits, aber darum ging es nicht.

Mit tausend Bauarbeitern kriegst du ein Haus nicht tausendmal 
schneller gebaut als mit einem, aber du könntest in der gleichen Zeit 
tausend Häuser bauen. Bringt nur nix, wenn du nur ein Haus willst.

> Heutzutage nutzt man fürs (Video-)Encoding besser die massiv parallele
> Grafikkarte als Beschleuniger.

Die ist aus Sicht des Anwenders übrigens auch nicht parallel: Vorne geht 
ein Datenstrom rein, hinten kommt ein Datenstrom raus. Intern wird 
natürlich massiv parallel gearbeitet, aber dafür gelten die o.g. 
Kompromisse. Die Qualität ist i.d.R. schlechter als bei einem guten 
Software-Encoder, oder die Dateien sind größer.