Beiträge von Brother John

truthy
Prinzipiell ja, dein Beispiel passt aber nicht, weil du gecropptes Video (die ersten zwei) mit nicht gecropptem Video verglichen hast. Je nach konkretem Film macht das den Vergleich mehr oder weniger unbrauchbar. Wenn ich von typischem Cropping ausgehe, werden aus 720×576 nämlich vielleicht 720×432 und das BPF ist schon bei 0,197. Und da kannst du schon kaum mehr so pauschal davon ausgehen, dass zu schlecht, wie man das bei 0,148 noch machen kann.

Weil das alles so extrem frei nach Schnauze ist: BPF als grober Anhaltspunkt, um im 2-Pass eine erste Auflösung zu setzen: ja. Als Grundlage für eine endgültige Entscheidung: nein. Dafür gibts ja den Kompressionstest.

Ach, Auflösung ist überbewertet! Zwölfunddreißig mal recodierte Youtube-Starcraftvideos in 320×216 waren auch lange Zeit im Vollbild erträglich … wenn man ne Schicht Rauschen drüberlegt und vorher starke Schmerzmittel nimmt …
Klar hast du recht. Deswegen ja optimistisch anfangen und wenn einem der Comptest auf die Finger haut, dann Platz sparen bzw. Auflösung runter.

Vascalero
Warum eigentlich genau 1500 MB? Machst du dann mit viel Gequetsche drei Filme pro DVD-Rohling? Meiner Xvid-Erfahrung nach reicht 1/2 DVD pro Film nahezu immer für die volle gecroppte Auflösung. Dann hättest du das Auflösungsproblem elegant umgangen und wirst sicher auch nicht pleite davon. Kommt natürlich auch wieder auf deine Abspielsituation an.

Jaaa, das ist die klassische Abwägung zwischen Bilddetails und Kompressionsartefakten. Pauschal lässt sich das leider nicht beantworten.

Wenn du einen brauchbaren Anhaltspunkt willst, mach nen Kompressionstest mit der höheren Auflösung. Wenn der zu schlecht ausfällt, skalierst du runter.

Die PDF ist fertig!
Jetzt fühl ich mich mit dem Encodingwissen endlich wieder wohl. Halbwegs. StaxRip braucht ein Update, wenn ich mal wieder Zeit und Lust habe.

Die Wasserzeichendiskussion hab ich abgetrennt. Hier gehts weiter:
http://forum.gleitz.info/showthread.php?t=41322

Update 20.11.2009

• x264-Kapitel: Fehlerkorrekturen und Anpassung auf die aktuelle x264-Revision 1342.
• Es gibt jetzt einen RSS-Feed. So einfach, wie der zu bauen ist, hätte ich eigentlich viel eher auf die Idee kommen können. Ihr habt nun also eine bequeme Möglichkeit, automatisch auf dem aktuellen Stand in Sachen Encodingwissen zu bleiben.
• Eine aktuelle PDF ist am Entstehen und kommt in den nächsten Tagen nach.

Theoretisch sicher ist H.263. Wie’s in der Praxis aussieht, hat nie jemand getestet. Wenn du Lust hast, die Lücke zu füllen, beim Testaufbau würde ich mitdenken.

P.S.: Von AQ abgesehen, ist die Heini MR für hochqualitative Encodings mit entsprechend hoher Dateigröße ne gute Wahl.

Pittiplatsch
432 ist ein ziemlich normaler Wert nach dem Cropping eines 2,35er-Films. Das kann schon so hinkommen.

Habanero
Mach erst ein Konsolenfenster auf und starte von dort aus x264, dann siehst du auch die Fehlermeldung. Auflösung und Framerate erkennt x264 übrigens bei einem AviSynth-Skript als Quelle automatisch. Kannst du also weglassen und sparst dir dadurch eine mögliche Fehlerquelle.
Welche x264-Version hast du (x264.exe --version)? Evtl. ne aktuelle von https://localhost/www.x264.nl besorgen. x264.exe --help und/oder x264.exe --fullhelp schon gelesen?

Gute Frage. Es ist, wie gesagt, kaum getestet. VAQ und CMs versuchen prinzipiell das selbe zu erreichen. Und wenn in einem Encoder zwei Funktionen an verschiedenen Stellen aufs gleiche Ziel hinarbeiten, kann das ins Auge gehen. Muss aber nicht.

