QuEnc^n - Das Multicore frontend für QuEnc v0.1 (Beta)

Hi Leute,

Hoffe mal, dass das Thema hier reinpasst ! :seher:
Ansonsten bitte an einen der Mods den Fred sonst in die richtige Ecke zu verschieben.

Ich habe gerade die letzten Tests mit QuEnc^n gefahren und denke, dass es bereit für eine Beta Release ist.

Da QuEnc nicht Multiprozessortauglich ist, aber immer mehr Multicore PCs auf den Markt drängen habe ich mir kurzerhand entschlossen ein Frontend zu "bauen", was diese Funktionalität nachrüstet.

Ich hoffe ihr verzeiht mir, wenn ich kurzerhand einfach nur einen Teil der englischen Readme poste:

Zitat

Q: What is QuEnc^n ?
A: A simple AutoIt script which forks "n" instances of QuEnc to enable the owners
of multicore PC systems to get the max performance of their systems.

Q: How does QuEnc^n work ?
A: Short answer: Very simple !
Long answer: It takes the source AVS and generates a separate AVS-segment for each
core, e.g. if you have 4 cores and a video length of 1811 frames then QuEnc^n will
calculate the following ranges:
Calculated Range# 0: 0-453
Calculated Range# 1: 454-906
Calculated Range# 2: 907-1359
Calculated Range# 3: 1360-1811
Now QuEnc^n copies the source AVS four times and adds a Trim to the end of every
temporary AVS-segment, e.g. Trim(0,453) for the first AVS. Then a QuEnc instance
is run for each segment. QuEnc^n will monitor until all QuEnc processes have closed
and then merge all segment under the output name specified in the CLI.

Alles anzeigen

QuEnc^n gibts hier: http://de.geocities.com/dark_soul_71/QuEnc_n.zip

Gruß,
D$

LigH:
Mag ja sein, aber
1) kann ich bei 60-70% Geschwindigkeitssteigerung auf nem Dual Core auf das letzte Quäntchen Quallie verzichten.

2) Quetsche ich meine DVDs nicht so mit analogen Filmen voll, dass ich da erheblich Einbussen erwarte. Wenn du halt ganz weit runter gehst, dann mögen 2x45 min encodeter Film gemerged eventuell eine sichtbar schlechtere Quallie haben als 1x90 min, aber in den Fällen mit 2-4 Segmenten bei 3-4 MBit wage ich zu bezweifeln, dass das sooooo sehr sichtbar ist. Ausser der Encoder wäre zu schlecht.....

3) Nutzt DVD-RB ja das selbe Konzept und da regt sich keiner über Qualität auf.

Zitat

Einen wirklichen Gewinn könnte man bei Mehrprozessor-Unterstützung nur in wirklich parallelisierbaren Anteilen des Encodierungs-Algorithmus erreichen, die sind aber eher eng beschränkt und innerhalb von kleinen Bereichen des jeweiligen Einzelbildes, über mehrere Bilder oder größere Flächen hinweg ist eine Parallelisierung kaum möglich.

Obwohl ich kein Encoderentwickler bin bezweifele ich das jetzt generell einfach mal. Mag sein, dass "mein" Ansatz mit separat laufenden Encodern nicht optimal ist, aber betrachte dir doch die Arbeitsweise im 2 Pass Modus. Im ersten Durchgang wird das Video analysiert. Wer hindert den Entwickler daran mehrere Segmente gleichzeitig zu analysieren ? Analog dazu könnte der Encoder auch mehrere (2 ?) Segmente mit der entsprechenden Bitratenverteilung encoden.

Im Cluster wird das ohne vorherige Analyse vielleicht zu Problemen führen, aber wenn ich z.B. einen Encoding Cluster für DVD-RB bastele wo jede Encoding Node nur das selbe Segment runterrechnet was DVD-RB erstellt hat, dann hast du auch im Cluster keinen Quallieverlust, weil ist ja egal ob nun ein Encoder nacheinander die Segmente encodet oder mehrere parallel. Daran bastele ich übrigens auch grade.

Sry, ich finde der Ansatz hinkt ein bisschen. Mal angenommen QuEnc würde nen "Q"-Encoding Modus bieten und man könnte sowas ähnliches entwickeln wie in D2SRoBa integriert (OPV mit size prediction), dann könnte das "Frontend" den "optimalen" Q-Faktor für den gesamten Film finden und hinterher mehrere Segmente unabhängig vonaneinder mit dem ermittelten Q-Wert vergleichen. Mir kann keiner erzählen, dass sich eine "Q"-Encodingvariante nicht in QuEnc (oder andere Freeware Encoder) integrieren liesse.

HCEnc hat sich leider bei meinen Experimenten mti dem Constant Quantizer Encoding Modus als ungeeignet für die OPV Prediction gezeigt. Mit AutoMatQEnc (bei dem Sapstar sich aber auch um "Kompatibilität" zu CCE bei CQ bemüht) funzt die Prediction schon ziemlich gut und der arbeitet basierend auf der selben Lib wie QuEnc.

