Ich hatte mal den Fall, das der Ton in anderer Framerate als das Bild vorlag. Ziemlicher Murks, aber das Problem äußerte sich ähnlich. Das kann man beheben, indem man die Frameraten anpasst. Es soll auch Player geben, die Frameratenunterschiede ausgleichen können. Vom smplayer hab ich das mal gehört. Ändert aber nix dran, das das Murks ist...
ach ja: 23.976... und 24000/1001 ist das gleiche. Rechne es aus...
Der fehler ist leider nicht reproduzierbar. Es sind im Film zwar immer die gleichen Szenen betroffen, aber nicht die gleichen Bilder.
Eins macht mich extrem stutzig:
Der Fehler tritt gar nicht auf, wenn ich eine im Film betroffene Szene herausschneide, und nur diesen kurzen Abschnitt codiere. Könnten thermische Probleme des Rechners sowas auslösen?
Mein ram ist fehlerfrei, hab ich grade mit memtest86 getestet.
Aber dafür ist beim Sichten noch ein anders gearteter Bildfehler aufgetaucht. Hier 3 Screenshots. (/edit: Link entfernt, da Problem gelöst)
Von RemoveGrain ist ein bugfix für die SSE3-Version herausgekommen, könnte es daran liegen? (wird ohnehin mal getestet)
/Nachtrag:
Mit der neuen RemoveGrainSSE3 ist das Problem weg. Ich hoffe nur, das das jetzt kein Zufall ist, weils ja auch vorher schon nicht reproduzierbar war...
ich teste es mal ohne fft (wobei ich den Filter echt vermissen würde, hält halt die cpu zum komprimieren frei)
Removegrain 22 soll ein sanfter und schneller rauschfilter sein. hab ich einfach von hier übernommen, ohne weiteres testen, weil ich mit dem ergebnis zufrieden bin.
21,22: recomended for good denoise performance with minor artefacts (22 is the fastest mode of all)
LigH:
müsste in diesem Falle der Fehler nicht reproduzierbar sein?
Hallo zusammen,
ich hab folgendes Problem: Beispiel (/edit: Link entfernt, da Problem gelöst)
Beim recodieren eines Films tauchen im Ergebnis einzelne Frames mit Falschfarbenfehlern auf. (sie Screenshots im Beispiel) Mal grünlich, mal Lila.
Ich versuchte das Problem zu verstehen, indem ich dieselbe Szene mal rausgeschnitten habe, und zunächst mit den gleichen Einstellungen getestet habe, um zu schauen, obs wieder auftaucht. Und diesmal war die Stelle völlig okay. Allerdings habe ich das Problem auch schonmal bei einem anderen Encoding beobachtet.
Ich benutze das aktuelle Staxrip (1.5.irgendwas)
mit Avisynth-filtern:
LoadPlugin("C:\Programme\StaxRip_1.1.3\Applications\AviSynth plugins\DGAVCDecode.dll")AVCSource("D:\Pfad\zum\Film.dga")Crop(0,0, -Width % 8,-Height % 8)ConvertToYV12()loadplugin("C:\Programme\StaxRip_1.1.3\Applications\AviSynth plugins\RemovegrainSSE3.dll")Removegrain(22)loadplugin("C:\Programme\StaxRip_1.1.3\Applications\AviSynth plugins\FFT3dGPU.dll")FFT3dGPU(plane=4, bt=4, bw=24, bh=24, ow=12, oh=12, sharpen=1.0)x264-Aufruf ist Standard:
x264.exe --tune film --b-pyramid none --output abcxyzWoran könnte das liegen? Wenn ihr irgendwelche Vermutungen habt, raus damit. Wenn ihr noch mehr Infos braucht, sagt mir was.
Grüße, D
Hallo zusammen,
ich hab eine schlechte Quelle, hier eine Probe
Die Rohdaten dazu kommen von der Macgyver-DVDbox, also kein schlecht gemachtes Internet-Release.
Ich kenn mich da leider nicht aus, erst recht habe ich keine Ahnung, welche filter man gut miteinander kombinieren kann.
FFT3dGPU(plane=4, bt=4, sharpen=1.0) hab ich schonmal drüberlaufen lassen, und das ist auch schon ne verbesserung. Oft werden viele Filter in Kombination vorgeschlagen (removegrain, limitedsharpen, uvm), aber da stehe ich grade etwas ratlos da^^
Könnt ihr mir eine Kombination empfehlen?
/Nachtrag:
Ich habe jetzt viele Sachen mit unzähligen Einstellungen ausprobiert, (limitedsharpenfaster, seesaw, ltsmc, ftt3dgpu, removegrain...)
Aktuell hab bin ich bei den beiden Filtern gelandet, mit diesem Ergebnis
Removegrain(22)
FFT3dGPU(plane=4, bt=4, bw=24, bh=24, ow=12, oh=12, sharpen=1.5)
Was kann man dort noch sinnvoll hinzufügen?
Ich muss sagen, das es mir irgendwann schwerfällt das Ergebnis zu bewerten. So der absolute Knaller war nicht dabei. LTSMC hat mir noch etwas besser gefallen als FFT3DGPU, war aber durch die gpu-unterstützung der FFT auch deutlich langsamer. LSF und seesaw erzeugten recht starkes Kantenflackern.
Grüße, D
Das ist klar... Qualitative Aussagen, die in den meisten Fällen zutreffen, sind eigentlich das, was ich will. Du hast davon so viel Ahnung, das deine Einschätzung mehr Wahrheit enthält, als sich die meisten Menschen (mich eingeschlossen) an Wissen aneignen wollen oder können.
Ne kleine Parameterempfehlung für 90% der erreichbaren Qualität wäre auch toll. 100% perfekt muss es ja auch nicht sein. Vielleicht auch dazu schreiben, in welchen Situationen diese Einstellungen gut sind, und in welchen Situationen man davon abweichen sollte.
Im einzelnen gehts darum, die Wirkung der Parameter zu erfahren. Welchen Einfluss sie auf den Rechenaufwand haben, und welchen Effekt sie im Bild erzeugen, damit ich selbst ein bissl rumspielen kann, und nicht völlig blind an den Knöpfen drehe, ohne eine Erwartung zu haben, was nun passieren könnte, und besser darauf achten kann
Auch wäre es interessant, in welchen Fällen einfachere Deinterlacer (Tomsmocomp, Tdeint,...) auch ordentliche Ergebnisse erzielen können, und eine grobe Einschätzung, wo diese jeweils von der Qualität her im Vergleich zum TGMC liegen.
Ja, da wär ich aber auch für^^
Ich glaube, ich gebs auf, dort bis in die Tiefen vorzudringen und beschränke mich aufs Anwenden.
Sind meine Fragen noch auf dem Schirm? Die ersten beiden sind noch von Interesse, die dritte ist ja eigentlich geklärt.
Grüße, D
Tag zusammen,
ich hab jetzt ein paar Stunden rumprobiert und den TGMCbeta2 in Staxrip eingebunden. Im Endeffekt hab ich ein rumgefrickel produziert, was aber läuft. Ästhetisch ist es bisher nicht. In die genaue Funktion von Avisynth-Scripten bin ich nicht eingestiegen, sondern habe (bildlich gesprochen) ein Treckerrad mit ein paar herumliegenden Schrauben an ein Auto geschraubt, mit dem Effekt, das sich das Rad dreht^^
Zu Leistungsmessungen bin ich noch nicht gekommen, und bei der Rechenzeit von TGMC werd ich das mit diesem Rechner auch nicht machen. In 10 Jahren auf ein paarhundert Kernen juckt das keinen mehr...
Da, wie ich aus diesen Thread entnommen habe, Avisynth erst von der Existenz der TGMC-Funktion in Kenntnis gesetzt werden muss, und man sie danach aufrufen kann (soweit reichen meine Turbopascal-Kenntnisse noch^^) habe ich für TGMC einfach 2 Einträge im linken Staxrip-Fenster gemacht.
Einen mit der import(tgmc.avsi)-Anweisung, gefolgt vom funktionsaufruf "tgmc(batterie,von,parametern,die,ich,nicht,verstehe)"
Parameter aus Didees Vorschlag hier.
Zusätzlich hab ich die tgmc.avsi um die pluginladeanweisungen in den ersten 5 Zeilen erweitert. (ich hab da mit Bauklötzen gespielt, mit denen ich eigentlich nicht umgehen kann...)
Danach alle fehlermeldungen gegoogelt, und entsprechend behoben (irgendein mode20-Fehler, wo man eine Datei austauschen musste, und ne fehlende .dll)
Läuft soweit. Das Ergebnis einer interlaced-Quelle ist nach langer Rechenzeit (Faktor 5-8!), eine ordentlich aussehendes progressives Bild.
Fragen:
1) Kann man die Wirkung der Parameter mal erklären? Was sie tun, mit welcher Wirkung auf die Quali und den Effekt auf den Rechenaufwand. Speziell würden mich qualitativ die lokalen Ableitungen (dQuali/dParameter-i) und (dRechenzeit/dParameter-i) an der Standardeinstellungsstelle interessieren. (wer mit solch fiesem Zeug wie Avisynth umgehen kann, kann auch Mathe^^)
2) Bei der Quali hab ich allerdings Einschätzungsprobleme:
Die hier gezeigten Beispiele sind klar "pro tgmc", allerdings ist hier der tradeoff "Quali vs. Rechenzeit" auch extrem. Ich benutzte bisher Tomsmocomp, und war nicht wirklich unzufrieden, ich weiß es aber auch nicht besser. Soviel interlaced-Material gibts ja auch nicht mehr, Tendenz stark fallend.
* Wo liegt TomsMoComp (Staxrip-Standard) im Vergleich zu anderen DeIntern? "TDeint" wird immer wieder mal genannt.
* Welche DeInter lösen den tradeoff nicht ganz so radikal, wie tgmc, aber immer noch brauchbar?
3) wie zum beispiel hier zu sehen, macht NNEDI2 seinen Job auch gut. Wenn NNEDI2 nun als vorausgesetztes Plugin für TGMC ein Teil der durch TGMC durchgeführten Berechnungen ist, was macht TGMC denn mehr? NNEDI2 ist angeblich langsam, TGMC auch.
LigH:
Und wenn man TGMC als Win32-DLL mit optimierendem Compiler programmieren würde, wäre er auch schneller als als AviSynth-Funktion.
Warum macht man das nicht? Wenn man den Algorithmus hat, kann das doch nicht so schwer sein, oder? Die Brainware ist doch schon gemacht, oder? Nicht? Kein Vorwurf, ich lerne gerne!
Das wars fürs erste.
Grüße
Hallo Zusammen,
da ich glaube, das mein Problem eher hier her passt, setze ich den Text in nochmal dieses Forum. Original wars unter "alternative AV-Container"
Ich hab eine Sicherungskopie^^ eines HD-Filmes als mkv-Datei
Darin ist eine englische und eine deutsche Tonspur enthalten. Die englische ist völlig in Ordnung, aber in der deutschen gibt unzählige, kurze und unregelmäßige Aussetzer.
Ich benutze den vlc-player zum abspielen.
Es liegt nicht an defekten Daten, da die Aussetzer nicht immer an der gleichen Stelle auftreten, sondern wenn man sich die selben Sekunden im Film immer wieder anschaut, liegen die aussetzer immer woanders. Auch wird der Ton nicht asynchron durch die Aussetzer, sondern bleibt immer Lippensynchron zum Film.
Woran kann das liegen? Kann ich durch irgendwelche Programme zum recodieren da was dran ändern? Womit könnte das gehen?
Grüße, D
Hallo Zusammen,
ich hab eine Sicherungskopie 
eines HD-Filmes als mkv-Datei
Darin ist eine englische und eine deutsche Tonspur enthalten. Die englische ist völlig in Ordnung, aber in der deutschen gibt unzählige, kurze und unregelmäßige Aussetzer.
Ich benutze den vlc-player zum abspielen.
Es liegt nicht an defekten Daten, da die Aussetzer nicht immer an der gleichen Stelle auftreten, sondern wenn man sich die selben Sekunden im Film immer wieder anschaut, liegen die aussetzer immer woanders. Auch wird der Ton nicht asynchron durch die Aussetzer, sondern bleibt immer Lippensynchron zum Film.
Woran kann das liegen? Kann ich durch irgendwelche Programme zum recodieren da was dran ändern? Womit könnte das gehen?
Grüße, D