Beiträge von 708145

Zitat von LigH

Nicht? — Hmm. Ich kann mir nie merken, ob die Parallelisierung immer noch über Slice-Bildung geht oder doch keinen Einfluss mehr auf die Vektorsuche hat...

Slice based parallelism war nur bei frühen X264 Versionen in Verwendung.

XviD SMP verwendet Zeilen von MacroBlocks die soweit parallel beerechnet werden, wie alle benötigten MBs auch schon da sind. Daher rührt der hohe Overhead!
Mein ELDER ist zwar effizient, aber passt eben nicht in Anwendungen wie AutoGK oder VDM, und damit interessiert sich kein Schwein dafür, dass man auch auf 64 Kernen kodieren kann
Dauert aber nur noch ca. 1 Jahr bis Intel den >64 Kern Atom rausbringt
< edit>Edith sagt grad, dass der aber eh net für HeimNutzer erhältlich sein wird sondern für SuperComputer. Schade, das. < /edit>

X264 hat ein Frame basiertes Modell: unabhängige Frames werden parallel kodiert. Das ist das intelligenteste hat aber bei XviD niemand implementieren wollen

bis besser,
T0B1A5

Zitat von LigH

Doch... die Anzahl Threads ist schon wichtig. Sie hat auch einen Einfluss auf die Auslastung mehrerer Kerne. Allerdings auch auf die Qualität der Encodierung.

Vielleicht wollen manche Zocker noch eine ZockCPU von XviD unbefleckt lassen :p
Ansonsten ist sicher eine AutoErkennung das Beste.

Bei XviDs SMP hat die Zahl der Threads keinen Einfluss auf die Qualität im Gegensatz zu X264 wo ein geringer Einfluss auf die RateControl da ist.

Aber warum diskutiere ich hier eigentlich mit? Privat habe ich immer noch einen SingleCore AMD, hehe.

bis besser,
T0B1A5

Zitat von Drognaut

[...]
Habe dann zufälligerweise einen Versuch mittels AutoGK gemacht. Damit probeweise ein Stream encoded und siehe da XviD benutzte beide Kerne; Systemauslastung von 100%. Und die Zeit war die Hälfte dessen wie mit VDM.
[...]

Hallo,

das mit der Auslastung von Nahe 100% kann ich ja glauben, das gibt es seit ca 2 Jahren, aber der Speedup von 2 ist nur schwer zu schlucken.
Kannst Du bitte mal mit einer Stoppuhr (also absichtlich nicht auf die angezeigten fps verlassen) beide Szenarien mit dem gleichen Werkzeug stoppen?
Also AutoGK mit einem Kern gegen AutoGK mit 2 Kernen?

Wenn Du das Tool, die Xvid-Version und die Anzahl Kerne auf einmal tauschst, dann hat das Ergebnis ja nicht direkt mit dem XviD Speedup zu tun sondern ist eine Mischung.

bis besser,
T0B1A5 ... der sich fragt, warum es 2 Jahre gedauert hat bis die meisten Leute 1.2.0 entdecken und wieviele Jahre es wohl noch dauern wird bis die Masse ELDER4XviD entdeckt :p

Zitat von LigH

Wenn in dem Dateinamen wenigstens ein "1.2" zu lesen wäre ... laut Datum ist die aktuellste Version: XviD.cvs.head.MTK.exe

Es gibt nen 1.1 Zweig und nen 1.2 Zweig. "head" ist meines Wissens im 1.1er Zweig, d.h. wer einfach nur so das repository aus-checkt bekommt die 1.1
In anderen Worten: Wer immer nur nach der "neuesten" Version sucht, der bekommt die "alte" 1.1. Andere sind dagegen mit der "alten" 1.2 zufrieden
An der 1.2 wurde auch schon ne Weile nicht mehr gebastelt funktioniert aber ganz gut so wie sie ist. Es ist wie immer jeder eingeladen weiterzuentwickeln.

bis besser,
T0B1A5

Zitat von LigH

