Beiträge von Didée

Weder noch. Die Automaten-Analyse kann Fieldblending nicht erkennen. Wenn Fieldblending vorliegt, sind beide Vorschläge falsch.

Jo, an Srestore führt kaum ein Weg vorbei. Außer man nimmt RePAL. Macht am Ende aber sowieso kaum einen Unterschied.

Geschwindigkeit ist auch nicht sooo schlimm. Srestore in Vdub rendern lassen läuft hier knapp über Echtzeit (26~27 fps). Das Material sieht auch nicht so aus als bräuchte es unbedingt QTGMC oder sonstige Verkünstelungen ... die reelle Auflösung liegt wohl sowieso eher bei 720p.

1080p:

DGsource()changefps(last,last,true)bob(0,0.5)srestore(frate=25.000,speed=-1,dclip=bicubicresize(768,432))

720p:

DGsource()
changefps(last,last,true)
bicubicresize(1280,height(),-.4,.2)
bob(-.2,.2,height=720)
srestore(frate=25.000,speed=-1,dclip=bicubicresize(768,432))

Wieso "sieht komisch aus"? Ist doch nur 'ne ganz normale PAL->NTSC Fieldblending-Normkonvertierung.

Willkommen im HD-Zeitalter, wo alles nur noch auch kristallklarer Bildinformation besteht, "schärfer als die Realität", oder so ähnlich, leck' mich am ...

Zitat von hdst

Das kann sehr wohl sein, in #1 ist die Source aber 1080i50 (Level 4.0), welche nicht abspielbar sein soll.
Lt. Handbuch wird bei USB als Audio nur mp3 und LPCM angegeben. Kann sein, daß Videos mit AC3 oder AAC überhaupt nicht abgespielt werden.

AAC kann nicht des Pudels Kern sein. Ein anderes *.mp4 mit AAC wurde ja abgespielt.

Das 1080i50 aus Post#1 ist aber
a) ein *.m2ts Transport Stream (möglich dass der TV das sowieso nicht erkennt?),
und vor allem
b) ist diese Datei mit 5.8 GB ein wenig sehr groß, da ja anscheinend nur FAT32 Datenträger eingesetzt werden ....

Sicher sehen tu' ich aus Post#1 bis jetzt nur, dass ein Level 4.1 Video abgespielt wird, ein Level 4.2 Video aber nicht. (Wobei das 4.2 allerdings das Unikum mit der VFR ist...)

Oh, und die nicht funktionierende Datei ist auch noch Profile High. Die nicht funktionierenden Videos mal außenvor gelassen - die als abspielbar bekannten Videos scheinen alle nur Profile Main zu sein, da ist keines mit Profile High dabei.

Zitat von Rammer

Mit welchen (Konvertern, Presets usw.) bewältigst Du mit dem Samsung D6500 die Problematik? Jede Empfehlung wird gerne entgegengenommen, obwohl ich mittlerweile bald nicht mehr "durchblicke" oder sollte ich "aufgeben" da der TV ohnehin nicht geeignet ist?
Danke!

Mein D6500 macht überhaupt keine Probleme, weder mit irgendwelchen Smart-Internet-Geschichten, noch mit Smart-Media-Playback, noch mit sonstigem Smart-Babbalabaa.

Ich hab' da ein schönes HDMI-Kabel vom 3m entfernt stehenden PC zum TV gelegt, und somit kann mich das ganze "ich-kann-alles-aber-nichts-davon-richtig" mal kreuzweise.

Stand 2012: Meine Einstellung zu (herstellerunabhängig) ALLEN ach-ich-bin-ja-so-SMART TVs: --klick--

Zitat von hdst

Das Problem liegt so ziemlich eindeutig an der var. Bildrate und nicht am Level 4.2. Dieser Level ist bei 1080p50 erforderlich und entspricht dem Standard von AVCHD 2.0. Mit diesem Level arbeiten einige Camcorder. Wird von der Sony PS3 und etlichen moderneren BD-Player auch abgespielt.

Ein "Smart-TV" ist aber noch lange kein BR-Player oder PS3. Die MediaPlayer in den "Smart-TVs" sind oftmals deutlich schlanker ausgelegt. Es kann absolut sein, dass 1080p50 (Level 4.2) von einem TV (bzw. von dessen internem MediaPlayer) nicht unterstützt wird. Mein Samsung D6500 z.B. spielt selber auch keine 1080p50 ab, das ist zu schwere Kost für den kleinen Chip der da drin steckt.

