Posts by Didée

Ich hätte da mal eine Frage aus dem Dunstkreis ffmpeg/libAV/LAV und "PAL Quelle" ... es gehört nicht wirklich in diesen Thread, aber hier gibt's vielleicht Leute die etwas wissen. - Beitrag darf gerne verschoben werden wenn's so besser sein sollte.

Kennt jemand das Problem: es gibt so unzälig viele der sog. "One-Klick-Converter", die allesamt auf den ffmpeg/libAV Bibliotheken basieren. Hat man nun einen PAL 25/50Hz Input, lässt diesen ggf. noch deinerlacen und dann ein *.mp4 erstellen, dann bekommt man in den meisten Fällen kein 25 oder 50Hz Ergebnis, sondern entweder 29.97 oder 23.976 fps. Oder noch seltsamere Framerates die leicht von diesen abweichen, und das Ergebnis ruckelt mehr oder weniger schlimm.

Ich hab' früher immer alles von Hand gemacht (DGsource > Avisynth > x264, Muxen mit MKVmerge). Dann hab ich's mal mit den One-Click-Dingern probiert, hab' graue Haare bekommen und den Glauben an die Welt verloren, und weiterhin alles von Hand gemacht. Ob's Hybrid richtig macht weiß ich gar nicht (aber ich hoffe doch mal schwer, dass!), es ist wohl auch schon >10 Jahre her dass ich Hybrid zuletzt benutzt habe ...

Jedenfalls: ganz grundsätzlich, kennt jemand das Problem über das ich hier jammere? Mich hat das wie gesagt schon vor >10 Jahren vergrault, und wenn ich mich heute in anderen Foren umschaue in denen ganz viele Videos von TV-Aufnahmen gepostet werden, dann sind die immer noch fast alle genau so vermurkst.

Nö, falsch ... es ist nicht so, dass ich "auf euch" keinen Bock mehr hätte. Es haben sich nur die Prioritäten verlagert, und ich mache jetzt viele andere Sachen, nur noch gaaanz wenig Videobearbeitung, eigentlich fast gar nicht mehr. Aus der Zeit gefallen bin ich ja auch, mit Stand Avisynth 2.6, Avisynth+ noch nie probiert, und mit diesem VapourSynth will ich gar nicht erst anfangen.

Fragt doch auch mal nach den vielen anderen! z.B. scharfis_brain ist auch mal sang- und klanglos verschwunden, wie schade. MoMonster hat den Geniestreich mit SRestore gemacht - den zentralen ScriptClip-Code hat wohl bis heute noch niemand kapiert - aber ich fürchte im Verlauf dieses Projekts ist irgendwas bei ihm durchgeknallt, und weg war er (das Durchknallen wäre mir mit Restore24 auch fast passiert, und das war nicht mal halb so gut wie SRestore). Und so viele andere Größen aus der alten Zeit, man käme ja mit Aufzählen gar nicht hinterher.

Aber ich schmunzle immer noch regelmäßig über den ehemaligen Avisynth-Core-Programmierer IanB, mit seinem "close, but no cigar", und "give the user just enough rope to hang himself".

Quote

https://localhost/www.infognition.com

Quote

Wie müsste ein Typisches Scrypt (SetMTmode) usw. aussehen damit es läuft?

Gar nicht, bzw., vergiss es einfach.

Dieser "High-Resolution" Filter ist i.d.Praxis ziemlich nahe bei "Schlangenöl".

Für Upscaling im Zweifelsfall einfach die NNEDI3.dll nehmen (Filter NNEDI3_rpow2() ), das funktioniert problemlos, und liefert mindestens genau so gute, in der Regel bessere Ergebnisse.

Mir ist es eigentlich wurscht, welcher Player oder welcher Renderer dieses oder jenes macht. Ich wüsste jetzt noch nicht mal auswendig, welche Renderer wie arbeiten (betreffs der YUV->RGB Konvertierung), und wo man aufpassen muss und wo nicht. Bei mir sind die Player so konfiguriert dass ffdshow zum dekodieren verwendet wird, die Ausgabe wird auf RGB erzwungen, und die Matrix-Ausgabe steht auf "Auto". Damit hab ich keine Probleme mit, äh, "Zufallsergebnissen", sondern es wird einfach immer "richtig" gemacht.

(VLC verwende ich sowieso nie ... hat der überhaupt schon mal irgendwas richtig gemacht?) 

Quote

