Von der ISO-DVD zum AVI-Hardsub - Versionsgeschichte

Devil Doll: +Interner Link

2008-06-10T14:29:44Z

+Interner Link

← Nächstältere Version		Version vom 10. Juni 2008, 16:29 Uhr
Zeile 50:		Zeile 50:
	Im selben Verzeichnis wie diese Projektdatei werden die extrahierten Audio-Streams gespeichert. Ab diesem Zeitpunkt bleiben Bild- und Toninformationen getrennt und werden erst beim Encoding eines fertigen AVI-Containers wieder zusammengefügt.		Im selben Verzeichnis wie diese Projektdatei werden die extrahierten Audio-Streams gespeichert. Ab diesem Zeitpunkt bleiben Bild- und Toninformationen getrennt und werden erst beim Encoding eines fertigen AVI-Containers wieder zusammengefügt.

	In dem während der Verarbeitung geöffneten Dialog wird dabei auch das ''tatsächliche Seitenverhältnis des Videos'' angezeigt (welches ''nicht'' mit dem Seitenverhältnis übereinstimmt, in dem DGIndex das Video selbst anzeigt!); diese Information sollte man sich ggf. notieren, sie wird später noch benötigt werden.		In dem während der Verarbeitung geöffneten Dialog wird dabei auch das ''tatsächliche Seitenverhältnis des Videos'' angezeigt (welches ''nicht'' mit dem Seitenverhältnis übereinstimmt, in dem DGIndex das Video selbst anzeigt!); diese Information sollte man sich ggf. notieren, sie wird [[#Auswahl_des_Zielformats_.28mod16-Regel.29\|später noch benötigt werden]].

	== Bearbeitung der Video-Daten ==		== Bearbeitung der Video-Daten ==

Devil Doll: +interner Link

2008-06-10T14:28:27Z

+interner Link

← Nächstältere Version		Version vom 10. Juni 2008, 16:28 Uhr
Zeile 132:		Zeile 132:
	==== Auswahl des Zielformats (mod16-Regel) ====		==== Auswahl des Zielformats (mod16-Regel) ====

	Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.		Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir [[#Durchf.C3.BChrung_des_Analyselaufs_mit_DGIndex\|während der Analyse des DVD-Materials ermittelt]]). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.

	Welche Bildgröße wollen wir erreichen? Beide Seitenlängen ''müssen'' (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:		Welche Bildgröße wollen wir erreichen? Beide Seitenlängen ''müssen'' (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:

Devil Doll: /* Filter zur Qualitätsverbesserung */

2008-06-10T14:15:08Z

Filter zur Qualitätsverbesserung

← Nächstältere Version		Version vom 10. Juni 2008, 16:15 Uhr
Zeile 165:		Zeile 165:
	RemoveGrain (mode=2)		RemoveGrain (mode=2)

	Der Parameter <code>mode=2</code> weist die Funktion an, das bezüglich des Einsparungseffekts beste der drei vom Autor als "risikolos" beschriebenen Verfahren anzuwenden; die Funktion unterstützt auch weitaus aggressivere Verfahren (die dann allerdings dünne Linien beschädigen können etc.), welche in der mitgelieferten Dokumentation des ~~TIVTC~~-Pakets ausführlich beschrieben sind.		Der Parameter <code>mode=2</code> weist die Funktion an, das bezüglich des Einsparungseffekts beste der drei vom Autor als "risikolos" beschriebenen Verfahren anzuwenden; die Funktion unterstützt auch weitaus aggressivere Verfahren (die dann allerdings dünne Linien beschädigen können etc.), welche in der mitgelieferten Dokumentation des RemoveGrain-Pakets ausführlich beschrieben sind.

	Diese Funktion wird realisiert durch eine im Paket [http://avisynth.org/mediawiki/Removegrain RemoveGrain] enthaltene Bibliothek (der konkrete Dateiname ist von der CPU des Zielrechners abhängig, siehe Installationsanleitung), welche entweder durch die Anweisung <code>LoadPlugin</code> dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss.		Diese Funktion wird realisiert durch eine im Paket [http://avisynth.org/mediawiki/Removegrain RemoveGrain] enthaltene Bibliothek (der konkrete Dateiname ist von der CPU des Zielrechners abhängig, siehe Installationsanleitung), welche entweder durch die Anweisung <code>LoadPlugin</code> dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss.

Devil Doll am 12. März 2008 um 14:56 Uhr

2008-03-12T14:56:27Z

← Nächstältere Version		Version vom 12. März 2008, 16:56 Uhr
Zeile 119:		Zeile 119:
	# Linke obere Ecke (Spalte)		# Linke obere Ecke (Spalte)
	# Linke obere Ecke (Zeile)		# Linke obere Ecke (Zeile)
	# positiver Wert: Breite des Bildes nach Wegschneiden des ~~Randes~~;<br>negativer Wert: Rechte untere Ecke (Spalte)		# positiver Wert: Breite des Bildes nach Wegschneiden des Rands;<br>negativer Wert: Rechte untere Ecke (Spalte)
	# positiver Wert: Höhe des Bildes nach Wegschneiden des ~~Randes~~;<br>negativer Wert: Rechte untere Ecke (Zeile)		# positiver Wert: Höhe des Bildes nach Wegschneiden des Rands;<br>negativer Wert: Rechte untere Ecke (Zeile)
	Bei einem Aufruf <code>crop (4,2,-0,-2)</code> würden also links 4 Pixel, rechts 0 Pixel sowie oben und unten jeweils 2 Pixel weggeschnitten (bei Angaben in dieser Notation muss man weniger rechnen ;-).		Bei einem Aufruf <code>crop (4,2,-0,-2)</code> würden also links 4 Pixel, rechts 0 Pixel sowie oben und unten jeweils 2 Pixel weggeschnitten (bei Angaben in dieser Notation muss man weniger rechnen ;-).

Zeile 136:		Zeile 136:
	Welche Bildgröße wollen wir erreichen? Beide Seitenlängen ''müssen'' (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:		Welche Bildgröße wollen wir erreichen? Beide Seitenlängen ''müssen'' (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:
	* Für Videos mit den Seitenverhältnissen '''4:3''' ist ein Bildformat von '''640*480px''' üblich.		* Für Videos mit den Seitenverhältnissen '''4:3''' ist ein Bildformat von '''640*480px''' üblich.
	* Bei einem Seitenverhältnis von '''16:9''' lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 916 = 144px ist; das ~~größe~~ Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung '''704396px'''; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf '''720*404px''' verzerren.		* Bei einem Seitenverhältnis von '''16:9''' lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 916 = 144px ist; das größte Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung '''704396px'''; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf '''720*404px''' verzerren.

	Entsprechende Vergleichstests haben allerdings bestätigt, dass XviD aufgrund seiner Eigenschaft, 1616px Pixel große Makroblocks zu komprimieren, bei durch 16 teilbaren Seitenlängen so deutlich viel effizienter arbeiten kann, dass es sich sogar lohnt, ein 16:9-Video auf 704400px statt auf 704396px zu skalieren (also 1% Bildinformation mehr zu speichern - die Seitenverzerrung von 1% wird vom Publikum nicht wahrgenommen); die XviD-komprimierte Version einer solchen Datei wird dabei üblicherweise sogar etwas kleiner als die 704396px-Version:		Entsprechende Vergleichstests haben allerdings bestätigt, dass XviD aufgrund seiner Eigenschaft, 1616px Pixel große Makroblocks zu komprimieren, bei durch 16 teilbaren Seitenlängen so deutlich viel effizienter arbeiten kann, dass es sich sogar lohnt, ein 16:9-Video auf 704400px statt auf 704396px zu skalieren (also 1% Bildinformation mehr zu speichern - die Seitenverzerrung von 1% wird vom Publikum nicht wahrgenommen); die XviD-komprimierte Version einer solchen Datei wird dabei üblicherweise sogar etwas kleiner als die 704396px-Version:
Zeile 188:		Zeile 188:

	# anamorphe DVD-Auflösung korrigieren und Bildformat das gewünschte Zielformat zerren		# anamorphe DVD-Auflösung korrigieren und Bildformat das gewünschte Zielformat zerren
	LanczosResize (704, ~~396~~)		LanczosResize (704, 400)

	# Defensives Entfernen von Bild-Unsauberkeiten		# Defensives Entfernen von Bild-Unsauberkeiten

Devil Doll: Testergebnis für mod16 eingebaut

2008-03-12T14:49:02Z

Testergebnis für mod16 eingebaut

← Nächstältere Version		Version vom 12. März 2008, 16:49 Uhr
Zeile 129:		Zeile 129:

	=== Anpassen der Bildgröße auf das gewünschte Zielformat ===		=== Anpassen der Bildgröße auf das gewünschte Zielformat ===

			==== Auswahl des Zielformats (mod16-Regel) ====

	Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.		Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.
Zeile 135:		Zeile 137:
	* Für Videos mit den Seitenverhältnissen '''4:3''' ist ein Bildformat von '''640*480px''' üblich.		* Für Videos mit den Seitenverhältnissen '''4:3''' ist ein Bildformat von '''640*480px''' üblich.
	* Bei einem Seitenverhältnis von '''16:9''' lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 916 = 144px ist; das größe Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung '''704396px'''; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf '''720*404px''' verzerren.		* Bei einem Seitenverhältnis von '''16:9''' lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 916 = 144px ist; das größe Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung '''704396px'''; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf '''720*404px''' verzerren.

			Entsprechende Vergleichstests haben allerdings bestätigt, dass XviD aufgrund seiner Eigenschaft, 1616px Pixel große Makroblocks zu komprimieren, bei durch 16 teilbaren Seitenlängen so deutlich viel effizienter arbeiten kann, dass es sich sogar lohnt, ein 16:9-Video auf 704400px statt auf 704396px zu skalieren (also 1% Bildinformation mehr zu speichern - die Seitenverzerrung von 1% wird vom Publikum nicht wahrgenommen); die XviD-komprimierte Version einer solchen Datei wird dabei üblicherweise sogar etwas kleiner als die 704396px-Version:
			[[Bild:AVI-Hardsub_Testergebnis.jpg\|Testergebnis: XviD-Codierung von 704400px-Videos gegenüber 704396px-Videos zur Bestätigung der mod16-Theorie]]

			==== Herstellung des Zielformats ====

	Die folgende Anweisung des Skripts dient dazu, die Bildgröße des Video-Streams in Breite und Höhe auf den gewünschten Wert zu skalieren (wobei es irrelevant ist, in welcher Größe das Videomaterial nach den vorherigen Transformationen tatsächlich vorliegt):		Die folgende Anweisung des Skripts dient dazu, die Bildgröße des Video-Streams in Breite und Höhe auf den gewünschten Wert zu skalieren (wobei es irrelevant ist, in welcher Größe das Videomaterial nach den vorherigen Transformationen tatsächlich vorliegt):
Zeile 143:		Zeile 150:
	Diese Funktion gehört zu den Avisynth-Grundfunktionen und muss deshalb nicht separat hinzugeladen werden.		Diese Funktion gehört zu den Avisynth-Grundfunktionen und muss deshalb nicht separat hinzugeladen werden.

	Auch hier wieder der Hinweis, das es [http://avisynth.org/mediawiki/Resize zahlreiche andere Verfahren zur Änderung der Bildgröße] gibt, welche sich u. a. in Bezug auf die Behandlung dünner Linien unterscheiden (also ggf. unterschiedlich scharfe bzw. verwaschene Ergebnisse produzieren).		Auch hier wieder der Hinweis, das es [http://avisynth.org/mediawiki/Resize zahlreiche andere Verfahren zur Änderung der Bildgröße] gibt, welche sich u. a. in Bezug auf die Behandlung dünner Linien unterscheiden (also ggf. unterschiedlich scharfe bzw. verwaschene Ergebnisse produzieren). LanczosResize schärft dünne Linien nach, was für Animes tendentiell ein wünschenswerter Effekt sein dürfte; BicubicResize tut das nicht, liefert dafür aber etwas besser XviD-komprimierbares Bildmaterial, d. h. kleinere Dateien nach dem Encoding bei sogar geringerem Informationsverlust relativ zum Original-Video (gemessen durch einen höheren [http://en.wikipedia.org/wiki/SSIM SSIM-Wert]).

	Durch zusätzliche Parameter für die jeweilige Resize-Funktion ist es auch möglich, Cropping und Resizing in einem Arbeitsgang zu erledigen (was die Verarbeitungsgeschwindigkeit minimal erhöht); Einzelheiten sind der Dokumentation der jeweiligen Funktion zu entnehmen.		Durch zusätzliche Parameter für die jeweilige Resize-Funktion ist es auch möglich, Cropping und Resizing in einem Arbeitsgang zu erledigen (was die Verarbeitungsgeschwindigkeit minimal erhöht); Einzelheiten sind der Dokumentation der jeweiligen Funktion zu entnehmen.

Devil Doll: /* Extrahieren der Audio-Daten aus dem MPEG2-Stream */

2008-02-09T20:06:28Z

Extrahieren der Audio-Daten aus dem MPEG2-Stream

← Nächstältere Version		Version vom 9. Februar 2008, 22:06 Uhr
Zeile 37:		Zeile 37:

	Während der Vorverarbeitung des Materials kann man die Audio-Daten in separate Dateien (je eine Datei pro Stream) extrahieren lassen (wie wir sie später beim Encoden auch benötigen werden), und zwar wahlweise		Während der Vorverarbeitung des Materials kann man die Audio-Daten in separate Dateien (je eine Datei pro Stream) extrahieren lassen (wie wir sie später beim Encoden auch benötigen werden), und zwar wahlweise
	* im ~~bereits~~ vorliegenden Format oder		* im auf der DVD vorliegenden Format oder
	* umgewandelt in das ~~WAV~~-Format		* umgewandelt in das PCM-Format

	Vor Beginn der Analyse der DVD-Daten weiß DGIndex nicht, wie viele Audio-Streams die DVD besitzt und welchen Inhalt diese Spuren enthalten (selbst japanische Original-DVDs enthalten manchmal mehrere Audio-Streams, etwa mit Anmerkungen von Regisseur bzw. Seiyuu zu einzelnen Szenen). Der Encoder muss also zunächst einmal ''sämtliche'' Audio-Spuren extrahieren und sich dann im Einzelnen ansehen, welche davon er verwenden will.		Vor Beginn der Analyse der DVD-Daten weiß DGIndex nicht, wie viele Audio-Streams die DVD besitzt und welchen Inhalt diese Spuren enthalten (selbst japanische Original-DVDs enthalten manchmal mehrere Audio-Streams, etwa mit Anmerkungen von Regisseur bzw. Seiyuu zu einzelnen Szenen). Der Encoder muss also zunächst einmal ''sämtliche'' Audio-Spuren extrahieren und sich dann im Einzelnen ansehen, welche davon er verwenden will.

	Zu beachten ist, dass ein Audio-Stream ''nicht'' exakt gleichzeitig mit dem Anfang des Video-Streams beginnen muss, sondern einen '''Delay''' relativ zu diesem aufweisen kann; um dieses Delay verschoben muss der Audio-Stream später wieder mit dem Video-Stream zusammengefügt werden, damit Bild und Ton synchron bleiben. Ein eventueller Delay wird beim Abspeichern des betreffenden Audio-Streams im Namen der erzeugten Datei vermerkt.		Zu beachten ist, dass ein Audio-Stream ''nicht'' exakt gleichzeitig mit dem Anfang des Video-Streams beginnen muss, sondern einen '''Delay''' relativ zu diesem aufweisen kann; um dieses Delay verschoben muss der Audio-Stream später wieder mit dem Video-Stream zusammengefügt werden, damit Bild und Ton synchron bleiben. Ein eventueller Delay wird von DGIndex beim Abspeichern des betreffenden Audio-Streams im Namen der erzeugten Datei vermerkt.

	=== Durchführung des Analyselaufs mit DGIndex ===		=== Durchführung des Analyselaufs mit DGIndex ===

Devil Doll: /* Filter zur Qualitätsverbesserung */

2008-01-24T16:59:58Z

Filter zur Qualitätsverbesserung

← Nächstältere Version		Version vom 24. Januar 2008, 18:59 Uhr
Zeile 149:		Zeile 149:
	=== Filter zur Qualitätsverbesserung ===		=== Filter zur Qualitätsverbesserung ===

	Nachdem nun das Videomaterial im Prinzip im richtigen Format (Vollbilder in der gewünschten Bildschirmauflösung) vorliegt, kann in einem abschließenden Verarbeitungsschritt noch Einfluss auf die Bildqualität genommen werden. Hierfür werden je nach subjektivem Ästhetik-Empfinden des Encoders entsprechende Filter auf das Videomaterial angewendet, um kleine Unsauberkeiten zu entfernen, dünne Linien zu schärfen oder die Auswirkungen bestimmter systematischer Fehler des Bildmaterials zu reduzieren. Grundsätzlich gilt dabei: Die Entfernung von Details verbessert ~~einerseits~~ die spätere Komprimierbarkeit des Videostreams, bewirkt aber gleichzeitig, dass das Bild verwaschener aussieht~~; je~~ aggressiver die entsprechende Filterfunktion dabei vorgeht (was jeweils durch entsprechende Parameterwerte eingestellt werden kann), umso stärker sind beide Effekte spürbar.		Nachdem nun das Videomaterial im Prinzip im richtigen Format (Vollbilder in der gewünschten Bildschirmauflösung) vorliegt, kann in einem abschließenden Verarbeitungsschritt noch Einfluss auf die Bildqualität genommen werden. Hierfür werden je nach subjektivem Ästhetik-Empfinden des Encoders entsprechende Filter auf das Videomaterial angewendet, um kleine Unsauberkeiten zu entfernen, dünne Linien zu schärfen oder die Auswirkungen bestimmter systematischer Fehler des Bildmaterials zu reduzieren.

			Grundsätzlich gilt dabei: Die Entfernung von Details verbessert die spätere Komprimierbarkeit des Videostreams, bewirkt aber gleichzeitig, dass das Bild verwaschener aussieht. Je aggressiver die entsprechende Filterfunktion dabei vorgeht (was jeweils durch entsprechende Parameterwerte eingestellt werden kann), umso stärker sind beide Effekte spürbar. Umgekehrt gibt es auch Filterfunktionen, die bestimmte Details (z. B. Linien) gezielt verstärken ("schärfen") können, etwa um Videomaterial geringer Ausgangsqualität nachträglich "aufzubessern".

	Die folgende Anweisung des Skripts dient dazu, mit einem relativ defensiven Filter kleine Unsauberkeiten des Bildmaterials aufzulösen:		Die folgende Anweisung des Skripts dient dazu, mit einem relativ defensiven Filter kleine Unsauberkeiten des Bildmaterials aufzulösen:

Devil Doll: /* Extrahieren der Audio-Daten aus dem MPEG2-Stream */

2008-01-24T02:49:49Z

Extrahieren der Audio-Daten aus dem MPEG2-Stream

← Nächstältere Version		Version vom 24. Januar 2008, 04:49 Uhr
Zeile 29:		Zeile 29:

	Eine DVD kann mehrere Audio-Streams enthalten; diese können in unterschiedlichen Formaten vorliegen:		Eine DVD kann mehrere Audio-Streams enthalten; diese können in unterschiedlichen Formaten vorliegen:
	* Audio-Streams im Format [[PCM]] sind verlustlos gespeichert. Da sie demzufolge sehr viel Platz auf der DVD benötigen, ist ihre Verwendung eher unüblich.		* Audio-Streams im Format [[PCM]] sind verlustlos gespeichert. Da sie demzufolge sehr viel Platz auf der DVD benötigen (bis zu 1440kbit/sec, was für eine Anime-Episode von 23 Minuten Spieldauer knapp 250 MB Speicherplatz bedeuten würde!), ist ihre Verwendung eher unüblich, kommt aber in der Realität durchaus vor.
	* Audio-Streams im verlustbehafteten Format [[Dolby Digital\|AC3]] bieten eine hohe Tonqualität und können insbesondere bis zu [http://de.wikipedia.org/wiki/5.1 sechs (5.1)] Tonkanäle enthalten. Ein AC3-Stream mit einer Qualität von 448 kbit/sec für eine Anime-Episode von 23 Minuten Spieldauer belegt etwa 77 MB Speicherplatz im späteren Encoding des Fansubs.		* Audio-Streams im verlustbehafteten Format [[Dolby Digital\|AC3]] bieten eine hohe Tonqualität und können insbesondere bis zu [http://de.wikipedia.org/wiki/5.1 sechs (5.1)] Tonkanäle enthalten. Ein AC3-Stream mit einer Qualität von 448 kbit/sec für eine Anime-Episode von 23 Minuten Spieldauer belegt etwa 77 MB Speicherplatz im späteren Encoding des Fansubs.
	* Audio-Stream im verlustbehafteten Format [[DTS]] bieten ebenfalls eine hohe Tonqualität und können bis zu Surround-Sound bis zu 7.1 enthalten. Im Gegensatz zu AC3 ist DTS auf DVDs optional.		* Audio-Stream im verlustbehafteten Format [[DTS]] bieten ebenfalls eine hohe Tonqualität und können bis zu Surround-Sound bis zu 7.1 enthalten. Im Gegensatz zu AC3 ist DTS auf DVDs optional.
	* Audio-Streams im verlustbehafteten Format [[Mp2\|MP2]] sind auf maximal zwei Tonkanäle beschränkt, benötigen dafür aber relativ wenig Speicherplatz.		* Audio-Streams im verlustbehafteten Format [[Mp2\|MP2]] sind auf maximal zwei Tonkanäle beschränkt, benötigen dafür aber relativ wenig Speicherplatz.

	Das Tonformat innerhalb von [[AVI\|AVI-Containern]] bei Verwendung von [[Hardsubs]] ist ~~meist~~ ein MP3-Stream mit 128 kbit/sec, ~~während bei Verwendung anderer [[Container]] häufig andere Formate wie [[Vorbis\|OGG Vorbis]] bzw. [[Aac\|AAC]] Verwendung finden~~.		Das Tonformat innerhalb von [[AVI\|AVI-Containern]] bei Verwendung von [[Hardsubs]] ist üblicherweise ein '''MP3-Stream mit einer konstanten Bitrate 128 kbit/sec''' ''(manche Standalone-DVD-Player haben Probleme mit variablen Bitraten in MP3)'', also nur etwa ein Viertel der Qualität des oben erwähnten AC3-Audiostreams.

	Während der Vorverarbeitung des Materials kann man die Audio-Daten in separate Dateien (je eine Datei pro Stream) extrahieren lassen (wie wir sie später beim Encoden auch benötigen werden), und zwar wahlweise		Während der Vorverarbeitung des Materials kann man die Audio-Daten in separate Dateien (je eine Datei pro Stream) extrahieren lassen (wie wir sie später beim Encoden auch benötigen werden), und zwar wahlweise

Devil Doll: /* Speichern des Verarbeitungs-Ergebnisses */

2008-01-23T14:25:18Z

Speichern des Verarbeitungs-Ergebnisses

← Nächstältere Version		Version vom 23. Januar 2008, 16:25 Uhr
Zeile 192:		Zeile 192:
	Sobald das Verfahren zu einem Ergebnis geführt hat, welches die Ansprüche des Encoders zu dessen Zufriedenheit erfüllt, möchte dieser das Ergebnis des Skript-Laufes eigentlich bis zum endgültigen Release nicht mehr löschen (um den Filtervorgang nicht wiederholen zu müssen). Eine verlustbehaftete Komprimierung scheidet allerdings aus, da deren Ergebnis nicht mehr die erforderliche Qualität für die spätere Produktion von QC- und Release-Dateien aufweist. Es existieren jedoch Codecs, welche eine '''verlustfreie Komprimierung''' des erzeugten Videomaterials ermöglichen (z. B. [http://de.wikipedia.org/wiki/HuffYUV HuffYUV] und [http://de.wikipedia.org/wiki/Lagarith Lagarith]). Bei einer Speicherung des Video-Materials unter Verwendung eines dieser Verfahren kann das Datenvolumen um etwa 50-60% reduziert werden, sodass pro Episode eine Datei von etwa 5-6 GB Größe anfällt. Sobald sämtliche Episoden der DVD in diesem Format vorliegen, benötigt man die VOB-Dateien dieser DVD nicht mehr auf der Festplatte des Encoding-Rechners.<br>''(ACHTUNG: Sowohl HuffYUF in der Version 2.2.0 als auch Lagarith in der Version 1.3.13 weisen Stabilitätsprobleme auf, die zum Absturz des Komprimierungslaufs führen können; der Verfasser dieses Artikels verwendet deshalb die etwas ältere Version 2.1.1 von HuffYUF.)''		Sobald das Verfahren zu einem Ergebnis geführt hat, welches die Ansprüche des Encoders zu dessen Zufriedenheit erfüllt, möchte dieser das Ergebnis des Skript-Laufes eigentlich bis zum endgültigen Release nicht mehr löschen (um den Filtervorgang nicht wiederholen zu müssen). Eine verlustbehaftete Komprimierung scheidet allerdings aus, da deren Ergebnis nicht mehr die erforderliche Qualität für die spätere Produktion von QC- und Release-Dateien aufweist. Es existieren jedoch Codecs, welche eine '''verlustfreie Komprimierung''' des erzeugten Videomaterials ermöglichen (z. B. [http://de.wikipedia.org/wiki/HuffYUV HuffYUV] und [http://de.wikipedia.org/wiki/Lagarith Lagarith]). Bei einer Speicherung des Video-Materials unter Verwendung eines dieser Verfahren kann das Datenvolumen um etwa 50-60% reduziert werden, sodass pro Episode eine Datei von etwa 5-6 GB Größe anfällt. Sobald sämtliche Episoden der DVD in diesem Format vorliegen, benötigt man die VOB-Dateien dieser DVD nicht mehr auf der Festplatte des Encoding-Rechners.<br>''(ACHTUNG: Sowohl HuffYUF in der Version 2.2.0 als auch Lagarith in der Version 1.3.13 weisen Stabilitätsprobleme auf, die zum Absturz des Komprimierungslaufs führen können; der Verfasser dieses Artikels verwendet deshalb die etwas ältere Version 2.1.1 von HuffYUF.)''

	Für die Weitergabe des so bearbeiteten Videomaterials an andere Mitglieder der Fansubber-Gruppe (vor allem den [[Timer]] und den [[Typesetter]], insbesondere über langsame Internet-Leitungen) ist natürlich eine solche Datei immer noch viel zu groß. Deshalb erzeugt der Encoder ''zusätzlich'' eine (mit dem später zu verwendenden Video-Codec und sinnvollerweise auch etwa den später zu verwendenden Einstellungen) komprimierte Variante des Videos, das sogenannte '''Timing-Raw''', dessen Größe sich von derjenigen des späteren Release nur unwesentlich unterscheidet (man kann in der Qualität auch problemlos ein wenig nach unten gehen, um Übertragungsvolumen zu sparen). Dieses Timing-Raw muss dann auch einen Audio-Stream (~~mit dem korrigierten~~ Delay) ~~enthalten~~, damit der Timer die passenden Zeitpunkte zum Ein- und Ausblenden der Untertitel exakt festlegen kann. (Bei einem Soloprojekt könnte man die verlustfrei komprimierten Video-Daten, ergänzt um den Audio-Stream, auch gleich als Timing-Raw verwenden.)		Für die Weitergabe des so bearbeiteten Videomaterials an andere Mitglieder der Fansubber-Gruppe (vor allem den [[Timer]] und den [[Typesetter]], insbesondere über langsame Internet-Leitungen) ist natürlich eine solche Datei immer noch viel zu groß. Deshalb erzeugt der Encoder ''zusätzlich'' eine (mit dem später zu verwendenden Video-Codec und sinnvollerweise auch etwa den später zu verwendenden Einstellungen) komprimierte Variante des Videos, das sogenannte '''Timing-Raw''', dessen Größe sich von derjenigen des späteren Release nur unwesentlich unterscheidet (man kann in der Qualität auch problemlos ein wenig nach unten gehen, um Übertragungsvolumen zu sparen). Dieses Timing-Raw muss dann auch einen Audio-Stream enthalten (der um den entsprechenden Delay zeitlich verschoben eingefügt werden muss) , damit der Timer die passenden Zeitpunkte zum Ein- und Ausblenden der Untertitel exakt festlegen kann. (Bei einem Soloprojekt könnte man die verlustfrei komprimierten Video-Daten, ergänzt um den Audio-Stream, auch gleich als Timing-Raw verwenden.)

	== Encoding als AVI-Container mit XviD-Videostream ==		== Encoding als AVI-Container mit XviD-Videostream ==

Devil Doll: /* Anpassen der Bildgröße auf das gewünschte Zielformat */

2008-01-21T18:54:42Z

Anpassen der Bildgröße auf das gewünschte Zielformat

← Nächstältere Version		Version vom 21. Januar 2008, 20:54 Uhr
Zeile 132:		Zeile 132:
	Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.		Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.

	Welche Bildgröße wollen wir erreichen? Beide Seitenlängen [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von ~~720x480px~~ vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Für Videos mit den Seitenverhältnissen 4:3 ist ~~deshalb~~ ein Bildformat von '''~~640x480px~~''' üblich~~; bei~~ einem Seitenverhältnis von 16:9 ist ~~der größte Wert~~, ~~bei dem dieses Verhältnis~~ mit durch ~~16 teilbaren Seitenlängen~~ ''~~exakt~~'' ~~erreicht werden~~ kann, '''~~704x396px~~'''.		Welche Bildgröße wollen wir erreichen? Beide Seitenlängen ''müssen'' (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und [http://encodingwissen.de/spezial/mod-regeln.html sollten möglichst durch 16 teilbar sein]; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:
			* Für Videos mit den Seitenverhältnissen '''4:3''' ist ein Bildformat von '''640*480px''' üblich.
			* Bei einem Seitenverhältnis von '''16:9''' lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 916 = 144px ist; das größe Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung '''704396px'''; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf '''720*404px''' verzerren.

	Die folgende Anweisung des Skripts dient dazu, die Bildgröße des Video-Streams in Breite und Höhe auf den gewünschten Wert zu skalieren (wobei es irrelevant ist, in welcher Größe das Videomaterial nach den vorherigen Transformationen tatsächlich vorliegt):		Die folgende Anweisung des Skripts dient dazu, die Bildgröße des Video-Streams in Breite und Höhe auf den gewünschten Wert zu skalieren (wobei es irrelevant ist, in welcher Größe das Videomaterial nach den vorherigen Transformationen tatsächlich vorliegt):