Decoder Multithreading für Windows

[toms]

Welche effizientere Alternative gibt es bzw. gibt es einen Parameter um Multithreading zu aktivieren?
Warum startest du den Decoder nicht einfach zwei oder dreimal? Dann kannst du mehrere Dateien gleichzeitig decodieren.

Einen Parameter für Multithreading von einer Datei gibt es meines Wissens nicht...

Allerdings würde ich bei meinen Laptop niemals mehrere Dateien decodieren. Denn die Festplatte ist hier selbst bei einem Decodierungsvorgang vollständig ausgelastet. Dauernde Schreib-/Lesezugriffe....
Außer du hast ne SSD, dann tritt das Phänomen bei dir vermutlich nicht auf...

[PeteLeFreak]

toms, danke für deine Vorschläge.


Warum startest du den Decoder nicht einfach zwei oder dreimal? Dann kannst du mehrere Dateien gleichzeitig decodieren.

Die Frage der Dekodierung bezieht sich in der Tat auf das Dekodieren jeweils einer Datei.
Das die CPU nicht effizient ausgenutzt wird stört mich eigentlich schon seit Jahren. Hatte halt immer die Hoffnung, es kommt mal ein Update vom EasyDecoder...


Einen Parameter für Multithreading von einer Datei gibt es meines Wissens nicht...
Schade...
Eventuell in der Kommandozeilenvariante?


Allerdings würde ich bei meinen Laptop niemals mehrere Dateien decodieren. Denn die Festplatte ist hier selbst bei einem Decodierungsvorgang vollständig ausgelastet. Dauernde Schreib-/Lesezugriffe....
Außer du hast ne SSD, dann tritt das Phänomen bei dir vermutlich nicht auf...

Korrekt, SSD ist vorhanden. Ist ein echter Jungbrunnen für diesen Laptop. Kann ich jedem nur empfehlen. Du willst kein zurück mehr ;-)
Ist halt eine alter Core2 Duo T6500 Prozessor. Da würde sich eine korrekte Parallelverarbeitung wirklich bemerkbar machen, da er ja (vom heutigen Stand) nicht der schnellste ist. ;-)

[worfroz]

Was nützt eine höhere CPU-Auslastung, wenn die Laufwerke mit dem Schreiben der Dateien nicht nachkommen? Hier liegt doch der Flaschenhals!

[PeteLeFreak]

Was nützt eine höhere CPU-Auslastung, wenn die Laufwerke mit dem Schreiben der Dateien nicht nachkommen? Hier liegt doch der Flaschenhals!
Siehe oben:
SSD ist vorhanden

Natürlich habe ich mir die Systemauslastung meines Systems angeschaut.
Laufwerk war damals vor der SSD das Problem, daher hatte ich mich nicht weiter darum gekümmert.
Nun sind die Vorraussetzungen gegeben ;-)

Kennst du denn einen Dekoder, der Multithreading leistet oder geht das nur mit einer Variante unter Linux?

[mchawk]

Siehe oben:

SSD ist vorhanden
Was nichts aussagt, es sei denn Du hast die SSD-Geschwindigkeit beim Schreiben mit ausgeschaltetem Schreibcache mit einem Tool gemessen.
Mal abgesehen davon, dass das Dekodieren mit meiner Western Digital Black-HD so ratzfatz geht, dass ich die Nutzung eines zweiten Kerns bisher nicht vermisst habe.

Da der Decoder auf meinem System mit einer HD rasant arbeitet dürfte es in der Tat auch eher an Deiner CPU als an der SSD liegen - wobei SSDs mitunter deutlich langsamer schreiben als lesen. Deshalb kann man ohne Messung des Datendurchsatzes nichts genaues sagen. Möglicherweise könnte die SSD auch schneller - wird aber durchs Mainborad (Controller) ausgebremst?

Bezüglich der Entwicklung von einer Multicore-Variante des Decoders schätze ich mal, dass das OTR nicht viel investieren wird - dafür dürften zu wenig Nutzer wirklich profitieren. Wie gesagt: Bei meiner Kiste arbeitet der Decoder so schnell, dass ich dem grünen Verlaufsbalken kaum folgen kann - und die hat auch schon ein paar Jährchen auf dem Buckel. ;)

[Cineatic]

Das Dekodieren einer Datei, auf einer handelsüblichen Festplatte, dauert doch selbst bei einer 1GB großen Datei nur ca. 5-6 Sekunden. Wo liegt denn hier das Problem? Verdoppel den Wert in etwas, wenn du sie vor dem Dekodieren verifizieren lässt.

Aber in welchem Tempo muss so eine Datei denn dekodiert werden? Dies ist nun wieder eines der Probleme, die ich sicherlich nie verstehen werde. Minutenlang beim Download warten, aber keine 5 Sekunden Zeit fürs Dekodieren....

