Beiträge von Supermario

Danke für die Antwort Nel-son. Ich kenne mich auch nicht soo gut aus mit DOS aber wenn ich eine Ausgabe von einem Programm unterdrücken will dann muss man dazu glaub ich einen Befehl geben und das Programm mus diesen Befehl auch verstehen. Global kann man da nichts einstellen. Außerdem hab ich ja geschrieben das es mit anderen Programmen geht.

Hab jetzt auch mal die Classic Shell deinstalliert, die war es nicht. Es muss irgendwas in meinem System geben was den Print to Screen Befehl, oder wie auch immer das heißen mag im DOS, abfängt. Aber was kann das sein und wieso nur bei eac3to? Ist die Bildschirmausgabe von eac3to irgendwie speziell programmiert, vielleicht auch weil ja der Bildschirm-Inhalt in die log-Datei geschrieben wird, welche ja den nicht angezeigten Bildschirmtext bei mir enthält.

sollte ich vielleicht mal die eac3to developer fragen? Wo treiben die sich eigentlich rum, im englischen doom9 oder 10, weiß das jemand?

MfG
Supermario

Hallo,

seit ein paar Tagen habe ich das Problem das wenn ich eac3to benutze das DOS-Fenster Schwarz bleibt. Die umwandlung funktioniert und im LOG steht auch das drin was normalerweise in der DOS-Box ausgegeben wird.

Also ich gebe z.B. ein:

"eac3to.exe input.ac3 output.ac3 -384"

Wenn ich dann Enter drücke kommt nur ein blinkender Cursor.

Ich dachte erst es liegt an der Version, hatte von 3.17 auf 3.24 geupdatet. Aber mit der alten Version dasselbe. Dann dachte ich es muss irgendwas mit meinem Windows 7 64bit sein. Aber andere DOS-Fenster-Anwendungen haben ein funktionierende Bildschirmausgabe. Es ist nur bei eac3to.
Das einzige was ich in letzter Zeit am System geändert hatte war die Classic Shell zu aktualisieren, will die aber wegen meinen Settings nur ungern deinstallieren.

Hatte schonmal jemand ein solches Problem? Wenn ja bitte helft mir.

MfG
Supermario

Tja scheinbar ist es wohl nicht möglich, ich hoffe aber weiter das irgwann jemand drauf antwortet, auch wenn ich bis dahin schon alles mit Tdeint umgewandelt habe.

MfG
Supermario

Hallo liebe Leute.

Ich habe leider einige Serien-Epsioden mit variierender Field Order, also es ist mal "Topfield first" und mal "Bottomfield first".
Gibt es die Möglichkeit in Avisynth eine Autoerkennung einzubauen, die die wechselnde Fieldorder an den verwendeten Deinterlacer weitergibt?

Andere Möglichkeiten wie TFM,Telecide oder restore scripts habe ich für mich schon ausgeschlossen und möchte daher mit TomsMoComp oder Tdeint arbeiten. Beide sind aber nicht von sich aus in der Lage eine wechselnde Field Order zu erkennen.

Hoffentlich kann mir jemand diese Frage beantworten, denn hier im Forum sowie über Google habe ich nichts dazu gefunden.

Ich habe Hoffnung da ja in MeGUI die Analysefunktion erkennen kann ob es sich um "varying Field order" handelt.

MfG
Supermario

Aha, und warum sind es genau 0,1 bzw. 0,2 Pixel? Hat das was damit zu tun wie bob() auf 50fps interpoliert?

Ich hab meine Methode jetzt noch minimal verbessern können indem ich statt mit lanczos4 mit spline36 upscale, dadurch hab ich noch ein bißchen weichere Kanten und weniger grain. Läßt sich damit sehr schnell und gut komprimieren. Bei screenshot-vergleichen sowie beim anschauen ist es sehr angenehm fürs Auge, die Schärfe ist besser wie beim Original und die Treppenstufen fallen nur auf wenn man zu nah am Bildschirm sitzt.

So Staffel 7 hab ich fertig encodet und mit Staffel 1 angefangen. Dann kann ich mich jetzt an die Analyse von Staffel 3 machen.

MfG
Supermario!

Darf man fragen wie du diese Verschiebung der Pixel herausgefunden hast?