"RemoteAVC".
It is loosely based on MeGUI and ELDER4X264.

(Auch witzig: Gerade mal 10 Beiträge, aber anscheinend so passend platziert -- ich hätte mit einigen hundert gerechnet... der "Profi-Lemming" fällt auf.)

Ja, so viel schreib ich halt net in Foren. *uups* schon wieder ein Beitrag... wenn das so weitergeht, dann knack ich die 1000 ja schon vor 2020

Zitat von kurt

bei x264 klappt die Prozessor-Ausnutzung beim meinem core duo sehr gut, aber vielleicht liegt das ja auch an der anderen Architektur des Codecs. Andererseits muss es ja auch nicht heißen, dass Codec A besser/schneller ist, nur weil er mehr Cyclen braucht - auf die Effizienz kommt es letztlich an. Und da könnte sicherlich bei xvid noch was rausgeholt werden

Ich hab da vor 3 Jahren was programmiert. Nannte sich ELDER4xvid. Die Nachfrage war verschwindend gering und Multicore CPUs auch noch nicht sehr verbreitet.

Ich komme leider nicht mehr dazu weiter zu machen trotz mehrer Anläufe in den letzten Jahren.

Das Problem ist:
a) xvid ist für die meisten schnell genug mit dem enthaltenen SMP code (1.2)
b) x264 hat nen super SMP code eingebaut
c) snow und theora verwendet niemand ernsthaft
d) Bei viel Preprocessing ist der Codec sowieso nicht der kritische Teil

Fazit: Auch heute noch kaum Bedarf. Wer ELDER aber ausgraben und verbessern will ist gerne dazu eingeladen. Ist alles GPL und staubt auf meinem Server zu

bis besser,
Tobias

Zitat von Brother John

Mir spukt gerade die dumme Idee im Kopf herum, ob man nicht auch mit Xvid so etwas wie CRF-Encoding hinkriegen könnte.

ELDER macht das schon seit einem Jahr. Hat aber keinen interessiert.
Zur Zeit ist das Projekt tot weil ich keine Zeit mehr reinstecke.

bis besser,
Tobias

Zitat von Selur

Ist der Output wirklich bit-gleich?

Nein, aber "verdammt nah dran"(tm). Einen Unterschied gibt es nur weil die ratecontrol in jedem Chunk von vorn anfängt. Dieser Fehler ist aber verdammt klein, überzeug dich selbst.

Im zusätzlichen crf Modus ist die Bitverteilung anders als im normalen 2pass Modus. Das soll so sein, denn das Ziel hier ist eine noch konstantere Qualität über den Gesamtfilm zu erreichen, genauso wie der crf Modus von x264 dies tut.

bis besser,
Tobias

Zitat von Gawith

ELDER hab ich schon gefunden, aber nicht weiter verfolgt, weil ich ein Linux-Prog brauche.

Und ich warte seit Jahren auf Avisynth3.0 damit ich es portieren kann... ELDER ist ist nämlich weitgehend OS unabhängig.

Zitat von Selur

Drastisch sollte es sich nicht verschlechtern. Hier und da wird das Ergebnis nicht so optimal Ausfallen, wenn die Einteilung der Chunks sinnig gewählt ist und die Ratecontrol keine fatalen Fehler macht sollte der unterschied minimal sein.

Ich habe eine Cluster Lösung geschrieben, die keine Qualitätseinbussen hat
Demnächst kommt noch ein Resume-Modus hinzu, d.h. man kann dann encodes auch unterbrechen.

ELDER findet ihr hier: http://forum.doom9.org/showthread.php?p=718465#post718465

bis besser,
Tobias

Zitat von Kopernikus

wie hast du den CRF Modus für XviD realisiert? Muss man zwei Durchgänge machen, und er rechnet die Quantverteilung aus dem stats File anders als der XviD Standard Algorithmus oder reicht ein Durchgang?

Falls zweiteres würde mich sehr interessieren, wie das im Detail funktioniert. Vielleicht könntest du ein paar Worte dazu sagen?

