[Sammelthread] ffdshow/avisynth - Videopostprocessing in Echtzeit... Teil 1

Status
Für weitere Antworten geschlossen.
@ Alexirsi

Ist eben bescheidene Ursprungsquali, wenn da es die Sendeanstalt schon verkakckt....so sieht die Szene ursprünglich aus :



und hier nochmal die beiden mit nachbearbeitung :





Da es HDR noch nicht auf Blu-ray gibt denke ich dass die HDTV Sender nen DVD Upscale ausstrahlen.

läuft bei mir. evtl. gehen nur echte blurays nicht?

Aha, cool, kannst ja mal ein paar Vergleichsscreenshots machen damit man zb. den Unterschied zum EVR sieht, na was meinste :d ?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich poste eigentlich nur jpeg´s, sieht eh nicht 100% so aus wie aufm Screen da die Bilder meistens pausiert gescreent worden sind, da geht nochmal etwas schärfe verloren.

Die Screenshots mach ich mit strg - entf. und füge sie dann in Paint ein, eben simpelst.
 
Zuletzt bearbeitet:
Da sollte keine XML drinne sein.

Sonst weiss ich auch nicht was du falsch machst, bei den anderen hat es ja auch geklappt siehe schockwave.

Hast du überhaupt die ganzen anderen Plugins installiert die man so braucht ( Anleitungen Thread ) ?



Resizing in FFD Show reicht eigentlich, der vorteil der Avisynth Resizer ist minimal. Für Leute die nur Resizen evtl. sinnvoll.

hab das problem wohl ... mein avisynth stammt ursprünglich ausm gordianknot-paket. Da wurde dann auch irgendwoe ein ZWEITER Plugin-Ordner angelegt - da kam alles rein ... fast alles :(

Hab der einfachheithalber jetzt beide Plugin-Ordner aufs gleiche Level gebracht ;) Später mal schauen wie ich Avisynth so installiert bekommen das es auf bei gordianknot mit einem ordner auskommt ;)

An welcher Stelle wird den mit welchen stellen dann der ffdshow-resive aktiviert? Vor oder Nach Avisynth? Gauss? Spline?

Der Thread wird langsam unübersichtlich was die scripte/tips usw. angeht ;)

Gruß
 
@ wulfman

Hier siehst du die Reihenfolge etc. unten auf den Screenshots http://www.hardwareluxx.de/community/showpost.php?p=11383594&postcount=2

Beim Resize klickst du dann im Fixieren Feld und wählst unten auch Spline aus, nicht Lanczos so wie auf dem bild zu sehen, sollten beide gleich sein. Gauss macht am meisten Sinn bei low res Material da es nicht zu Ringing führt, bei besserem Material ist wiederum Spline besser.

was die Scipts angeht werde ich den Post dann bald updaten, hab nur noch nicht genug Feedback was die Fluxsmooth Scripts angeht bzw. auf welchen Rechnern es optimal läuft.
 
Die Screenshots mach ich mit strg - entf. und füge sie dann in Paint ein, eben simpelst.

du speicherst sie hoffentlich nicht auch mit paint ab? das komprimiert ziemlich schlecht, nimm lieber irfanview und speicher es da mit geringer kompression. meine folgenden bilder sind mit 95% gespeichert.

Aha, cool, kannst ja mal ein paar Vergleichsscreenshots machen damit man zb. den Unterschied zum EVR sieht, na was meinste :d ?

hab einen kleinen vergleich der verschiedenen renderer gemacht - haali renderer lässt sich leider nicht screenshotten.

EVR Standard


EVR Custom Bicubic A=-0.6


EVR Custom Bicubic A=-1.0


madVR Lanczos8


madVR Spline64


VMR9 Bicubic A=0,75


zum Vergleich nochmal VMR9 Bicubic A=-0.75 mit Paint gespeichert.


generell bis auf die helleren farben / höheren kontrast beim madVR kein wirklicher unterschied.
lediglich der normale EVR sieht ziemlich unscharf aus, beim EVR Custom sieht man zwischen -1 und -0,6 einen gewissen schärfeunterschied.