Vielleicht kann hier einer von euch mal eure Hardware Player daraufhin testen. Würde mich ml interessieren ob da meiner die Ausnahme oder die Regel ist.

Das muss jemand anders machen, mein Hardware-Player IST der PC.

Im Zweifelsfall wäre es natürlich hilfreich, wenn die korrekten Matrix-Einstellungen und Color-Primaries bereits beim Encodieren auch in das Video hineingeschrieben würden. So ist es nämlich richtig, aber bei vielen Eigen-Encodings wird das typischerweise nicht gemacht. Sind die Transfer-Charakteristiken eingetragen, dann "weiß" der Player, wie es richtig ist. Sind sie nicht eingetragen, dann gibt es streng genommen kein richtig oder falsch ... es ist zwar naheliegend, dass HD-Quellen mit Rec.709 kodiert sind, und deswegen ist es günstig, dieses im Zweifelsfall einfach anzunehmen. Aber ein absolutes "Muss" ist das natürlich nicht. Wenn keine Transfercharakteristiken im Video drinstehen, dann ist der Zustand höchst offiziell "undefiniert".

Quote from trecordings

Ich sehe in der Vorschau was ich Enkodiere und was ich auf allen Playern und geräten auch sehe.

Zurück auf Anfang: Wenn die Quelle HD/Rec.709 ist, dann ist das, was Du in der Vorschau siehst, bereits falsch.

Wenn Du also beim Playback das gleiche siehst wie in der Vorschau, dann konvertieren deine Player ebenfalls falsch.

Quote

Also mit dem VLC sind die beiden NICHT gleich. Bilder mit VLC erstellt.
Auch auf meinem Patriot Box Office player (Realtek) und Röhre sind die farben nicht gleich. Ebenfalls nicht mit VLC. Nicht mit MPC-HC und EVR-cp. Und nicht mit Staxrip.

Du lieferst selber die Bestätigung. Wenn ein Player sich "richtig" verhält, dann müssen die beiden Videos nämlich genau die gleiche Farbe zeigen. Zeigen sie hingegen unterschiedliche Farben, dann macht der Player es eben nicht richtig. (D.h. Rec.709 wird fälschlich mit Rec.601 Matrix zu RGB konvertiert.)

Große Philosophie: Ist das Quellmaterial Murks, [dann] ist das Quellmaterial Murks.

imagesource("batb_ivtc.tif")
converttoyv12()
[B]separatefields().vinverse().weave().vinverse()[/B]

[Blocked Image: http://thumbnails104.imagebam.com/27961/2a7d5e279609486.jpg]

Dass man vinverse erst auf die separierten Felder anzuwenden hat ist zwar nicht der Normalfall, aber bei manchem Quellmaterial ist es nun mal so, dass "2 Pixel hohe" Streifen nach dem IVTC drin sind. Warum auch immer, aber die Frage ist müßig ... wenn es in einem Fall so ist, dann ist es eben so.

Vinverse.dll

Zeig' doch bitte noch ein Beispiel, wie diese 'Linien' im Endergebnis genau aussehen. Nach IVTC kann durchaus ein rest-Aliasing übrigbleiben, in dem Fall ist es oft gut, wenn man etwa den Vinverse()-Filter dem IVTC hinterherschießt.
Inhalt des avs-Scripts bitte auch posten, nur um sicher zu sein, dass nichts anderes versehentlich übersehen wird.

Quote from may24

und festgestellt das bei "sehr starkem Rauschen" Blocking Artefakte entstehen. Also besser da nicht verwenden

Overlap auf halbe Blockgröße setzen, dann gibt's auch keine Blockartefakte. Und bei "sehr starkem" Rauschen die Blockgröße auf 16, Default 8 ist zu klein. (Bei HD wäre evtl. sogar Blockgröße 32 angebracht, aber das ist leider etwas buggy.) - Einerlei, bei wirklich "sehr starkem" Rauschen muss man im allgemeinen einen Pre-Filter für die Bewegungssuche anzuwenden. Sonst sucht die Engine mehr nach der Bewegung des Rauschens anstatt der Bewegung von Objekten, und die Block-SADs gehen auch durch die Decke, was die Beurteilung zwischen "guter" und "schlechter" Kompensation sehr ungünstig verschleiert.

Quote

Ja, nur das Avisynth MT alles andere als stabil läuft (bei mir - Win7 63bit).

Hmja ... dass das unter 63bit nicht stabil läuft, das ist durchaus denkbar. :zunge:

Ich meine: wenn ich nicht einen Zwischenzustand zwischen Frame A und Frame B erzeugen will, sondern einfach nur Frame A auf Frame B bewegungskompensieren will, dann nehme ich nicht MFlow, sondern MCompensate.

Überhaupt würde ich vrmtl. hergehen, einen kompensierten temporal-Median nehmen, spatial punktmuster aussieben. DeSpot hat mir zuviele Parameter, das ist zu kompliziert für mich.:) - Bis ich da ausprobiert und verstanden habe was wie arbeitet und welche Auswirkungen hat, wäre ich mit der zu-Fuß-Lösung wahrscheinlich schneller fertig.

