Encodierungs-Tips? Videos shrinken

Hallo nochmal,
hole den Thread noch einmal aus seiner Versenkung heraus, da das Thema für mich immer noch aktuell ist und ja schon einige tolle, hilfreiche Infos geliefert wurden. Ich fasse kurz zusammen:

In Besitz
- MeGUI 1911 (inkl. aller Updates, die beim Erststart aufgeführt werden)
- AviSynth 2.5.8
- Ein verlustfreies DV-Video

Videodaten
Format: DV (Avi)
Länge: 6:46 Minuten (10150 Frames)
Größe: 1,41 GB
Ziel des Vorhabens: DV möglichst qualitativ umwandeln in h264, gleichzeitig angemessene Dateigröße von weit weniger als 1,41 GB

Mein Vorgehen (chronologisch)
[MeGUI]
File -> Open: Video (.avi) reinladen

[File Indexer]
Auf Standardeinstellungen belassen -> Queue

[MeGUI]
Queue -> Start (der 1. Job mit dem Index läuft durch)

[AviSynth script creator]
Auf Standardeinstellungen belassen -> Save
Videoplayer schließen

[MeGUI]
Encoder settings: x264*scratchpad* -> Config

[x264 Configuration dialog]
Show advanced settings -> Häkchen setzen
Modes: Automated 2pass
Bitrate: 5000
Presets: Medium
"Misc" -> Logfile setzen
An die restlichen Einstellungen trau ich mich nicht ran (verstehe nur Bahnhof) -> OK

[MeGUI]
File format: MKV
Queue -> Start (beide Jobs laufen durch)
Job commandline:
Code:
"[...]x264.exe" --pass 2 --bitrate 5000 --stats "[...].stats" --sar 1:1 --output NUL "[...].avs"

Ergebnis
- Video ist jetzt 241MB groß
- Artefakte praktisch unsichtbar
- deutlich interlaced
- Bild (speziell bei Videosequenzen, wo sich wenig ändert) wird böse zersetzt von schwarzen Blöcken
-> unmöglich anzusehen!

Fragen an die Community
- Gegen die Artefakte hilft es sicherlich, die Bitrate noch höher zu schrauben, richtig?
- Was kann ich gegen das Interlacing tun? Die Quelle hat das Problem nicht.
- Auf was muss ich noch aufpassen, gerade für die Szenen, bei denen sich 5 Sekunden lang nichts ändert? Dort ist das Bild die ersten ~2 Sekunden sauber, doch dann zerfetzt es förmlich. Habe ich irgendeine Einstellung missachtet?
- Ich hab schon gesehen, dass meine Job-Commandline im Vergleich zu "professionellen" Encodings verhältnismäßig wenig Parameter aufweist. Könnt ihr mir Aufschluß geben, ohne dass ich jetzt zig Testvideos encodieren muss?

PS: Ich weiß, dass später Audio noch dazugemuxt werden muss, aber mir geht's zunächst primär um die Videoqualität.


EDIT
Nach der Nutzung von Google und einigen Beispielen habe ich nun ein paar neue Einstellungen vorgenommen; meine Commandline sieht nun folgendermaßen aus:
Code:
"[...]x264.exe" --profile main --level 4.1 --pass 2 --bitrate 5000 --stats "[...].stats" --bframes 0 --ref 1 --subme 5 --trellis 0 --sar 1:1 --output "[...].mkv" "[...].avs"

Ergebnis
- Video 241MB groß (ein paar KB größer als oben)
- Artefakte praktisch unsichtbar
- deutlich interlaced
- kein Zerfetzen mehr durch schwarze Löcher
--> Spielen das Profil und das Level dabei eine Rolle?


EDIT 2
Sorry für den Riesenbeitrag, aber so langsam komme ich weiter und möchte das auch der Nachwelt hinterlassen.
Inzwischen habe ich herausgefunden, dass
Code:
--subme 5 --trellis 0
bei mir zu der fürchterlichen schwarzen Blockbildung führt, die das Bild zerfetzt. Weder Profil noch Level haben sichtbare Auswirkungen auf mein Testvideo. Bei einer Bitrate von 4000 werden allerdings die ersten leichten Artefakte sichtbar, aber nur sehr, sehr vage. Das ist meine derzeitige Commandline:
Code:
"[...]x264.exe" --pass 2 --bitrate 4000 --stats "[...].stats" --bframes 0 --ref 1 --sar 1:1 --output "[...].mkv" "[...].avs
Alles in Allem bin ich mittlerweile recht zufrieden mit meinem

ERGEBNIS
- Video nun 193MB groß
- evtl. schon sehr leichte Artefaktbildung
- deutlich interlaced

Ich denke, ich werde die Bitrate also wieder auf 5000 anheben (auf Nummer sicher ;) ) und muxe anschließend noch das auf Winamp-AAC 192kbps codierte Audio dazu. Oder vielleicht sollte ich mal noch mit der variablen Bitrate spielen...
 
Zuletzt bearbeitet:
Was mir noch dazu einfällt:
  1. Wieso encodest du eigentlich nicht qualitätsbasiert (per Angabe des CRF)? Wenn man keine feste Zieldateigröße im Auge hat, wäre das doch ein idealer Ansatz, weil x264 so versucht die Qualität konstant zu halten!
  2. Wenn das Quellmaterial interlaced ist und es auch bleiben soll, warum sagst du das x264 nicht (im x264-Konfigurationsdialogfenster => Reiter "Frame-Type" => unter "Other" einen Haken bei "Encode Interlaced" machen), damit es entsprechend damit umgeht?
  3. Es gibt im Netz (zusätzlich zu den vorhandenen) diverse weitere MeGUI Video-Profile (z.B. hier) für unzählige Anwendungsfälle. Da findet sich möglicherweise auch ein Profil, das man übernehmen und einstellungsmäßig für eigene Bedürfnisse anpassen kann!
  4. Wer auf die Profile pfeift und lieber alle x264-Settings manuell vornehmen will, sollte sich vorher auch darüber einlesen, wofür die gut sind bzw. was die bewirken. Eine gute Anlaufstelle ist das schon auf der vorherigen Seite von "De-M-oN" genannte PDF-File "Wissenswertes rund um x264" von "Selur", sowie das Encodingwissen von "Brother John", das einsteigerfreundlich technische Infos zu x264, sowie Konfigurationsbeispiele und eine Auflistung der wichtigsten Parameter und deren Funktion liefert.
 
Vielen Dank für die Anregungen, Tom. Die PDF von Selur hab ich die ganze Zeit bei meinen Tests geöffnet und lese parallel dazu. So allmählich steige ich hinter das System, aber bei den unzähligen Filtermöglichkeiten bei AviSynth und möglichen Custom-Matrizen kann ich im Moment noch nicht mitkommen. Diese schiere Einstellungsvielfalt ist überwältigend.

Mit CRF schlage ich mich jetzt gerade rum, nachdem ich CBR soweit hinter mich gebracht habe. CRF 20 und 21 habe ich nun durch, und für mein Video scheint CRF 21 voll in Ordnung zu gehen:
Code:
--crf 21.0 --bframes 0 --ref 1 --sar 1:1

Die Profile hat MeGUI beim Erststart als Download angeboten, ergo hab ich die sogar alle. Als Profile meinte ich auch eher die "AVC Profiles", die bei der Auswahl von x264 und "Config" anschließend rechts erscheinen. Diese dort gelisteten haben bei mir bislang keinen Unterschied hervorgebracht (gleiches gilt für die "AVC Levels" dadrunter).

Nun habe ich zwar auch schon selbst herausgefunden, wo sich das "Encode Interlaced" aktivieren läßt, allerdings habe ich auch dazu im Internet gelesen, dass dann wieder die Dateigröße stark wächst... Bis ich dort alles durchprobiert habe, vergehen Jahre, und ich habe inzwischen die Vermutung, dass eine gute Einstellung, die ich jetzt finde, für ein anderes Video evtl. nicht mehr funktionieren wird, und ich kann alles von vorne machen. Darum versuche ich das so simpel wie möglich zu halten und CRF scheint ein guter Weg dafür zu sein.
 
Zuletzt bearbeitet:
HardRockDude schrieb:
Als Profile meinte ich auch eher die "AVC Profiles", die bei der Auswahl von x264 und "Config" anschließend rechts erscheinen. Diese dort gelisteten haben bei mir bislang keinen Unterschied hervorgebracht (gleiches gilt für die "AVC Levels" dadrunter).
Mit meiner Aussage zu den MeGUI-Profilen bezog ich mich eigentlich nicht auf deine Frage zu den AVC-Profilen ;) . Was es mit den AVC-Profilen auf sich hat, kannst du im Encodingwissen nachlesen:
Code:
--profile <H.264-Profil>
Werte: baseline, main, high
Standard: high
Beispiel: --profile main

Erzwingt die Kompatibilität mit dem angegebenen H.264-Profil. H.264-Level, VBV-Einstellungen etc. sind davon nicht betroffen.

baseline
Deaktiviert B-Frames, CABAC und die 8×8-DCT. Auch Custom-Matrizen sind nicht möglich.

main
Deaktiviert die 8×8-DCT und Custom-Matrizen.