Ich denke es gäbe genug praktikable Ansätze: Eventuell einen Encoder mit "Quick First Pass" (analog zum Encoding bei OPV Prediction) der durch encoden von kurzen Samples sowas wie einen "schnellen Überblick" über den Film erhält, also wo viel Action ist und wo wenig und dann sein "Bitratenreservoir" entsprechend verteilt.

Heya Erklärbär,

ich finde es schade, dass du nicht nochmal "Stellung beziehst".
Weißt du, "stänkern" kann jeder. :nein:

Erinnert mich irgendwie stark an die typischen "Bedenkenträger", die wir in der Firma auch immer sitzen haben. Große Sprüche "Das könnte kritisch sein", "Daran muss man denken" und keine Lösungsvorschläge einbringen. Nicht dass ich dich nach Lösungsvorschlägen gefragt hätte, aber ich würde mir wünschen, dass sich jemand wenn er schon postet auch ein bisschen neutral mit der Materie auseinandersetzt.

Bevor ich mich dazu äußern würde wie und ob "segmented" encoding einen wirklich sichtbaren Impact auf die Qualität hat, würde ich mal eine solide Testreihefahren, z.B.
Quellvideo 30 min / 60 min / 120 min
1-16 Segmente
Bitraten von 1.2 bis 4 MBit.