Ich habe mich für eine möglichst einfache Realisierung des Prototyps entschieden. Ich mache je einen xvid und x264 first pass und berechne daraus das neue stats file und die Bitratenverteilung.
Ist also insgesamt 3 pass

Das Ganze soll ja auch nur zeigen was ein crf Modus bei xvid bringen kann. Eine native 1pass Implementierung ist schon auch möglich aber wesentlich mehr Aufwand.
Also einfach mal testen und sehen ob es genug bringt.

Ausserdem habe ich noch einen qcomp Modus, das ist ein 2pass Modus der die Bits genauso verteilt wie x264 bei qcomp 0,6.

Zitat von LigH

Ich gehe mal davon aus, dass der Rate Factor im Verlaufe der Quantisierung nebenbei ermittelt werden kann, wodurch bereits in einem Durchgang eine schnelle Anpassung der Quantisierung zur Korrektur und Stabilisierung des Rate Factors führen kann.

Aber verständlicher wird es sicherlich, wenn man versteht, an welcher Stelle der Encodierung er eigentlich greift. Denn wenn sich der Rate Factor nicht direkt proportional mit dem Quantisierungsfaktor ändert, dann muss ja die Abhängigkeit vom Bildinhalt irgendwie anders ermittelt werden.

Direkt proportional ist da leider gar nix. Wäre zu einfach. :p
Aber Du hast recht: Der Rate Factor kann nebenbei ermittelt werden und auch mit xvid ist ein 1pass crf Modus möglich.

Ich spiele grad noch mit weiteren Verbesserungen, manche sind leider zu keinem existierenden Standard kompatibel.

bis besser,
T0B1A5

Zitat von Massaguana

ich würde schon gerne mit der vorhandenen Software weiter arbeiten.

Kein Problem. Muss ja auch irgendjemand bei VDub bleiben

Hallo miteinander,

ich wollte euch auf meine neueste Entwicklung hinweisen: Einen crf Modus für XviD.
Das Ganze habe ich in ELDER integriert, d.h. ihr könnt direkt loslegen. Input ist .avs, Output bisher .mp4. Ich werde aber avi noch nachrüsten, auch wenn mir persönlich der Sinn schleierhaft ist. Matroska kommt natürlich auch

Zwei Modi bezüglich crf sind drin:
1) xvid 2 pass, der die Bits genauso verteilt wie x264 im crf n Modus (n ist der Parameter)
2) xvid 2pass mit Zielgröße, der die Bits so verteilt wie x264 mit qcomp 0.6

Einen "nativen" crf Modus werde ich vielleicht später einbauen. Jetzt sollte erst einmal das grosse Testen losgehen

Im englischen doom9 Forum ist mein Announce Thread: http://forum.doom9.org/showthread.php?t=100766

Ach so: verteilt auf SMP oder mehreren Windows PCs kodieren kann ELDER auch.

bis besser,
T0B1A5

Ich liebe ja jeden Fortschritt den XviD macht, aber wäre es nicht allgemeingültiger einen HVS basierten RD Modus einzubauen?

Soweit ich weiss betrachtet SSIM auch Helligkeiten und Kontraste.

Noch ne prinzipielle Frage: Darf man in ASP jeden Block beliebig quantisieren oder gibt es nen maximalen Abstand zum frame quant?

bis besser,
T0B1A5

Zitat von Kopernikus

Was lange währt wird endlich gut

Freut mich, dass es funktioniert.

Hab mich grad für's deutsche Forum registriert. Hallo miteinander

Wie gut würde AQ mit höheren Quants funktionieren?
Ich frage weil ja bei Q3 encodes +-1 enorm viel ist. Also was ist mit ner CQM die alle Werte halbiert oder drittelt und damit den quant Bereich 2..6 der oft verwendet wird nach 4..12 bzw. 6..18 abbildet. Dann ist der Einfluss von AQ besser steuerbar.

bis besser,
T0B1A5