Page 1 of 1

h264 VFR der speziellen Art

Posted: 25.11.2009 12:08
by Beowulf
Ohayou~
Beo is back mit 'ner Frage.
Heutiges Thema: h264 VFR + 20 sek. längeres Video... Ôo

Also, die Raws zu Crimson S, die von Raws-4U stammen, weisen auf einen 120 fps hack hin. (MediaInfo)
Jetzt hab ich das Problem, sobald ich die File demuxe und die h264 um mittels DGAVC 'nen Indexer zu erstellen, spuckt der mir eine Videofile nach'm encoden aus, die ganze 20 Sekunden länger ist. (XviD/AVI)
Außerdem besteht natürlich ein Quali Verlust, was mir ebenfalls am Sack geht. >.<

Gut, mittels avi tc pack versuch ich die encodete Datei und die Timecodes zu muxen:
Problem) In Aegi kann man nicht mal versuchen zu timen, da anscheinend die Keyframes in der Audio wie wild durcheinander fliegen.

Zweite Methode die ich versucht habe wäre mittels avc2avi.
Die Raw-h264 einfach nur in einen AVI Container muxen mit 23.976 fps und dann wieder durch avi-tc zu muxen, das Video ist zwar exakt so lang wie es sein soll, jedoch noch eine VFR mit der man nicht frame genau typen kann.
Außerdem würde der Encode schlappe 29 Stunden pro Pass dauern. -.- (Bild)

Mittlerweile hab ich soweit alles versucht was mir einfiel. (außer mkv2vfr, das versuch ich jetzt weils mit bis dato nicht einfiel xD)
Hab natürlich noch mehrere Methoden per avisynth versucht, jedoch ohne Erfolg.

Wahrscheinlich wieder eine so doofe Frage von meiner Seite aus, aber ehrlich gesagt hab ich bei sowas immer ne Denkblockade. >.>

Ich wär dankbar wenn mir wer erklären könnte wo da der Fehler liegt von meiner Seite aus, da ich dem Problem schon einmal gegenüberstand.

MfG, Beo~

PS: Generell dauern die h264 Encodes plötzlich 4-7 Stunden, liegt das am Windows 7? Obwohl die x264.exe im XP SP3 Kompatibilitätsmodus läuft... Ôo

Re: h264 VFR der speziellen Art

Posted: 25.11.2009 16:26
by DigiFox
Wie wäre ein einfaches Directshowsource("blub.mkv/mp4",fps=23.976,convertfps=true) oder DSS2("blub.mkv/mp4",fps=23.976) ?

DGAVC 'nen Indexer <- ich hoffe mal nicht das du die "nicht" Nvidia Variante probierst? die würd ich überhaupt garnicht mehr nutzen, weil der verwendete libavcodec total veraltet ist und nicht mehr erneuert werden kann.
Da wäre ein über CoreAVC Directshowsource Blub.h264 weitaus besser, aber in deinem Fall bei einer VFR Quelle wohl nicht möglich.

Generell dauern die h264 Encodes plötzlich 4-7 Stunden
x264 hat viele neue nette süße happy Einstellungen, manche davon schlucken viel Zeit wie --b-adapt 2. Sonst kann man nur raten ohne x264 Einstellungen.

Re: h264 VFR der speziellen Art

Posted: 25.11.2009 17:34
by Beowulf
DigiFox wrote:Directshowsource("blub.mkv/mp4",fps=23.976,convertfps=true) oder DSS2("blub.mkv/mp4",fps=23.976) ?
Nope, das war einer meiner ersten Möglichkeiten, kommt trotzdem immer eine 20 Sekunden längere Videofile raus.
Ich versuch das ganze nochmal als Laga...
Generell dauern die h264 Encodes plötzlich 4-7 Stunden
Ich beschäftige mich nicht so~ sehr mit den profiles, hab nur einen Standart umgeändert.

program --profile high --preset fast --pass 2 --bitrate 1905 --stats ".stats" --thread-input --threads 4 --deblock 1:1 --bframes 16 --direct auto --b-bias 0 --scenecut 40 --ref 8 --rc-lookahead 40 --no-mbtree --merange 16 --me umh --subme 7 --partitions all --trellis 2 --psy-rd 0.6:0 --output "output" "input"

29 Stunden wären trotzdem sehr, sehr heftig. ôo