Gefühlsmäßig würde ich maximal eine etwas geringere Effizienz erwarten und eher keine sichtbaren Artefakte. Da es hauptsächlich um einen höheren Quantizer (= stärkere Kompression) für manche Makroblocks geht, schätze ich, dass sich Probleme in verstärkten Blockartefakten äußern würden.

Ja, kannst du.
In kurz: xvid_encraw.exe -help
In lang: http://encodingwissen.de/xvid/cli-referenz.html (noch für Xvid 1.2, also nicht ganz aktuell)

Aktueller Xvid 1.3:
http://www.xvidvideo.ru/xvid-video-cod…tk-x86-x64.html

Keine Ahnung, was MediaCoder anstellt, Xvid kann jedenfalls auch in der Kommandozeilenvariante Matroska-Dateien ausgeben.

Afaik unterstützt MKVMerge keine ASP-Rohdateien. Umbenennen bringt natürlich nichts. Dadurch änderst du ja nicht den Dateiinhalt. Was gehen könnte: Mit Yamb/MP4Box die M4V in MP4 muxen und die dann in MKVMerge laden.

Lumi ist die sehr simple Methode, wie sie schon Ewigkeiten in Xvid drin ist. Variance ist das von x264 portierte, leistungsfähigere VAQ.

Falls du Custom-Matrizen zusammen mit VAQ verwendest, kontrolliere deine Encodings genau. Das Zusammenspiel zwischen den beiden ist praktisch ungetestet und kann theoretisch Probleme machen.

Außerdem ist das doch eh alles kein Problem. Die Nero-Seite prüft ja nur, ob man eine syntaktisch korrekte Mailadresse eingibt und aktiviert dann den Download-Button.

Außerdem:
http://ftp6.nero.com/tools/NeroDigitalAudio.zip
Ich glaube, wir sollten genug Links gesammelt haben, über die man den Encoder kriegt.

Probier’s mal testhalber ohne »MB Tree« (Rate-Control-Tab). Welche x264-Version hast du genau?

Wenn da offensichtlich jemand fragt, der sich nicht so richtig auskennt, wär’s dann nicht besser, solche Spitzfindigkeiten in der Antwort zu vermeiden; oder zumindest zu erklären? So wie’s dasteht, erweckt das erst einmal den falschen Eindruck, als wäre x264 VfW eine ganz normale bedenkenlose Methode.

Zitat von olnima

x264 per VirtualDub(Mod) ist bedingt möglich mit der VFW-Version von x264:

Ja, schon, aber welchen guten Grund gibt es denn, als Endformat H.264 in eine AVI zu vergewaltigen? Mit mag da nicht recht was einfallen.

So subtil wie der Unterschied ist, weil v.a. die 1-px-Linien betroffen sind und die Art wie diese Linien einfach »matter« werden, deutet imo extrem stark auf den Farbraum hin.

Das lässt sich auch nicht vermeiden, weil alle modernen Codecs praktisch ausschließlich mit YV12 (d.h. 4:2:0-Subsampling) arbeiten. Du kannst höchstens das Quellbild so gestalten, dass die geringere Farbauflösung möglichst wenig auffällt. Das ist imo schon der Fall. Ohne die beiden Bilder in verschiedenen Tabs zu öffnen und schnell hin und her zu schalten, ist der Unterschied nicht zu erkennen.

Hast du das Problem in jedem Player?

Nein, mit VDub ist das nicht möglich. Die wichtigsten modernen großen Encoding-Frontends dürften MeGUI und StaxRip sein. Wobei ich StaxRip empfehlen würde, weil es imo eine deutlich bessere Benutzerführung hat. Anleitung z.B. http://encodingwissen.de/staxrip

Wenn du eh schon auf moderne Technik umsteigen willst, wär das auch eine gute Gelegenheit, den ganzen Prozess in Frage zu stellen. z.B.: Ist 2-Pass noch das richtige? Ist das Ziel-Speichermedium zeitgemäß? Passt das bisherige Vorgehen bei Audiospuren, Video-Auflösung etc. noch? Usw. …

Klar geht das: MKVMerge. Doku ist dabei. Am einfachsten ist es wahrscheinlich, wenn du dir mit MKVMerge GUI einen Film zusammenklickst und dann dort nachschaust, wie die passende CLI aussieht.