ansonsten muss man auch drauf achten je nach renderer bei CoreAVC verschiedene input-levels zu verwenden. die einstellungen bei FFDShow sowie ob BT.601 oder 709 macht garkeinen unterschied!?
 
Zuletzt bearbeitet:
Danke für die Pics, ja man sieht schon Farbunterschiede zwischen den Renderern, madVR übersättigt etwas bei den Einstellungen, sonst sehe ich schärfemäßig auch keinen Unterschied.

Dankee für den Tipp mit Irfanview, werde ich mich mal mit beschäftigen :)

Hab noch eine Bitte, und zwar möchte ich von euch wissen welches Pic der folgenden 2 für euch in Sachen Farben natürlicher aussieht, und möchte auch gerne wissen warum.

Thx

Bild 1



Bild 2

 
finde das zweite besser, das erste hat für mein empfinden einen gelbstich.

ist das zweite die gleiche quelle wie das erste, nur mit LSFmod behandelt? wenn ja finde ich es in diesem fall richtig gut gelungen...
 
Ja das ist beides 720p. Bild 2 ist mit dem Fluxsmooth script ohne LSFmod entstanden, dazu noch ein paar Farb Gamma Tweaks im Bildeigenschaften Tab.

bildeigenschaftensetti8lny.jpg


Bild 1 ist ohne jegliche Bearbeitung so wie es von Core AVC ausgegeben wird ;)
 
Zuletzt bearbeitet:
The ffdshow gray background is *not* caused by incorrect settings (like output levels), I've double checked that. The gray background must originate from calculation errors in the scaling algorithm (lanczos, default settings).

Aus dem madVR Thread bei doom9.
Wenn ich das richtig verstehe, ist das der Grund warum bei ffdshow Upsclaing schwarz immer grau ist. Ich steig jetzt auf madVR um, Cuda ist sowieso am schönsten!
 
Zuletzt bearbeitet:
Bei mir ändert sich an der Schwarzdarstellung durch Scaling nix, es sind eher die Rottöne die bei scaling korrigiert werden müssen ;)

Ich kann nur jedem empfehlen Core AVC bei HD vor FFD Show zu schalten, dann bleibt schwarz auch schwarz und nicht wie grau zb. wenn man nur FFD Show als Decoder für HD verwendet :)
 
