Beiträge von Didée

    Dein finaler Rückschluss/Behauptung/Unterstellung ist doch schon wieder totaler Quark. Du hast also befunden, dass "Deine" Settings guten Regen etc. produzieren ... bei ~5000kbps. Und dass der vorgegebene Preset keinen guten Regen etc. produziert ... bei 1500kbps.

    Hast Du es wirklich nicht verstanden? Oder tust Du nur so?

    sneaker hat Vergleiche bei gleicher Bitrate gegenübergestellt. (Zur Erinnerung - mit dem Ergebnis, dass der vorgegebene Preset die homogenste Bilddarstellung erzielt hat.) Das Niveau der Bitrate war dabei absichtlich sehr niedrig gewählt, um die Unterschiede besser zu verdeutlichen. Klar kann man auch alles mit 30 Mbps encoden, aber dann sind sowieso alle Einstellung ziemlich wurstegal. Wenn Bitrate hoch [genug], dann sieht alles gut aus.

    Schraub' mal bei Deinen Settings die Bitrate auf 1500 runter. Oder nimm den Standard-Preset und schraube ihn auf 5000 hoch. DANN kannste irgendwas vergleichen.

    Ach Gottchen, das is' NTSC mit 3:2 Soft-Pulldown. Deswegen erscheint es "interlaced", wenn man mit DGIndex ganz "normal" indiziert, ohne forced-film. Per DirectShow wurde mir das Vanilla als (24p) progressiv angezeigt/abgespielt.

    Ihr könnt da noch lange über x-fach erhöhte Bittiefe diskutieren. Das hilft nix.

    Wenn man Pi-mal-Daumen rechnet, dann bringt es nichts, "Pi" mit 10, 100 oder 1000 Nachkommastellen zu benutzen.

    Ist nicht 100%ig das gleiche, weil die gradfun2db.dll etwas anders arbeitet als 'Deband' in ffdshow (gradfun hat keinen einstellbaren Radius, sondern fix r=16).
    Aber man sieht doch wohl, wohin die Reise geht.

    Besser in 8bit das Richtige tun, als das Falsche in 10 oder 16 Bit. :zunge:

    Was hältst du von meiner ursprünglichen Idee Deblocking durch dithering zu machen? Und kann der ResampleHQ 10/16 Bit pro Kanal an den x264-10bit weitergeben oder nicht ? bzw. Wie kann ich das nachprüfen ? ... Ich habe immer noch die Hoffnung das es doch was bringt ;)


    Nix halt' ich davon. Und das 10-bit oder 16-bit Zeugs auch einfach mal vergessen. Vorerst, zumindest. Das alles geht zu 98% am Problem vorbei. Es hilft nichts, sich irgendwelche schöne Lösungen auszudenken ... wichtig ist vor allem, dass eine Lösung überhaupt erstmal zum Problem passt. Zitat aus "Der Volltreffer": "Kreditkarten funktionieren aber bei einer völlig anderen Art von Schloß!".
    (Wer den Film kennt, liegt jetzt mit Lachkrämpfen auf dem Boden.)

    Das Problem ist nicht das Blocking als solches (spatiales Problem), sondern vielmehr die zeitliche Varianz. Es flickert und flackert. Kurz, das ist Rauschen. Dagegen hilft ein Rauschfilter. Rauschen weg --> Blocking weg --> Problem weg.

    Haste da vielleicht mal ein kleines Beispiel vom betreffenden Material, so mit Original-Interlaced und QTGMC-Deinterlaced? Weil, so langsam driftet das jetzt stark ab in den Nebel aus Vermutungen, wer-weiß-schon-was-WIRKLICH-das-Problem-ist, und dann machen viele Leute viele falsche Vorschläge zu völlig falschen Baustellen, ...

    Also, das mit DeblockQED (oder irgend'nem anderen Deblocker) ist Quark, das bringt so gut wie garnichts. Nochmal zurück zu Post#1.

    besonders in "Lichtschwachen" Scenen - bei der auch noch die Kamera ordentlich Grain liefert - nach dem Encoden sehr starke Blockartefakte zu sehen sind.


    Wenn die Blockbildung im Originalmaterial nicht drin ist, sondern erst nach dem neuerlichen Encoden .... was soll es dann bringen, vor dem Encoder einen Deblocker einzusetzen?


    Die Commandline sieht im Prinzip nicht übel aus, das was drin steht ist okay ... versuch' mal, die folgenden Parameter zusätzlich einzubinden:

    Code
    --crf 16 --preset slow --tune film --rc-lookahead 20 --subme 10 --trellis 2 --deadzone 6,6 --no-fast-pskip 
    --no-dct-decimate --qcomp 0.50 --psy-rd 1.05:0.15 --aq-mode 1 --aq-strength 1.25


    Ohne Gewähr natürlich, aber ... "Versuch macht kluch".

    Die x264-Devels machen einen sehr guten Job damit, den definierten Standard umzusetzen /bzw. dessen Möglichkeiten auszuloten.

    Wenn da -zig-hunderte von abgespeckten mini-Chips kursieren, oder User auf veralteter Software (VLC 0.8) bestehen, wo die HW oder SW jammert "ich kann aber den Standard nicht so richtig, sondern ich kann nur dies und das, aber bitte nicht jenes oder folgendes", dann .... ist das nicht wirklich das Problem der x264-Devels. Schon allein weil da wiederum -zih-hunderte von Kombinationen enstehen, was der eine oder der andere eben gerade kann oder nicht kann. Deswegen gibt es den Standard. Sogar so richtig schön nach Profilen und Levels unterteilt. Und wer sich nicht an die Spielregeln des Standards halten kann, der muss eben draußen bleiben und darf nicht mitspielen.

    Ich will bitteschön H264-HD-Videos auf meinem Hobbykeller-PC mit Windows 3.1 abspielen! Wie, was heißt hier "geht nicht"?! Mann mann mann, was für ein Schei**-Codec das doch ist ...

    In 1-2 Jahren hoffe ich, den (wg. Röhren-Tod als "Übergangslösung" gekauften) LCD endlich durch einen OLED ersetzen zu können. Bei Plasma-vs-LCD ist's am Ende immer die Wahl zwischen Pest und Cholera. OLED hat endlich - zumindest von den technischen Voraussetzungen her - die Möglichkeiten, um all das zu vermeiden, was mich bei Plasma-TVs einerseits, oder bei LCD-TVs andererseits jeweils am meisten stört. Aber man muss abwarten ... irgendwie ist OLED ein Stein der alles andere Plattwalzen kann, wenn er denn erstmal ins Rollen kommt. Das Problem ist: er kommt einfach nicht ins Rollen ...

    Ich kann, soweit ich das bis heute gesehen habe, beim Pana nichts eigenes einstellen, das geht nur über den BD-Player


    Kann auch sein ... ich hab mit den Pana-Plasmas fast keine "erste-Hand" Erfahrung, und/oder wie wie viel sich seit 2009/2010 bis heute verändert hat, und/oder welche Parameter in den verschiedenen Modell-Stufen (nicht) vorhanden sind ...

    Zitat

    Heisst das, dass ein Plasma "länger" für die Darstellung braucht oder sich diese aufwendiger gestalltet und es daher zu Rucklern kommen kann?


    "Länger" ... jein. In dieser Hinsicht heißt das vor allem, dass die sensationell kurzen "Reaktionszeiten", von 0.001 Sekunden oder so, großteils auch nur ein Marketing-Hype sind, die in der Praxis relativ wenig zu sagen haben.

    Ganz allgemein wollte ich damit nur ausdrücken, dass es bei der Plasma-Technik relativ schwierig ist, verschiedene Bildwiederholfrequenzen darzustellen. "Schwierig" in dem Sinn, dass für *jede* der möglichen Wiederholfrequenzen eine komplett neue, komplett eigene Strategie in den Zündungs-Mustern der Plasmazellen erarbeitet werden muss. Bei LCD ist dieser Aspekt technisch sehr viel einfacher zu handhaben. Und am Vorhandensein des "50Hz-Bugs" kann man sehen, dass Panasonic sich bei der Entwicklung vornehmlich auf die NTSC- und Film-Frequenzen 24/30/60Hz konzentriert hat, die funktionieren nämlich fehlerfrei. Nur die PAL-Frequenzen 25/50Hz, die haben die letzten Jahre mit dem 50Hz-Bug zu kämpfen ... technisch handelt es sich um "Posterizations"-Artefakte (sieht so ähnlich aus wie eine Wandlung von 16.7 Mio. Farben auf 256-Farben-Palette), in der Praxis wird auch öfters von "Matschgesichtern" bei Bewegung gesprochen. Der Hund begraben liegt einfach in der genannten Schwierigkeit, dass für jede Bildwiederholfrequenz eine ganz eigene Strategie der Ansteuerung und Zündmuster erarbeitet werden muss ... und wichtig war halt vor vor allem NTSC/Film. Für Europa/PAL wurde anscheinend etwas zusammengestrickt, dass nur in ca. 98-99% aller Situationen korrekt arbeitet. Und 1-2% Fehlerrate sind hier leider relativ viel, das springt einem relativ häufig ins Auge. Soll sich aber deutlich minimieren, wenn man die IFC dazuschaltet.

    Um den Bogen zurückzuspannen zum Ruckel-/Flüssigkeits-Problem: ich weiß nun mal nicht, was DU auf DEINEM Plasma zu sehen bekommst. Aufgrund "sekundärer" technischer Gründe kann es schon möglich sein, dass bei Dir das eine mehr ruckelt und das andere etwas flüssiger erscheint. Aber, jedenfalls, von meinen Erfahrungen mit PC-Monitor (voll 24/48/50/60Hz fähig), sowie einem hinreichend neuen und technisch ausgestatteten Samsung-LCD, komme ich ganz eindeutig zu dem Schluss: (nun zum dritten Mal geschrieben): bei technisch korrekter Umsetzung der Wiedergabekette gibt es keinen nennenswerten Unterschied zwischen 24Hz- und 25Hz- Bildwiederhofrequenz bei Filmen. Ohne Zwischenbild-Tricks ruckelt beides genau gleich. Und mit Zwischenbild-Tricks erscheint beides gleich flüssig. Es macht keinen Unterschied.

    ____

    Übrigens bin ich durchaus kein Gegner von Plasma-TVs. Es ist nur so, dass recht oft von Befürwortern (ohne ausreichenden Background) das-Blaue-vom-Himmel heruntergelobt wird, mit irgendwelchen Buzzwords: "Plasma ist die beste Technik, weil [dieses], weil [jenes], und weil [folgendes] !!"
    - Und wenn man dann mal im Detail auseinandernimmt, wie die Plasma-Darstellung wirklich funktioniert, dann zeigt sich, dass [dieses], und [jenes], und [folgendes] sehr oft überbewertet, oder sogar komplett falsch ausgelegt oder fehlinterpretiert wird. Und deswegen "schimpfe" ich in diesem Bereich gerne mal. Nicht weil Plasma schlecht wäre, ganz sicher nicht. Aber wenn unbedarfte mit falschen Begründungen argumentieren, und dann auch noch meinen es wären Totschlag-Argumente, dann man muss man einfach mal dagegenhalten.

    Aber das ist ja momentan nicht das Thema des Threads ... trotzdem wollte ich's zur Klarstellung hier mal dazugeschrieben haben. ;)

    Also, meine Meinung - auf jeden Fall mein Empfinden - ist, dass bei idealer Darstellung kein nennenswerter Unterschied zwischen 24fps und 25fps zu sehen ist. Außer wenn einem die Technik irgendwie einen Strich durch die Rechnung macht.

    Sind die Geräte einzeln an den Plasma-TV angeschlossen, oder über einen AVR? Weil, wenn einzeln, dann wäre evtl. denkbar dass die Einstellungen für die beiden Eingänge nicht identisch gewählt sind? Stichwort "IFR" bei Panasonic, die "Intelligent Frame Creation". Wenn da bei Eingang A was anderes eingestellt ist als bei Eingang B, dann ist auch das Ergebnis unterschiedlich.
    Unabhängig davon kann der Unterschied zwisch 24Hz und 25/50Hz Eingangssignal bei Plasma-TVs schon einen Unterschied ausmachen. Die übliche Allgemeinplatz "LCDs sind die bösen Sample+Hold-Displays die die schlimme Zwischenbildberechnung 'brauchen' ... Plasmas sind die guten 'Impuls'-Displays die sowas nicht nötig haben", der ist eben nicht so ganz richtig. Insbesondere bei den niedrigen Bildwiederholraten von "Film" sind Plasmas im wesentlichen eigentlich auch Sample+Hold Displays. (Kann ich auf Wunsch gerne mal ausführen, hab jetzt keine Zeit.) Wesentlich ist, dass ein Plasma einen Bildpunkt nicht einfach "pulst", und da ist er, und gut. Nein. Einen Plasmazelle kann im Prinzip nur einen Helligkeitswert darstellen (oder bestenfalls sehr wenige unterschiedliche Helligkeitswerte, vielleicht 4 oder max. 8). Daher muss jeder Bildpunkt mehrfach gpulst werden, um einen gewünschten Helligkeitswert "aufzubauen". (Etwa so wie man einen Nagel nicht BUMM mit einem Schlag einschlägt, sondern mit einer Srie kleinerer Schläge). - Und an diesem Punkt entsteht in der Folge ein nicht unwesentlicher Unterschied zwischen den verschiedenen Eingangsfrequenzen, weil mit unterschiedlicher Presentation Time für ein Bild eine jeweils unterschiedliche Anzahl von Impulsen zur Verfügung steht, um die Helligkeitswerte zusammenzubauen. Das ist alles andere als trivial, diese Internas der Bilddarstellung bei Plasmas sind eine ziemlich komplizierte Wissenschaft. Und Kenner der Materie haben schon vom tratidtionellen "50Hz Bug" bei Panasonic gehört - das allein ist schon ein Zeichen, dass das alles nicht so einfach ist.

    Lange Rede kurzer Sinn: vom Prinzip her macht 24Hz oder 25Hz keinen wesentlichen Unterschied in der Wahrnehmung. Aber dass die Technik z.B. des Anzeigegerätes für zusätzliche Unterschiede sorgt, das ist durchaus möglich.

    Für mich habe ich von 25 zu 24 teilweise schon unterschiede festgestellt


    Da melde ich mal Zweifel an. Natürlich sind 25fps -theoretisch- etwas "flüssiger" als 24fps. Tatsächlich ist der Unterschied aber so gering, dass man da mit dem nackten Auge praktisch keinen nennenswerten Unterschied feststellen kann.

    Zitat

    Es gibt bei "Der dunkle Kristall" eine Szene, in der zum ersten mal das Planetarium der Aughra gezeigt wird, bei der langsam mit einer Kamera darüber gefahren wird. Auf der DVD sieht dies wesentlich flüssiger aus...


    Wie wurde das überprüft? Speziell, welche Wiedergabe-Hardware und was für ein Anzeigegerät wurde verwendet? Und zu beiden gehört: mit jeweils welchen Einstellungen? - Weil, es ist natürlich essentiell, dass Wiedergabe und Anzeigegerät den Quell-FPS entsprechend optimal eingestellt sind. Wenn das Anzeigegerät z.B. einen Pulldown der 24fps auf 60fps durchführt, dann ist das natürlich nicht gut für die Wiedergabe. (Typisch für so manchen PC-Monitor, und ebenfalls häufig bei "etwas älteren" TV-Geräten.) Und auch bei externen Zuspielern wie BD-Playern muss man ggf. erst mal sicherstellen, dass die 24p-Option auch wirklich aktiviert ist, und nicht bereits der Player per Pulldown eine 60i-Ausgabe liefert.

    der fünfte hat im Namen schon so einen Beigeschmack ... und gaussian-Blur ist Holzhammer auf gesamtes Frame ... grins ... ich möchte doch Details "retten" und nicht mit dem rest zusammenmatschen


    Tja. Wenn man nur nach den Buzzwords geht ohne das Prinzip des Problems gut genug zu verstehen, dann kann man natürlich zu solchen Schlüssen kommen. ;)

    HQDering, BlindDeHalo, Dehalo_alpha, YAHR, mt_convolution, einfache prozentuale Wichtung eines Gaussian-Blur ... ein Füllhorn von möglichen Methoden. Und was genau gerade passt oder nicht passt, hängt davon ab wie die Sache genau aussieht. Aber, egal wie oder wo oder was .... VCD-Auflösung von 352x240 ist schon mal ein ganz schlechter Start.

    Von was für "29" ist eigentlich die Rede? Bei Filmen gibt's das ja eigentlich nicht. Geht's immernoch um Game-Captures?

    Wieauchimmer: bei einem Einsteiger-HD-TV ohne Zwischenbildberechnung sieht ein 30p-Stream schon merklich weniger ruckelig aus als ein 24p/25p Stream. Bei den besseren TVs -- mit Zwischenbildberechnung -- macht es kaum einen Unterschied. Bzw. es liegt am Benutzer, ob er die ZBB nutzt oder wie er sie einstellt.

    Sieh' an, wie sich das Bild gewandelt hat.

    Betreffs "TemporalDegrain": Also, "eigentlich" profitiert das Ding auch von MT. Das Problem ist hier die extreme Komplexität, verursacht durch die Verkettetung von MVTools-Anwendungen. Die treibt u.a. den Speicherbedarf sehr stark in die Höhe, verursacht Probleme mit Avisynth's internem Frame-caching (Strategie welche Bildinstanzen gecached werden müssen usw.), ...
    Insbesondere bei HD geht das dann ganz schnell in die Hose mit dem MT. Bei 1080p sowieso, und bei 720p wirds auch schon sehr eng ... manchmal kann man über Setmemorymax noch einen Sweetspot finden, aber eigentlich ist 720p schon zu viel. (Außer, vielleicht, bei gecropptem 2.35 Cinemascope.)

    Allein der Umstand, dass etwas durch MT langsamer wird, ist ein deutlicher Hinweis, dass die Komplexitätsgrenze überschritten wurde. Kannst ja mal mit SD-Videos gegenprüfen - bin mir ziemlich sicher, dass da TemporalDegrain ebenfalls durch MT schneller wird.

    Schneller Test mit nem 720x576 TV-capture: ohne MT 5 fps, mit MT (4 Threads) sinds 9 fps.

    vermute das Problem bei FineSharp ist, dass es halt nicht dafür gedacht ist auf HD Material zu laufen

    Nee, ne-neee. Das Problem ist einzig+allein DGSource. Das arbeitet sehr oft gar nicht gut mit MT-Scripten zusammen.

    Probier mal irgendwas mit ffvideosource, oder Mpeg2source(), oder Avisource. Das Gesamtbild in Deiner Tabelle wird sich grundlegend ändern. :)


    edit
    Ooooooder ... probier mal, direkt nach dgsource ein RequestLinear(rlim=50,clim=50) als Puffer zu setzen.
    DGsource mag es einfach nicht, wenn es Anforderungen von mehreren Downstream-Threads erfüllen muss ...

    Irgendwas scheint mir da komisch. Da sind so einige Sachen dabei, die definitiv von MT profitieren sollten, aber in der Liste steht "no" drin. :huh:

    Erzähl mal was über das Setup - Welche Version von Avisynth-MT, Art des Videomaterials, welcher Sourcefilter zum Laden, vollständiges Rahmenscript.


    edit:
    Also, z.B. FineSharp() wird bei mir schon mal mehr als doppelt so schnell, mit MTmode(2,4) : 63 --> 134 fps, oder Deblock_qed: 13 --> 36 fps, ....