Die brutale version sieht sehr schön glatt aus, ist mit tempgaussmc zu vergleichen, nur doppelt so schnell. Aber leider macht dass das Bild viel zu weich, da konnte LS auch nichts mehr rausholen. Es sieht dann schon fast aus wie ein Ölgemälde. Die schnelle antiDEFT version ist ehrlich gesagt schlechter wie meine Version, wo ich nicht finde dass das Holzhammer ist.
Ich bin schon am überlegen ob ich einfach source->tomsmocomp->LimitedSharpenFaster->denoiser nehme für die erste und die zweite Staffel. Ist ähnlich gut wie meine resize-methode nur eben ohne resizen, muss mal schauen was schneller ist.

MfG
Supermario!

Das würde ich auch lieber machen, hab aber die NTSC-Versionen nicht gefunden. Und importieren über Amazon ist viel zu teuer.

So musste es splitten weil der ftp-server von meinem provider eine große datei nicht wollte.

***links gelöscht***

In Quarks Bar sieht man es ganz heftig. Ganz weg gings nur mit TempGaussMC aber ich wollte dieses Jahr noch fertig werden, und zwar mit allen 526 Folgen von TNG,DSN,VOY.

Vielen vielen Dank schon mal das ihr euch das anschauen wollt.

MfG
Supermario!

Sample kommt gleich, aber nur ausnahmsweise, weil mir DSN wichtig ist.
Dauert nur weil das hochladen als abbricht

Danke für die Info scharfi, da muss ich doch gleich mal in deinem exotischen interlacing howto gucken, falls das da drin steht. DEFT...DEFT... ah deftich

So hab jetzt Tdeint vor's resizen gemacht, die comb-Erkennung funktioniert korrekt, alles wunderbar. Ich hatte halt nur Angst das auf Grund des Aliasings der Quelle Tdeint zuviel als combed erkennt.
Mit LS und Supersampling an läuft es ja verdammt langsam, das weis ich jetzt, aber meine Methode mit dem Resizen (down,up) sieht sauberer aus wie LS mit SS und ist um Welten schneller. Zudem hab ich jetzt auch ohne denoiser weniger grain wie mit LS mit SS, und das ohne sichtbaren Schärfeverlust. So kann ich LS ohne SS nehmen, hab die Schärfe nur auf 100 gesetzt statt 60. Smode=3 muss aber bleiben oder? Hätte Smode=4 irgendwelche Vorteile, weil der ja weniger Halos erzeugen soll?

MfG
Supermario!

Da ist nicht mehr viel kaputt zu machen und normalerweise würde ich auch nicht so vorgehen, es ergibt aber ein sehr gutes Ergebnis bei diesem Quellmaterial und das bei akzeptabler Geschwindigkeit.
Außerdem soll Tdeint durch seine Comb-Erkennung auch nur die FX-Szenen deinterlacen die interlaced sind. Ich will nicht jede Folge vorher nochmal in Echtzeit schauen um zu entscheiden ob überhaupt deinterlaced werden muss. Denn es gibt Weltraumszenen die Progressiv sind und welche die interlaced sind, klingt komisch, ist aber so
Dann ist da noch, wenn ich nicht vorher resize könnte TDeint alles als Combed, oder zumindest mehr wie nötig, erkennen und würde jedes Frame interpolieren.

Außerdem versuche ich nur Rückgängig zu machen was verbrochen wurde. Von dem Original-480-29,97i-Material wurde, ich schätze das jetzt einfach mal so, zuerst IVTC gemacht und dann von 480 auf 576 hochskaliert dann PAL-Speedup. Also muss ich zuerst das falsche resizing korrigieren und dann erst alles andere.

Die FX-Szenen die in der PAL-Version interlaced aussehen, kommen wahrscheinlich daher weil die ohne Pulldown in 30i vorlagen und beim IVTC so behandelt wurden als wären sie's.

Aber ich muss mir jetzt erstmal von der 2. Staffel so ne FX-Szene raussuchen um zu schauen ob das Resizing vor dem Deinterlacen alles kaputt macht, dann dreh ich das ganze nochmal um.
Ich werde auch nochmal NNEDI2 und TempGaussMC testen, nur für den Bildvergleich, weil zulange dauern die mir auf jedenfall, danke für die Warnung Didée.

MfG
Supermario!

