Du kannst ja mal Avisynth MT probieren. Vielleicht bringt es bei dir was.
Man kann es ja kombinieren.
Du kannst ja mal Avisynth MT probieren. Vielleicht bringt es bei dir was.
Man kann es ja kombinieren.
Ich bin's nochmal.
Erstmal SORRY!!
Wollte hier keine große Diskussion lostreten.
Hatte jetzt mal (um was anderes zu testen) die Testversion von HAENLEIN "DVR-Studio HD 2" installiert. Scheinbar installiert bzw. verändert das Programm Einstellungen unter "ffdshow". Der HDTV-Mitschnitt der bei mir Probleme unter STAXrip verursacht hat:
ZitatHab schon ein bissel mit StaxRip rumprobiert, aber bekomme häufig Fehlermeldungen wenn ich unter StaxRip in den Bereich gehe wo man schneiden kann. Irgendwas mit "...ffmpeg..."
wird nun von STAXrip problemlos angenommen und kann auch ohne jegliche Fehlermeldungen den Mitschnitt schneiden usw.
Was das DeIntelacen angeht, hatte ich schon den Fall (war eine Aufnahme von NatGeo HD --> 1080i), wo ich nach dem Encoden (ohne DeInterlacen) extreme Kammeffekte hatte. Nutze nun TDeint als DeInterlacer und alles ist gut.
Trotzdem DANKE für eure Tipps.
Zitat von Koto99;476188Das problem ist das Script muss man verstehen um zu wissen welche DLLs man braucht. Das kann man aber auch nur nachvollziehen wenn man nicht zu den Experten gehört.
Naja... bei den meisten Scripten ist das eigentlich schon in den ersten Zeilen ersichtlich. Bei Restore24 RC1 steht da z.B.:
ZitatAlles anzeigen# Restore24 v1.0 RC1
#
#
# Prerequisite plugins:
loadplugin("RemoveGrain.dll")
#loadplugin("RemoveGrainSSE2.dll")
loadplugin("ReduceFlicker.dll")
#loadplugin("ReduceFlickerSSE2.dll")
loadplugin("WarpSharp.dll") #for FrameCache()
loadplugin("LeakKernelDeint.dll")
loadplugin("MaskTools.dll")
loadplugin("avisynth_c.dll")
loadCplugin("smartdecimate.dll")
loadplugin("tivtc.dll")
loadplugin("tdeint.dll")
... bei SRestore gibt's eine Readme (und den schon erwähnten MediaWiki-Eintrag):
Zitatnotwendige Plugins:
- mt_masktools v2.0 (immer)
- TIVTC v1.04 or higher (nur bei cache>0)
- RemoveGrain (nur für Doppel-Blend-Entfernung)
- Average (nur für Doppel-Blend-Entfernung)
... und ansonsten steht das gelegentlich auch als Kommentar zu Beginn des Scripts (wie hier z.B. bei QTGMC):
ZitatAlles anzeigen# --- REQUIREMENTS ---
#
# Input colorspaces: YV12, YUY2
#
# Core plugins:
# MVTools2 (2.5.11.2 or above)
# MaskTools v2 (recommend 2.0a45 or above. Must use the 2.5 version with YUY2)
# NNEDI3 (recommend 0.9.2 or above)
# RemoveGrain + Repair
#
# Additional plugins:
# NNEDI2, NNEDI, EEDI3, EEDI2, TDeInt - if selected directly or via a source-match preset
# Yadif - for Preset="Ultra Fast" or if selected directly (cannot be autoloaded, must be loaded in the calling script)
# VerticalCleaner - for SVThin or Lossless modes
# FFT3DFilter - if selected for noise processing
# dfttest - if selected for noise processing
# For FFT3DFilter & ddftest you also need the FFTW3 library (FFTW.org). On Windows the file needed for both is libfftw3f-3.dll. However, for FFT3DFilter
# the file needs to be called FFTW3.dll, so you will need two copies and rename one. On Windows put the files in your System32 or SysWow64 folder
# AddGrainC - if NoiseDeint="Generate" selected for noise bypass
Ist also in den meisten Fällen schon recht klar ersichtlich, welche Plugins benötigt werden (Grundkenntnisse in der Benutzung von AviSynth vorausgesetzt).
Nun haste dir aber 3 schöne Beispiele von vielen gesucht wo dem nicht so ist.
Bei Gleiz zb werden die LoadPlugin angaben fast immer weggelassen. Da ist dann suchen angesagt. Von den versionen mal nicht zu reden.
Man merkt aber Du bist auch etwas Betriebsblind gegen Neulinge in der materie.
Alles Super einfach für die Freaks. Wobei es eben eine Sache der Freaks ist.
Ich hab die Beispiele gebracht, welche hier schon genannt wurden. Schließlich hast du ja KEINE genannt, die deine Aussage betrifft - warum sollte ich jetzt also an deiner Stelle nach einem Negativbeispiel suchen!?
Du machst dir deine Kritik also auch sehr einfach, indem du dich mindestens genauso weigerst über den eigenen Tellerrand zu schauen, wie du es mir vorwirfst ...
Irgendwann muss man auch mal zum ende kommen.:-)
Hier übrigens noch ein Benchmark:
http://forum.doom9.org/showthread.php?p=1559441
... wo DGDecNV+x264 gegen x264 mit LAVF-Support (= eine spezielle x264-Version mit quasi integrierten Decodern aus dem FFMPEG-Projekt) im BD-Rebuilder antritt. Und es scheint sich tatsächlich zu bewahrheiten: zumindest beim reinen Reencoding (ohne irgendwelche Filterung) bringt DGDecNV wenig bis gar keinen Vorteil. Teilweise sogar eher einen Geschwindigkeitsnachteil...
Was ich nicht ganz verstehe warum bei meinem DVD Test nix rauskam. Als ich 1080p zu DVD machten wollte, hat Avisynth gebremst. Also das Resize. CPU last war auch nur 50%
Nun sollte sich mit DGDecNV da ja was tun. Was aber nicht so ist. Ich kann da nur vermuten die GPU ist genauso stark wie die CPU mit einem Core.
Das würde auch erklären warum Avisynth MT was bringt.
Der Punkt ist einfach, wie ich das auch drehe es ist ein der Praxis kaum möglich da einen vorteil zu haben. Wer hätte zb eine 1000 Euro GK auf einen kleinen I3.
Einen vorteil sehe ich da nur, wenn man einmal ein File mit Cuda enkodiert zb mit Selurs hybrid und dann eines parallel mit der CPU zb mit Staxrip. Wenn sich dann Avisynth nicht ins gehe kommt.
Wobei ich mir eh mal wünschen würde das sich Avisynth zu Multicore entwickelt. Das Avisynth MT ist alles andere als Optimal.
Was auch Geil wäre ein Encoder der eben mit CPU, Cuda, Intel Quick Sync Enkodiert. Also die Last verteilt. Und nicht entweder oder.
Sorry, muss mich nochmal einklinken.
Hab jetzt versucht eine HDTV-Aufnahme (ZDF-HD, 720p) in Xvid zu encoden und dabei zusätzlich die Option "MISC Assume 25 fps" ausgewählt um auf 25fps zu kommen. Jetzt ist aber nach dem Encoden, die Datei von der Lauflänge doppelt so lang und sie wird viel zu langsam abgespielt.
Gibts da andere Möglichkeiten?
Deine Aufnahme war 50P das kann nicht klappen.
Lasse das Assume 25 fps weg und setze ein selecteven()
Audio nicht Speeden.
Du kannst auch selber eine Funktion einbauen.
Filters / Profiles
[HD50 zu Pal25]
50p zu 25p = selecteven()
Ok. Nun hast Du unter Filter ein neue Option dafür. So kann man Funktionen in Stax Einbauen. Und muss sich das nicht immer merken.
Die namen kannst Du logo nach deinem Geschmack anpassen.
Vielen Dank. Schon eingebaut
Was meintest du mit "Audio nicht speeden"? Muss ich da jetzt noch was einstellen? Und muss die Option mit 50p zu 25p von der Reihenfolge der genutzen Filter an eine bestimmte Stelle oder ist das Wurscht? Der Filter ist jetzt sozusagen als letztes von der Reihenfolge her:
Würde das vor Crop setzen.
Du Coppst sonst Frames die man danach verwirft. Was unnötig Rechenzeit kostet.
Mit Speeden meine ich unter Audio. Es gibt ein Assume 25 auch für Audio. Speed Up heißt die Option. Das ist aber nicht nötig.
Und Crop immer vor Resize sonst stimmt die Resize Berechung nicht mehr. Nur so als Tipp.
ok, vielen Dank nochmal
Zitat von Koto99;476393Einen vorteil sehe ich da nur, wenn man einmal ein File mit Cuda enkodiert zb mit Selurs hybrid und dann eines parallel mit der CPU zb mit Staxrip. Wenn sich dann Avisynth nicht ins gehe kommt.
(...)
Was auch Geil wäre ein Encoder der eben mit CPU, Cuda, Intel Quick Sync Enkodiert. Also die Last verteilt. Und nicht entweder oder.
GPU-Encoding ist wesentlich unsinniger als GPU-Decoding:
Zitat von TomKellerAlles anzeigenStreamprozessoren ziehen ihre enorme Rechenleistung aus dem Zusammenschluss aller vorhandenen Recheneinheiten. Das aber wiederum bedeutet: vor allem viele parallel durchführbare Berechnungen profitieren von ihrer Ausführung auf Streamprozessoren. Pixel-Shader-Effekte sind ein gutes Beispiel dafür: da muss für jeden Pixel ein bestimmter Farbwert berechnet werden - zig Pixel = zig parallel durchzuführende Berechnungen = PERFEKT für Streamprozessoren!
Videoencoding ist aber nur begrenzt parallelisierbar. Das ist auch ganz logisch: ein Großteil der Schritte MUSS einfach nacheinander ausgeführt werden. Man stelle sich dafür einfach mal zwanzig Köche vor, die einen einzigen Kuchen backen. Die werden kaum bis gar nicht schneller als zwei Köche arbeiten - einfach weil die meisten Schritte nacheinander ausgeführt werden müssen (man kann ja den Teig nicht in den Ofen schieben, BEVOR er angerührt wurde )... was in der Praxis bedeutet: 1-2 Köche machen etwas, während die anderen 18-19 Köche darauf warten müssen, dass diese 1-2 Köche fertig werden.
Und genauso sieht es bei Streamprozessoren und Videoencoding aus: einige wenige Streamprozessoren werden genutzt, während die restlichen auf das Ergebnis dieser Berechnungen warten müssen, um es dann weiter zu verarbeiten.
Hinzu kommt, dass die Daten zur Berechnung per Streamprozessoren ständig vom Hauptspeicher in's Grafik-RAM und zur Verifizierung nach der Berechnung wieder in den Hauptspeicher geladen werden müssen. Im Gegensatz zu CPUs, die üblicherweise eine direkte und flotte Speicheranbindung zum Hauptspeicher besitzen, ist das ein vergleichsweise gigantischer Umweg, der einiges an Zeit kostet.
Lange Rede - kurzer Sinn: Videoencoding per GPU ist laaaaangsaaaam ! Da sich das aber schlecht in diversen Marketingversprechungen lesen würde, erkaufen sich alle GPU-basierten Encoder den Geschwindigkeitsvorteil durch eine schlechtere Encodingqualität - sprich: durch eingeschränkte Bewegungssuche, weniger Reference-Frames u.ä. "Kleinigkeiten" scheinen(!) solche Encoder recht flott zu arbeiten - können aber von einem Software-Encoder leicht geschlagen werden, wenn man ihn ähnlich moderat konfiguriert.
Zitat von Koto99;476393Wobei ich mir eh mal wünschen würde das sich Avisynth zu Multicore entwickelt. Das Avisynth MT ist alles andere als Optimal.
Das Problem dabei ist: nicht bei jedem Filter-Plugin lässt sich die Funktionalität so einfach auf mehrere Threads verteilen.
Bei AviSynth-MT gibt es außerdem zwei interne "MT-Varianten", die unterschiedlich arbeiten. Über MT() wird immer ein Frame angefordert und in mehrere Bereiche gesplittet, die dann parallel bearbeitet werden (= klappt nicht mit allen Plugins):
... über SetMTMode() werden hingegen mehrere Frames gleichzeitig angefordert, die parallel bearbeitet werden (= klappt mit mehr Plugins als MT(), aber eben auch nicht allen - ist teilweise schneller & teilweise langsamer als MT() -> abhängig vom benutzten Plugin):
Beides ist außerdem nicht einfach zu benutzen... und daher nur eingeschränkt empfehlenswert.
Woher habt ihr eigentlich das extreme Detailwissen???
ZitatBeides ist außerdem nicht einfach zu benutzen... und daher nur eingeschränkt empfehlenswert.
In der Tat ist es nicht einfach zb beim Resize ist MT richtig und bei MDeGrain2 zb SetMTMode. SetMTMode zb bringt beim Resize gar nix.
Aber im ggs zu DGDecNV bringt es immerhin was. Aufwand und nutzen müssen stimmen bei mir. Und meistens ist es so. Hat man ein Script mal, benutze man es einfach nur noch.
Ich habe für Staxrip zb einige Filter & Scripte die ich einfach in den Profilen eingebaut habe. Nach einer weile hat man damit schon ein sehr mächtiges Werkzeug.
Zb
MDeGrain 1&2 gegen Rauschen um die Kompremierbarkeit zu verbessern.
LimitedSharpenFaster fürs Schärfen so weiter.
asiloinfantile77
Also bei mir "Learning by Doing" und "schaun was passiert" Methode. Wobei ich schon bei DVDs mit Avisynth in verbindung kam. Hatte DVD2DVD-R benutzt und das basiert auf Avisynth. Irgendwann hat man dann angefangen zu gucken was das Tool im Hintergrund macht.
Und so nach und nach immer mehr Wissen dazubekommen.
http://avisynth.org/oldwiki/index.php?page=AviSynth+Deutsch
Es gibt ja auch ein Forum dafür.
Man muss ja oft nicht wissen warum etwas geht, sondern das es geht.
Übrigens:
Zitat von Koto99;476393Der Punkt ist einfach, wie ich das auch drehe es ist ein der Praxis kaum möglich da einen vorteil zu haben. Wer hätte zb eine 1000 Euro GK auf einen kleinen I3.
Da für die Decodierung nicht die GPU selbst, sondern der in der GPU integrierte Hardware-Videodecoder zuständig ist, und der sich bei High-End- und Low-Budget-Grafikkarte der selben Generation(!) NICHT unterscheidet (siehe hier), gibt es zwischen beiden auch keine Geschwindigkeitsunterschiede. Sprich: eine kleine Mobile-GPU mit VP5 decodiert das Video exakt genauso schnell wie die GPU einer aktuellen, sauteuren Grafikkarte mit VP5 . Das belegen auch die Doom9-Benchmarks:
GTX680 (= VP5) / Preis: ca. 500€
Zitatfps (min/max/avg): 83.34 | 146.17 | 135.61
GT520 (= VP5) / Preis: ca. 40€
Zitatfps (min/max/avg): 83.53 | 146.02 | 135.60
Kurz: eine schnellere/teurere Grafikkarte würde rein gar nichts bringen .
Ich bleibe aber dabei, dass wahrscheinlich am ehesten das Hin- und Herschaufeln der Videodaten ausbremst und deshalb DGDecNV im Vergleich mit einer halbwegs aktuellen MultiCore-CPU keine Vorteile bringt. Interessant wäre es aber zu sehen, ob durch aufwändige Filterung (z.B. HQ-Deinterlacing, Rauschfilter, Deblocking, bewegungsadaptive Frameinterpolation usw.) vielleicht eher ein Geschwindigkeitsunterschied zwischen CPU- und GPU-Decodierung auftritt...
Filter haben keine Wirkung. Warum sollten sie auch. Die arbeiten CPU basiert und mit x264 ist die CPU ja ausgelastet.
Warum sollte freigewordene Power durch die GPU auf die Filter wirkten und nicht auch auf die x264.exe ohne Filter?
Zitat von Koto99;476450Habe eine SSD also das ist es nicht. Und wenn Du nun mit anderen Faktoren kommst, ist das egal. Es ist nun mal so, der Grund ist eigentlich Wurst. Das ändert am Ergebnis nix.
Ich bezog mich damit auf den Datenbus, und nicht auf die Datenträgergeschwindigkeit. Anders ist es nicht zu erklären.
Ich weiß... ich weiß - dich interessiert nicht das "Warum". Mich hingegen schon. Denn wenn ich das "Warum" beantworten kann, dann weiß ich unter Umständen auch, bei welchen Voraussetzungen sich die Vorteile evtl. umkehren - sprich: ab wann ist DGDecNV FFMS geschwindigkeitsmäßig deutlich überlegen.
Und sag jetzt bloß nicht "Na immer." Wenn ich nämlich über ein simples AviSynth-Script (= eine einzige Zeile mit dem entsprechenden Quellfilter) FFMS und DGDecNV per AVSMeter vergleiche (in beiden Fällen logischerweise mit der selben Quell-Datei), dann scheint DGDecNV nicht nur schneller zu sein, sondern auch das System weniger zu belasten:
FFMS2
DGDecNV
Wenn also DGDecNV die Videoframes über AviSynth schneller an x264 liefern kann und gleichzeitig noch mehr CPU-Resourcen für x264 frei lässt, warum ist dann x264 + DGDecNV nicht wesentlich schneller als x264 + FFMS2?
Zitat von Koto99;476450Filter haben keine Wirkung. Warum sollten sie auch. Die arbeiten CPU basiert und mit x264 ist die CPU ja ausgelastet.
Deswegen ja die Frage: mehr Filter = mehr belegter Hauptspeicher + mehr benötigte CPU-Resourcen für AviSynth = weniger Resourcen für x264. Vielleicht macht sich dann (gerade deshalb) DGDecNV positiv bemerkbar.
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")
DGSource("C:\iND-nordsee.1080p.dgi")
Da habe ich zwar die CPU last runter aber bin auch deutlich langsamer. Wenn ich also eine PC
Bremse brauche ist das Ideal.
Ich habe aber auch eine ganz andere CPU. Es kann sein das deine CPU einfach lahm genug für die GK ist. Nicht böse gemeint.