Re: h264 VFR der speziellen Art

Posted: 25.11.2009 17:57
by DigiFox
Wegen deinen 29 Stunden....
"Megui" wird nicht mehr weiterentwickelt, das Ding is tot...
Sollte man auch nicht mehr verwenden. Vorallem die letzten Versionen hatten Massiv Fehler, weil auch nur noch einer was dran gemacht hat, der jetzt auch abgesprungen ist.
Ich bräuchte übrigens bei deinen reinen Einstellungen ohne Filter 40Minuten + 1. Pass vielleicht Stunde mit einem einfachen Quad Core.
Kannst aber mal Threads auf Auto machen also 0, das findet selber immer die besten Einstellungen, aber daran sollte es wohl nicht liegen.
Vielleicht auch mal x264 aktualisieren...
Mit Win7 hab ich noch nix gemacht im Encoding, vorallem wegen den internen Directshow Filtern, aber hast "XP SP3 Kompatibilitätsmodus läuft" auch mal ausgeschaltet und probiert?
Nope, das war einer meiner ersten Möglichkeiten, kommt trotzdem immer eine 20 Sekunden längere Videofile raus.
Ich versuch das ganze nochmal als Laga...
Haste auch wirklich Convert... blub drin gehabt? Deine 20 Sekunden hättest wenn nur ohne Frameraten Konvertierung.
Deine Länge vom Encode Video (Megui) und die von deinem Mediainfo teil stimmen übrigens überein.

Re: h264 VFR der speziellen Art

Posted: 25.11.2009 19:07
by Beowulf
Hab ich gemerkt mit Megui, der neue core build war voll für'n arsch. >.>

Werds mal versuchen nicht im Komp.modus laufen zu lassen. Dachte nur evtl bringt sich das was weil unter XP brauchte der encode, wie du schon sagtest, auf meinem Quad Core nur 1h30 - 2 Stunden.
Die x264.exe is bereits die neue. (1347 falls ich mich nicht täusche)

Falls sich das alles nichts bringt steig ich auf's CMD um, muss mich nur mal damit einüben.


Sobald der encode fertig is meld ich mich mal~
Bis dahin dank ich dir schon mal. ^^

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 16:44
by Beowulf
Mann, komplett vergessen hier mal was zu schreiben. >.<

Also~
Hatte mal alle Codecs/Player ect deinstl. (was eig. nur das CCCP und lagarith war soweit ich weiß) und nochmal alle neu drauf, und man siehe, auch mit DirectShowSource funzt es nun.
Mit 'nem Indexer zwar nicht, aber wayne.

Nur eine Frage habe ich noch, wie sieht es mit crf aus? (constant rate factor)
Ist es eine Überlegung wert, mal damit zu encoden oder sprengt das im Endeffekt bei 'nem Anime die Dateigröße da er sich die Bitrate selbst wählt?

Schon jemand mal damit rumexperimentiert?
Was ich so gelesen hab liefern kleinere CRF-Werte bessere Qualität bei einer größeren Datei. Umgekehrt liefern höhere Werte eine schlechtere Qualität bei einer kleineren Datei.
Stimmt das?
Da ich noch nicht damit rumgetestet hab, beläuft sich mein Wissen diebezüglich noch auf minimalem Stand.

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 17:07
by DigiFox
Beowulf wrote: Schon jemand mal damit rumexperimentiert?
Was ich so gelesen hab liefern kleinere CRF-Werte bessere Qualität bei einer größeren Datei. Umgekehrt liefern höhere Werte eine schlechtere Qualität bei einer kleineren Datei.
Stimmt das?
Da ich noch nicht damit rumgetestet hab, beläuft sich mein Wissen diebezüglich noch auf minimalem Stand.
Ist doch normal das bessere Qualität eine größere Datei bedeuten. Also ist es auch normal das wenn du einen kleineren Quantizer für die den Zielquantizer angibst auch bessere Qualität bekommst.
Ist es eine Überlegung wert, mal damit zu encoden oder sprengt das im Endeffekt bei 'nem Anime die Dateigröße da er sich die Bitrate selbst wählt
Kenn sogar ein Team das seine x264 Encodes genau nach dem Verfahren macht. Ein 1. Pass fällt dadurch auch weg und bedeutet wenn man keinen langsamen 1. Pass durchführt eh schlechtere Qualität beim 2-Pass verfahren. Das nur auf Kosten der genauen Datengröße zu verwenden ist nicht sinnvoll.
Also ich würds auch so machen ;).

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 17:28
by Beowulf
Muh~ Quantizer... vor langer Zeit mal 'nen Blick drauf geworfen... iwie sahs kompliziert aus. xD'
Dachte einfach iwie crf -20 oder so... *hust*