high
Keine Restriktionen.
Sprich: bestimmte Funktionen sind mit bestimmten Profilen deaktiviert (entsprechend der Vorgaben in den H.264-Spezifikationen). Das ist alles.

Zu den H.264-Leveln sagt Wikipedia mehr:

http://de.wikipedia.org/wiki/H_264#Level

Prinzipiell sind mit den Leveln bestimmte Obergrenzen definiert. Die Level-Einstellung in x264 schreibt nur in das Video eine Information a la "für dieses Video gilt Level so-und-so". Das muss übrigens nicht mal korrekt sein und ist eigentlich nur für (Hardware-)Decoder gedacht, die dann (nach dem Auslesen der Info) sofort wissen "aha... der Level ist höher als der höchste von mir unterstützte => kann ich nicht decodieren, brauch ich erst gar nicht zu versuchen".

Wie gesagt: das ist nur eine Info im Videostream selbst, die nicht mal stimmen muss (da man sie auch nachträglich beliebig ändern kann). MeGUI versucht aber trotzdem im Konfigurationsdialog dafür zu sorgen, dass du keine widersprüchlichen Einstellungen machst und warnt dich, wenn du einen Level auswählst, der für die sonstigen Einstellungen (z.B. Bitrate und Auflösung) zu niedrig ist.

HardRockDude schrieb:
Nun habe ich zwar auch schon selbst herausgefunden, wo sich das "Encode Interlaced" aktivieren läßt, allerdings habe ich auch dazu im Internet gelesen, dass dann wieder die Dateigröße stark wächst...
Das sollte aber trotzdem gewählt werden. Selbst MPEG2-Encoder benutzen bei progressive und interlaced Quellmaterial während der Quantisierung verschiedene Scan-Ordnungen, die für das jeweilige Ausgangsmaterial optimiert sind. Und das ist nicht ohne Grund so. Bei H.264 ist das nicht anders.
 
HardRockDude schrieb:
[AviSynth script creator]
Auf Standardeinstellungen belassen -> Save
Videoplayer schließen
Ich würde hier aber angeben, was das video ist. (Progressive oder Interlaced?)
Weil das kann man im avisynth script creator einstellen.

HardRockDude schrieb:
[MeGUI]Presets: Medium
Würde ich wenigstens slow nehmen.
Medium hat mir persönlich zu grobe Einstellungen.
Slow ist da schon besser - wobei ich slow auch noch paar Einstellungen zum positiven ausgebessert habe, und zwar zeigt mir megui folgende Kommandozeile:

Code:
program --preset slow --bitrate 12000 --deblock 2:2 --b-adapt 1 --scenecut 64 --qpmin 10 --merange 24 --me hex --subme 6 --partitions all --no-fast-pskip --output "output" "input"

Das benutze ich für Youtube 1080p Videos und holt das maximale aus Youtube raus.
Fürn Heimgebrauch tuts auch eine kleinere Bitrate. Fürn Heimgebrauch rate ich auch eher zu das, was du dich jetzt zugewandt hast -> Dem CRF Verfahren.


HardRockDude schrieb:
- Gegen die Artefakte hilft es sicherlich, die Bitrate noch höher zu schrauben, richtig?
Oder intensivere Encodiereinstellungen. ;)
Allein das Preset "Slow" wird da schon einiges mehr richten, als medium.

HardRockDude schrieb:
- Was kann ich gegen das Interlacing tun? Die Quelle hat das Problem nicht.

In was liegt die Quelle denn überhaupt vor? Interlaced oder Progressiv?
Wenn sie interlaced ist, dann stell deine Kamera auf Progressiv um!
Interlaced ist sehr sehr störend und war eig. nur für alte Röhrenfernseher produktiv, da diese im Halbzeilenmodus arbeiten. Aber ansonsten ist interlaced ein Störfaktor.
Bei deinem bestehendem Material entweder "Encode interlaced" anhaken, oder versuchen einen Deinterlacefilter drüberzujagen - zb yadif.

HardRockDude schrieb:
- Auf was muss ich noch aufpassen, gerade für die Szenen, bei denen sich 5 Sekunden lang nichts ändert? Dort ist das Bild die ersten ~2 Sekunden sauber, doch dann zerfetzt es förmlich. Habe ich irgendeine Einstellung missachtet?
Genügend b-frames und ref-frames einstellen.
Ich bevorzuge 5 ref-frames und 3 b-frames - musst du ausprobieren.

HardRockDude schrieb:
- Ich hab schon gesehen, dass meine Job-Commandline im Vergleich zu "professionellen" Encodings verhältnismäßig wenig Parameter aufweist. Könnt ihr mir Aufschluß geben, ohne dass ich jetzt zig Testvideos encodieren muss?