Auch bedenken, dass der genannte Philips ein "Altmodell" ist, der ging im Frühjahr 2009 auf den Markt. Zu der Zeit waren die Funktionen in den TVs sowieso noch nicht so dicke.

... Und wer glaubt, dass "veryslow" oder "placebo" irgendwie langsam wären, der hat's offensichtlich noch nicht erlebt, wenn der Didée in Avisynth seine GANZ GROSSEN Universalprügel auspackt. :santa:

Zitat von kudo

Es gibt ja Methoden, die komplette Zwischenbilder berechnen können (z.B MFlowFps), währe es möglich die fehlenden Farbinformationen so zu berechnen?

Das hatte ich bereits vor zwei Monaten ausprobiert, als der Thread aktuell war. Und nein, das klappt leider nicht, sondern geht mächtig-gewaltig in die Hose.

Das 'Original' sieht schon ziemlich mau aus, und durch die verwendeten Entrausch-Filter wird's nur noch matschiger.

Interessant wäre, welche/r Rauschfilter zu Einsatz gekommen sind/ist. Es ist ja nicht so, dass man aus dem Pool von dutzenden verschiedenen Filtern einfach irgendwas rausgrabscht, und dann wird's schon irgendwie passen ...

Faustregel: die in One-Click-Konvertern angebotenen Rauschfilter sind zwar schnell, aber Qualitätsmäßig sind sie auch (fast) alle ziemlich Käse, die mehr oder weniger breit- und flach-matschen.
Für Hi-Quality Denoising kommt man an MVTools-Denoising eigentlich kaum vorbei. Sprich MDegrain1/2/3, idealerweise noch mit zusätzlichem Pre-Processing (Bewegungssuche), und ggf. noch mit zusätzlichem Inloop-/Post-Processing. Das ist natürlich vergleichsweise langsam, und bei Full-HD Videos erst recht und sowieso.
Entweder "Schnell + schlampig", oder "gut Ding will gut Weil haben". Dazwischen gibt's nicht so arg viel.

Und solange man kein "Bilder-in-Bewegung" vom Original - ohne erneute re-Komprimierung - gesehen hat, kann man auch kaum spezielle Empfehlungen aussprechen.

- edit -

Tja. Wenn man die Bülders auf 40% runter- und dann wieder hochskaliert, dann ändert sich an der Erscheinung nur sehr wenig, da entsteht kaum ein nennenswerter Verlust. Da könnte schon der Verdacht aufkommen dass es sich um ein "Upscale" handelt.
'Runtergehen auf 720p (1280*xxx, entsprechend dem Seitenverhältnis), da könnte noch was einigermaßen brauchbares 'rauskommen.

Oder sagen "LMAA", und lassen wie's ist. Das macht am wenigsten (unnötige) Arbeit.

Solange ein Filter potentiell irgend etwas am Bild ändert, gibt es keine "universelle Unbedenklichkeitserklärung".