Aber gut, evtl befass ich mich mal mit, sofern es wirklich Sinn macht.
Nur, wenn es Sinn mach, warum benutzt es keiner. xD

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 17:34
by DigiFox
Weil die meisten halt unbedingt eine genaue Datengröße bei allen Episoden eines Animes haben wollen, auch auf Kosten von Artefakten.

Du kannst halt nicht abschätzen...
Bei Folge A passiert nix, alles quatschen nur, wenig Bewegungen = 160MB
Bei Folge B bricht Krieg aus, viele Bewegungen, auch einzelne Partikel wie Gewehrkugeln, also viele Einzelbewegungen = Codec Killer = 340MB

Ist jetzt übertriebenes Beispiel, aber man Encoded dann lieber alles auf 300MB, auch wenn Folge A nichtmal soviel brauch, nur um eine genaue Dateigröße zu haben. Folge B hat wegen 40MB Unterschied in manchen Szenen einen zu kleinen Qz beim 2.Pass Verfahren und deswegen Artefakte. Episoden sind halt verschieden...

Den CRF, wenn man ihn denn benutzt sollte man selbst entscheiden. Manche finden 19 gut, andere sind mit 21 zufrieden, andere schwören auf 18.5, wieder andere finden 23 toll. Jeder findet halt was anderes gut ;) aber in dem Rahmen bewegt es sich.

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 17:52
by Beowulf
Die Erklärung bezüglich deines Beispieles war mir bewusst, deshalb bin ich ja erst auf crf gekommen.

Nur frage ich mich eben, ob es einen Unterschied macht, den/die Quantizer Matrix zu benutzen oder stumpf seine Settings einzustellen und crf -(19-21) zu benutzen.
Denn sonst wirds noch 2 Monate auffährst dauern bis ich das check. xD

Sry das ich dich ein bisschen löchere, aber jetzt grad bin ich zu faul doom9 leer zu lesen. ^^'

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 18:24
by DigiFox
Unterschied?

2-Pass = Genaue Dateigröße ; Schlechtere Qualität bei ungenauerem 1-Pass im Vergleich zur selben Dateigröße wie beim CRF Mode (Turbo Mode im 1. Pass...) ; Längerer Encode wegen 1. Pass
CRF = Ungenaue Dateigröße ; Keinen 1. Pass ; Schnellerer Encode

Hatte ich aber jetzt schon aufgeführt. Sonst ist das vollkommen egal, verwende was dir gefällt.

Wenn du Doom9 aufführt. Die sagen oft bzw. schreiben oft das man nur einen 2. Pass verwenden soll, wenn man eine genaue Dateigröße haben will.
Was sagt Dark Shikari? (x264 Entwickler): Wieso keinen 1. Pass und die zusätzliche Dauer eines 1. Pass (beim 2. Pass Verfahren) in bessere x264 Einstellungen stecken?
http://forum.doom9.org/showpost.php?p=1 ... ostcount=4

Entscheide halt selbst. Ist alles deine Entscheidung was du willst und vorallem deine Zeit die beim Encoden drauf geht.

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 21:37
by max2k
DigiFox wrote:
Was sagt Dark Shikari? (x264 Entwickler): Wieso keinen 1. Pass und die zusätzliche Dauer eines 1. Pass (beim 2. Pass Verfahren) in bessere x264 Einstellungen stecken?
http://forum.doom9.org/showpost.php?p=1 ... ostcount=4
Er schreibt aber, leider, genau das Gegenteil von Dir: "Warum keinen firstpass, wen der eh nur 20% der encoding Zeit ausmacht, dieses kann man doch durch 20% schnellere x264 Einstellungen ausgleichen ..."

Und wen es nicht um die encoding Dauern, sondern um bessere Qualität bei gleicher bitrate geht den kann man ruhig auch beides nutzen. Bessere Einstellungen und 2pass. Meine Fresse ich nutze selbst Trellis 2 obwohl der Qualitätsgewinn zur CPU Belastung ihn keiner Relation steht.