hinter dem preset Parameter kommen nur Parameter, die dem gewähltem preset abweichen.
z.B. hat "slow" nicht den no-fast-pskip haken aktiviert - ich habe ihn aber aktiviert = abweichung vom preset = taucht in commandozeile auf.

HardRockDude schrieb:
Code:
"[...]x264.exe" --profile main --level 4.1 --pass 2 --bitrate 5000 --stats "[...].stats" --bframes 0 --ref 1 --subme 5 --trellis 0 --sar 1:1 --output "[...].mkv" "[...].avs"

b-frames 0? Das ist ja abartig. sollte mind 3 sein. zwischen 3 und 5 ist optimal.
trellis würd ich wenigstens auf 1 machen.
Ref-frame von 1 ist auch viel zu low. Auch hier mind. 3.

Kein Wunder das dir bei solchen Einstellungen die Bilder abreißen.

b-frames und ref-frames kümmern sich ja GENAU DARUM^^

achja und

HardRockDude schrieb:
--profile main --level 4.1

unnötig. Kannst du auf unrestricted machen. Oder soll das unbedingt Blueray Player kompatibel sein?
 
Zuletzt bearbeitet:
De-M-oN schrieb:
[...]oder versuchen einen Deinterlacefilter drüberzujagen - zb yadif.
Dazu würde ich nur bedingt raten. Die Aufnahme einer Videokamera mit 50 Halbbildern je Sekunde, enthält in diesen 50 Halbbildern nunmal 50 verschiedene Bewegungszustände. Dadurch ist die Bewegungsauflösung höher als bei einer progressiven Aufnahme mit 25 Vollbildern je Sekunde... aber im Gegenzug ist auch die Detailauflösung (da ja je Halbbild nur die halbe vertikale Auflösung genutzt wird) niedriger.

Wenn jetzt so eine Videokamera-Aufnahme mit 50 Halbbildern je Sekunde per Deinterlacer auf 25 Vollbilder je Sekunde gebracht wird, müssen dadurch gezwungenermaßen Frames mit unterschiedlichen Bewegungszuständen zu einem neuen Frame gemischt werden. Da hierbei Halbbilder gemischt werden die nicht zusammen gehören, steigt die Detailauflösung (selbst bei guten Motion-Compensation-Deinterlacern) bestenfalls nur geringfügig, während gleichzeitig die hohe Bewegungsauflösung (logischerweise) flöten geht.

Bei solchem echten interlaced Material (also welches, das NICHT ursprünglich mal progressive erzeugt und nachträglich zu interlaced "verwurstet" wurde) empfiehlt sich daher immer, daraus auch ein interlaced Zielvideo zu erzeugen. Dadurch gehen einfach die wenigsten Informationen verloren. Und wenn man das Zielvideo als interlaced erzeugt, weiß üblicherweise auch jeder ordentliche Decoder, wie er bei der Wiedergabe damit um zu gehen hat.
 
Neue Feststellungen in Gegenüberstellung mit euren Tips

Nach 13 Tests habe ich eine Commandline gefunden, die mir bislang das beste Ergebnis liefert:
Code:
--crf 20 --bframes 0 --ref 1 --me umh --subme 8 --sar 1:1
AVC Profile ist auf "high", AVC Level "Unrestricted", Preset "Medium".

De-M-oN schrieb:
trellis würd ich wenigstens auf 1 machen.
Bei diesem Preset ist trellis auf 1.

De-M-oN schrieb:
In was liegt die Quelle denn überhaupt vor? Interlaced oder Progressiv?[...]
Bei deinem bestehendem Material entweder "Encode interlaced" anhaken, oder versuchen einen Deinterlacefilter drüberzujagen - zb yadif.
Tom Keller schrieb:
Wenn das Quellmaterial interlaced ist und es auch bleiben soll, warum sagst du das x264 nicht (im x264-Konfigurationsdialogfenster => Reiter "Frame-Type" => unter "Other" einen Haken bei "Encode Interlaced" machen), damit es entsprechend damit umgeht?
De-M-oN schrieb:
Ich würde hier aber angeben, was das video ist. (Progressive oder Interlaced?)
Das habe ich nun auch getan. Es ist ein 15 Jahre altes Video von einer Hi8-Kamera. Progressiv. Sobald ich es mit File->Open öffne und der seinen Index erstellt hat, ist das Video im Player aber interlaced. Im AviSynth Script Editor lass ich das automatisch analysieren und führe ein Deinterlace anschließend mit den selbstständig gewählten Einstellungen durch.
Ein "Encode Interlaced" im x264-Config erzeugt ein komplettes grünes und damit unbrauchbares Video. Aber mit dem Deinterlacer aus dem AviSynth-Script sieht das Endvideo quasi so aus wie das Quellvideo, also so, wie es soll ;)