LigH, da haste den Nagel gut auf den Kopf getroffen.:) - Mit blklsize/blocksize hab ich mich ganz einfach verschrieben (MVTools-intern/vs/Script-Parameter), und überhaupt hab ich das alles mit TGMC durchexerziert, nicht mit QTGMC. (TGMC ist übersichtlich, da kann ich systemische Änderungen 'reinschreiben wie ichs gerade will oder brauche. QTGMC ist mir dafür viel zu komplex und verstrickt.) Na, jedenfalls hab ich den Parameteraufruf dann von TGMC zu QTGMC hinüber"geraten" - und bis zur v3.11 von QTGMC hätte das auch funktioniert, da war der "preset"-Parameter noch nachgestellt. Nur bei der aktuellen Version ist der "Preset"-Parameter inzwischen führend angegeben, da funktioniert's nicht mehr.

Wie auch immer - dieses schleichend umschlagende Aliasing kriegt man bei diesem Video nicht weg. Zum einen ist es ein Worstcase-Beispiel für den Fall, wo die Methode versagen MUSS: normalerweise lassen sich die fehlenden Scanlines für ein Feld->Frame ja aus den Nachbarfeldern herholen. Aber wenn der Vertikalanteil der Bewegungsgeschwindigkeit ein ganz bestimmtes Maß hat, dann ist dort, wo man die Info herholen möchte, ganz einfach "nichts vorhanden". Und wenn die Geschwindigkeit nicht genau das kritische Maß hat, sondern nur nahe dran liegt, dann bekommt man zwangsweise dieses langsame Umschlagen an horizontalen Kanten.
Zum anderen kommt noch erschwerend hinzu, dass das Interlacing des Videos ohne Lowpass-Filter des progressiven Eingangsmaterials erstellt wurde. Das ist zwar schön hinsichtlich der Bildschärfe, aber das Problem zeigt nun, warum ein Lowpass-Filter normalerweise verwendet werden sollte. Wäre er verwendet worden, dann wäre das Aliasing-Problem sehr, sehr viel kleiner.

Was ich probiert hatte, war, den MVTools-Anteil des Deinterlacers auf einen *sehr* großen temporalen Radius umzustellen (wenn die Info in den direkten Nachbarfeldern nicht drinsteckt, kann man sie vielleicht aus den +-10 ... +-20 entfernten Nachbarn gewinnen). Aber das hat nicht funktioniert. Man bräuchte für jedes Pixel einen individuellen temporalen Radius, abhängig von der jeweils individuellen Bewegungsgeschwindigkeit. Das ist theoretisch nachvollziehbar, ist aber in der Praxis fast unmöglich zu realisieren.
_____

Wie ist das jetzt eigentlich mit der Regenbogen-Entfernung? Mir gefällt der vorgeschlagene Einzeilen-Trick bei diesem Video nämlich richtig gut ...

Jajaa... denke mal dass es schon um dieses langsam wandernde Aliasing geht. Leider wird sich das bei Szenen wie dieser kaum vermeiden lassen. Das ist die "Resonanz mit dem Schwarzen Loch", wenn Bewegung mit einer Vertikal-Geschwindigkeit nahe bei 1Pixel/Sekunde stattfindet.
Muss heute abend mal noch etwas probieren (was der alte Bürorechner hier nicht schaffen würde ohne zu durchschmelzen), aber allzu großer Optimismus ist da nicht angebracht.

Was das Chroma-Rainbowing angeht: Schmeiß' mal den GuavaComb weg, und alle anderen Ratschläge auch, und probier' dieses hier:

mpeg2source(...)


MergeChroma( SeparateFields().blur(0,1).Weave() )  #   " Hokus, Pokus, Regenbogen verschwindibus! "


QTGMC(1,1,3,rep0=0,rep1=0,rep2=0,edimode="NNEDI3",blksize=16,overlap=8,border=true,NNsize=3,NNeurons=3)

Üpsala.

Um nochmal auf Post#16 zurückzukommen:

Zitat von hdst

Bei Kameraschwenks treten gelegentlich störende Schlieren auf, die auch QTGMC nicht reduziert. Das fällt vornehmlich bei Fenstern und Treppen auf.
http://www.file-upload.net/download-66951…reppen.m2v.html
Für einen Filtervorschlag wäre ich sehr dankbar.

Was genau meinst Du hier mit "Schlieren"? Ist hier auch das Chroma-Rainbowing gemeint? Oder vielleicht so ein langsamer "Wobbel" an horizontalen Kanten/Strukturen?

Samstag, knapp nach Mittag. Will den Rechner einschalten - mit Betätigen des Power-Knopfes geht die Musik aus. Oha! Sicherungkasten ... jaaa, Sicherung ist 'raus. Oh-oh, das sollte nicht sein ...

... Netzteil gibt keinen Mucks mehr von sich. Vermutlich hat der Safeguard ausgelöst (Enermax Modu87+).

Geht morgen früh zur RMA. Der sehr freundliche Herr an der Hotline meinte auf Nachfrage, dass das bis zwei Wochen dauern könnte ... :hm:

... und weil kein adäquater Ersatz zur Hand ist, bleibt die nagende Ungewissheit, WARUM das Ding durchgegangen ist. Nur ein Netzteil-interner Fehler? Oder hat es ausgelöst, weil etwas anderes kaputt ist ... ?

Die Blockgröße 32 wurde fehlerhaft implementiert, und (soweit ich weiß) niemals korrigiert, zumindest nicht in der offiziellen Version. Aber, für SD-Auflösung wäre 32 eh zu groß, da ist 16 groß genug.

Das Degraining schneller machen heißt auch, das Ergebnis schlechter zu machen. Qualität und Geschwindigkeit sind Antagonisten. War schon immer so.

Für die CGI-Sequenzen ist Fieldmatching (TFM) natürlich schlicht+einfach die falsche Operation. QTGMC im Prinzip eigentlich auch, aber durch die temporalfilterung erreicht er vrmtl. eine Verblendwurstelung von Gut+Böse, was im Endeffekt nicht die schlechteste Variante sein muss.

Es hilft aber alles nichts - es git keine verlässliche Möglichkeit, ein Script automatisch alle Fälle richtig zu erkennen und behandeln zu lassen. Fieldmatching taugt nicht für die CGI-Sequenzen, und QTGMC taugt nicht für die Film-Sequenzen. Automatisierte Unterscheidung zwischen Interlaced(progressive Phase-Shift) und Interlaced(Fieldblended) ist schwierig. Man müsste hergehen, und jede Folge von Hand sezieren, um die CGI-Sequenzen separat zu behandeln. Viel Arbeit. Oder man akzeptiert einfach, dass die CGI-Teile noch mehr verhunzt werden als sie's eh schon sind.

Es hat schon seinen Grund, dass 'mein' Projekt nach all den Jahren noch immer bei Null Prozent steht. :hm:

Au weia, das Material ist ja noch schlimmer. Fast durchgängig ist jedes 2. Feld mit dem Vorgänger überblendet. Aber keine Normkonvertierung, sondern "einfach nur so". Außer bei Sample#3 - die erste Hälfte mit Überblendung, die zweite Hälfte ist clean. Und das innerhalb einer einzigen Szene, ohne Schnitt. :eek:

Check' mal ob nur der Pilot so aussieht. Wenn's bei der Hauptserie genauso ist, dann machen sich die DVD-Boxen hübsch im Regal, zur Präsentation. Aber zum Abspielen auf'm TV taugt's nicht wirklich ...

Gerade mal die Samples angeschaut ... Huch! Ist das Die Pilotfolge "Die Zusammenkunft"? De'Lenn sieht so herb aus, und G'Kar auch irgendwie anders. Die Masken waren ja im Pilot etwas anders als später in der Hauptserie. (Den Pilot habe ich nämlich nicht auf DVD.)

Vor allem wunder' ich mich aber gerade über das 4:3 Seitenverhältnis. Ich weiß noch dass die ursprüngliche Fernsehausstrahlung der Serie in 4:3 erfolgte. Die DVD-Boxen die ich habe - jeweils kurz nach Erstveröffentlichung - sind aber in 16:9 gemastert, nicht in 4:3. (Obwohl sie das auch vermurkst haben - das 720x576 Material ist zwar als 16:9 geflaggt, mein Augenmaß sagt aber dass das falsch ist, und eigentlich 1.6 bzw 1.666 sein sollte. Nicht 1.777.)

Nö, gibbed nich'. Kein Budget. Straczynski war sich während der vorletzten (5.) Staffel nicht mal sicher ober er die letzte (6.) Staffel überhaupt noch drehen können würde. Deswegen wurde die Folge "In Hundert Jahren, in Tausend Jahren" - die Straczynski als 'Ende' der Serie UN-BE-DINGT veröffentlicht haben wollte - vorsichtshalber schon am Ende von Staffel 5 angehängt. Dadurch dass die 6. Staffel doch noch zustande kam, steht "in 100, in 1000" jetzt leider ein wenig deplaziert im Raum. Von der erzwungenen Abkürzung und Umstruktierung der Handlungsstränge ganz zu schweigen. (Bei B5 war der Plot eigentlich von vornherein von der aller-ersten bis zur aller-letzten Folge bei Serienstart bereits komplett vorgearbeitet. Im Gegensatz zu heute, wo man einfach mal mit 'ner halben Staffel anfängt, und dann "mal sehen wie weit wir kommen, bevor wir abgesetzt werden. Wenn's laufen sollte, dann denken wir uns halt irgendwas aus...")