Wieso eigentlich Motion-Tresholds, wenn doch sowieso schon Motion"compensation" durchgeführt wurde ...

Wieso eigentlich MFlow, wenn man doch eine Kompensation haben will, und keine Interpolation ...

Nö, das passt schon, wenn der Input bereits 50p ist. Man könnte erwägen, ob man vor dem Interlacing noch einen vertikalen Lowpass-Filter setzt (wg. Zeilenflimmern etc.), aber bobben oder um-eine-halbe-Zeile-erschieben muss man bei 50p Input ganz sicher nicht.

Ich ergänze mal frisch von der Leber weg:

Quote from Erhy

Diese MP4's sind auch bei bewegten Objekten von guter Qualität. und werden auf einem PC-Monitor angeschaut

eine Video-DVD erstellt....
Die erzeugten Videos zeigen aber leichte Bewegungsunschärfen. wenn sie auf einem LCD-Fernseher angeschaut werden

Falls ich mich täuschen sollte: einfach drauflos schimpfen.

Gute Frage ... weiß gar nimmer, ob ich die Variante mit verkettetem Aufruf und stdout.wav auch probiert hatte. Weil, wenn man nach 2 Stunden nur 10 BSODs auf der Rechnung hat, aber immer noch kein Ergebnis, dann drehste nur noch am Rad, und wünscht Dir HeadAC3He zurück ...

Komplett manuell über WAV hab ich auch nicht hingekriegt, soviel weiß ich noch. Falsche Bittiefe / falsche Endian-ness (keine Ahnung, das Ergebnis war BZZZZRRSCHSCHSCHRRRSCHSCHSCH), zu kurzes Ergebnis ohne -ignorelength, zu langes Ergebnis mit -ignorelength ... das waren zwei weitere Stunden ohne ein Ergebnis, und dann war ich an dem Punkt "LECK MICH AM AAAAAAA..."
==> "dann drehste nur noch am Rad, und wünscht Dir HeadAC3He zurück ..."

Inzwischen hab ich die Faxen dicke, reiß' den Kram mit --no2ndpass 'runter (schei** auf die paar Clippings), und zerbrech mir den Kopf stattdessen über andere Sachen.

Quote from sneaker2

Bleibt nur, von eac3to auf einen externen Encoder zu pipen, sei es NeroAacEnc, Fraunhofer oder qaac...

Das macht er ja schon. eac3to piped die Daten zu NeroAACenc.

Quote from Selur

Kann es sein, das NeroAACEnc probleme hat Dateien > 2GB zu schreiben? (Hab noch nie versucht so eine großes File zu erstellen)

Da ist der Murks schon längst passiert, die erstellte aac würde mit q 0.3 sowieso niemals so groß werden. Die Logs "Processed XXX seconds" tauchen erst auf, nachdem der Encoder sich festgefressen hat.

____

Ich kenn' das Problem, steh' aber auch völlig ratlos auf dem Schlauch.
Was mir aufgefallen ist:
- sehr, sehr häufig bei AC3-Audio
- einigermaßen häufig bei DTS, wenn 2-pass Normalisierung verwendet wird
- sehr selten (bei DTS), wenn keine 2-pass Normalisierung verwendet wird [--no2ndpass]

Außerdem:
- Mit der älteren v3.24 von eac3to hatte ich es, wenn, dann immer nur mit Fehlermeldungen/Abbrüchen zu tun.
- Bei v0.26/0.27 gibt es mit Glück eine Fehlermeldung ... desöfteren schmiert die Kiste aber auch komplett mit BSOD ab. :mad:

Letztlich kann Dir die Entscheidung niemand abnehmen, zu irgend etwas musst Du Dich durchringen.

