StaxRip Encoding-Frontend (Diskussion)

  • Ohne Avisynth ist keine wirkliche Alternative, denn ich bin zu begeistert von fft3dgpu.


    Das hab ich bei der letzten Systemauflage irgendwie ans laufen bekommen, wusste aber auch damals nicht wirklich, was ich da tat...


    hier ein "loadplugin", da ein aufruf... und irgendwann kam keine fehlermeldung mehr, und die parameter in fft3dgpu hatten eine auswirkung aufs ergebnis, was mir sehr gut gefiel. Die Kompression wurde schneller, die Qualität besser, und die Dateien kleiner, im Grunde ziemlich abgefahren...


    Jetzt werde ich da noch ein bischen dran rum frickeln, und versuchen denselben weg wieder zu gehen.


    Vom manuellen erstellen einer avs habe ich keinen blassen Dunst, und was Virtualdubmod ist, weis ich (außer dem Namen) auch nicht.

  • Eine AviSynth-Datei zu bearbeiten ist gar nicht so schwierig. Die Einführung in AviSynth als Skriptsprache ist dank der hervorragenden Anleitung, die AviSynth in seiner Dokumentation mit installiert hat, gar nicht so schwierig – vor allem, wenn man ohnehin schon ein wenig Beziehung zum Programmieren hat.


    VirtualDubMod ist eine Modifikation von VirtualDub, dem Standard-Freeware-Editor für AVI-Videos. Neben ein paar zusätzlichen Dateitypen, die neben AVI verarbeitet werden können, und einer etwas besseren Verarbeitug von VBR-MP3 und AC3 als Tonspuren (weshalb VirtualDubMod in einigen Konvertern auch zum Konvertieren von AviSynth-Video-Skripten über VfW-Codecs in AVIs benutzt wird), ist sein Hauptvorteil in diesem Zusammenhang ein integrierter Editor für AviSynth-Skripte, der dabei hilft, Skripte mit Syntaxfärbung zu bearbeiten und die Änderungen schnell in der Vorschau neu zu laden. Ansonsten ist es aber leider schon ein wenig veraltet...

  • Danke, das ihr mir helft!


    ein einfaches skript mit


    Code
    1. DirectShowSource("D:\testen\test.mkv")


    kann ich an virtualdubmod verfüttern, wenn nur die ffdshow-x64 installiert ist. Was sagt mir das jetzt?


    /edit: Das geht auch komplett ohne ffdshow, eigentlich wie erwartet.


    Was wären denn die Nachteile beim verwenden von ffdshow in 32bit? Das ist doch (soweit ich weis...) nur zum Abspielen von AV-Daten in Gebrauch, und nicht beim Erzeugen, oder?

  • Also, wenn es auch ohne ffdshow64 geht, bedeutet das, dass auch deinem System noch ein anderer 64bit H.264-Decoder installiert ist. Ggf. der Windows eigene.
    Das führt zu der Aussage, dass Staxrip nicht 64bit kompatibel ist.


    ffdshow ist ganz allgemein gesprochen ein codec für alles. Sowohl beim en- als auch beim decoden unterstützt er alles was so an Wald- und Wiesenquellen unterwegs ist. Quasi VLC ohne den Player, sondern als DirectShow-Filter.


    DirectShowFilter lassen sich NUR dann für Staxrip oger generell Encoding benutzen, wenn zwei Punkte zutreffen:


    1. Ich will in einem Rutsch von Frame 0 bis zum letzten Frame durchencodieren und auf keinen Fall schneiden.
    2. Ich weiß genau, welchen Filter für den Codec meiner Quelldatei ich im System als höchten Merit eingetragen habe und kann mir sicher sein, dass er so eingestellt ist, dass er nicht irgendwelche Qualitätsverschlechterungen vornimmt oder Frames weglässt, wenn er das Gefühl hat zu wenig CPU zu bekommen.


    Wenn man spontan nicht in beiden Fällen Ja sagen konnte, dann sollte man auf Frame-akkurate Decoder ausweichen wie dgdecode(NV/DI), oder ffmpegsource.


    Führt dich aber alles wieder dahin zurück, dass du deine Encodings mit avisynth32 gestaltest (was im übrigen auch geschwindigkeitstechnisch ok ist, da würde ich eher mal auf avisynthMT schielen.)

  • Okay, das macht Sinn!


    Nur mal als Zusammenfassung:


    Wenn ich ffdshow installiert habe (nach Standardeinstellungen - mit den mitgelieferten Konfig-Tools kann ich nicht viel anfangen...), dann Filme mit directshowsource in Avisynth lade, habe ich die Grundlagen für ein ordentliches Encoding gelegt, oder?


    Zu den Poteltialen von avisynth 64, oder 32bit:
    Meine Plugins in Staxrip sind
    source (welche auch immer, macht staxrip ja zum glück automatisch)
    Deinterlacing (falls erforderlich Tomsmocomp oder Tdeint)
    crop (manuell)
    fft3dgpu (Ganzer Rattenschwanz an Parametern, Sehr hoher Aufwand)
    removegrain(22)


    Diese Kombination hat sich in aufwändigen Vergleichen als mein persönliches Optimum herausgestellt.


    Das einzige, was Rechenleistungsintensiv ist, ist die FFT3d, die allerdings auf der Graphikkarte läuft, die damit ohnehin unterfordert ist (<10% Auslastung).
    Interlaced-Material hab ich kaum, daher ist das für den Regelfall nicht tragisch, wenn das etwas langsamer laufen sollte.


    Ergo: Avisynth ist eh nicht CPU-Intensiv bei mir, sodass der Nutzen von 10, oder 20% mehr Leistung ohnehin gering ausfallen wird. Oder hab ich da jetzt wieder irgendwas nicht bedacht?


    Frage:
    Kann ich das auf diesem Wege Avisynth32-gefilterte Video an X264-64bit verfüttern, und davon auch profitieren? Hier würden mich 20% Zusatzleistung sehr interessieren...


    Grüße
    Dis

  • Hallo!
    Ist einer der Filter in Staxrip dazu geeignet, beim Encoding die manchmal entstehenden "Treppenstufeneffekte" an irgendwelchen schräg verlaufenden Kanten,Linien o.ä. im Bild zu verhindern ? Hab jetzt mit x264 in verschiedenen Qualitätseinstellungen rumprobiert,ebenso mit DivX und Xvid..aber dieser "Stufeneffekt" bleibt auch bei sehr hohen Qualitätseinstellungen erhalten.

  • Hi


    ich benutze Staxrip derzeit recht intensiv. Gelegentlich kommt aus mir unerklärlichen Gründen nach dem Start eines Kompressions-Prozesses die Meldung, daß der Stream nicht geöffnet werden konnte. Es handelt sich um mit Fraps gecaptureten content, üblicheweise 4GB chunks, die ich mit Merge zu größeren Videos zusammenfüge. Fast immer funktioniert das problemlos. Dieser Tage versuchte ich eine deutlich größere Menge von chunks als normal (über 30 statt normal so 3-7) zu einem Video zu mergen und bekam die Meldung, daß der Stream nicht geöffnet werden könnte. Bin ich halt ohne weitere Untersuchung wieder zu kleineren Portionen übergegangen, was mit den gleichen Dateien problemlos funktionierte.


    Eben wollte ich eine Gruppe aus drei chunks mergen, wieder die Fehlermeldung. Mehrmals neu versucht, immer das gleiche. Die chunks selbst ließen sich alle mit VLC betrachten. Erstmal versucht die chunks einzeln in Staxrip zu prozessieren. Ging auch. Dann paarweise, auch keine Probleme. Dann mal mit mehreren anderen zu einem 7er Pack gemergt: ging nicht! Dann wieder im 3er Pack probiert: nun gings plötzlich!


    Was kann sowas verursachen? Arbeite unter Windows XP SP3. AVS hab ich dieser Tage erst neu installiert.

  • Um mehrere Videos an einem Stück zu verarbeiten, muss man sie nicht "physisch" als Datei verbinden. Man kann in AviSynth auch mehrere Videoquellen öffnen und diese dann im Skript "logisch" aneinanderhängen: Mit UnalignedSplice() = + oder AlignedSplice() = ++. Der Unterschied zwischen beiden liegt nur in der Behandlung von Tonspuren, wenn die eine andere Länge als die Videospur haben.


    Für die erfolgreiche Verwendung mehrerer Quellvideos in einem Skript kann es allerdings wichtig sein, einen Codec oder Decoder zu verwenden, der mehrfach ausgeführt werden kann. Sollte der originale FRAPS-Codec also bei mehreren AviSource()-Funktionen fehlerhafte Videoinhalte zeigen oder gar die Verarbeitung zum Absturz bringen (am besten vorher mal in VirtualDub testen, Video nach Fehlern scannen), kann es helfen, statt dessen den VfW-Codec für FRAPS in ffdshow zu benutzen (Start › [Alle] Programme › ffdshow › VFW-Konfiguration › Decoder › Fraps » libavcodec); vielleicht kann auch FFmpegSource2 FRAPS-Videos decodieren, also FFVideoSource() statt AviSource().

  • Hab in letzter Zeit zunehmend den oben beschriebenen Fehler. Die Fehlermeldung im Log:


    Code
    1. x264 failed with exit code -1
    2. avs [error]: AviSource: Could not open video stream in any supported format.
    3. (C:\Fraps\bzone 2011-05-19 21-31-42-61 temp files\bzone 2011-05-19 21-31-42-61.avs, line 2)
    4. x264 [error]: could not open input file `C:\Fraps\bzone 2011-05-19 21-31-42-61 temp files\bzone 2011-05-19 21-31-42-61.avs'
    5. avs [error]: AviSource: Could not open video stream in any supported format.
    6. (C:\Fraps\bzone 2011-05-19 21-31-42-61 temp files\bzone 2011-05-19 21-31-42-61.avs, line 2)
    7. x264 [error]: could not open input file `C:\Fraps\bzone 2011-05-19 21-31-42-61 temp files\bzone 2011-05-19 21-31-42-61.avs'


    Sie erfolgt immer unmittelbar an dem Punkt, an dem x264 normalerweise den Kompressionsprozeß begänne. Habe bisher keine Umgebungsbedingungen festellen können, die diesen Fehler begünstigen oder reduzieren. Meistens funktioniert es bei späteren Versuchen plötzlich, ohne daß erkennbar wäre, warum. Eben hab ich folgendes versucht: die sieben Chunks, die ich erfolglos zu mergen versuchte, sind Nummer 22-28 in einer Kette von 37 Chunks. Um auszuschließen, daß es an einzelnen Chunks liegt habe ich versucht, die Chunks #23-29, sowie #21-27 zu mergen, was beide male problemlos funktionierte. Gleich nochmal wieder #22-28 probiert, wieder Error. *kopfkratz* Wat mach dat wohl fürn Fehler sein?

  • Was genau versuchst du denn überhaupt? Mehrere Videos öffnen und aneinanderhängen? Wie sieht dein AviSynth-Skript dazu aus?


    Klingt ja fast, als würdest du mit den einen sieben eine Summe überschreiten, die mit anderen sieben nicht überschritten wird. Eventuell die 2 GB RAM pro 32-bit-Applikation.

  • Ich starte StaxRip und klicke "Single or Merge", wähle dann im Öffnen-Dialog sieben aufeinanderfolgende Fraps-AVI-Chunks (weils kombiniert etwa 15 Minuten ergibt), die dann von Staxrip zu einem Video gemerged werden (sollen). Im AVS script steht anschließend einfach die Zeile AVIsource("datei1", "datei2" ....).


    RAM-Limit? Dann wär die Fehlermeldung, daß AVS den Stream nicht öffnen kann, zumindest ungewöhnlich. Aber irgendwas in der Art muß es wohl sein.

  • Hi,


    ich benutze noch StaxRip 1.1.7.0, bei der Version müsste ich feststellen, das dass Bild manchmal für ein paar Sekunden ruckelt (mp4 Container) bei einer codierten Aufnahme. Das Ausgangsmaterial ist ok.
    Wenn ich manuell die codierten Dateien in einen anderen Container packe (mp4/mkv) mit mkvmerge oder yamb, dann ist das ruckeln verschwunden.


    Videomaterial ist h264: Profil x264 Film HQ


    Beim manuellen packen der Streams über Console in mp4 mit mp4box.exe, die bei Version 1.1.7.0 mitgeliefert wurde, tritt der gleiche Fehler auf.


    Wollte nach StaxRip_1.1.7.1 wechseln und nachschauen ob der Fehler immer noch existiert. Aber das Programm benötigt von mir immer DGIndexNV und DGDecodeNV. Dies ist nicht bei den mitgelieferten Applications dabei. Ausserdem konnte StaxRip 1.1.7.0 doch auch ohne auskommen?

    Beim manuellen packen der Streams über Console in mp4 mit mp4box.exe, die bei Version 1.1.7.1 mitgeliefert wurde, tritt der Fehler nicht auf.



    Kann mir jemand helfen, wie kann ich das DGIndexNV/DGDecodeNV Problem in der neuen StaxRip Version lösen?


    Danke im Vorraus!


    MfG
    jim936


  • Wollte nach StaxRip_1.1.7.1 wechseln und nachschauen ob der Fehler immer noch existiert. Aber das Programm benötigt von mir immer DGIndexNV und DGDecodeNV. Dies ist nicht bei den mitgelieferten Applications dabei. Ausserdem konnte StaxRip 1.1.7.0 doch auch ohne auskommen?


    Das Problem ist,daß in den Settings der Staxrip-Version 1.1.7.1 automatisch die Nutzung von DGIndexNV/DGDecodeNC voreingestellt ist. Kannst du unter Tools-->Settings-->Demuxing ausschalten. Einfach die Haken für beide Programme wegnehmen.

  • Hallo zusammen


    muss auch mal wieder ne doofe Frage stellen :D


    Hab jetzt nach Ewigkeiten mal wieder Stax auf meinem Laptop nutzen wollen.
    Da ich noch in der Version 1.1.5*irgendwas unterwegs war, dachte ich mir, ich upgrade mal auf den neuesten Stand.
    Aber irgendwie war das offenbar ein Fehler, denn ich kann Stax überhaupt nicht mehr nutzen, weil er mich schon beim Template erstellen ausknockt und zwar damit...



    Jetzt ist mein Englisch in all den Jahren nicht besser geworden :ani_lol: doch ich verstehe das so, daß ich 15 $ spenden darf, um an diese Lizenzdatei zu kommen, was ich mich in sofern verwundert, da stax ja eigentlich komplett Freeware sein sollte.


    Ebenso verstehe ich nicht, ob oder wofür ich diese App brauche und bin daher auch nicht wirklich gewillt dafür dann 15 $ zu bezahlen um es vielleicht nie zu brauchen.


    Genauso stutzig macht mich folgender Satz ...


    Zitat

    DGDecNV is a decoder/frameserver for AVC, MPEG2, and VC1 streams that runs on the GPU of Nvidia graphics card


    Mit meinen Nicht-Englisch-Kenntnissen verstehe ich das so, daß es speziell für Nvidia GKs ist...


    Zusammgefasst ....


    Brauch ich diese App wenn ich Stax auf PC/Laptops nutze mit Nvidia GK oder ist es generell eine App die man so oder so bespenden darf um Stax nutzen zu können und gibt es irgendeine Alternative zu der App ???

  • Das Problem ist,daß in den Settings der Staxrip-Version 1.1.7.1 automatisch die Nutzung von DGIndexNV/DGDecodeNC voreingestellt ist. Kannst du unter Tools-->Settings-->Demuxing ausschalten. Einfach die Haken für beide Programme wegnehmen.



    Danke für deine Antwort.


    Ich verstehe nur nicht warum das gemacht wurde, wenn man DGIndexNV/DGDecodeNC nicht kostenlos benutzen kann... .
    Die alte Version nutzt DGIndex/DGDecode und läuft damit super. Also gibt es keine Möglichkeit dies wieder in den Settings zu ändern?
    Das StaxRip nicht mehr Demuxen kann ist schon ein Nachteil...


    Kann ich die neue mp4Box mit der alten ersetzen und weiter 1.1.7.0 nutzen, obwohl mir eine falsche Version angezeigt wird? - aber das ist dann auch nur eine vorübergehende Lösung.

  • DGDecNV ist ein Decoder, der speziell den PureVideo-Decoderchip ab Version 2 der Nvidia-Grafikkarten ab Generation 8 (Architektur G84) benutzt. Um diesen Decoder nutzen zu können, musst du ihn bei Donald Graft registrieren (http://neuron2.net/dgdecnv/dgdecnv.html - Donate).


    Der Programmierer von StaxRip (stax0711) hat davon finanziell keinerlei Vorteile – wenn du ihn unterstützen willst, dann schau auf der SourceForge-Seite des Projektes staxmedia nach einem "($) Donate"-Link.


    Wenn du für DGDecNV kein Geld ausgeben möchtest oder keine passende Grafikkarte hast, dann kannst du auch die Benutzung dieses Filters in StaxRip deaktivieren. Es gibt noch andere Quellfilter, die alternativ verwendet werden können.
    __


    Ohne die Nutzung des Nvidia-Decoderchips gibt es von Donald Graft noch getrennte, aber technisch teilweise veraltete Plugins (DGMPGDec für MPEG2 mag noch gut funktionieren, bis auf den eher mäßigen Deblocker; DGAVCDec ist wirklich wesentlich eingeschränkt auf MPEG4-AVC-Video weniger Quellen, und soll deshalb nicht mehr angeboten werden); mit dem Decoder DiAVC von 'schweinsz' arbeitet auch DGAVCDecDI zusammen, kostet aber für beide Komponenten je eine Kleinigkeit. Kostenlos wäre FFmpegSource2 = FFMS2, der hat jedoch auch so seine Eigenheiten. "Letzte Chance" ist DirectShowSource oder DSS2, die verlassen sich aber auf die in Windows installierten DirectShow-Filter, was oft keine gute Idee ist.

  • Nur mal so nebenbei..


    kann es sein dass der x264 mit VC1-Material sehr langsam zu werke geht? Bei mir geht die FPS bei CRF 18, Preseit Slow, Tune Film unter 1 FPS...normalerweise sinds fast 10.


    Oder hat StaxRip da Probleme???


    Besten dank


    Lapje

  • x264 ist ein Encoder, der unkomprimiertes Video benötigt, der hat selber keinen VC-1-Decoder. In den meisten Fällen bekommt er YV12-Video aus AviSynth.


    StaxRip ist nur eine Benutzeroberfläche, die lediglich die eigentlich aktiven Programme im Hintergrund steuert, insbesondere den Encoder mit Video aus einem AviSynth-Skript versorgt.


    Wenn etwas Probleme hat, dann ist es der Decoder, der vom AviSynth-Skript verwendet wird. Da bisher kein echtes AviSynth-Plugin die interlacete Variante von VC-1 beherrscht, dürfte für VC-1 auch weiterhin DirectShow bevorzugt werden. DirectShow ist abhängig von Splitter-Filtern für den Container und Decoder-Filtern für den Inhalt.


    Bei beschädigten Videodateien kann bereits der Splitter Probleme haben, wenn die Datei nicht mehr die Zusatzinformationen enthält, durch die der Splitter erfährt, an welcher Stelle sich Schlüsselbilder befinden, wo der Decoderfilter die Decodierung auch am Ende des Videos sofort direkt neu beginnen kann (AviSynth kann je nach verwendeten Filtern manchmal mehrere Bilder vor und nach der aktuellen Position neu anfordern). Dann müsste er das Video jedes Mal von vorn zumindest durchsuchen, wenn nicht gar komplett durch decodieren, was gegen Ende des Filmes dann ewig lang dauert. Helfen kann hier das Remultiplexen vor der Verarbeitung – entweder in das selbe Container-Format, oder in ein vorteilhaftes anderes, wie MKV. Aber auch Parameter wie "seek" oder "seekzero" in DirectShowSource() können schon helfen.

  • Moin,


    ich habe hier ein seltsames Problem mit Staxrip.
    Unter Optionen sind die Standardeinstellungen unverändert in Bezug auf Croppen und AR.
    Jetzt habe ich hier eine Film, anamorph codiert, 2,40:1, also noch mit schwarzen Balken. Nach dem Einlesen/Indizieren ermittelt Stax den Autocrop mit 2/2 + 74/74 ganz korrekt. DAR der Source ist korrekt 1,82 und beim Rezise zeigt er dann auch korrekt die neue DAR von rund 2,4 an.


    Nur beim Codieren (Ziel Xvid, 2pass, 2 Audiospuren) bricht er nach dem first pass ohne Fehlermeldung einfach ab, im Log steht auch nichts dazu. Gerade nochmal rumprobiert, er macht auch keinen Compressibility Check.
    Wenn ich den Croppfilter deaktiviere und die schwarzen Balken dran lasse, dann läuft der Codierungsvorgang ohne Probleme durch ... :confused: