Du bist ja einer...;D
Beiträge von Kopernikus
-
-
Aus meinem Verständnis heraus sollten sich Mode Decision (P-Skip) und Quantisierung (Trellis/DCT-decimate) nicht beißen, aber ich habe da weder Tests gefahren, noch wirkliche Praxiserfahrung.
Die beiden Optionen greifen an ganz unterschiedlichen Stellen im Encodingvorgang, einmal bei der Entscheidung des Makroblocktyps, und einmal bei der Quantisierung der Koeffizienten, ich sehe da keinen Grund, warum sich das beißen sollte.
-
Ist es echtes schwarz/weiß (1 bit) oder graustufen?
-
Nach der Transformation haben wir anstatt 64 Bildpunkten 64 Koeffizienten, die die Amplituden der Cosinusbasisfunktionen beschreiben. Diese werden durch bestimmte Zahlen geteilt und dann gerundet (Quantisierung). Die übrigbleibenden quantisierten Koeffizienten werden dann in den Bitstream geschrieben.
DCT Decimation verwirft Frequenzkomponenten, die nach der Quantisierung nur sehr kleine Amplituden haben. Das erhöht die Effizienz der nachfolgenden verlustfreien Kompression in einen Bitstream mit RLE und Huffman.
Trellis geht an das selbe Problem etwas professioneller (aber halt auch alangsamer) ran und findet eine nach RD Gesichtspunkten optimale Quantisierung.
-
Ich würde bei --crf noch erwähnen, dass das eine gute Möglichkeit ist, einen Pass gegenüber 2Pass verfahren einzusparen, da die Bitratenverteilung sehr ähnlich ist, die Zielgröße aber nicht genau angegeben werden kann.
--chroma-qp-offset kann nicht sehr viel einsparen, da die Chroma kanäle nur wenig (< 10 %) der Bitrate ausmachen.
--pre-scenecut ist etwas konfus, vielleicht sind aktiviert und deaktiviert vertauscht?
--nr wohl eher Pre als Postprocessing
-
Was ist "neuester Xvid Codec"? Da gibt es durchaus nochmal Unterschiede.
-
Zitat
New build available (for the second time this week): http://members.optusnet.com.au/squid_80/xvid_encraw.zip
Changes include plugh's alternative 2 pass algorithm (thread) and Kopernikus's HVS mods (thread). Also some SSIM options from xvid's CVS.
Zu HVS mods: http://forum.gleitz.info/showthread.php?t=25150
-
-
Eastermeyer: Könntest du sie trotzdem noch auf Rapidshare hochladen, ich hätte das auch gerne?
-
Kann es sein, dass der Formelmodus nicht richtig funktioniert? Oder mach ich was falsch?
Beispiel: https://gleitz.info/wiki/index.php/PSNR
-
Den Sharktooth Build Link kann man im englischen Forum nachschauen, mag sein, dass er sich geändert hat, bei DCT Info vielleicht auf den DCT Wiki Eintrag verlinken oder so.
Warnung würde ich drinlassen, zwar ist x264 stabil, aber es gibt kein offizielles Release.
-
Kopernikus: Frage: Deine Erklärung zu H.264 hier im Forumwäre auch recht hilfreich für H264/ MPEG4 AVC in der Wiki. Könnte man den Text nicht einfach überführen?Doch, gerne. Nur hab ich gerade kein Internet (ausser manchmal wie jetzt grade), von dem her kann ich es nicht zeitnah machen, aber wenn das jemand übernehmen würde, wäre ich dankbar.
-
Eriman: Ich denke nicht, dass man alles 1 zu 1 in die Wiki packen muss, aber vielleicht lassen sich einige Teile recyclen. Was genau man davon nehmen kann muss man halt schauen.
-
Hi allerseits,
falls einer von euch Langeweile haben sollte, und gern ein paar Fachbegriffe "bewaffnen" würde, aber leider nicht ganz genau weiß, was sie bedeuten, dann habe ich hier eine Anregungsquelle:
http://xvid.ist-dein-freund.de/stuff/wiki/index.html
Es handelt sich um einen Entwurf eines Lexikons, das vor einigen Jahren hier begonnen wurde (von ac-chan), aber an dem die Arbeit eingeschlafen ist.
Die Ergebnisse dieser Initiative finden sich auf der obigen Seite. ac-chan hat sie dem Wiki Team zur Verfügung gestellt.
Da ich gerade nur mittelmäßig viel Zeit habe, habe ich bisher nur den aktuellsten Snapshot hochgeladen. Über inhaltliche Fragen müsste man bei Bedarf diskutieren
-
Für Screenshots von Dialogfenstern ist JPEG nicht so gut geeignet, weil es mit den scharfen Kanten Probleme hat, das braucht entweder recht viel Platz (im Vergleich gesehen) oder gibt so hässliches Gekräusel um die Kanten herum. PNG ist rein technisch dafür besser geeignet. JPEG ist eigentlich für natürliche Bilder gedacht.
Es sieht aber nicht so schlimm aus, als dass man es nochmal neu machen müsste (IMHO), für die Zukunft könnte man das aber berücksichtigen.
-
-
Wenn ich mich recht erinnere, war das ein Beispiel für Temproal Supersampling, bei dem auch zeitliche Informationen mitverwendet wurden (Das Bild ist ein Frame aus einem kurzen Clip, verwackelte DigiCam, wenn ich es noch recht weiß). Da gabs auch einen Thread dazu, aber ich find ihn hier grad nicht, vielleicht auch im englischen Forum).
Kannst du das fraktale Ergebnis mal posten, würde mich interessieren, wie das aussieht.
-
und schau mal nach, ob du die avs Datei mit einem Media Player öffnen kannst, und ob die Fehler da auch auftreten.
-
Mit den DivX Presets bist du bei einem DivX zertifizierten Player auf der sicheren Seite.
-
Es sind nur einige Teile des Xvid Codecs für mehrere Kerne optimiert. D.h. man könnte unter Umständen noch beschleunigen, aber dazu sollte man solide Kenntnisse in C, Xvid, Videoprogrammierung und Erfahrung mit Threading besitzen.
Ausserdem ist CPU Auslastung kein so guter Messwert für die Effizienz einer SMP Implementierung.