Dann die finalen Videos mit einem PSNR Tool wie dem PF Comparer mal testen (http://www.mpeg-vs-avi.de/PF%20Comparer.html).

Erst wenn man dann mal ein paar Zahlenwerte hat, kann man sich noch ein bisschen mehr über die Zahlenwerte diskutieren, wie z.B. wie groß ist der Qualliedrop bei n Segmenten und m kBit.

Wie groß der visuell erfassbare Verlust dann ist, wenn z.B. die segmentiert encodete Datei nen PSNR Wert von 70 und die am Stück encodete Datei von 73 hat, dass lass ich jetzt mal dahin gestellt sein.

Alles Andere is Kaffeesatzleserei und Unkenrufen ! :seher:

cu,
D$

P.S.: Danke auch für den Hinweis mit der Cluster-Geschichte. Der Fred war zwar schon ein bischen alt, aber interessanter Lesestoff.

seeigel:
"stänkern" steht bewusst in Anführungszeichen ! Ich spreche Ligh generell nicht seine Erfahrung ab, aber achte auf seine Wortwahl:

Zitat von LigH

Die Geschwindigkeit wird es eventuell erhöhen;

Man möge sich diese Aussage auf der Zunge zergehen lassen. Die Geschwindigkeit wird es eventuell erhöhen - QED

Drüben auf doom9 hat Revgen nen Test mit nem 4600+ X2 Dual-Core Athlon gemacht und für analoges, interlacetes Material ca 65% Geschwindigkeitssteigerung erzielt
http://forum.doom9.org/showpost.php?p=825589&postcount=12

Bei progressivem Material über 80%:
http://forum.doom9.org/showpost.php?p=826001&postcount=16

Soviel zum Thema "eventuell". Ist ja wohl klar, dass ich zumindestens 30-40% Geschwindigkeitsteigerung bei diesem Ansatz kriege, wenn ich zwei Instanzen eines Encoders gleichzeitig auf ner DualCore Maschine laufen lasse...

Zitat von LigH

die Qualität aber bestimmt nicht

Ich habe nie davon gesprochen, dass die Qualität "gesteigert" werden soll, aber es bleibt ohne echte praktische Tests (wie in meinem oberen Posting ja geschrieben) einfach Kaffeesatzlesen wie gut oder schlecht so ne Methode funzt. Die Mehrheit der Nutzer von QuEnc^n wird ja wohl kaum 3 min Viva Musikvideos auf nem 16 Core Server mit 1 MBit/s encoden, oder ? :ani_lol:

Ganz im Gegenteil: Die breitere "Masse" (wenn es denn eine gibt) wird wohl eher zu Hause auf nem Dual Core (bestenfalls Dual CPU Dual Core oder Dual Core mit HT) nen Film >= 90 min encoden, oder meinst du nicht ? :ja:

Dedadewegen und gerade weil ich auch (eben erst) mitbekommen habe, dass QuEnc auch CQ kann, denke ich bereits über eine "dynamische" Bitratenverteilung pro Segment nach.

Schon deshalb (man möge mir Encoder Mongo verzeihen) halte ich solche Aussagen wie diese schlichtweg für Käse:

Zitat von LigH

Ein solches Thema wurde bereits unter dem Stichwort "Clustering" besprochen; im Allgemeinen ist das generell wenig geeignet für Videoverarbeitung. Einen wirklichen Gewinn könnte man bei Mehrprozessor-Unterstützung nur in wirklich parallelisierbaren Anteilen des Encodierungs-Algorithmus erreichen, die sind aber eher eng beschränkt und innerhalb von kleinen Bereichen des jeweiligen Einzelbildes, über mehrere Bilder oder größere Flächen hinweg ist eine Parallelisierung kaum möglich.

Direkt auf den Encoding Algorithmus bezogen hat LigH ja bestimmt Recht, dass dieser nicht sehr gut parallelsierbar ist, aber der Segmentansatz ist sehr gut parallelisierbar.

Damit meine ich z.B. die Möglichkeit den ganzen Film per CQ mit Size Prediction zu analysieren und dann mit konstantem CQ Wert die einzelnen Schnippsel encoden. Wo soll da bitte die Quallie leiden ?

...aber gut, ich bin doof und LigH hat Recht.:daumen:

Hi Leute,

freut mich ja, dass hier ein bisschen "Bewegung" reingekommen ist.

Meine Ansatz mit der CQ Methode sieht garnicht so schlecht aus:

22:12:29 >>Starting Calculation for Adaptive Bitrate Distribution (ABD) !
22:12:29 >>Average Filesize for Samples: 1.49 MB
22:12:29 >>Average Bitrate specified in CLI: 3789 kBit/s
22:12:29 >>Filesize for Sample # 0:                  1507265 MB
22:12:29 >>Filedeviation for Sample # 0:             -3.39 %
22:12:29 >>Bitrate Correction Factor for Sample # 0: 1.03388236493116
22:12:29 >>Corrected Bitrate Factor for Sample # 0:  3917
22:12:29 >>Filesize for Sample # 1:                  1196836 MB
22:12:29 >>Filedeviation for Sample # 1:             -23.29 %
22:12:29 >>Bitrate Correction Factor for Sample # 1: 1.23285927432452
22:12:29 >>Corrected Bitrate Factor for Sample # 1:  4671
22:12:29 >>Filesize for Sample # 2:                  1408118 MB
22:12:29 >>Filedeviation for Sample # 2:             -9.74 %
22:12:29 >>Bitrate Correction Factor for Sample # 2: 1.0974330114095
22:12:29 >>Corrected Bitrate Factor for Sample # 2:  4158
22:12:29 >>Filesize for Sample # 3:                  1881345 MB
22:12:29 >>Filedeviation for Sample # 3:             20.59 %
22:12:29 >>Bitrate Correction Factor for Sample # 3: 0.794106821196945
22:12:29 >>Corrected Bitrate Factor for Sample # 3:  3009
22:12:29 >>Filesize for Sample # 4:                  1126985 MB
22:12:29 >>Filedeviation for Sample # 4:             -27.76 %
22:12:29 >>Bitrate Correction Factor for Sample # 4: 1.27763194729656
22:12:29 >>Corrected Bitrate Factor for Sample # 4:  4841
22:12:29 >>Filesize for Sample # 5:                  1429775 MB
22:12:29 >>Filedeviation for Sample # 5:             -8.36 %
22:12:29 >>Bitrate Correction Factor for Sample # 5: 1.08355143808119
22:12:29 >>Corrected Bitrate Factor for Sample # 5:  4106
22:12:29 >>Filesize for Sample # 6:                  1963289 MB
22:12:29 >>Filedeviation for Sample # 6:             25.84 %
22:12:29 >>Bitrate Correction Factor for Sample # 6: 0.74158284997219
22:12:29 >>Corrected Bitrate Factor for Sample # 6:  2810
22:12:29 >>Filesize for Sample # 7:                  1967393 MB
22:12:29 >>Filedeviation for Sample # 7:             26.1 %
22:12:29 >>Bitrate Correction Factor for Sample # 7: 0.738952292787937
22:12:29 >>Corrected Bitrate Factor for Sample # 7:  2800

Hm, sind doch schon ganz schöne Varianzen pro Segment drin.

Zitat von Trekkie2

Hm, beleidigt zu schmollen treibt Dein Projekt sicher nicht voran.

Das solltest du nicht überbewerten. Ich bin, sagen wir mal, offensiv sarkastisch.

Wenn jemand was ablässt ohne die Software ganz ersichtlich nicht mal angetestet zu haben, dann darf ich mich nicht gerade darüber freuen, oder ?

Fakt is ja wohl, dass der Erklärbär (sorry LigH, ich find´s echt geil !) erstmal rein theoretisch geposted hat, oder ?
Das Bedenken ist theoretisch durchaus berechtigt, aber ich stelle immer noch in Frage wie viel davon ein DualCore User merkt, der mit QuEnc^n ausschließlich längere Filme mit ordentlichen Bitraten encodet, oder ?

Aber lassen wir das....

Ich habe die ABD Funktion jetzt mal einfach spaßhalber implementiert und werde mal ein paar Tests fahren.

We´ll see...

Kopernikus:
Habe keine Ahnung, ob die Statsfiles so einfach lesen kann. Das wäre natürlich auch ein Ansatz.

D$