Kann ich da nicht auch gleich dein "TempGaussMC" nehmen?

Hab jetzt aber mit:

bicubicresize(720,480)
lanczos4resize(720,576)
tdeint(full=false,cthresh=6,mi=32,slow=2,tryweave=false,type=3,mtnmode=1)
limitedsharpenfaster(wide=true,ss_x=1.0,ss_y=1.0,strength=60,soft=30)

die jaggys und miceteeths wegbekommen und es sieht schärfer aus wie das Original ohne das etwas negativ auffällt.

So erst mal gute Nacht.

Didée: Ich hatte mich noch nicht so intensiv mit LS(F) auseinandergesetzt und dachte das die standardeinstellung nicht gleich die langsamste ist
Aber mit deinen Parametern läuft es sehr schön schnell und die Schärfe ist besser wie bei msharpen. Mein Problem ist, das ich das bei der 2. Staffel DSN anwenden will, die aber wie oben schon erwähnt wohl bilinear auf 576 geresized wurde und dadurch jeder Schärfefilter die jaggys noch verschlimmert.
Mit deinen Paramtern sind jetzt die jaggys genauso schlimm wie mit msharpen, also unansehnlich. Ich bin gerade am tüffteln wie man das falsch gescalte Material wieder glattbügelt.
Hab mal "Antialiasing" probiert, geht nicht. Auf 480 runter und dann wieder auf 576 hochscalieren wird zu unscharf...usw. mal sehen was ich da noch machen kann.

MfG
Supermario!

restore24 hab ich zum "Spaß" auch mal probiert. Bei der FX-Szene die ich glattbügeln will hat es wunderbar funktioniert, nur beim Rest der Folge hatte ich dann ne Art Pulldown-Ruckeln. Außerdem ist mir restore24 zu langsam für das bißchen mehr Quali die möglich wäre.

Ich hatte die Star Trek threads im deustchen und englischen Forum schon weitestgehend gelesen, leider gings irgendwie immer nur um TNG oder Enterprise, aber nie um DSN.

Ich hab auch schon Kopfschmerzen von dem Ganzen, daher belass ich es wohl bei TDeint mit Ela-2 als interpolation für die combed Frames. Kommt am nahesten an Tomsmocomp dran. Jedenfalls für Staffel 7.

Staffel 1 von DSN scheint komplett interlaced, zwar auch verschiedene Methoden, aber keine richtig progressiven Frames dabei.

Staffel 2 hat am meisten Probleme mit Kantenbildung weil wohl nach dem IVTC beim upscalen von 480 auf 576 bilinear resized wurde. Wenn ich bilinear auf 480 zurück-scale sind die Stufen fast weg.
Muss jetzt nur noch rausfinden wie schnell limitedsharpenfaster auf nem DualCore mit SSE2 läuft. Weil auf meinem alten Athlon XP nehm ich lieber msharpen weil LS ca. 10x langsamer ist. Nur msharpen geht eben nur bei Staffel 2 wenn ich vorher auf 480 bilinear resize.

Noch was, die Erkennung von MeGUI (Analyse bei d2v-source) sagt bei DSN immer "Progressiv", auch die Standalone-Version von dem Interlace-Analyser. Das ist echt s****, jetzt muss ich jede (Halb)Staffel einzeln per Hand untersuchen, welche Methode am besten ist zu deinterlacen.

Fals noch jemand Tipps oder Erfahrungen zu Star Trek DSN hat immer her damit.

MfG
Supermario!

Hallo,

leider habe ich keinen Rat für dich Wummel aber wollte mal selbst etwas fragen.
Und zwar mach ich gerade fast dasselbe wie Wummel nur mit Star Trek DSN. Ich habe mit Staffel 7 angefangen weil die angeblich die am meisten vergewaltigtste ist was interlacing und rauschen angeht.

Ich habe mal mit separatefields die halbbilder verglichen. Bei den FX-szenen wo combing vorkommt habe ich folgendes Gebilde wenn ich Frames vorklicke: 1 Halbbild vor, 1 geblendetes Halbild, 1 Halbbild vor, 1 Halbbild vor, 1 geblendetes Halbbild.

Also immer 1 normal + 1x blend dann 2x normal + 1x blend.