SetMemoryMax(1024)
MT("
a = last
b = FluxSmoothT
SeeSaw(a, b, NRlimit=2, NRlimit2=1,Spower=2, Sdamplo=8)
SPresso(bias=25, biasC=25)
LSFmod
",5)

bei mir stand gestern mal wieder an nen mpeg2 zu nem xvid zu encoden. Hab mal aus spass dieses script genommen (dazu noch crop vor und resize (blackman) nach dem scriptfetzen ... ist dort irgendwo eine max. Anzahl Frames definiert? Ich hatte fast durchgängig 50fps - 49-51 mal geschwankt - aber sonst sehr fix. Fand ich bissel komisch - das ich hier keien 120fps erreiche wie bei normalen scripten ist klar - aber so fix 50fps fand ich doch komisch - selbst die 120fps schwanken teils extrem - je nach Bild was gerade dran ist mal 70 aber auch mal 150fps ....

Gruß
Wulfman

PS: quelle war ZDF - Ergebniss des encodings war recht gut
 
Aha, interessant, hab mich selbst noch nicht viel mit Encoding beschäftigt, von daher hab ich recht wenig Ahnung davon...

Was die CPU Auslastung angeht, die ist bei mir mit diesem Script konstanter als mit den anderen, schwankt nur höchstens 10%, bei den anderen sind es oft über 20% Unterschied.
 
verstehe ich auch nicht so richtig.
welcher teil im skript ändert denn überhaupt die anzahl der frames?

@screenshots:
soweit ich weiss wird bei der jpeg komprimierung immer auf YCbCr BT.601 (standard video-level) konvertiert.
dazu kommen die verschiedenen monitore / tv geräte usw.
die ergebnisse anhand der bilder würde ich also nicht überbewerten!
 
der screenshot wird durch den jeweiligen bildschirm aber nicht beeinflusst.. geknippst wird ja der framebuffer vor der bildausgabe.


(..)

mfg
tobi
 
der screenshot wird durch den jeweiligen bildschirm aber nicht beeinflusst
Aber auf das Gamut (und den sonstigen, farbmetrischen Eigenschaften) des jeweiligen Anzeigegerätes abgebildet.

die ergebnisse anhand der bilder würde ich also nicht überbewerten!
Richtig. Zum Anderen sollte man mit Korrekturen über den Renderer zumindest vorsichtig sein. Zunächst muß man sicherstellen, dass am Ende auch tatsächlich die korrekte Matrix für die YCbCr => RGB Wandlung eingesetzt wird.

Und dann sollte man sich klar sein, dass bei einem 8-Bit Quellsignal und dem Arbeiten auf einer 8-Bit LUT bzw. 8-Bit Processing, Tonwertverluste unvermeidbar sind. Verfügt man über einen geeigneten Bildschirm, wäre hier der richtige Ansatzpunkt, sofern die Bordmittel das erlauben. Ich kann hier nur dringend empfehlen z.B. HCFR zu nutzen (als sehr gute, allerdings kostenpflichtige, Alternative kann ich CalMAN nennen). Test-DVD mit den geeigneten Pattern (Primär- Sekundärfarben, 0-100 IRE Graustufen) gibt es ebenfalls kostenfrei. Bleibt nur das Colorimeter. Eine sinnvolle Investition.

Geht es um die Wiedergabe über den Rechner, reicht für Wunschgamma, Farbtemperatur und eine neutrale Grauachse sogar eine normale, weitgehend automatisierte, Kalibrierung über die mitgelieferte Software. Die Änderungen der Grafikkarten-LUT (die natürlich ebenfalls nicht verlustfrei sind) gelten systemweit.

Gruß

Denis
 
Zuletzt bearbeitet:
der screenshot wird durch den jeweiligen bildschirm aber nicht beeinflusst.. geknippst wird ja der framebuffer vor der bildausgabe.
soso :d

die screenshots zu posten finde ich auch gut, belebt den thread und macht ihn interessanter.
nur die ergebnisse würde ich wie gesagt nicht überbewerten.
 
Zuletzt bearbeitet:
screenshots kannst du auch komplett ohne monitor/display anfertigen.. und sie werden hinterher beim betrachten auf jedem bildschirm anders aussehen.. TN, MVA/PVA, IPS, komprimierung usw.. ;-)


(..)

mfg
tobi
 
ach so meinst du das ...
naja das kein kleines männchen vor dem Bildschirm sitzt, diesen abzeichnet und das bild auf die festplatte zaubert sollte klar sein ;)
 
jepp.. und auch, dass die bilder bei jedem anders aussehen.. ist mir erst neulich wieder aufgefallen, als ich bei einem bekannten vorm rechner saß.. unglaublich wie da grau und schwarz abgesoffen sind..


(..)

mfg
tobi
 
Ob ich die Bilder als BMP oder jpeg speichere macht bei mir was die Farben betrifft keinen Unterschied. Wie sollte man denn nun Bilder zb. in Irfanview am besten abspeichern ?

Wenn ich Jpeg´s mit dem verkleinerten MPC Fenster vergleiche in dem die selbe szene pausiert ist kann ich auch keinen Unterschied erkennen... :confused:

Lustig ist dass wenn ich die auto color correction von Irfanview verwende Bild 2 wieder farblich ausschaut wie Bild 1.... :fresse:

http://www.hardwareluxx.de/community/showpost.php?p=11873778&postcount=728
 
Zuletzt bearbeitet:
verstehe ich auch nicht so richtig.
welcher teil im skript ändert denn überhaupt die anzahl der frames?