Die Plugins waren doch als Hilfe für Nel-son gedacht. Und außerdem für mein richtiges Script. Nicht für Dein falsches. :zunge:

Babylon5 ? Man hat mich gerufen?

Bei der Serie ist fast alles dabei. Die Filmsequenzen sind überwiegend rein progressiv. Desöfteren mal sind Szenen Progressiv Phase-Shifted (insbesondere immer der Serien-Vor-/Zwischenspann, andere Szenen ab und zu mal.) Wesentlich seltener, aber auch immer wieder mal sind Szenen die Phase-Shifted sind nur in halber Auflösung vorhanden, d.h. nach Fieldmatching sieht man dass man eigentlich nur ein Field-Doubling hat, also halbe vertikale Auflösung.

Ach ja, und die CGI-Sequenzen. Die sind mit Fieldblending normkonvertiert, im Original waren die vermutlich 30i/p. Macht Freude. :):)

Universalprügel: "TFM(pp=0).blur(0,1)"

Wer's ordentlich machen will, muss viel Zeit investieren. Ich meine, SEHR viel Zeit.

(Ich hatte auch mal den Plan, Babylon5 aufzumöbeln. Inzwischen sind zehn Jahre ins Land gegangen, und die Durchführung des Plans liegt aktuell bei Null Prozent.)