Ich habe es mit Tdeint schon gut hinbekommen würde aber gerne etwas haben mit der Comb-Erkennung von Tdeint und dann bei den combed Frames aber Tomsmocomp nehmen, geht das? Denn wenn ich statt Tdeint Tomsmocomp nehme sieht die FX-Combed-Szene viel schöner und zeitlich weicher aus. Problem mit Tomsmocomp ist das er mir alle Frames interpoliert, so wie Yadif auch.

Also kann ich Tdeint und Tomsmocomp irgendwie verbinden?

Wummel: Noch ne Anmerkung zu Colormatrix, man sollte es eigentlich nur verwenden wenn man HD->SD oder SD->HD wandelt.
In irgendnem englishen Forum, glaube AVS-Forum, stand das die Video-Chips in DVD-Player das Flag für die Colorimetry nicht auslesen und immer 609'er Koeffizienten verwenden. Außerdem Wummel, musst du für korrekte Hints DGIndex ab Version 1.51 beta 2 oder so verwenden, sonst wurde immer 709 übergeben und die Farben wurden falsch.

MfG
Supermario!

So, da bin ich wieder. Habe jetzt durch zufall rausgefunden wo der Fehler liegt.

Wenn ich ein AVI direkt in VirtualDub öffne wird als VFW-codec XVID verwendet.
Wenn ich über "AVISOURCE" oder "DIRECTSHOWSOURCE" eine Videodatei öffne wurde bei meinen beiden PC's DIVX als VFW-Decoder verwendet.
Nutze ich als VFW aber XVID oder FFDSHOW, sehen die Screenshots von "AVISOURCE" und "DIRECTSHOWSOURCE" genauso aus, wie wenn ich das AVI direkt öffne.

Also deine anfängliche Vermutung LigH war richtig. Ich musste nur erstmal rauskriegen wie ich den zu verwendenden VFW-Codec ändere.

Der DIVX-VFW muss sich irgwann mal dazischengeschoben haben, denn ich sagte ja, das es früher bei mir keine Helligkeitsunterschiede bei Screenshot-vergleichen gab.

Man sollte also den DIVX nie als VFW verwenden, er ist fehlerhaft, zumindest bei der Anzeige in VirtualDubMod.

Mein H.264 reencode wurde aber korrekt behandelt beim umwandeln, sonst würden die Helligkeitsunterschiede ja nicht durch ändern desVFW-codec verschwinden.

Ich finde es aber schon seltsam wie DIVX sich da verhält.

MfG
Supermario!

Sorry das ich mich erst jetzt wieder melde.

Habe leider noch nicht rausgefunden woran meine Bildunterschiede liegen.
Aber zufällig hat das Quell-AVI eine custom Matrix.

LigH:
Da du dies ja expliziet erwähnt hast, meine Frage, hat denn eine Custom-Matrix etwas mit dem verwendeten YUV-Farbraum zu tun? Also das durch die Custom-Matrix eine falsche Annahme vom vfw-codec oder von Avisynth gemacht wird und dadurch die Wandlung von dem Quell-YUV-Farbraum nach RGB falsch gemacht wird. Es muss ja für den Screenshot nach RGB gewandelt werden.

Beim abspielen meine ich auch keinen unterschied zu sehen. Habe beide Videos (Quell-AVI und H.264 reencode) gleichzeitig abgespielt. Das ganze auch auf einem Röhrenmonitor, sodaß Unterschiede im Bild nicht durch unterschiede im Blickwinkel eines TN-Panels entstehen.

Der Unterschied den ich sehe ist also nur bei den Screenshots.
Ich habe die Screenshots auf einem 2. Rechner wiederholt, um auszuschließen, das es die Grafikkarte ist, oder ein Fehler in der decodierungskette.

Wie gesagt wundert mich dieser minimale helligkeits- oder Farbunterschied, weil er bei anderen AVI nach sonstwas recodierungen nicht auftritt.

Ich hoffe ich werde es irgendwann rausfinden.

MfG
Supermario

