Beiträge von TheGenesis

    So ... der stinknormale sharpen mit 0.79 produziert ebenfalls Artefakte ... daraus schließe ich, das es von "OK" bis zu dem häßlichen blurring einen maximal möglicher Detailsgrad bei gegebener Bitrate pro Auflösung gibt.

    Neuer Ansatz ... bereits gegengecheckt ... stimmt ... grins ... das ist soo krank ...

    bitte nicht hauen ...

    dafür komm ich in die Hölle :)

    Aber egal ... das sieht bombastisch aus!!!

    Noch ein Nachtrag:
    Hab das gerade nochmal gegen einen 1080p upload gechecked ... das bringt ein wenig mehr feine Details (nur bei wenig motion) hervor, führt aber in den unteren Auflösungen zu wesentlich mehr Artefakten. Das nervigste daran finde ich, ist das hin und herschalten des Codecs bei movement und stehenden szenen.
    Das Script taugt übrigens auch hervorragend für "normale" Filme (nicht vergessen die Level-Korrektur rauszunehmen ;) ).
    Getestet hab ich das mit einem SD-Video (Lost in Space) und einem HD-Video (Hellboy 2).
    Bei den Filmen kann ich das Ergebnis mit dem "Overscale-Upload" bestätigen. Dort entstehen ebenfalls mehr Artefakte, wenn nur die native Auflösung hochgepumpt wird.

    Ja, aber eigentlich schade ... wenn die das nämlich etwas aufwendiger runterscalen würden (z.b. vorher stabilisieren und weichzeichnen) dann sähe das bei kleinen Bitraten wesentlich besser aus ... die 360er sind echt übel ... aber wie du schon sagtest ... die Stromkosten sind wahrscheinlich das k.o. Kriterium ... hihi ... die sollten in Ihre Server einfach ein paar stromsparende nVidia's reinbauen, dann könnte man da viel mehr rausholen.

    Gut fände ich übrigens, wenn die einem mal eine Vorgabe machen könnten, wo die die obere Auflösung (die man hochlädt) nicht nochmal runterrechnen ... dann könnte man mit viel kleineren Dateien jonglieren ... ist schon ziemlich frustrierend, wenn ich hier auf'm Land mal eben 800MB hochlade und davon nur die hälfte übrigbleibt.

    Sodele ... hier nochmal ein zwischenstand ...

    Upscaling auf 1152p:
    Lohnt sich immer, weil auch die niedrigeren YT-Auflösungen mit weniger Artefakten re-kodiert werden.
    Die Upload-Datei wird damit um ca. 5% größer

    Over-Sharpen (mit 1.0 anstatt 0.79):
    Erhöht den Detailgrad/Tiefenschärfe. Die niedrigeren Auflösungen des YT-recodes (unterhalb 1152p) profitieren davon am meisten.
    Der Gewinn ist jedoch nur vertretbar, wenn mit 1152p hochgeladen wird, weil man sonst das bischen mehr Details gegen mehr Artefakte (Bewegungsunschärfe/wabern) tauscht.
    Die Upload-Datei wird damit um ca. 15% größer

    Fehlt noch ein letzter Testdurchgang ... ich habe bisher nur Capture-Auflösungen mit 720p verwendet.
    Ungeklärt ist noch, ob höhere Auflösungen (die ja naturgemäß mehr Bildinformationen beinhalten) durch die begrenzte Bitrate beim re-encode nicht plötzlich mit Artefakten kodiert werden.
    Die Tests laufen ... ich geb Bescheid, was draus geworden ist ...

    Gruß
    Thom

    Smart-Cutter ist pfui ... VideoReDo konnte ich nocht nicht ausprobieren ... aber ich freunde mich gerade mit Avidemux an.

    Die sind schon ganz schön weit gekommen ... die ersten Versionen hatte ich mal zwischen ... die waren auch pfui bah :zunge: ... aktuelle Version ist schnell und schneidet verlustfrei an I-Frames (synchron inkl. aac) direkt wieder nach .MP4.

    Das geht damit ratzfatz (inkl. Strg+S :ja: ) ... und da ich P/B bei Lets-Plays eigentlich nicht cutten muss (glaub ich zumindest :rolleyes_: ) geb ich Sohnemann das teil in die Hand.

    Wenn DGIndexNV ein MP4 nicht verarbeiten kann, wird das Donald Graft sicherlich interessieren ...

    Ups ... erwischt ... da müßt ich erstmal "spenden" :)

    Videoredo TV Suite V.4

    Die Beschreibung auf der Homepage sieht vielversprechend aus (die vom Smart-Cutter allerdings auch) ... mhmmm ... für "ab und zu mal hobbyschneiden" ist das recht viel Geld ...
    Warum gewinnt VideoReDo? ... sind da noch extra features mit drin? Ich brauch nämlich nur den schnöden Schnitt :)

    Sodele ... mein template steht ... hier ist der Link: http://www.youtube.com/watch?v=7u3oGPAYHJM

    Die Bewertung:

    Original (720p, 3,35GB) 100%
    UploadFile (1152p, 818MB) 95% (hauptsächlich geht etwas an Schärfe verlohren)
    YT "Original" (453MB) 90% (minimales wabern bei hohem Detailgrad in großer Entfernung, minimale halos, Closeups noch nahezu perfekt)
    YT "1080p" (179MB) 80% (weiteres 10% degrading wie bei "Original", leichte Kantenbildung bei closeups)
    YT "720p" (92,8MB) 50% (starkes wabern, hoher detailverlust, halos minimal, Closeups im Verhältnis ok)
    YT "360p" (21,8MB) 5% (On-The-Fly DivX capture mit 1000kbit vom VHS Rekorder der Oma ... würg :D )

    *die %-Angaben sollen meine subjektives Qualitätsempfinden zum Original darstellen

    Alles unter 1080p würde ich mir nur auf meinem alten Rückpro angucken ... 720 ist mir schon zu schlecht ... die 360p braucht niemand :nightmare: .

    Ich bin erstaunt, wie gut der x264 so einen bandbreiten-limitierten recode bei den Closeups und bei Verhältnismäßig Aufwendigen Details (Wasser, Spritzer, Bäume/Planzen) noch hinkriegt.
    Wenn die das wabern stabilisieren könnten, dann würde das beim gucken garnicht so in den Augen brennen :ani_lol:

    Das finale Script sieht jetzt so aus:

    Kodiert mit (altem) x264 bei CRF 18 (wie Anfangs beschrieben).

    Ich hätte nicht gedacht, das man trotz gezwungenem upscaling, YT-re-encode und limitierter Bitrate noch solche Ergebnisse auf YT erzielen kann ... und das, obwohl die Testszene recht brutal ist, was Komplexität angeht.

    ***Korrektur:

    Hab gerade nochmal mit ausgeschlafenem Kopf die Videos verglichen ... Ich schmeiss mich weg ... durch das upscaling (Lanczos4Resize ist 1000x besser als der blöde resize von DirectShow/MPC) und das anschließende sharpen, sieht das UploadFile gefühlte 10% besser aus, als das original.
    Dementsprechend ist beim YT "Original" sogut wie kein Unterschied zum eigentlichen Capture mehr vorhanden.
    Die 1080p liegen dann bei 90% und die 720p bei 60% ... dem 360p würd ich dann vielleicht noch maximal 10% geben wollen.

    Supi ... jetzt noch 'nen Check machen, ob man überhaupt hochskalieren muss ... bin gerade dabei, zwei Varianten der Original-Auflösung (720p) hoch zu laden ... mal gucken, was YT daraus macht.

    Schade ... wie befürchtet mach der recode bei YT den crf24 und leider auch einen crf22 kaputt ... ist und bleibt wohl nie eine gute Idee rauschen zu encoden ... egal wie gut das im ursprünglichen Video ausgesehen hat :)

    Wofür braucht ihr die Kurvenanpassung eigentlich ... nur für analoges Material?

    ... MP4's in DirectShow ... "Microsoft DTV-DVD Video Decoder" ...
    ****update*** habs gerade mit Win7DSFilterTweaker totgehauen das Microsoft-Ding ... nu geht auch DirectShowSource() wieder :)

    Die "Build 2044" von DGDecNV kann meine MP4-Container nicht lesen ... uaah ... der parsed die zwar, sagt aber er hätte keine Frames gefunden ... Zitat:

    "Found NALU type 22, len 19762 undefined, ignore NALU, moving on"
    "data partitioning not implemented"
    "invalid sps -> pic_order_cnt_type = 3"
    "Error: pic_order_cnt_type != 1"

    die kommen in dieser Reihenfolge 2-3 mal, dann semmelt er ab.

    Was soll der Käse?

    Liegt das an meinem mux? ... ich muxe mit mp4box (die is allerdings auch schon was älter).

    Womit schneidet ihr eigentlich MP4 (möglichst verlustfrei, recode nur an den Schnittpunkten oder ohne am GOP)?

    Meine MPG2 hab ich früher immer mit MPEG-VCR geschnitten ... das ging super schnell und ohne nerviges demux/mux/recode.

    hast Du eigentlich den Screen mit der YUV-Kurve angeschaut den ich hier gezeigt hatte,da kannst den Level anpassen ohne den ganzen Stream im unteren & mittleren Bereich zu ändern.

    Huch ... hab ich was übersehen? Wo?

    Wir haben da auch den Fritz Framalyzer, der tut auch so was. Aber ...

    Bei dem Test ist mir gerade aufgefallen, das meine erstellten MP4-Videos via DirectShowSource() nur graue Frames zurückliefern. Jemand ´ne Ahnung warum?

    Der DGIndexNV kann leider noch keine MP4-Container ... geht das mit irgendeinem anderen Parser?

    Urgs ... hab mal (mit dem alten Encoder) mit Trellis=2, *_intra=6 und subme=10 kodiert ... aua ... das macht dann Encodingdauer x2,5 (bei meinem kleinen i7) ... bei dem alten Encoder bringt das Bildmäßig überhaupt nix und die Bitrate steigt ein klein wenig an. Vielleicht liegts auch am Lets-Play-Material.

    Werds dann die Tage auch nochmal mit dem neuen x264 und anderem Quellmaterial probieren.

    Ich hatte gerade wieder so einen Aha-Effekt ... bei crf runter auf 24 baut x264 scheinbar mehr "error-distortion" mit rein ... das führt dazu, das mein blödes Gehirn einen "höheren Detailgrad" wahrnimmt... uaaahhh ... das ist sooo blöde ... würd ich glatt nehmen, aber bei den closeups geht dann der detailgrad teilweise wieder runter ... außerdem befürchte ich, das der re-encode bei YT das komplett zusammenmatscht ... ich lads aber trotzdem mal hoch ... 1/2 Bitrate sollte einen Versuch wert sein :)

    Achso ... ich kann euch übrigens wärmstens so ein Kleinod nahelegen ... nennt sich VideoCheck ... sucht einfach mal in Google nach SetupVideoCheck0.4.exe
    Das teil ist super simple aber prima geeignet, um unterschiede zwischen unterschiedlichen encodings zu vergleichen ... da öffnet man einfach das "referenz-video" und dann das "test-video" und beide werden synchron abgespielt ... mit einem Mausklick auf das Video schaltet er zwischen referenz-video (Blauer Indikator) und test-video (Roter Indikator) hin und her ... mit Space kann man das ganze pausieren. Das läuft bei mir zwar nicht mit der vollen FPS, aber nahe dran ... super simpel ... einfach mal ausprobieren.

    Ok ... ist doch mal ein Ansatz ... werd ich morgen/übermorgen mal ausprobieren ... muss vorher leider noch 'nen blöden Auftrag erledigen.

    Achso ... hätte mir ja mal jemand sagen können, das es von dem FFT3DFilter() auch 'ne GPU-Version gibt ... jauchz ... mal locker die rendering zeit um über die hälfte verkürzt ... voll geil ... das lässt sich damit fasst in Echtzeit angucken :)

    Ich nehm den White-Level-Input übrigens wieder hoch, allerdings "nur" auf 230 ... da entsteht durch den erhöhten Kontrast mehr (subjektive) Tiefenschärfe ... und den Sigma schraub ich auch wieder auf 1.5 hoch ... das weniger glätten bringt keine zusätzlichen Details (im Upload-File) zutage, aber kostet mich 20% zusätzliche Bitrate.

    Sind bis zu 16 aufeinander folgende B-Frames nötig und sinnvoll?

    Ich bin nochmal ein bischen in mich gegangen und meine, ich hätte damit (damals) Speed gegen Bitrate getauscht.

    Zitat

    Deblocking extrem reduziert?

    Ich glaube, ich hab den reduziert, damit das Video bei der Ausgabe nicht verfälscht wird ... ich möchte keine Blöcke im encode, das ist (oder war früher) ein Zeichen dafür, das für das aktuelle Quellmaterial zu wenig Bitrate zur Verfügung steht.
    Vielleicht habe ich das auch nur gemacht, um zusätzlich Bandbreite zu schonen ... nach dem Motto: "enkodiert eh satt, also brauch ich auch keine widerherstellungsdaten".

    Zitat

    Warum Bewegungsvorhersage speziell nur "temporal" statt "auto"? (Vielleicht wegen der x264-Version.)

    Ja, mag der Verion geschuldet sein ... ich glaube ich hatte auf 'ner PS3 mal Artefakte ... könnte aber auch Trellis gewesen sein.

    Ich experimentiere übrigens gerade mit 'ner frischen Version vom Holländer :)
    Und es ist nicht besonders emutigend die Bitrate ist bei den gängigen presets (zumindest mit CRF 18/19) viel zu hoch.

    Ich hab mir gerade das Ergebnis in YT angeschaut ... bin recht zufrieden ... ich hatte die Erhöhung des White-Level-Inputs (um 35) rausgenommen und dafür das Output-Level um 20 erhöht ... ist jetzt von der Helligkeit akzeptabel und es wäscht den Himmel nicht mehr so stark aus.

    Werd das wohl nochmal mit dunklen Szenen testen müssen ... will nicht plötzlich mit banding überrascht werden.

    Wenn sonst niemandem mehr eine Aufhellung ohne Kontrastverlust einfällt, würde ich mich auf die neuen x264-Versionen stürzen, denn ein Upload-File von 800MB ist bei meiner ollen 4Mbit-Leitung (480KB upstream) "nicht so wirklich prickelnd" :)

    Zitat

    Vergiss bitte nicht die alte Bauernregel:

    "Schärfe" ist schlecht komprimierbar, und bei begrenzter Bitrate sorgt das für sichtbare Artefakte.

    Als alter Hase mach ich das normalerweise auch nicht ... aber 264 reagiert darauf nicht so böse, wie MPG2 oder DivX aka MP4.

    Bei meinen ersten Encoding-Versuchen für die "Lets Plays" waren die Details, die ich mit meinen mühsam zusammengesuchten optischen Mods zur Geltung bringen wollte, so dermassen ausgewaschen, das ich zu drastischeren Maßnahmen greifen musste.

    Zitat

    Erst das überschärfende Skalieren mit Lanczos4 (Gibbssches Phänomen), und dann noch mal nachschärfen mit dem "blinden" Anti-Blur, halte ich persönlich nicht vorteilhaft für die vollautomatische Recodierung bei YouTube.

    Das 50% schärfen ist bei den "Lets Plays" komischerweise die einzige Holzhammermethode, die gewirkt hat, um die feinen Details (wie z.B. die Maserung an den überall rumstehenden Holzbalken) zu erhalten, ohne das mein Upload (oder später das YT-re-encode) die wieder herauswaschen.

    Ich könnte das schärfen ein bischen runterziehen (auf 45%), aber durch den zwingenden upscale geht eh schon zuviel bei drauf, als das ich die wahl hätte.

    Zitat

    Getreu dem Motto "Weniger ist oft mehr", gibt ein neutraleres Skalieren und "LimitedSharpen" dem Recoder vielleicht etwas mehr Spielraum, in der vorgegebenen Bitratengrenze (die Optimierung könnte ja theoretisch mit Netzwerk-Bandbreiten zu tun haben) noch ein paar Bits für Texturdetails übrig zu haben.

    Hatte ich ganz am Anfang schonmal probiert ... sah echt übel aus ... gibt große weiche Flächen in der mittleren Entfernung, in trotzdem anfangen zu wabern.

    Welche kombi würdest du denn vorschlagen?


    Zitat

    Deine x264-Parameterliste ist von der Länge her beeindruckend, aber vielleicht reichen dafür – bei aktuellem x264 – auch eine Handvoll Basisparameter (preset, tune). Ich persönlich halte ein paar der Parameter in der vorliegenden Kombination für übertrieben.

    Wenn ich ehrlich bin, hatte ich bei dem halbherzigen Versucht letzte Woche keine Lust, wieder soviel Zeit für die Tests zu verballern. So hab ich an einem abend gerade mal die Dokus verglichen und die meisten Parameter in der tat durch preset und tune zusammengefasst.
    Das Ergebnis war dann von der Qualität vergleichbar, hat aber doppelt so lange kodiert und über 50% mehr Bitrate gefressen. Und dann hab ich aufgehört, weil ich in die Einstellungen da oben in 2009 ungefährt 2 Wochen arbeit reingesteckt habe.
    Da hatte ich "im zuge der Umstellung von MPG43 auf x264" alle Kombinationen an Filmmaterial in den unterschiedlichsten CRF/VBR Varianten kodiert und auf alle mir und meinen Bekannten zur Verfügung stehenden Geräte auf Kompatibilität und subjektivem Empfinden getestet.
    Die "beeindruckende Parameterliste" ist "Rock-Stable" will meinen, funktioniert mit allen mir bisher untergekokmmenen Quellen hervorragend, was Endgröße und Qualität angeht ... bisher hatte ich 0-Artefakte und die Dateigrößen entsprechen i.d.R. der doppelten Größe von MP43.
    Ich hab auch schon mehrere Blue-Rays auf 720p runterkodiert und dabei gigantische "Platzeinsparungen" erreicht, ohne das jemand in meinem Bekanntenkreis (die mit den riesengroßen, neumodischen HD Fernsehern :) ) was gemerkt hätten.

    Zitat

    Sind bis zu 16 aufeinander folgende B-Frames nötig und sinnvoll? Deblocking extrem reduziert? Warum Bewegungsvorhersage speziell nur "temporal" statt "auto"? (Vielleicht wegen der x264-Version.)

    Grins ... du fragst mich gerade sachen, die schon 4 Jahre her sind ... lol.

    Zitat

    Und ja ... gibt es Gründe für das Verbleiben bei einer so "veralteten" x264-Version, außer dass neue Versionen veraltete Parameter nicht mehr akzeptieren?

    Nein, eigentlich nur der Zeitaufwand zum testen, aber Zeit ist bei mir immer sehr knapp und da weiche ich ungerne vom "bewährten" ab.
    Aber du hast recht ... ich tu's mir nochmal an ... arrgghhh ... hab gerade gesucht und kann die angepasste Parameterliste nicht mehr finden (hab ich warhscheinlich aus Frust gelöscht) ... gibst du mir mal 'nen Ansatz? ... vielleicht kann ich mir dann das rumvergleichen der einzelnen Parameter sparen.

    Zitat

    Dann wär's mal Zeit zum Umlernen und neu Optimieren; wäre es nicht sinnvoll gewesen, hätte man sich die Weiterentwicklung sparen können. In den aktuellen Versionen sollte man sich vorwiegend auf "--preset" und "--tune" verlassen und darüber hinaus nur anpassen, wovon man genau weiß, warum das nötig ist (z.B. Profile@Level und VBV-Parameter für Geräte-Kompatibilität). Welches Tuning für PC-Spiele-Aufzeichnung sinnvoll ist, bin ich mir nicht sicher; aber für das Preset wird sicherlich kaum ein langsameres als "slow" oder "slower" notwendig sein.

    Ich glaube nicht, das für Spiele besondere x264-Parameter notwendig sind ... weisst du, was mich an dem Preset-Gedöns stört? ... ich gebe die Kontrolle von "meinem persönlichem Empfinden von Qualität" an die Allgemeintheit bzw. an die Leute ab, welche festlegen, was in den Presets enthalten ist ... da hab ich ein bischen Angst davor, das in ein paar Jahren jeder so ein Preset für das Maß aller Dinge hält und die folgeversionen auf diesem (evtl. degradierenden) Qualitätsempfinden aufbauen.

    Gruß
    Thom

    So ... das wird voerst die Endfassung sein:

    http://youtu.be/P8HNw5NGO_I

    (lädt noch hoch ... 815MB ... ca. 320min ... bis ca. 08:15)

    Achso ... das wäre dann das folgende Script:

    Code
    loadplugin("c:\Program Files\AviSynth\plugins.manual\FFT3DFilter.dll")AVIsource("d:\Storage\Work\Dxtory\TESV 2013-03-13 22-22-30-998.avi")Levels(0,1.2,255,20,255)FFT3DFilter(sigma=1, bt=5, bw=32, bh=32, ow=16, oh=16, ncpu=8)Lanczos4Resize(2048,1152)Sharpen(0.79)

    getreu dem Motto ... weniger ist oft mehr ;)

    ... und der Vollständigkeit halber noch die x264 Parms:

    Code
    x264.exe --crf 18 --no-fast-pskip --ref 4 --bframes 16 --b-pyramid --weightb --analyse all --subme 7 --trellis 1 --mixed-refs --no-psnr --no-ssim --direct temporal --partitions all --me hex --deblock -3:-3 --aq-strength 0.5 --deadzone-inter 2 --deadzone-intra 4 --threads auto --progress --output OUTFILE.mp4 INFILE.avs

    Achtung ... die sind für die Version "x264 core:66 r1093M 1df50b9" (irgendwann Anfang 2009) ... die neueren x264's nehmen die so nicht mehr ... da sind einige obsolete ... ich hatte die demletzt mal an eine aktuelle Version angepasst, aber Dateigröße und Encodingdauer hatten sich damit drastisch erhöht, ohne das ich optisch irgendeinen Nährwert erkennen konnte und deshalb bleib ich für meinen Teil erstmal bei des "Schusters Rappen" ;D

    Nääähhh ... pfui ... bah ... spuck ...

    Wurde gerade wieder schmerzlichst daran erinnert, warum ich den FFT3D eingebaut habe ... das reinste rumgeflackere an allen Ecken und enden ... und der Gewinn an Details ist kaum sichtbar (wahrscheinlich nur durch das erhöhte Rauschen) ... den Gamma anheben bringts auch nicht ... das hebt die mittleren Lumas zu weit an ... da gibts dann keine vernünftigen Schatten mehr und heller wirds dadurch auch nicht.

    Ich schraub jetzt den Sigma beim FFT3D auf 1.0 runter und lass den Gamma auf 1.2 (ohne Levelerhöhung).

    So'n Käse ... das sieht zwar gut aus, ist aber immernoch zu Dunkel ... in der Szene sind es 13:00 Uhr und die Sonne steht voll am Himmel ... muss eigentlich so hell sein, wie in dem Beispiel mit Levels 220 ... aber dann verliehr ich die Details in den hellen Bereichen ...

    Jemand noch 'ne Idee, wie ich das Heller kriege ohne den Himmel in eine Weisse Fläche zu verwandeln?

    Bitte keine Kommentare wie "Brightness und/oder Contrast" ... das kann ich dann auch gleich mit 'nem ACDSee drüberbügeln :hm:

    Hast recht!

    Ich hab aber gerade doch noch was gesehn ... der Himmel ist beim 220er-White-Input-Level komplett ausgewaschen ... is auch logisch ... außerdem ist mir gerade aufgefallen, das mein Uploadfile bei vollem spektrum kleiner wird ... der YouTube re-encode bei voller Auflösung lustigerweise größer ... bei den downscalings macht das größenmäßig nichts aus.

    Das ist doch eigentlich unlogisch ... mehr Farbe müsste eigentlich mehr Bitrate bedeuten.

    Aber ich möchte die Details (z.B. am Himmel) nicht verliehren, wenn ich dadurch keinen Vorteil in anderen Bereichen habe ... die Texturen in den dunkleren (nicht so "hellen") Frames sind rein subjektiv nämlich gleichermaßen ok.

    Neuer Ansatz (rendered gerade):

    Nativ YV12 wird genommen
    Gamma von 1.2 auf 1.3

    Und ich lass gleich noch 'nen Faktor mit reinlaufen ... das ist mir alles noch zu weichgespült ... mir ist aufgefallen, das die Gesichter mehr wie ein convolution3d() aussehen, als das man die Hautpigmentierungen noch erkennen könnte ... ich nehm den FFT3DFilter() nochmal komplett raus ... auch auf die Gefahr hin, das es im Hintergrund wieder anfängt zu wabern bzw. mir das höhere Graining den re-encode bei Youtube versaut ... mit etwas Glück gibts bei 1152p trotz höherem Detailgrad noch keine Artefakte.

    Die Renderingzeit beschleunigt das Manöver auf jedenfall schonmal um den Faktor 3 ... mal sehen wie groß die Uploaddatei wird ... grusel :disturbed:

    Übrigens nettes Prog das du da hast ... was kann man damit machen, außer Frames zu vergleichen?

    Schade ... aber gesetz den Fall ich krieg die Elemente rausgeschnibbelt ... kann man in AviSynth irgendwie eine Erkennung programmieren, ob ein Element gerade eingeblendet ist oder nicht?

    Der Kompass ist nämlich immer sichtbar, damage und stamina nur, wenn sie "nicht voll" sind.

    Ich hab nämlich überlegt, die HUD-Opacy in den Game-Settings auf einen sehr niedrigen Wert zu setzten (so, das sie fasst nicht mehr zu sehen sind) ... anschließend für X-Logo alle 3 Matrizen erstellen, die Logos damit rausbügeln und die "fasst unsichtbaren" Elemente mittels Contrast/Hue/Weisichwas solid zu machen und nach der Stab-Stage wieder einzufügen.

    Oh Mann ... die Arbeit an den Matrizen graußt mich jetzt schon ... urgs ... und dann muss man das für jedes Game wieder neu machen ... aber egal ... ist ja schließlich nur'n Hobby :)

    das wär schön ... geht aber bei TESV nicht ... ich kann entweder ohne oder mit HUD cappen.

    Aber selbst wenn das Skyrim könnte ... mein Sohn sagt, die Re-Play's haben nicht allzuviel mit der ursprünglichen Aufzeichnung zutun ... is wohl noch nicht so ganz ausgereift :)

    Ja, ich hab noch eine Idee, aber da sprengt der Aufwand den Nutzen ... vielleicht lass ich meinen Sohn einfach mit 30fps cappen und bei seiner Superduperhypermaus ruckelt das bestimmt nicht so doll, wie ich mit mein "klein Laptop".

    Wäre schön gewesen wenn jemand irgendwo ein filterchen aus der Schublade zaubern würde, das ich noch nicht kenne :)