Beiträge von Phoenix323

Hmm.. was macht QTGMC anders als TFM mit den Frames? Die CGI-Szenen sind merkbar flüssiger mit QTGMC.

Hat vielleicht jemand noch n Tipp wie ich das degraining bisschen schneller bekommen könnte? Mein Script schaut bisher so aus:

Zitat

SetMemoryMax(1600)
SetMTMode(3, 4)

SetMTMode(2)

LoadPlugin("G:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("G:\X264\bab5.d2v", info=3)

#QTGMC( Preset="Fast", EdiThreads=1 )
#SelectEven()
TFM(pp=0).blur(0,1)

o = last
pre = o.fft3dfilter(sharpen=0.3,sigma=2.5,sigma2=5,sigma3=3,sigma4=2,bw=16,bh=16,ow=8,oh=8,bt=3,ncpu=2).fluxsmootht(2)
sup1 = pre.msuper()
sup2 = o.msuper(levels=1)
bv2 = manalyse(sup1,isb=true,delta=2,truemotion=false,global=true,blksize=16,overlap=8,search=5,searchparam=6,DCT=5)
bv1 = manalyse(sup1,isb=true,delta=1,truemotion=false,global=true,blksize=16,overlap=8,search=5,searchparam=6,DCT=5)
fv1 = manalyse(sup1,isb=false,delta=1,truemotion=false,global=true,blksize=16,overlap=8,search=5,searchparam=6,DCT=5)
fv2 = manalyse(sup1,isb=false,delta=2,truemotion=false,global=true,blksize=16,overlap=8,search=5,searchparam=6,DCT=5)
o.mdegrain2(sup2,bv1,fv1,bv2,fv2,thsad=280)

#distributor()
return(last)

Alles anzeigen

Edit: Script geändert. Blockgrößen von 32 haben ganz eigentümliche Effekte in den CGI-Szenen zur Folge gehabt. War allerdings auch doppel so schnell.

Serie sollten eigentlich die bekannten Staffelboxen sein. Hab ich vor 4 Jahren oder so gekauft. Denke nicht, dass es da verschiedenes Material für Region 2 gib, oder?

Die Filme sind jedoch aus ner anderen Box. In The Beginning is dann auch wie die Serie 16:9 und überflutet einen mit noise und grain und sah grad beim kurzen drübergucken so aus wie die Serie.

b5_sample4.demuxed.m2v
b5_sample5.demuxed.m2v

Sample 3 hab ich extra so ausgesucht. Die Szene kommt gleich nach einer CGI-Sequenz und ich dachte mir beim gucken: "was zur Hölle?"

Jap das is der Pilotfilm. Dachte mir, am besten von Vorne beginnen

Edit: ist von der ersten Movie-Box. Da is der Ton sogar noch nur Stereo.

Hehe jo, ich glaubs auch.

Ohje, das klingt nach wirklich bösem Material.

Das TFM scheint ganz gut zu funktionieren. Hab es auch mal mit QTGMC probiert und optisch sieht das für meine Augen sehr sehr ähnlich aus, vielleicht einen Tick weniger Überblendungen. Aber so wie ich die Materialbeschreibungen lese wäre QTGMC eigentlich eher falsch dafür?

Hi Propaganda,

klar kein Problem. Hier die Links:

b5_sample1.demuxed.m2v
b5_sample2.demuxed.m2v
b5_sample3.demuxed.m2v

Hallo Leute,

hoffe ihr habt den Sommer gut überstanden.

Ich bekam jedenfalls einen Anflug von Nostalgie und dachte mir: "Hey, wär doch ma wieder coll ein bisschen Babylon 5 anzugucken"

Gesagt, getan. DVD rein in den Computer und los gings. Und dann die Ernüchterung: Bildqualität irgendwie sonderbar. Ich hatte die DVDs vor Jahren das erste mal auf meinem alten Röhrenfernseher geschaut und da wars ganz brauchbar gut. Aber jetzt am Computer-TFT ist es irgendwie merkwürdig Treppenstufenartig.

Also dacht ich mir, muss wohl irgendwie interlaced sein und mein MPC-HC und Konsorten kriegen das irgendwie nicht gescheit hin. Als Lösung viel mir die Umcodierung mit x264 ein, dann hätte ich alle Filme und die Serie auch schön zentral auf ner Platte.

Beim Sichten des Materials aber bin ich auf Merkwürdige Phänomene gestoßen. Undzwar scheint der live-action Teil irgendwie nicht interlaced, sondern phasenverschoben zu sein, die CGI-Szenen aber echt interlaced und ganz selten zwischendrin dann dochmal live-szenen die auch interlaced sind.

Ich bitte euch um Rat wie ich das Material reparieren kann, dass es auch auf einem TFT schön ausschaut.

Neugierde. Im Mewiki wird durchaus empfohlen vbv-maxrate zu benutzen. Ich wollte einfach mal sehn, was das macht

Ja, das is ja das komische. Für ne DVD-Quelle reicht ja im High-Profil das Level 3.0. Also ergibt sich daraus ne vbv-maxrate von 12,5 Mbit. Erhöht möglicherweise die vbv-bufsize die Bitrate? Hab nochmal durchlaufen lassen und mit --preset slow --tune film --crf 19 bekomm ich 10,5% weniger Bitrate raus wie mit --preset slow --tune film --crf 19 --vbv-maxrate 12500 --vbv-bufsize 6250 (wert einfach mal ins blaue geraten).

Aso ja nee, ich mein wegen VBV. Mit VBV weicht die Bitrate ergo Dateigröße stark von der ohne VBV ab - bei sonst gleichen Einstellungen. Ich benutze quasi nur --preset slow und halt --tune film für Filme. Das sind mir die sinnigsten Einstellungen.

Hehe, ja. Der MB-Tree hat hier bei mir einiges durcheinander gebracht. Die finalen durchschnittlichen Bitraten weichen nun bis zu 50% von früher ab. Muss mir noch irgendwie überlegen wie ich nu meine Bitrate festlege.

Ich hab grad 2 Test-Läuft mit VBV gemacht und da war die resultierende Bitrate ca. 10% höher. Warum ist das so?

Hi Leute,

ich hab da mal ne Frage, die nach langer Google-, Doom9- und Gleitz-Suche ich mir nicht eindeutig beantworten kann.

Anstatt das ganze Frame mit einem einzigen QP zu belegen, ist doch wohl ein variabler QP auf Macroblockbasis deutlich besser und würde sowohl der Kompression als auch der Qualität zu gute kommen - hab ich mir gedacht.

Laut diesem Thread http://forum.gleitz.info/showthread.php?t=38608 sollte das x264 auch tun wenn VAQ aktiviert is (was standardmäßig der Fall ist).

Allerdings sagt dieses Dokument, verlinkt aus dem MEWiki, dass das nur der Fall im VBV-Modus ist. Das Doc ist zwar von 2006 .. aber ein aktuelleres hab ich auch im git-repo von x264 nicht gefunden.

Weiß da jemand was definitives drüber?

Äh, naja gut. Das hilft mir so nicht wirklich weiter. Ich stell' die Frage mal anders: Wie kann ich sowohl im Videostram, als auch im Container das PAR setzen?

Hi Leutz,

normal codier ich meine Vids nach x264 und da klappt dat mit den AR-Flags einwandfiffi. Hab aber nu mal aus Neugier bissl mit Xvid rumgedoktort und da tun sich mir einige Probleme auf.

Meine x264-Encodings gehn immer als RawAVC raus weils ja auch nur Video is. Wenn dann der Ton hinzukommt brauch ich ja erst nen Container. Bei Xvid hab ich mir das nun genauso gedacht, weil sich mir der Vorteil mit dem Xvid-Encraw nach AVI zu encoden nicht erschließt.

Das codieren nach rohem m4v funzt soweit auch wunderbar, der fertige rawstream enthält laut GSpot das korrekte PAR und somit DAR. Wenn ich das nun aber mit MP4Box mit Ton nach MP4 muxe ist das PAR verschwunden und das DAR ist laut GSpot dem SAR identisch und Gspot meldet auch eine falsche recommended display size. Der VLC und MPC-HC spielen es zwar im korrekten Seitenverhältnis ab, aber zumindest der MPC-HC fängt nach ca. 5 Sekunden an zu ruckeln, b.z.w. das Bild eben nicht flüssig darzustellen. MP4Box über Yamb oder manuell das PAR mitzugeben funktioniert nicht, nach dem Tracks importieren beendet sich MP4Box mit dem schlichten Fehler "Bad Parameter"

Jemand n Vorschlag?

Öh ja, die Fragen haben sich mittlerweile alle selbst erledigt. Nummer eins hat sich ja selber beantwortet, Nummer 2 auch nachdem ich gesehen habe, dass MeGUI den schalter nach einer internen Berechnung an den Encoder weitergibt. Und Nummer 3 hat sich auch erledigt, da ich nun sowieso immer für ASP und AVC nen manuellen Comp.-Check mach.

Ah hm lol, da bin ich ja voll drauf reingefallen

Ich dachte schon der MPC könne zaubern. Schwarze Magie

Hi Leutz,

ich schreib das mal hier rein, weil ich mir nicht ganz sicher bin wo das Phänomen herkommt.

Folgendes: Ich möchte ganz normal ein MPEG2 Video nach Xvid codieren und benutze MeGUI. Läuft auch alles ganz normal, D2v indexen, Audio demuxen, Avisynth-Script erstellen, Video umwandeln.

Nun hab ich das merkwürdige Phänomen, dass sich in der fertigen Videodatei (bisher nur mit avi und rawasp ausgabe versucht) weiterhin exakt die demuxten Audiospuren befinden! Weder GSpot noch Mediainfo zeigt diese an. auch der VLC findet diese nicht und spielt nur Video. Aber der Media Player Classic HC spielt diese bloße Videodatei, die ja keinerlei Audio enthalten sollte mit Ton ab und zeigt in den Datei-Eigenschaften auch genau die demuxten Original-Tonspuren.

Strange irgendwie, wa? Weiß jemand was?

Ja auf Vollbild is halt Vollbild, da seh ich dann auch keinen Unterschied. Aber im 1:1 Modus schon, is mir halt aufgefallen. Im Endeffekt isses dann ja auch egal

Naja ich bin halt perfektionist

Mich hat halt gewundert, dass am PC mit dem gleichen Player exakt übereinander geöffnet das Bild von der DVD nicht so stark in die Breite gezogen wird das mit PAR 16:11 encodierte Gegenstück

Hm ah ok, die zoomen also quasi ins Bild rei,n um die vollen 720 Pixel auszunutzen. Das Seitenverhältnis bleibt dabei gleich. Aber im Quellmaterial sind oben und unten 2 Pixel schwarze Balken. Fürs Seitenverhältnis würde das, bei einem eventuellen Backup, nun folgendes bedeuten:

DAR 1,78

572 Px. hor. x 1,78 = 1018 Px.
1018 Px. vert. / 702 Px. aktiv, da gezoomt = 509/351 = 1,45

also eine PAR von 509:531 für 720 Pixel = 1044 Pixel horizontal

und somit ein korrektes Seitenverhältnis von 1044x572 Pixel für das Bild am PC Monitor.

Hab ich das DAR und PAR korrekt verstanden?