[PeteLeFreak]

Aber in welchem Tempo muss so eine Datei denn dekodiert werden? Dies ist nun wieder eines der Probleme, die ich sicherlich nie verstehen werde. Minutenlang beim Download warten, aber keine 5 Sekunden Zeit fürs Dekodieren....
Demnach ist es auch egal, ob dein Auto auf der Autobahn bei freier Strecke 170 oder 210 fahren kann, nachdem du eine halbe Stunde in der Stadt Stop and Go hattest. Ist ja beides schnell genug ;)

Wie am Eröffnungspost zu sehen ist, wird ja auch nicht von mir rumgemoppert, dass die Welt soooo fürchterlich schlimm ist.
Eine derartige Option wäre halt interessant gewesen. ;)

Da keiner darauf eingegangen ist vermute ich mal, dass es bei den Linux-Dekodern ebenfalls so ist.

Habt noch eine schöne Woche und Danke für eure Beiträge.

[mchawk]

Da keiner darauf eingegangen ist vermute ich mal, dass es bei den Linux-Dekodern ebenfalls so ist.
In Anbetracht dessen, dass auf Dein Thema eingegangen wurde würde ich mir an Deiner Stelle diesbezüglich wenig Hoffnung machen.

[PeteLeFreak]

In Anbetracht dessen, dass auf Dein Thema eingegangen wurde würde ich mir an Deiner Stelle diesbezüglich wenig Hoffnung machen.
Da habe ich mich eventuell nicht klar ausgedrückt: natürlich wurde auf das Thema an sich von euch eingegangen. Diese Aussage bezog sich nur auf den anderen Teil der Frage bezüglich Multithreading beim Decoder unter Linux ;)


... von einem Geschwindigkeitsplus von vielleicht 1-2 Sekunden reden. Falls überhaupt ... Aber bitte sehr, wenn du beim Dekodieren dermaßen in Eile bist, drücke ich dir die Daumen dass der Dekoder endlich mal richtig Power bekommt :) ...
Danke fürs Daumendrücken, aber da wird sicher nichts kommen ;)
Wenn das wirklich nur ein, zwei Sekunden bringt habe ich dann wohl doch noch ein Problem an meinem System.

Aktuelles Beispiel mit qotrdecoder-win32-0.0.247-r1132 und Tatort_16.01.24_20-15_ard_90_TVOON_DE.mpg.HQ.avi.otrkey (776 MB) mit Schnittliste von beat7:
Verifizieren knapp 8 Sekunden
Dekodieren ca. 19 Sekunden
Also eine ungefähre eine halbe Minute und damit bei der eigentlichen und doppelt so großen HD-Fassung eine Minute pro Sendung.
Das SSD-Interface wird nur mit ca 30MByte/s belastet, die CPU mit 55%. Arbeitsspeicher bleibt fast unverändert bei 50%.

Wenn ich mal viel Muße habe sollte, werde ich mal schauen, wo der Flaschenhals im Laptop ist.
Aber bis dahin ist dieser Laptop bestimmt schon im Rentenleben als MP3-Schleuder im Partyraum :)

Wie gesagt, alles kein Drama. Wäre halt interessant gewesen.



Euch allen eine gute Woche :cool:

[AndyK70]

Aktuelles Beispiel mit qotrdecoder-win32-0.0.247-r1132 und Tatort_16.01.24_20-15_ard_90_TVOON_DE.mpg.HQ.avi.otrkey (776 MB) mit Schnittliste von beat7:
Verifizieren knapp 8 Sekunden
Dekodieren ca. 19 Sekunden
Also eine ungefähre eine halbe Minute und damit bei der eigentlichen und doppelt so großen HD-Fassung eine Minute pro Sendung.
Das SSD-Interface wird nur mit ca 30MByte/s belastet, die CPU mit 55%. Arbeitsspeicher bleibt fast unverändert bei 50%.

Ich habe jetzt gerade keine Testdaten zur Hand, aber ich erinnere mich auch noch daran, wie ich selbst getestet habe, als ich eine SSD in meinen Rechner eingebaut habe.
Wenn ich auf einer HDD dekodiert habe, dauerte es am längsten.
Wenn ich auf der SDD dekodiert habe ging es schon wesentlich flotter, is ja klar.
Wenn ich von einer HDD auf eine zweite HDD dekodiert habe, ging es aber noch schneller.
Und jetzt habe ich folgenden Workflow: Von HDD auf SDD dekodieren und schneiden zurück auf die große HDD. Das geht am schnellsten bei möglichst wenigen Umkopierungen. So sind selbst 1GB große Dateien in unter 10s dekodiert und genauso viel nochmal fürs Schneiden.