das ja die frage - ob da was ist was ein limit angibt.

Ich encode letzendlich mit virtualdubmob - das teil gibt mir einen aktuellen Status - u.a. div. schätzungen ;) aber auch wieviel Frames er aktuell pro Sekunde verarbeiten kann. Und die waren halt komischerweise fast konstant 50fps und ich hatte noch CPU-Ressourcen über (nicht viel; xvid nutzt ja auch die 4 kerne komplett) ... so das ich mir vorstellen könnte das hier ein limiter drin ist ... entweder im script oder beim blackmanresize. k.a.

@Mr. Wifi: wenn ich das script wie hier im Thread vorgesehen nutze ;) hab ich mit lsfmod auch ruckler :( (Q6600, 3GHz; Material einfache xvids mit Zielgröße durch resize auf "nur" 800x???)

madVR hab ich gestern auch mal angetestet ... nen 1080p File mal reingehauen ... tja ;) was soll ich sagen ;) ... failed :( naja ist ja noch Alpha-Version - das wird noch! ... das 1080p wurde grundsätzlich angezeigt - aber mit schön bunten Balken unten und rechts ;) dazu mein ich das es geflimmt hat - und geruckelt wie sau hats auch ;)

Gruß
 
@Mr. Wifi: wenn ich das script wie hier im Thread vorgesehen nutze hab ich mit lsfmod auch ruckler (Q6600, 3GHz; Material einfache xvids mit Zielgröße durch resize auf "nur" 800x???)

Bei mir ruckelts zwar nicht, mit LSFmod ist´s aber immer async, genauso schlimm...

Ist wohl eher eine Option für die Zukunft, wenn irgendwann mal doppelt so schnelle CPU´s günstig zu haben sind ;)
 
Bei mir ändert sich an der Schwarzdarstellung durch Scaling nix, es sind eher die Rottöne die bei scaling korrigiert werden müssen ;)

Ich kann nur jedem empfehlen Core AVC bei HD vor FFD Show zu schalten, dann bleibt schwarz auch schwarz und nicht wie grau zb. wenn man nur FFD Show als Decoder für HD verwendet :)


Die von dir wahrgenommene änderrung der Rottöne durch das Upscalling, könnten daher kommen, das der Videorenderer die HD Transformationsmatrix nutzt( z.b VMR9). Werden dem Videorenderer 720 und 1080 Zeilen in YUV übergeben wird die entsprechende Matrix (für YUV nach RGB)für HD verwendet, bei 576Zeilen für SD. Genaue auflösungen und grenzen habe ich nicht durchgespielt.
Wenn du SD Material mit ffdshow hochrechnest, dann führe doch mal die YuV -> RGB wandlung mit ffdshow durch unter bedacht der Auswahl für die SD Transformationsmatrix, falls die automatik versagt, BT.601.
 
Als Renderer nutze ich den EVR, in Mediaportal und im MPC HC. Bei SD Material passt es bei mir, da nutze ich ein anderes FFD Show Profil wo nix korrigiert werden muss, dort gebe ich YV12 aus. Es wird nur bei HD Resize etwas rotlastig, bin aber im Nachhinein zufrieden wohl das richtige Farbmodell ( Yuy2 ) und die für mich momentan richtigen Gammakorrekturen in FFD Show zu verwenden. Bei der RGB Umwandlung bockt ausserdem meine Grafikkarte, ist ein Nvidia Bug der noch nicht behoben ist.
 
@WulfmanSG naja die zdf aufnahme hatte zu 99,9% 50 fields/s

@Mr.Wifi
was FaxenDicke sagen will (denke ich :d): erst zum erweiterten farbraum (BT.709) konvetieren, dann der rest!
der evr erweitert übrigens immer zum erweiterten farbraum!

P.S. @Mr.Wifi lass dich von klugscheissern wie mir mir nicht verunsichern :d
deine vorleistung in sachen deutschsprachige ffdshow anleitung finde ich toll (und mutig :d)!
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh