Probleme mit Staxrip (HD-TS, DGIndexNV)

    Ich bin's nochmal. :)
    Erstmal SORRY!!
    Wollte hier keine große Diskussion lostreten. :rolleyes:


    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:

    Zitat

    Hab 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;476188

    Das 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.:


    ... bei SRestore gibt's eine Readme (und den schon erwähnten MediaWiki-Eintrag):

    Zitat

    notwendige 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):


    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 ;) ...

    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.

    Zitat von Koto99;476393

    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.


    (...)


    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 Koto99;476393

    Wobei 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.

    Zitat

    Beides 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.


    http://forum.gleitz.info


    Man muss ja oft nicht wissen warum etwas geht, sondern das es geht. :-)

    Übrigens:

    Zitat von Koto99;476393

    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.


    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€

    Zitat

    fps (min/max/avg): 83.34 | 146.17 | 135.61


    GT520 (= VP5) / Preis: ca. 40€

    Zitat

    fps (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;476450

    Habe 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;476450

    Filter 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. :-)