Ich selber nutze CRF um einen Eindruck der Komprimierbarkeit der einzelnen Folgen zu kriegen und nutze den 2pass target bitrate ... Sozusagen ein 3pass verfahren ;). Den Luxus kann ich mir aber Momentan noch leisten. Welche Zeit sich Beowulf leisten kann sollte er selber entscheiden.

Re: h264 VFR der speziellen Art

Posted: 18.12.2009 22:37
by DigiFox
max2k wrote:
DigiFox wrote:
Was sagt Dark Shikari? (x264 Entwickler): Wieso keinen 1. Pass und die zusätzliche Dauer eines 1. Pass (beim 2. Pass Verfahren) in bessere x264 Einstellungen stecken?
http://forum.doom9.org/showpost.php?p=1 ... ostcount=4
Er schreibt aber, leider, genau das Gegenteil von Dir: "Warum keinen firstpass, wen der eh nur 20% der encoding Zeit ausmacht, dieses kann man doch durch 20% schnellere x264 Einstellungen ausgleichen ..."

lol stimmt. Hab ich wohl den einen Tag nur schnell übersprungen und hier hatte ich nur schnell den Link gesucht und hier rein kopiert.
Hätte ich echt mal richtig lesen sollen :? ändert aber nix an allem, außer halt der Link und der Verweis... ^^"

Re: h264 VFR der speziellen Art

Posted: 19.12.2009 15:06
by Beowulf
max2k wrote: Ich selber nutze CRF um einen Eindruck der Komprimierbarkeit der einzelnen Folgen zu kriegen und nutze den 2pass target bitrate ... Sozusagen ein 3pass verfahren ;). Den Luxus kann ich mir aber Momentan noch leisten. Welche Zeit sich Beowulf leisten kann sollte er selber entscheiden.
Versteh ich das jetzt richtig, du machst 'nen CRF Encode, um die eigentliche Bitrate zu erfahren und dann 'nen 2-Pass Encode?
Weil irgendwie verwirrt mich das jetzt, da CRF 'nen Single-Pass ist und keine .stats Files anlegt. Ôo

Check ich nicht ganz xD

Re: h264 VFR der speziellen Art

Posted: 19.12.2009 19:14
by max2k
MeGui zeigte dir bisher, die average bitrat eines Constant Quants encodes an. Da x264 encoding mit MeGui jetzt veraltet ist, muss selber sehen wie man bei einer Komandozieleneingabe auchh ein logfile anlegen kann. Zur Zeit hab ich immer noch die Größe des Videostreams bei einer Spieldauer(+fps) oder „Frame-anzahl“(vfr), hieraus lässt sich auch mit Hilfe eines bitratcalculators, ohne Probleme die durchschnittliche bitrat pro frame errechnen. Den Kalkulator kann es ja egal sein für welches Videoformat du das Ergebnis willst ;).

Btw dient mir der CQ encode eigentlich nicht zu einer genauen Festlegung der bitrat, sondern um diese zu schätzen.

Re: h264 VFR der speziellen Art

Posted: 19.12.2009 19:47
by DigiFox
max2k wrote:Da x264 encoding mit MeGui jetzt veraltet ist,
Nicht mehr...
Kurtnoise und Sharktooth haben sich zwar aus privaten Gründen von Megui zurückgezogen, aber Zathor macht es weiter.
Da er im Gegensatz zu den beiden Zeit hat, kann man Megui auch wieder verwenden, wenn man Lust hat.

Re: h264 VFR der speziellen Art

Posted: 24.12.2009 11:08
by max2k
Für mich jetzt zu spät. Außerdem hinkt der ihn MeGUI verwendete x264 build immer noch hinterher, r1183M zu r1376, oder?

Re: h264 VFR der speziellen Art

Posted: 24.12.2009 11:45
by DigiFox
Nein, Megui ist bei r1376...
http://forum.doom9.org/showthread.php?t=151159
http://megui.org/auto/

Aber sollte man wie bei allem eh selber entscheiden, was man verwendet. Bei ~200 Revisionen Unterschied war Megui auch für mich tot, vorallem ohne neue Funktionen, wo man dann die exe ersetzen und mit der Kommandoline arbeiten musste, aber das war eh ein durcheinander, da war die reine exe schon schöner.