Nur für Spass, mal ganz schnell.
[Blockierte Grafik: http://thumbnails107.imagebam.com/24429/58ddb3244282414.jpg] [Blockierte Grafik: http://thumbnails103.imagebam.com/24429/9f0f12244282406.jpg] [Blockierte Grafik: http://thumbnails103.imagebam.com/24429/c10ded244282397.jpg]
Probieren. Hey, so übel ist das gar nicht. 
Ja, dass freie Kurven möglich sind ist schon klar. Is' ja kein so großes Ding. Ich hatte das Dithering gemeint. Einfaches Beispiel: wenn eine Graustufentreppe 20,21,22,23 per Kurvenabflachung auf die Hälfte zusammengestaucht wird, dann haste statt 4 Bereiche nur noch 2 Bereiche (z.B. 20&21~> 20, 22&23~> 21). Information geht verloren. Wenn SmoothAdjust mit Dithering arbeitet, dann haste nach dem auf-die-Hälfte-Zusammenstauchen immer noch 4 Bereiche. 20->20, 21->(Dithering-Mix aus 20+21), 22->21, 23->(Dithering-Mix aus 21+22). Und andersrum bei Tonwert-Spreizung: Wenn man einen Kurventeil z.B. auf 400% Steigung anhebt, dann entstehen da "Löcher" im Histogram. 0->0, 1->4, 2->8, 3->12 usw, und nix dazwischen. Ein unstetes Histogram, wodurch oft auch "Banding" sichtbar werden kann. SmoothAdjust kann das vermindern, indem die lokalen Gradienten abgeschätzt, und dann diese "Löcher" im Histogram entsprechend aufgefüllt werden.
Eben solche Kleinigkeiten und Nebensächlichkeiten. Und ich hatte mich halt gefragt, ob der Edius das auch .... oder doch eher nicht.
Das geht natürlich ebenso in Avisynth: mit LaTo's "SmoothAdjust.dll", Filter "SmoothCurve". Freie Kurvenanpassung, inklusive Smoothing/Dithering für die expandierten bzw. komprimierten Level-Bereiche. Weiß nicht ob der Edius das auch kann? 
Das ist keine große Überraschung bzw. hat nicht viel zu sagen. Das was "CRF=xy" liefert, das hat sich im Verlauf von ca. 1000 (!) Revisionen seit Deiner uralt-Version definitiv mehrmals geändert. Ziemlich sicher ist aber: bei am Ende gleicher Bitrate wird das Egebnis eines aktuellen Builds sicherlich besser sein als das vom 1000 Revisionen älteren Build. Und wenn der neuere Build +1 oder +2 höheres CRF braucht um auf die gleiche Bitrate zu kommen, dann ist es halt so. CRF ist immer nur ein relatives Maß. Niemals ein absolutes.
Nebenbei: ohne jetzt allzu tief in die x264 Settings einsteigen zu wollen, aber ein einziger Punkt: Wenn Du dermaßen niedrige Deadzone-Werte verwendest, dann ist das MÖRDERISCH betreffs Bitrate, wenn man NICHT Trellis=2 verwendet. (Ich nehme auch gerne die deadzone-Werte vom Grain-Preset: deadzone_intra und _inter beide = 6 -- aber NUR mit Trellis=2 und SubME=10. Wenn das zu langsam ist, kann man sich die Deadzone-Geschichte auch gleich komplett sparen, zumindest mMn.)
Ne, mit "schnell mal ein Filterchen" is' da nix. Es gibt hier keine "Trennung" zwischen Vordergrund und Hintergrund. Es gibt nur eine einzige spatiale Ebene, in der alles drinsteckt. Und sicher, man kann/könnte schon dafür sorgen, dass "statische" Objekte an ihrem Platz bleiben. (Macht auch schon seine Probleme, geht aber so einigermaßen.) Aber man kann ja nichts dagegen tun, wenn andere bewegte Bereiche ihren (theoretischen) Referenz-ursprung genau dort haben, wo sie von HUD-Objekten verdeckt gewesen sind. Da zieht man sich dann sofort die HUD-Elemente in die Kompensation hinein. Oder man arbeitet tatsächlich mit irgendwelchen Tools ala Delogo & Co ... aber wenn die zu entfernenden Bereiche etwas größer als Winzig-Klein sind, dann sieht das Result meistens recht peinlich aus. Insbesondere wenn die restlichen Bereiche schön viel Detail enthalten, und das Delogo-Tool dann große einfarbige Blobs oder lineare Gradienten 'drüberlegt.
=> Nicht alles, was man gerne hätte, ist auch realisierbar ....
Tricky, that is.
Sehe ich das richtig - ist das ein "Re-Play", und Du kannst exakt die gleiche Sequenz einmal mit und einmal ohne HUD-usw.-Elemente capturen?
1) Wenn ja, dann wäre es relativ einfach:
a) das Video ohne HUD-Kram zu stabilisieren, und dann
b) durch Differenzierung die unterschiedlichen Bereiche zwischen Video1 + Video2 markieren (das wären dann ja genau die HUD-usw Bereiche), und diese entsprechend wieder zurück-Kopieren auf das stabilisierte Video.
2) Wenn nein, dann sch...ade.
Wobei dieser Vergleich zum MSU-Deinterlacer nicht mehr aktuell ist - den hatte ich noch mit der 2.0 vom MSU-Deint gemacht, der inzwischen aber schon bei 2.1 angekommen ist.
Beschwören kann ich's nicht, aber nach grobem Augenmaß:
2.0 hat seine Fehler nur mit Full-Pel Genauigkeit produziert, 2.1 macht sie mit Half-Pel Genauigkeit. 
Schnell mal ein Bild gepinselt.
[Blockierte Grafik: http://thumbnails102.imagebam.com/23782/c0ad9d237814710.jpg]
Schnell-schnell mit Xvid kodiert, also 4:2:0. Das Ergebnis-Video ...
... in VirtualDub geöffnet (verwendet einfaches Pointsampling für Chroma)
[Blockierte Grafik: http://thumbnails107.imagebam.com/23782/266994237814708.jpg]
... in einem Mediaplayer mit ffdshow abgespielt (mit RGB-Wandlung in ffdshow, d.h. unabhängig welcher Renderer verwendet wird)
[Blockierte Grafik: http://thumbnails108.imagebam.com/23782/aeeb8d237814703.jpg]
^Thumbnails^, anklicken für Originalgröße.
Anderen Render bzw. andere Rendering-Optionen benutzen, oder gleich beim Dekodieren eine RGB-Wandlung erzwingen.
Beispiel ffdshow: Farbausgabe auf "RGB" erzwingen (Tab "Output"), und im Tab "RGB Conversion" die Optionen "High Quality YV12 to RGB conversion" und "Dithering" aktiviert haben.
10bit- und 4:4:4- Encoding scheint mir etwas "mit Kanonen auf Spatzen geschossen". Außerdem sind die mir aus rein praktischen Gesichtspunkten etwas suspekt. Klar funktioniert das alles ... bis man bei irgendeiner Gelegenheit mal ein Video "woanders" abspielen will, und dann merkt "Oh Schei**e, dieses Gerät kann das ja gar nicht abspielen."
Zitat von Goldwingfahrerwenn ich hier 4:2:0 hochpumpe zu 4:4:4 sehe ich auch keinen Unterschied..obwohl mein Eizo 10 Bit kann.
Zackige Kanten bleiben bestehen,gleiche Krankheit also wie das DV-AVI Format zeigt.
Mit 10bit-Genauigkeit des Monitos hat das üü-ber-haupt-nichts zu tun. Zumal die allermeisten "Consumer"-Grafikkarten eh' nur 8bit zur Anzeige 'rausgeben können.
[HR][/HR] Die zackigen Kanten liegen einfach daran, wenn die Wandlung von 4:2:0 (YV12) zu RGB nur ein einfaches Pointsampling für das Chroma-Upsampling benutzt. Da liegt der Hund begraben.
[HR][/HR]
Bei dem Sample entsteht durch dgsource.assumetff.bob.srestore nichts ruckeliges oder hakeliges. Ich krieg' hier einen komplett sauberen Bildfluss @ 23.976 fps.
Wechsel der Field-Order auf der DVD. Da können NNEDI3/Srestore nichts dafür.
PAL DVDs sollten eigentlich BFF sein. Das Sample ist TFF. Wenn solche Paritätswechsel innerhalb einer Video-Sequenz vorkommen, dann ist Arbeit angesagt.
DGIndex müsste/sollte eigentlich warnen, wenn so ein Paritätswechsel erkannt wird. Ob die angebotene "Reparatur"-Option erfolgreich ist oder nicht, sollte man immer manuell überprüfen.
Zum Beispiel sowas. Oder eben die 50/60 fps VQEG-Testsequenzen, die MSU verwendet hat.
Doch, methodisch passt das schon. Nehme progressives Video (A). Erstelle aus (A) ein interlactes Video (B). Übergebe (B) an einen Deinterlacer, der (B) wieder de-interlaced, Ergebnis ist (C).
In einer perfekten Welt wäre (C) == (A).
PSNR ist für den Allerwertesten.
MSU zeigt für Stockholm PSNR Werte: QTGMC=~34.5 , MSU=~36.7
Mit Stockholm hatte ich mal einen PSNR-Test gemacht, als TGMC die Lossless-Option bekommen hatte.
TGMC "normal": PSNR=40.0
TGMC "lossless": PSNR 44.8
Sicher, es kommt drauf an welches Tool den PSNR berechnet hat, und wie die Testsequenz genau gewählt war ... aber trotzdem, irgendwas ist da komisch.
Rein "visuell" sind die beiden TGMCs (normal/lossless) kaum zu unterscheiden, beim Live-Anschauen ist "normal" eigentlich sogar etwas besser.
Festzuhalten ist:
- geht's um PSNR-Fetischismus, dann raucht QTGMC den MSU-Deinterlacer in der Pfeife, wenn's denn sein muss.
- geht's ums visuelle Ergebnis, macht der große PSNR-Unterschied kaum einen Unterschied. (bei TGMC)
und
- das, was einen Deinterlacer ausmacht - insbesondere "Stabilität auf der Zeitachse" (Shimmering) - lässt sich mit PSNR überhaupt nicht erfassen.
(Ein ganz doofer "Bob()" ist PSNR-mäßig nicht viel schlechter als Tdeint oder Yadif. Bisweilen ist Bob() hier sogar besser!)
Etwas früher war da noch dieser kleine Test, mit einem Ausschnitt aus "Parkrun" (bzw. der alte "Parkjoy"). Da hat TGMC die anderen üblichen Verdächtigen auch schon ziemlich alt aussehen lassen, obwohl da noch ohne "lossless", also mit "schlechteren" PSNR-Werten als möglich.
Es ist ziemlich wurscht, ob's um PSNR oder um visuelle Qualität oder um Komprimierbarkeit geht, oder um irgendwas anderes.
Die Erkenntnis am Ende des Tages ist immer die gleiche:
QTGMC raucht den MSU-Deinterlacer in der Pfeife.
MSU bietet gerne "hochparallelisierte Reinigungswerkzeuge mit zehntausenden synchronisiert arbeitenden Einzelelementen" an.
(andernorts manchmal auch "Besen" genannt.)
Wieso sind die Ergebnisse "2=4 3=5..." oder "1=3 2=4..." - - - was heißt "gleich"? Es dürfte ja keine "gleichen" Bilder geben, der Stream ist echt-interlaced, und nach Bob() soll herauskommen:
A B C D E F G H ... also nix mit Doppel-Buchstaben. Außer wir reden gerade aneinander vorbei, was möglich wäre.
Mir fällt gerade ein: beim Um-Muxen hat sich MKVMerge über den Datenstrom beschwert, irgendwas mit fehlenden Referenz-Timecodes oder so, und dass bei Multi-Referenzen Probleme auftauchen könnten. Kann sein dass hier ein Teil des Problemes liegt .... allerdings nutzt der Stream sowieso nur 1 Referenzframe, nicht mehrere. Wäre schon möglich dass Timecodes eingespart wurden (weil bei 1 Referenz nicht unbedingt nötig), verschiedene Decoder aber die Timecodes erwarten, weil sie "eigentlich" immer da sein sollten? (Was weiß ich ... da unten auf dem Datenstrom-Level kenne ich mich auch nicht aus.)
Schon mal DirectShowSource probiert? Normalerweise wird ja immer abgeraten ... außer in den Fällen wo nichts anderes funktioniert, und wo es dann der rettende Notausgang sein kann. Vielleicht haben wir hier so einen Fall. (Von DGDecodeNV mal abgesehen.):)
So, Sample angeschaut. WAS IST DENN DAS?!?!
Wenn ich das auf die Schnelle alles richtig gesehen habe, dann befinden sich in dem Sample Szenen mit:
- 25p progressiv
- 50i ohne blending
- 25i50 mit fieldblending
Also ein ganz wilder Mix, wobei unklar ist wie das so zustande gekommen sein kann.
Generell unterscheiden sich
a) die Szenen ohne Texteinblendungen - die scheinen überwiegend progressiv zu sein
b) die Szenen mit Texteinblendungen - das sind die üblichen Fieldblending-Geschichten
Gar nicht ins Bild passen tut
c) die Hochhaus-Szene mit dem wandernden Schatten (bei ca 0m07s~0m08s), das scheint reines 50i zu sein: der Schatten bewegt sich in jedem Halbbild, aber Blending kann ich eigentlich keines Entdecken.
Vielleicht (hoffentlich) sind ja nur diese Intro/Trailer Sequenzen so schlimm, und die Hauptfeatures sind "normal", auf welche Weise auch immer? Weil, wenn das durchgängig so ist wie in dem Sample, dann würd' ich das Projekt gleich wieder begraben. Bzw. interlaced lassen wie's ist und nix weiter daran machen.
Ich kann mir keinen Fall vorstellen, in dem die Kombination TFM + QTGMC richtig wäre. Wenn TFM angebracht ist, hat QTGMC danach nix mehr verloren. Wenn QTGMC angebracht ist, hat TFM davor nix verloren.
Jo, das alte Problem. ffms2 ist desöfteren (oder "meistens") nicht fähig, interlactes Videomaterial korrekt zu dekodieren.
- dekodiere ich das *.mov mit ffvideosource: weitgehend richtig, manchmal treten vorwärts-rückwärts-Sprünge auf. => unbrauchbar
- muxe ich das *.mov in *.mkv, dann ffvideosource: vorwärts-rückwärts-Sprünge nach jeweils 4 Frames. => unbrauchbar
- muxe ich das *.mov in *.mkv, und dekodiere mit DGDecodeNV: Keine Probleme. Alles gut. Alles so wie es ein soll.
Warum die das mit dem Interlacing bei ffms2 nicht gebacken kriegen weiß ich auch nicht. ffmpeg bzw. libav kann es ja, über directshow funktioniert's ja schließlich auch. Aber bei ffms2 ist's ein riesen-Problem. SEIT JAHREN.
Für alles, außer dem Intro. Was man dem tun soll, da fällt mir gerade auch nichts ein. Großer Murks!
Die meiste Wirkung mit dem wenigsten Aufwand:
Source()
nnedi3(field=-2)
Srestore(frate=25.0,speed=-1)