De-M-oN schrieb:
Genügend b-frames und ref-frames einstellen.[...]
b-frames 0? Das ist ja abartig. sollte mind 3 sein. zwischen 3 und 5 ist optimal.
Deine Ratschläge decken sich mit den Tooltips, die im x264-Configfenster erscheinen. Aber ich habe herausgefunden, das genau das meine Bilder zerreißt. Nur wenn b-frames auf 0 steht und ref-frame auf 1, also bei beiden die kleinsten Einstellungen, dann funktioniert mein Encoding. Ansonsten erscheinen immer diese schwarzen Blöcke.
In meinen Tests habe ich alles ausprobiert, auch deine Lieblingseinstellung mit b-frames 5 und ref-frames 3.

De-M-oN schrieb:
Kein Wunder das dir bei solchen Einstellungen die Bilder abreißen. b-frames und ref-frames kümmern sich ja GENAU DARUM^^
Würde es sehr begrüßen, wenn das bei mir auch so wäre :) Hohe ref-frames verbessern angeblich ja auch die Qualität, laut den Tooltips und Guides. Ich verstehe ja selbst nicht, warum das bei mir eher kontraproduktiv wirkt.

De-M-oN schrieb:
Slow ist da schon besser[...]
Allein das Preset "Slow" wird da schon einiges mehr richten, als medium.
Das habe ich auch in einem Guide gelesen und ausprobiert. Allerdings setzt Slow ja wieder die b-frames und ref-frames rauf. Zu was das bei mir führt, weiß man ja nun. Ich habe aber zumindest das --me umh und --subme 8 aus dem Slow-Preset in mein Medium übernommen.

De-M-oN schrieb:
unnötig. Kannst du auf unrestricted machen. Oder soll das unbedingt Blueray Player kompatibel sein?
Hab ich nun wieder gemacht - siehe oben. Das Blu-Ray-Player-Argument hab ich eh nicht bedacht. Als ich zum Testspielen auf Level 4.1 gestellt hab, wusste ich noch gar nicht, wofür die Levels überhaupt da sind, aber das hat Tom weiter oben ja schön erklärt.


Zusammenfassung
Ich bin begeistert. Der x264 macht genau das, was ich will, auch wenn ich noch weit davon entfernt bin, das Encodiersystem zu 100% zu verstehen. Vorerst abschließend sieht das nun so aus:

Dateigröße: von 1,4 GB auf 212 MB (!!!) (allerdings ohne Audio)
Bild: subjektiv keine sichtbare Veränderung. Wenn überhaupt, extrem minimal. Aber dann stell ich einfach CRF eins besser auf 19.
--> Ziel eigentlich schon erreicht :) alles weitere wäre ein Sahnehäubchen.


Vielen, lieben Dank für eure Anregungen und Hilfestellungen! Hätte nicht gedacht, dass ich doch mal irgendwie mit MeGUI zurechtkommen kann ;)
 
Zuletzt bearbeitet:
Wenn du WEISST, das das Quellmaterial Progressiv ist, dann stell auch progressiv ein. Du solltest wirklich genau wissen obs das nun ist, oder doch interlaced.
Vllt auch mal mit Mediainfo nachschauen.

Die Analyse kann sich durchaus auch mal irren. Die Analyse ist eine Hilfestellung, solltest du es nicht wissen, ist aber keine 100% Garantie, das er das richtige erkennt.

vllt rühren daher auch deine b-frame/ref-frame probleme. Denn normal arbeiten sie einwandfrei.

Mit b-frames 0 und ref-frame 1 brauchst du erheblich mehr Bitrate (da er sich ja so auf I-Frames (volle Frames, keine referenz-frames) verlassen muss - Jedes mal ein Volles frame, als nur Veränderungen zu vorgängerbilder ist natürlich speicherintensiver und sinkt somit die Qualität - es sei denn man wirkt eben mit mehr Bitrate entgegen)

Mit b-frames 3 und ref-frame 5 würdest du wahrscheinlich auch mit crf 20 oder 21 auskommen, statt 19. -> Und das muss auch bei dir gehen, das kann gar nicht angehen, das es nicht geht - wahrscheinlich echt wegen dem falschen vorgehen mit dem Source type (Progressiv/interlaced)
 
Zuletzt bearbeitet:
Okay. Also ich versuche mir selbst und allgemein nochmal Klarheit zu schaffen. Dazu habe ich mir jetzt auch das von Dir genannte MediaInfo besorgt. Das hier kommt dabei rum:

Code:
General
CompleteName                     : [...].avi
Format                           : AVI
Format/Info                      : Audio Video Interleave
Format_Commercial_IfAny          : DVCPRO
Format_Profile                   : OpenDML
FileSize/String                  : 1.42 GiB
Duration/String                  : 6mn 46s
OverallBitRate/String            : 30.0 Mbps

Video
ID/String                        : 0
Format                           : DV
Format_Commercial_IfAny          : DVCPRO
CodecID                          : dvsd
CodecID/Hint                     : Sony
Duration/String                  : 6mn 46s
BitRate_Mode/String              : Constant
BitRate/String                   : 24.4 Mbps
Width/String                     : 720 pixels
Height/String                    : 576 pixels
DisplayAspectRatio/String        : 4:3
FrameRate_Mode/String            : Constant
FrameRate/String                 : 25.000 fps
Standard                         : PAL
ColorSpace                       : YUV
ChromaSubsampling                : 4:2:0
BitDepth/String                  : 8 bits
ScanType/String                  : Interlaced
Compression_Mode/String          : Lossy
Bits-(Pixel*Frame)               : 2.357
StreamSize/String                : 1.36 GiB (96%)

Audio
ID/String                        : 1
Format                           : PCM
Format_Settings_Endianness       : Little
Format_Settings_Sign             : Signed
CodecID                          : 1
CodecID/Hint                     : Microsoft
Duration/String                  : 6mn 45s
BitRate_Mode/String              : Constant
BitRate/String                   : 1 024 Kbps
Channel(s)/String                : 2 channels
SamplingRate/String              : 32.0 KHz
BitDepth/String                  : 16 bits
StreamSize/String                : 49.6 MiB (3%)
Interleave_Duration/String       : 40 ms (1.00 video frame)
Interleave_Preload/String        : 40 ms

AviSynth stellt dann bei der automatischen Analyse folgendes fest:
Code:
Source type: Hybrid film/interlaced. Mostly interlaced.
Field order: Varying field order
[X] Deinterlace: TIVTC

Im Preview des Players sieht das dann auch ganz wunderbar aus, nahezu 1:1 wie die Quelle! Es spielt auch keine Rolle, wenn ich bei "Source type" z.B. nur "Interlaced" und anschließend den "Yadif" zum Deinterlacen wähle. Die Unterschiede sind absolut marginal und es ist schwer zu entscheiden, was besser ist.

Wenn ich das Häkchen bei "Deinterlace" AUSmache, sehe ich im Preview eindeutig das hässliche Interlacing. Das ist aber interessant, denn wenn ich das Originalvideo normal öffne mit dem Media Player Classic, dann sieht man nichts von dem Interlacing. Erst nach dem Einfügen in MeGUI wird es sichtbar, und deswegen muss ich dort das DEinterlacing auch aktivieren. Das funktioniert dann auch wundervoll.


Zu den b- und ref-frames:
Verstehe ich das richtig, dass beim IBP-Verfahren die B- und P-Frames diejenigen sind, die "errechnet" werden? Das heißt, die I-Frames sind die Index-Frames, also die, die "voll" gespeichert werden. Das wiederrum heißt, wenn ich weniger B- und P-Frames einstelle, werden mehr I-Frames gesetzt, und das bedeutet doch eigentlich eine Qualitätssteigerung.
Es ist klar, dass diese Qualitätssteigerung dann mit mehr Speicherplatz einhergeht, da diese I-Frames ja nicht komprimiert werden (oder zumindest nicht so stark (?)). Da ich bei meinem Encoding aber doch trotzdem von 1,4 GB auf ~220 MB runtergekommen bin, ist das doch eigentlich schon... schnurz? :confused_alt:
 
Zuletzt bearbeitet:
Ja. wenn du keine b-frames nutzt, muss er alles i-frames schreiben. Also volle Bilder, statt nur veränderungen.

Es benötigt dann aber für gleiche Qualität eben auch viel mehr Bitrate. Für kleinere Dateigrößen ist das eig. so nicht gedacht. Selbst Bluerays arbeiten mit b-frames und ref-frames.

Kannst du deine Kamera denn nicht auf Progressiv umstellen? Dann wäre alles viel einfacher.
 
De-M-oN schrieb:
Mit b-frames 3 und ref-frame 5 würdest du wahrscheinlich auch mit crf 20 oder 21 auskommen, statt 19. -> Und das muss auch bei dir gehen, das kann gar nicht angehen, das es nicht geht - wahrscheinlich echt wegen dem falschen vorgehen mit dem Source type (Progressiv/interlaced)
ODER ein buggy Decoder bei der Wiedergabe des encodeten Materials ist dran Schuld.


HardRockDude schrieb:
Das ist aber interessant, denn wenn ich das Originalvideo normal öffne mit dem Media Player Classic, dann sieht man nichts von dem Interlacing.
Na das ist doch nicht verwunderlich: der Decoder könnte das Deinterlacing während der Wiedergabe vornehmen... und deshalb siehst du davon nichts! Wichtiger ist, was MediaInfo sagt: steht da "interlaced" und du siehst auch die typischen Interlacing-Streifen bei einem AviSynth-Script OHNE Deinterlacer, dann ist das Video auch interlaced :rolleyes: !


HardRockDude schrieb:
Zu den b- und ref-frames:
Verstehe ich das richtig, dass beim IBP-Verfahren die B- und P-Frames diejenigen sind, die "errechnet" werden? Das heißt, die I-Frames sind die Index-Frames, also die, die "voll" gespeichert werden. Das wiederrum heißt, wenn ich weniger B- und P-Frames einstelle, werden mehr I-Frames gesetzt, und das bedeutet doch eigentlich eine Qualitätssteigerung.
NEIN! Es bedeutet eine Steigerung des Platzbedarfes. I-, P- und B-Frames haben nämlich NICHT eine unterschiedliche Qualität... sie nehmen nur unterschiedlich viel Platz weg. I-Frames am meisten, weil sie den kompletten Bildinhalt (ähnlich der JPEG-Kompression für Bilder) speichern... P-Frames deutliche weniger, da sie nur den Unterschied zum vorherigen Frame speichern... B-Frames am wenigsten, da sie neben dem vorherigen Frame auch das nachfolgende Frame einbeziehen können. Qualitativ sind P- und B-Frames aber eben NICHT schlechter als I-Frames, sondern nur platzsparender. Siehe auch hier (wie oft muss ich das Encodingwissen eigentlich noch nennen :p ?):

http://encodingwissen.de/grundlagen/interframe.html

HardRockDude schrieb:
Es ist klar, dass diese Qualitätssteigerung dann mit mehr Speicherplatz einhergeht, da diese I-Frames ja nicht komprimiert werden (oder zumindest nicht so stark (?)). Da ich bei meinem Encoding aber doch trotzdem von 1,4 GB auf ~220 MB runtergekommen bin, ist das doch eigentlich schon... schnurz? :confused_alt:
Nur könntest du dann auch auf H.264 verzichten... denn gerade durch B-Frames und multiple Referenzen für P-Frames komprimiert H.264 ja so unschlagbar gut:

http://encodingwissen.de/x264/technik.html

... und du nimmst x264 diese Möglichkeiten weg :rolleyes: !
 
Puh, ihr beiden seid derzeit meine besten Ansprechpartner auf dem Gebiet. Ich werde mal mein Testvideo irgendwie kürzen, um schneller mehr Tests machen zu können. Ich sehe ja ein, dass meine Einstellungen irgendwie Hokuspokus sind, obwohl das Ergebnis tatsächlich gut aussieht :)

Als Decoder hab ich übrigens ffdshow...

Ihr braucht im Moment nicht hier drauf zu antworten, werde genau diesen Post später editieren, um auf alles nochmal einzugehen - das hier ist quasi ein Platzhalter ;)

Vielen Dank!

EDIT
Das gibt's nicht... habe gerade den neuen Media Player Classic - Home Cinema installiert, und mit dem scheint es plötzlich zu laufen. War es am Ende doch ein Decoder-Problem? Hatte bislang den Media Player Classic 6.4.9.1 (rev 104) benutzt und _nie_ Probleme mit dem gehabt...
Ich investigiere weiter...
 
Zuletzt bearbeitet:
Neueste Erkenntnisse

Gute Nachrichten: das Problem mit den schwarzen Blöcken lag scheinbar an einem fehlerhaften bzw. zu alten Decoder. Ich habe zwar ein sehr neues ffdshow drauf (2011-01-19), aber der Media Player Classic 6.4.9.1 (rev 104) von Gabest ist dann wohl doch schon etwas in die Jahre gekommen. Mit der neuesten MPC-Home Cinema treten diese Blöcke nicht mehr auf.

Dass die Originalvideos beim Abspielen deinterlaced schienen, lag tatsächlich am internen dvsd-Decoder der Player. Habe das in ffdshow zwar auf libavcodec umkonfiguriert gehabt, allerdings ist mein alter MPC darauf nicht angesprungen. Der hat immer irgendwas internes verwendet, obwohl ich in dessen Filteroptionen alle Häkchen rausgemacht hab. Deswegen bin ich ursprünglich auch davon ausgegangen, dass das Originalvideo progressiv ist, obwohl MeGUI immer suggeriert hatte, es ist interlaced (und im MeGUI Preview-Player erschien es dann auch interlaced) - das war wohl der Grund der Verwirrung.
Erst der neue MPC-HC geht auf die Zuweisung in ffdshow ein und deaktiviert seinen eigenen internen Decoder - und siehe da: es sieht im MPC-HC nun genauso aus wie im MeGUI Preview-Player: nämlich eindeutig interlaced.

Daher habe ich im x264-Config nun - auch auf Toms Rat hin in Post #27 - die Option "Encode interlaced" aktiviert und jegliche AviSynth-Deinterlacer DEaktiviert. Desweiteren steht der x264-Preset nun auf "Slower" und CRF auf 20. Die ersten fertig encodierten Videos sehen toll aus und haben mit einer Größe von ~1/9 des Originals wahnsinnig viel Speicherplatz freigegeben.
Das Ergebnis ist nahezu perfekt.

Ich denke, damit hat sich das Videoproblem gelöst und das schönste ist ja fast, dass man sogar weiß, wo der Fehler lag :D Ihr habt mir dabei wahnsinnig geholfen! Vielen, vielen Dank dafür. Ihr beiden seid der CB/FB-Community goldwert!


Zusammenfassend kann ich nur auflisten:
1. Immer die neuesten Player und ffdshow installieren! Never touch a running system, aber wenn mal was nicht klappt, sollte das das erste sein, was man tut!
2. Anschließend checken, womit der/die Player überhaupt decodiert/decodieren. In ffdshow müssen die Codec-Zuweisungen richtig gesetzt sein und die Player müssen drauf ansprechen!
3. Auf De-M-oN und Tom Keller hören :D


Abschließende Kommentare zu euren Kommentaren
De-M-oN schrieb:
Kannst du deine Kamera denn nicht auf Progressiv umstellen? Dann wäre alles viel einfacher.
Nicht, dass ich wüsste. Es ist ein sehr altes Gerät gewesen. Die Videos sind inzwischen mindestens 15 Jahre alt. Hi8-Format. Ich habe sie nur mit einer neueren Digitalkamera auf den Rechner bekommen. Die konnte man bestimmt auf progressiv stellen, aber hätte das was genützt, wenn die Aufnahmen auf Kassette doch schon interlaced geschehen sind?

Tom Keller schrieb:
ODER ein buggy Decoder bei der Wiedergabe des encodeten Materials ist dran Schuld.
So ist es schlussendlich auch gewesen. Zum Glück? Denn das ist ja im Grunde noch das kleinste Problem :D

Tom Keller schrieb:
[...] der Decoder könnte das Deinterlacing während der Wiedergabe vornehmen... und deshalb siehst du davon nichts! Wichtiger ist, was MediaInfo sagt: steht da "interlaced" und du siehst auch die typischen Interlacing-Streifen bei einem AviSynth-Script OHNE Deinterlacer, dann ist das Video auch interlaced :rolleyes: !
Du solltest absolut Recht behalten. Auf der Suche nach dem Fehler bin ich auf den Trichter gekommen, als ich Frame für Frame-Vergleiche angestellt habe und dabei immer wieder verschiedene Deinterlacer in AviSynth ausgewählt hab. An einem Punkt hatte ich mit Bezug auf Deinen Post #27 einen Blend-Deinterlacer gefunden, der genau so ein Bild erzeugt hat, wie es der MPC von Grund auf zeigte: überblendete Halbbilder ohne interlace-Effekt. Damit war für mich die Sache klar! Ein Blick auf ffdshow zeigte mir für dvsd aber schon libavcodec -> darum musste mit dem MPC was faul sein. Testweise sofort den neuen MPC-HC installiert und tadaaaa :D schon erschien das Originalvideo unverfälscht, eben interlaced.

Tom Keller schrieb:
[...] [IPB-Wissen] (wie oft muss ich das Encodingwissen eigentlich noch nennen :p ?)
Leider muss man auf sowas immer wieder hinweisen, bis man auch den Bezug zum eigenen Problem erkannt hat. Sonst fragt man sich ständig, inwiefern das bei der Lösung des Problems hilft. Ich habe zwar Lücken im Encodingwissen und nichts gegen die Verwendung von B- und P-Frames, nur lag das Problem woanders.

Tom Keller schrieb:
... und du nimmst x264 diese Möglichkeiten weg :rolleyes: !
Das sehe ich ein. Nach diesem Statement habe ich es mir zu Herzen genommen, das Verfahren auch richtig nutzen zu wollen, und keinen Hokuspokus mit meinen Einstellungen zu veranstalten :)


So weit, so gut - käme als nächstes der Audiostream... :)


PS: Off-Topic: Warum gibt's hier eigentlich keinen "Danke"-Button im Forum? Das wäre hin und wieder echt praktisch.
 
Zuletzt bearbeitet:
Zurück
Oben