StaxRip Encoding-Frontend (Diskussion)

  • VelleX


    Zur Erkennung der Stream IDs und allen anderen Stream Eigenschaften benutzt StaxRip grundsätzlich MediaInfo, für jeden Dateityp, Programme wie mkvinfo werden nicht benutzt. Mit TS funktioniert das leider nicht, irgendwelche Änderungen daran wären eher schwer und wenig aussichtsreich.


    DGDecNV würde mit deinem Sample zurechtkommen, gilt auch sonst als zuverlässig, in StaxRip ist DGDecNV so integriert dass es alle Audiospuren extrahiert (demux) werden.


    Ansonsten kannst du Settings > Demuxing > dsmux versuchen, damit wird die TS Datei in eine MKV Datei umgewandelt, dafür muss der Haali Splitter installiert sein, mit manchen Dateien gibt es leider Probleme, dsmux wird nicht mehr aktiv entwickelt. TS-Doctor hat ebenfalls eine Option um mit Haali MKV zu erzeugen, ich kann dir nicht sagen ob dass stabiler wie dsmux ist.


    Ansonsten kann man auch mit mkvtoolnix nach MKV konvertieren, in der Vergangenheit war es so dass mkvtoolnix scheinbar mit Zeitstempeln gearbeitet hat was in StaxRip zu async Problemen geführt hat, wenn man TS-Doctor verwendet kann es sein dass es dieses Problem nicht gibt, müsste man probieren, die von Haali erzeugten MKV Dateien haben keine Async Probleme verursacht.


    Kann TS-Doctor nicht demuxen?

  • Hab gerade ein neues Build hoch geladen, die demuxing GUI unterstützt neben mkvextract und mp4box jetzt auch ffmpeg (bis jetzt nur Audio), da ich die Einstellungen nicht zurückgesetzt hab muss man sie manuell zurücksetzten:



    Tools > Settings > Demuxing > Restore


    oder nur den ffmpeg Demuxer hinzufügen:


    Tools > Settings > Demuxing > Add



    Standardmäßig sind avi, ts und flv als Eingabe Dateityp für den ffmpeg Demuxer eingestellt, lässt sich beliebig editieren.


    Außerdem sollten ffmpeg und mkvmerge jetzt auch für TS korrekte Stream IDs verwenden.


    Mit dem Brexit Sample war der Ton async wenn Audio demuxt wurde (delay stammt von MediaInfo), wenn man nicht demuxt und konvertiert sondern mkvmerge direkt die Audiospur aus der TS Datei einlesen lässt dann ist alles synchron.

  • Ich werde die neue Build auch mal testen wenn ich Zeit habe. Hab jetzt aber auch mal DGDecNV integriert zum testen.


    Das mit dem Async Audio, da hatte ich mal irgendwie das Problem, dass wenn mit MKVExtract demuxt wurde, der Ton dann async war, aber mit eac3to nicht. Kann mich aber nicht mehr genau erinnern.
    Über MediaInfo werden ja zb die -1112ms angezeigt als Delay. EAC3TO erkennt aber zb -1691ms.
    Vielleicht fügt EAC3TO automatisch das Delay hinzu. Dann würde das aber bei StaxRip im grunde doppelt geschehen wenn man den Ton umwandelt.
    In der Log seh ich allerdings nichts. Wenn ich mit EAC3TO nur demuxe steht das schon drin.


    Hab aber auch mal die TS direkt in MKV gemuxt. Da bekommt man wieder andereres Ergebnis. Ist zwar sync, aber die Framerate ist dann auch anders
    Bildwiederholungsrate : 49,921 FPS
    originale Bildwiederholungsrate : 50,000 FPS



  • Hallo Stax76


    In den letzten drei Builds wird leider das Hauptfenster und die Job-Ablage währenddessen Encodiervorgang nicht mehr ausgeblendet.
    Das Nervt irgendiw da sonst nur das Logfenster sichtbar war.


    ASRockZ170Ext.4 I-5 Skylake(K)
    LG OLED TV 55C17 :) Panasonic Blu-Ray Player
    Denon AVR 4520 DTS-HD :ja: Canton Stand-LS 6X+2X Center+2X Surround-Back

  • Hi, ist OK weil:


    Jeder einzelne Job wird in einer neuen und eigenen Instanz ausgeführt, eine Instanz führt niemals mehr als einen Job aus.


    Du kannst mit der Hauptfenster Instanz weiter arbeiten oder sie komplett schließen.


    Die Standby/Shutdown Funktion geht nur wenn ausschließlich Job Instanzen ausgeführt werden.


    Nach wie vor kann man beliebig viele Instanzen parallel die Jobliste abarbeiten lassen.

  • Hi stax76!



    So sieht es wieder gut aus!



    Aber hier wirkt der UI-Skalierungsfaktor 1,30 zu groß.
    Cursor verschwindet ins sankt nimmerleinsland.
    Ich muss immer gerade beim öffnen des Code-Editors die UI-Skalierung auf 1,00 zurückstellen,
    damit man überhaupt erst mit diesen arbeiten kann.


    Ansonsten ist dein Tool erste Wahl... auch Rigaya´s Encoder einfach nur Top!


    MfG
    Roadrunner

    ASRockZ170Ext.4 I-5 Skylake(K)
    LG OLED TV 55C17 :) Panasonic Blu-Ray Player
    Denon AVR 4520 DTS-HD :ja: Canton Stand-LS 6X+2X Center+2X Surround-Back

  • Hi RoadrunnerRR,


    wenn ich die Sache richtig verstanden hab dann ist das Problem die Höhe des Dialogs. Ich hab ein neues Build hochgeladen wo die einzelnen Text Felder auf ca. 10 Zeilen beschränkt sind.


    Eventuell ist es geschickter den Code auszulagern und in StaxRip zu importieren, siehe Import:


    http://avisynth.nl/index.php/Import



    edit:


    15 Zeilen dann im nächsten Build


  • So ist es Super Danke...dieser Schönheitsfehler war von Anfang an da,
    hatte mich nicht wirklich gestört aber jetzt war ein passendes Thema da.


    Roadrunner

    ASRockZ170Ext.4 I-5 Skylake(K)
    LG OLED TV 55C17 :) Panasonic Blu-Ray Player
    Denon AVR 4520 DTS-HD :ja: Canton Stand-LS 6X+2X Center+2X Surround-Back

  • Beim *:avi-Import als UT Video (ULH0) folgendes Problem mit chroma subsampling. Es wird korrekt als 4.2.0 angezeigt. Kodiere ich mit x265, wird chroma subsampling als 4.2.2 ausgegeben. Spielt der BD-Player nicht ab. Bei x265-Einstellung auf Main Profile erscheint die Fehlermeldung: main profile not compatible with i422 input chroma subsampling.
    Ein einfaches Skript mit avs2yuv encodiert korrekt.


    Läuft doch nicht korrekt: mit x264.exe erscheint die Meldung: resize warning: converting from yuv422p to yuv420p.
    Der Fehler liegt somit nicht bei Staxrip. Erzeugt wurde das lossless-File mit Aviutl (interlaced kodiert).
    Mediainfo zeigt 4.2.0

    Einmal editiert, zuletzt von hdst () aus folgendem Grund: Berichtigung

  • Ein kurzer Test mit dem Lagarith Codec zeigt ein korrektes chroma subsampling. Allerdings weiß ich nicht, ob der für lossless interlace-Kodierung gut geeignet ist. Der Fehler ist mit ziemlicher Sicherheit nicht bei Staxrip zu suchern.



    2 Mal editiert, zuletzt von hdst () aus folgendem Grund: Log-Dateien