Einfaches Frameskipping würde ich nach Möglichkeit auf jeden Fall vermeiden - bei Kameraschwenks mittlerer Geschwindigkeit sieht man die Skips fast immer. Nicht schön.
Sobald man MVTolls-Tralala dazunimmt, müsste/sollte man sich auch gleich um das Problem der Scenechanges kümmern und kontrollieren, dass die auch wirklich gut erwischt werden.

Wie gesagt - solange nichts anderes ausdrücklich dagegen spricht, Methode b). Macht am wenigsten Arbeit, und es kann am wenigsten schief laufen.

Solange Audio-mäßig nichts gegen ein reencoding spricht, würde ich Methode b. eindeutig für am schmerzfreiesten befinden.

Sollte ein strobing-judder Problem störend bemerkbar werden (weil 1/50s belichtete Frames als 24p dagestellt werden), dann könnte man den fehlenden Motionblur per MVTools-Interpolation dazurechnen. (Würde ich aber ebenfalls auf Basis eines 25>24 Slowdowns machen [wenn ok mit Audio], weil weniger Probleme mit Artefakten.)

Eine laufzeitidentische Umrechnung würde ich nur machen, wenn Audio der hauptkritische Bestandteil ist (Musikvideo, Konzert, o.ä.)

Der ursprüngliche Ansatz ist okay ... bis auf zwei Dinge:

- Threshold=0 für Ydifference ist i.d.Praxis vermutlich zu klein, bei Mpeg2-Codierung sind die Dup-Frames vermutlich nicht völlig identisch. Überprüfen und den Threshold ggf. etwas größer wählen.
- Es ist keine so tolle Idee, den Komplex aus SuperClip-Erstellung + Bewegungssuche innerhalb des Conditionalfilter anzulegen. Die komplette Conditional-Environment wird doch irgendwie bei jedem Frame neu initalisiert.
Besser ist's, den Clip mit neu-errechneten Frames komplett extern außerhalb der Conditional-Enironment zu erstellen, und dann im ConditionalFilter eben nur noch darauf zuzugreifen.

In etwa

mpeg2source("vts_01_1.d2v")
o = last
flowed = interleave( o.selecteven().fflow(), 
 \                   o.selectodd() .fflow()  ).selectevery(4,-1,2)


ConditionalFilter(o, o, flowed, "YDifferenceFromPrevious()", "greaterthan", "0.12345", true)
return(last)


#--------------------------
function fflow(clip c) {
sup   = c.msuper(pel=1)
bv    = sup.manalyse(isb=true)
fv    = sup.manalyse(isb=false)
c.mflowfps(sup,bv,fv,num=0)
return(last) }

Die MVTools-Parameter in der "fflow()" -Deklarierung dürfen natürlich nach belieben erweitert & verfeinert werden.

Interessant. Das ist ein Fall, in dem sich gar nichts tun lässt. Besonders deutlich zu sehen bei zB. Sekunde 8~9 : jedes Bild ist ein Blend mit dem Nachfolger ... AB BC CD DE EF usw.

Klappe zu, Affe tot, Fall geschlossen.

Quote from may24

Nur was ist das wenn solche Blends praktisch in (fast) jedem Bild vorkommen ?

Na, ... Wenn Blends in fast jedem Bild vorkommen, dann ist das etwas völlig anderes als

Quote from may24

Blends tauchen nach folgendem Muster auf:

p p p b b p p p b b p p p b b ...

Bei Normkonvertierungen gibt noch den Fall, dass eine "gleitende" Framrate-Conversion à la "ConvertFPS()" gemacht wurde - für diesen Fall ist "RestoreFPS" (von mg262 / Clouded) vorgesehen, das kann oftmals die Sache zurückrechnen, mit ein wenig manuellem Try-and-error.

Die Frage ist, in jedem Fall aufs Neue, wie bzw. warum Blendings da sind. Lösungen gibt es viele, aber man muss halt zusehen, dass man auch die Lösung erwischt, die zum aktuellen Problem passt.
- (Und da kann's einem gehen wie beim Pilzesammeln: Die Unterscheidung zwischen einem rötlichen Bläuling und einem bläulichen Rötling ist nicht immer einfach.)

Dieses Pattern tritt auf, wenn ein 30i Video mit 3:2 Pulldown fälschlich "deinterlaced" wurde (Verschmelzung von Top- und Bottom-Fields)

FixBlendIVTC()
TDecimate()

oder

Srestore(omode="pp3")
TDecimate()