Hybrid: Input -> x264/x265/Xvid/VP8/VP9/AV1

    So nachdem ich 2 Tage gegen cygwin gekämpft habe um die 1.1.5 zu bauen reichts mir.
    Es geht auch mit der 1.0.7:

    Cygwinports - Transcode

    cygwin1.dll dazu und es läuft ohne cygwin-installation.

    Im Folgenden ein paar Anmerkungen:

    Code
    avimerge.exe -i quell.avi -o ziel.avi -p weiteretonspur.end -f comments.txt


    Comments.txt siehe usr\share\doc\transcode-1.0.7\avi_comments.txt

    Code
    avisync.exe -i quell.avi -o ziel.avi -n (-1)*round(length/videoframelength) -a spurnummer(0..n)


    Delay wird nicht hart in die Datei gepatched sondern im Header angegeben.
    Etwas unorthodox gibt man hier kein Delay in Millisekunden an, sondern die Anzahl der Frames um die der Ton verschoben werden soll, und das genau invers zur Denkweise (- ist positives Delay, + ist negatives Delay.)

    Code
    avisplit.exe -i quell.avi -o basename -s "Size in mb" oder -t s1-s2[,s3-s4,..] (split von bis in hh:mm:ss.ms)


    Auch möglich ist es mit avisplit, Teilstück(e) auszuschneiden und wieder zu einer gesamten Avi zu schreiben.

    Unschön ist, dass man für jede tonspur einen erneut Muxen muss, aber das ist bei ffmpeg nicht anders, es ist nur schneller (wesentlich).
    Unschön ist, dass man das auch für jedes Delay machen muss.

    Leider reicht auch avifix.exe nicht um den ac3-bug von der ffmpeg-Ausgabe zu korrigieren.

    Es ist zugegebenermaßen nicht schön das via transcode-tools zu machen, aber es ist die einzige verlässliche und homogene Variante die ich gefunden habe.

    Rettet das den avisupport?

    Edit: Bezüglich Filesplitting fällt mir gerade ein, ob man nicht an der Cutstelle ggf. bei einem 2-pass entsprechend einen I-Frame erzwingen könnte beim Encoding um selbst minimale Asynchronitäten zu vermeiden. Allerdings cuttet avisplit eh schon an I-Frames in der Nähe und bei 32ms Alignment ist das eigentlich zu vernachlässigen (habs mal getestet, in einer 4 ebenen Cutcaskade konnte ich immernoch keine Asynchronität erkennen.)
    Und ich glaube im Gui fehlt der Support für Variance-Based AQ, falls der Encoder das unterstützt (evtl. auch erst zukünftig).

    2 Mal editiert, zuletzt von -TiLT- (16. Dezember 2010 um 03:20)

    Zitat

    Unschön ist, dass man für jede tonspur einen erneut Muxen muss, aber das ist bei ffmpeg nicht anders, es ist nur schneller (wesentlich).


    Ne, bei ffmpeg kannste mehrere Audiospuren auf einmal zusammen muxen.

    Zitat

    Variance-Based AQ


    .. hat das nicht vor einiger Zeit eh das alte AQ ersetzt? (http://git.videolan.org/gitweb.cgi?p=x…65752da9f2cd032 <-etwas verwirrt)

    Wegen .avi Support, wäre schön, wenn Du die tools irgendwo hochladen könntest, dann experimentiere ich mal mit ihnen etwa. ;) (neuere Version ist interessanter ;))
    Sehe ich das richtig:
    Davon ausgegangen ich habe einen Video und zwei .ac3 Audiostreams und der erste Audiostream hat einen Delay von 80ms und der zweite von -80ms, müsste man:
    1. Sicherstellen das der Videostream bereits in einem .avi Container steckt. (notfalls erst mit ffmpeg ein .avi erzeugen, falls der Stream als raw Videostream vorlag)
    2. mit avimerge den ersten Audiostream hinzufügen. (+ Inputstreams gegebenenfalls löschen)
    3. mit avimerge den zweiten Audiostream hinzufügen. (+ .avi aus 1. löschen + Inputstreams gegebenenfalls löschen)
    4. mit avisync den ersten Audiostream um zwei frames versetzen (+ .avi aus 3. löschen)
    5. mit avisync den zweiten Audiostream um zwei frames versetzen (+ .avi aus 4. löschen)
    6. Falls man noch Containertaggs haben will und ffmpeg die Files nicht wieder kaputt macht müsste man noch mal mit ffmpeg remuxen. (vermute aber ffmpeg würde die .ac3 Streams wieder falsch in das neue .avi schreiben)
    7. Falls man das File nun in X MB Teile unterteilt haben will müsste man noch avisplit aufrufen. (+ .avi aus 5. löschen)
    (habe gerade mit dem 1.0.7er Versionen herumgetestet)


    Cu Selur

    Das ist so richtig, außer Punkt 6, den erledigt man gleichzeitig mit dem letzten Schritt vor dem Splitting. (-f commentfile)

    Ich suche momentan noch nach Lösungen, das delay der Tonspuren im Vorfeld zu korrigieren (so wie delaycut oder eac3to), damit man sich einige Schritte sparen kann.

    Zitat von Selur

    .. hat das nicht vor einiger Zeit eh das alte AQ ersetzt? (http://git.videolan.org/gitweb.cgi?p=x…65752da9f2cd032 <-etwas verwirrt)

    Zurecht, ich meinte nämlich eigentlich AQ: Variance-Masking von XviD (gegenüber Luminance-Masking)

    2 Mal editiert, zuletzt von -TiLT- (16. Dezember 2010 um 18:09)

    Zitat

    Das ist so richtig, außer Punkt 6, den erledigt man gleichzeitig mit dem letzten Schritt vor dem Splitting. (-f commentfile)


    Stimmt! :)

    Zitat

    Ich suche momentan noch nach Lösungen, das delay der Tonspuren im Vorfeld zu korrigieren (so wie delaycut oder eac3to), damit man sich einige Schritte sparen kann.


    Lass mal, würde die Tonspuren lieber so lassen wie sie sind, da man ja eventuell nur eine Tonspur durchreicht die man nicht ändern will/kann.

    Zitat

    Zurecht, ich meinte nämlich eigentlich AQ: Variance-Masking von XviD (gegenüber Luminance-Masking)


    Wenn Du mir sagen kannst wie der entsprechenden xvidEncOpts Parameter sagen kannst, könnte ich dafür ne Option hinzufügen. Bis dato habe ich nur 0-Feedback bzgl. Xvid Encoding in Hybrid bekommen und bin deshalb davon ausgegangen, dass es so passt wie es aktuell ist. ;) (ist AQ bei Xvid nicht auch standardmäßig aktiviert bei den builds die es enthalten?)

    Cu Selur

    So mittlerweile hab ich ein Buildsystem für die 1.1.5.
    Es fehlen mir noch ein paar Pakete für eine vollständige Version, aber derzeit teste ich.
    Ein Bug der mir bereits aufgefallen ist:

    transcode kommt mit folgenden mp3 header Tags nicht klar:
    HDCD
    VALID_BITS

    Ich vermute, dass valid_bits der Auslöser ist, jedenfalls wird dann die mp3 nicht als solche erkannt.

    Wegen vaq bei XviD werd ich ebenfalls noch nachschauen. Der Weihnachtsstress ist im Moment kaum auszuhalten hier ;)

    Zitat

    Der Weihnachtsstress ist im Moment kaum auszuhalten hier


    Dito, vor allem weil ich nur mit einer Hand tippe (was auf einem M$ Naturalkeyboard wirklich doof ist) weil ich mir beim Wii spielen mit meinem Patenkind die Hand mit Power gegen die Kante einer Stuhllehne gedonnert habe -> bunte, fette Prellung (nix gebrochen oder so, aber tippen geht momentan nicht)

    Gab jetzt einen Kommentar, den ich nur so verstehen kann, dass nicht ffmpeg kaputte files erstellt, sondern es ein Fehler in vlc, mplayer, wmp, mpc-hc und ffplay ist, dass sie mit den erzeugten Files nicht umgehen können.
    Hab deshalb im selben Bugtracker einen neuen Eintrag für ffplay erstellt: http://roundup.ffmpeg.org/issue2454 :D
    Antwort: "This is not a valid issue."
    -> ich geb auf.

    cehoyos hat jetzt angemerkt, dass ffmpeg wohl .ac3 Files mit hohen Datenraten so multiplexed, dass kein Player damit klar kommt,.. (wobei sich das bei ihm immer noch nach einem Bug in den Playern und nicht in ffmpeg anhört,..)

    Da der Weg über die transcode Tools für meinen Geschmack leider viel zu viele Zwischenschritte beinhaltet und es, mit einem Blick auf die Bugliste, wohl noch eine Weile dauern wird, bis der Bug in ffmpeg gefixed ist, fliegt der .avi Output-Support erst mal raus.
    (Der Status ist mittlerweile übrigens: Open , was schon mal angenehm ist, da so zumindest die Hoffnung besteht, dass das Problem mal gefixed wird,.. )


    Cu Selur

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden