Das artet sehr schnell in mühsame Tipparbeit aus – und wer will sich schon die Syntax mit den ganzen Pipes und Stream-Umleitungen merken. Deswegen habe ich mir nach und nach ein Python-Skript gebastelt, das alle Varianten abdeckt. Im Idealfall reicht dann ein

venc Quelldatei

fürs 1-Pass-CRF-Encoding incl. Logdatei. Wer das genauso nützlich findet wie ich, sollte einen Blick ans Ende dieses Beitrags wagen. ;-)

Das venc-Skript läuft mit Python 3.2 (oder neuer; ältere 3.x könnten klappen, 2.x nicht) unter Windows. Außerdem nötig sind x264, MuldeR’s Logger, evtl. Avs2yuv und evtl. ein installiertes AviSynth. Standardmäßig wird davon ausgegangen, dass die 32bit-Version von x264 x264.exe heißt, die 64bit-Version x264_x64.exe. Die Aufrufe der Tools und x264-Standardoptionen könnt ihr am Anfang der Skriptdatei im Abschnitt User config anpassen.

Wenn die Quelldatei ein AviSynth-Skript ist, nutzt venc unter 64bit-Windows automatisch den Weg

Quelle.avs ⇒ AviSynth 32bit  ⇒ Avs2yuv  ⇒ x264 64bit ⇒ Ziel

oder bei anderen Quellformaten direkt

Quelle ⇒ x264 64bit ⇒ Ziel.

Unter 32bit-Windows wird natürlich 32bit x264 verwendet und der Umweg über Avs2yuv fällt auch automatisch weg. Außerdem legt venc immer eine Logdatei namens encstats.txt an.

Hier ist der komplette venc-Hilfetext:

x264 encoding script v2.0 Encodes video with x264 in 1-pass CRF mode. Logs information about x264 version, encoding configuration and x264’s info output to encstats.txt. Usage: venc [--mkv|--mp4|--264] infile [sar] [crf] [more options] Example: venc --mp4 "D:\Video files\Source.avs" 16:11 19 --preset fast The order of the parameters is important! Only the [more options] section is passed to x264 as is. Output formats     Can be omitted (defaults to .mkv) or one of the following:     --mkv   Matroska container     --mp4   MP4 container     --264   raw H.264 stream infile     AviSynth script or any other valid x264 input file.     On 64bit Windows if infile is an avs script 64bit x264 via avs2yuv is used     by default. Call the script as venc32 to force usage of x264 32bit.     If infile is not an avs script 64bit x264 is used automatically.     On 32bit Windows obviously 64bit is never used. The output file is created in the same folder as infile with "-ENCODED" added to its name. Existing output files are overwritten. The three x264 config sections are optional. But if you specify one of them you must specifiy all preceding ones as well. [sar]     Pixel aspect ratio in x264 compatible notation. Defaults to 1:1. [crf]     CRF quality level. Defaults to 20. [more options]     Additional x264 options. Defaults to:     --preset slow --tune film     Do not use this section to override CRF or SAR!

Ich hoffe, der eine oder andere kann etwas mit dem Skript anfangen. Wenn Fragen auftauchen, einfach einen Kommentar posten.

Damit man venc tatsächlich einfach mit venc aufrufen kann anstatt venc.py, muss man Windows pythonisieren. Systemsteuerung › System › Erweiterte Systemeinstellungen › Umgebungsvariablen: Dort unter Systemvariablen die Variable PATHEXT bearbeiten und .py als neue Endung hinzufügen. Ab/anmelden bzw. Neustart dürfte nötig sein.

Download: venc.py 2.0

Und das Jahr geht schon gut los. Das Encodingwissen nutzt Contao als CMS. Insgesamt bin ich extrem zufrieden damit, nur eines nervt: Wer einen Kommentar schreibt, muss normalerweise verpflichtend eine E-Mail-Adresse angeben. Bisher hatte ich das per Hack rausgepatcht. Mit dem Update auf v2.10.4 ist es jetzt leider wieder reingerutscht, nur finde ich keine Möglichkeit mehr, das wieder zu ändern. :-(

Dabei interssieren mich eure E-Mail-Adressen doch gar nicht besonders! Wenn jemand weiß, wie ich das Feld wieder optional kriege, bitte melden! Ist zwar kein riesiges Problem, aber schon ärgerlich – von wegen Datensparsamkeit und so.

Dass man in das Feld natürlich auch irgendwelchen Mist eingeben kann, der nach Mailadresse aussieht, muss ich nicht extra sagen, oder? ;-)

Ripping: An eac3to führt kein Weg vorbei. Da Seamless Branching absolut üblich ist, hat man den Film meistens auf viele M2TS-Dateien verteilt und die Tonspuren brauchen unbedingt eine Spezialbehandlung, um synchron zu bleiben. eac3to kann das sehr gut und zerlegt mir den Film in eine MKV mit dem Video plus einzelne Ton- und Untertiteldateien. Genau das, was ich zum Weiterverarbeiten brauche. Man kann mit eac3to zwar auch gleich das Audio-Transcoding übernehmen, aber ich werde es nur zum Rippen und Demuxen verwenden. Mir ist einfach wohler, wenn erst eimal alle Einzelteile unbehandelt auf der Platte liegen.

Vorher muss man natürlich rausfinden, welche Playlist auf der Blu-ray eigentlich die richtige ist. Mit MPC Homecinema geht das zwar halbwegs, aber mit BDInfo geht’s viel übersichtlicher.

Das Audio hat bisher am meisten Zeit gebraucht. Da sich DTS stark durchgesetzt hat, muss BeSweet wohl oder übel in den Ruhestand. Nach einigen Experimenten mit eac3to und ffmpeg bin ich tatsächlich beim guten alten AviSynth hängen geblieben: NicAudio bzw. FFAudioSource, SoxFilter und SoundOut machen’s möglich. Eigentlich habe ich mir in manuell BeHappy zusammengebastelt. :-D

Btw: Vorbis kann seit Frühjahr 2010 sinnvoll Multikanal!? Das ist vollkommen an mir vorbeigegangen! Oh, Mann: jahrelang drauf gewartet und dann eineinhalb Jahre lang verpennt. Schon ein bisschen peinlich, oder?

Bei den Untertiteln bin ich am Überlegen, die SUPs einfach so zu lassen wie sie sind. Im Gegensatz zu DVD-Vobsubs haben die Dinger genug Auflösung, dass man sie tatsächlich lesen kann und sie dabei sogar noch gut aussehen. Andererseits: gute Typografie gibt’s immer noch nicht: es tummeln sich nach wie vor die " als Anführungszeichen und ähnliche Sünden. Also doch Subtitle Edit und Konvertierung nach SRT? Zumindest für UT-Spuren, die ich auch tatsächlich zu Gesicht bekomme, werde ich das wohl machen. Die automatische Umwandlung ist dank Tesseract und Hunspell-Rechtschreibprüfung echt sehr sehr brauchbar geworden.

Zum Video: Tja, vom Echtzeitencoding muss ich mich wohl oder übel verabschieden. ;-) Ansonsten ist’s halt x264. Gewohnter Wein in dickeren Schläuchen sozusagen. Über den CRF-Werten hängt nach den ersten Tests noch ein leichtes Fragezeichen. Müsst ihr die auch je nach Filmtyp anpassen? D.h.: Anspruchsvoller Actionfilm mit CRF 21: problemlos. Pixar-style Animation mit CRF 21: deutliche Artefakte in sehr weichen, glatten Farbverläufen. Aua! Mehr als CRF 18 ging da gar nicht. Ist das normal?

Und nun fehlt eigentlich nur noch, das ganze professionell zu vertutorialen. Aber erstmal muss ich dringend den Vorbis-Encoder anwerfen. :-)

Wenn man Film-Discs anfasst, steht man ja immer sofort mit einem Bein im Arbeitslager. Deswegen lasst mich erstmal versichern, dass ich natürlich niemals die Filmindustrie brutal berauben und meine höchstpersönlich gekauften Scheiben auch abspielen wollen würde. Davon abgesehen gehen wir mal davon aus, dass der Anti-Abspiel-Irrsinn nicht zutrifft.

Was also tun mit der ersten Blauscheibe? Erst rippen und verarbeiten dauert viel zu lange. Schließlich will ich hier stressfrei und jetzt 1080p in Aktion sehen! Einen offiziell Blu-ray-fähigen Softwareplayer einzukaufen, seh’ ich natürlich auch nicht ein. Das muss mit MPC Homecinema gehen! Klappt auch, nachdem ich den Menüpunkt File › Open DVD beherzt großzügig ausgelegt habe – schließlich ist die Blu-ray genauso wie die DVD 12cm groß und rund. Also!

Menüs kann der MPC zwar nicht, aber er sucht sich automatisch die längste Playlist der Disc heraus und spielt die ab. Die Chancen stehen nicht schlecht, dass das der Hauptfilm ist. Ein bisschen lästig ist, dass von jedem Spurtyp einfach die erste aktiviert wird. V.a. heißt das, der Film läuft standardmäßig mit Untertiteln. Naja, das ist schnell behoben, Film läuft und ich bin ein bisschen erstaunt, wie einfach das war. Kein Basteln, keine Hacks? Enttäuschend, wirklich! ;-) Aber das kann beim Encoding ja noch kommen.

Über die Vorzüge vom Blu-ray-Bild brauch’ ich euch HD-Experten ja sicher wenig erzählen. 1080p ist schon saugeil! Dass Disc- und Bildschirm-Auflösung fürs Vollbild genau zusammenpassen, schadet natürlich auch nicht. Ich hab mich spontan dran gewöhnt :-D. Und HD hat ja auch sonst seine Vorteile: Kein PAL-Speedup mehr (teilweise echt irritierend, wenn man den Soundtrack gut kennt), keine vermatschten NTSC-nach-PAL-Transfers. Interlacing … naja … das schaffen wir dann beim HD-Nachfolger gar.

Die neuen Audioformate lassen mich dagegen vollkommen kalt. Ob nun 8 statt 6 Kanäle und noch ein paar Kilobit mehr: das reißt’s nicht raus. Anders die Untertitel: das sind auf einmal keine Pixeltürmchen mehr, sondern die sind ja lesbar, ohne sie erst in Text umzuwandeln! Und sehen dabei auch noch gut aus.

Insgesamt bin ich glücklich, und vielleicht hätte ich nicht ganz so spät einsteigen sollen. Wenn die Industrie mit ihren Anti-Abspielmaßnahmen nicht so massiv Amok gelaufen wäre, hätte ich das wohl auch getan. Aber so war eine zeitlang Boykott einfach bitter nötig.

Für den ersten HD-Eindruck soll das erstmal reichen. Demnächst zur allgemeinen Erheitung auf diesem Kanal: Brother Johns erste HD-Encodingversuche. Stay tuned! ;-)

Nötig war’s. Die Handarbeit funktioniert beim Videoencoding bestens, für ein Webprojekt schränkt sie vor allem ein. Bisher war allein der RSS-Feed schon ein echter Schmerz im Hintern – weil handgetippt. Jetzt ist das bequem und stressfrei und ich bin glücklich :-).

OK, was heißt das Update konkret?

• Alle Seiten können jetzt kommentiert werden. Und da bin ich ja gespannt, ob/wieviel/was da so an Getippsel eintrudelt. Wünscht mir Glück, dass sich der Spam in Grenzen hält …
• Die Adressen von einigen Seiten haben sich geändert. Dank Suchfunktion sollte das aber kein großes Problem sein. Alle haarklein rauszufieseln und umzuleiten, wäre einfach zu aufwändig gewesen.
• Die Adresse des RSS-Feeds hat sich geändert. Die alte funktioniert zwar noch, aber das wird nicht bis in alle Ewigkeit so bleiben. http://encodingwissen.de/blogfeed.xml ist die neue. Ja, da steht nun Blog. Das ist das, was früher Changelog hieß ;-). Wie blog das tatsächlich werden wird, mal sehen.
• Neue technische Basis geht natürlich nicht ohne neue Optik. Ich schätze, da werd’ ich in nächster Zeit noch ein bisschen rumpolieren (müssen), bis wirklich alles browserübergreifend run läuft.

Was mich bisher genervt hat war der Riesenaufwand, um mal ein kleines Update online zu kriegen. Das sollte jetzt deutlich einfacher werden. Leichte Anpassungen gibt es schon für StaxRip. V.a. die Optionen-Dialoge haben sich in der aktuellen Version doch etwas geändert.

Neues, Altes und Anderes:

• Taschentücher raus, bitte! Auf Wiedersehen, Gordian Knot! Ab und zu braucht es einen Generationswechsel, und der ist nun in Sachen Frontends endgültig passiert. Gordian Knot ist nicht mehr Teil des Encodingwissens. Aber keine Angst: Für ein schnelles Wiedersehen ist gesorgt, denn das komplette Gordian-Knot-Kapitel ist weiterhin auf Brother-John.net verfügbar. Es wird allerdings keine Updates mehr geben. Dass es keine ausgegliederte GK-PDF gibt, liegt hauptsächlich an Faulheit und mangelnder Zeit. Ob die PDF nachkommt, da mag ich mich im Moment nicht festlegen.
• Da der Abschnitt zur Videocodec-Konfiguration immer mehr wächst, ist er nun nicht mehr Teil des Hintergrundwissens sondern bildet seine eigene Kategorie namens Codecwissen.
• Update des x264-Kapitels für Revisionen nach den Änderungen um --subme und --b-adapt und der Einführung von --psy-rd.
• DivX 7 hat das Licht der Welt erblickt und wird im DivX-Abschnitt kurz angesprochen.
• StaxRip-Update für die aktuelle Version.