Als decompressor in VDubMod steht XVID, da ich keinen extra vfw xvid decoder in meinem system finde, nehme ich an das es der selbe decoder ist wie für directshow. Außerdem wollte ich damit nur sagen, das bei "no force" YUY2 übergeben wird und nicht YV12, wobei YV12 richtiger wäre, da das AVI ja in 4:2:0 vorliegt.
Habe aber bemerkt, wenn ich in XVID YV12 erzwinge dann sagt ffdshow bei input "IYUV" also inverses YUV. Ich wollte mit dieser vorgehensweise nur herausfinden, ob YUY2 oder YV12 in dem AVI steckt.
Da du aber sagtest in h.263 ASP gibts nur 4:2:0 kanns doch nur YV12 sein und mich wunderte dann, das bei "no Force" YUY2 übergeben wird.

Edit

Ich wollte nochmal was zu meinen "YUV-Helligkeitsschwankungen" sagen. Wahrscheinlich nehme ich es nur als Unterschied in der Helligkeit war, in wirklichkeit ist es aber ein Farbunterschied. Da du ja sagtest die Helligkeit ist gleich aufgelöst und nur die Farbdifferenzen sind unterschiedlich. Jetzt kam ich gerade auf die Idee, dass es für das bestimmen der RGB-Werte von U und V ja unterschiedliche algorithmen gibt, z.B. YUV und YCBCR. Vielleicht findet irgendwo ein falscher algorithmus anwendung und verschiebt die Farbe minimal. Nur so'n Gedanke.

Hallo Ligh,

also nach deinen Angaben müsste meine Quellmaterial in 4:2:0 vorliegen. Somit ist die Entscheidung die AVISource trifft richtig und übergibt YV12.

Mich wundert dann nur das der XVID decoder es beim abspielen als YUY2 ausgibt. Das hab ich überprüft indem ich das Originalvideo im Zoomplayer abspiele und ffdshow hinter den XVID-decoder schalte. Der zeigt mir dann im Info-Fenster welchen Farbraum die Quelle hat.
Ich kann im XVID-decoder auch YV12 erzwingen, aber die Option "no Force" gefällt mir besser, da dann keine Farbraumkonvertierung stattfindet wenn nicht nötig.

Der Fehler scheint also an VDubMod zu liegen. Nur ist mir das bei anderen Vergleichen von Früher nie aufgefallen.
Ich probiere noch ein bißchen rum, vielleicht finde ich heraus wer das Bild heller oder besser dunkler macht, denn scheinbar ist das hellere Bild das richtige.

Was ich mit typischen YUV-Helligkeitsschwankungen meine ist irgendwie in meinem Kopf gespeichert das verschiedene YUV-Farbräume unterschiedliche Helligkeitsauflösung verwenden. Aber wenn du sagst das 4:2:0 dieselbe Helligkeitsauflösung hat wie 4:2:2 dann weis ich auch nicht
Die unterschiede die ich meine sind auch wirklich gering, vielleicht können einige Menschen es gar nicht sehen.
Ligh es ist auch nicht PC/TV-Scale, das wäre überdeutlich zu sehen.

Hallo,

habe seit langem mal wieder einen reencode machen müssen.
Quelle ist ein XVID-Avi mit B-Frames und Qpel.
Das habe ich mit megui nach h.264 gewandelt.
Danach habe ich mit VDubMod screenshots verglichen.
Dabei ist mir aufgefallen, das mein h.264 heller ist als die Quelle. Es handelt sich um die typischen YUV-Helligkeitsschwankungen, die auch nur bei einigermaßen eingestelltem Bildschirm sichtbar sind.
Mit dem Ergebnis kann ich leben, jedoch interessiert mich welches Bild richtiger ist?

Mein Wissensstand:
- AVISource() verwendet seit Avisynth 2.5 YV12 als Standard wenn nichts anderes übergeben wird.
- Beim XVID decoder habe ich bei Farbraum "no Force" gewählt und ffdshow sagt mir beim abspielen das es YUY2 vom XVID-decoder bekommt.

Meine Frage, wird in Avi's mit "h.263 ASP" denn 4:2:0 (YV12) oder 4:2:2 (YUY2) gespeichert?

Denn ich wüsste gern ob AVISource einfach nur falsch erkennt oder falsch von YUY2 nach YV12 wandelt. Bei korrekter Wandlung der Farbräume sollte der Helligkeitsunterschied doch nicht so auffällig sein?

Was meinen die Profis?

P.S.: Wenn ich in AVISource YUY2 übergebe oder ein ConvertToYUY2 angebe im script habe ich keinen Helligkeitsunterschied zum original avi.

MfG
Supermario