Audio delay mit X6 unter x264vfw

  • Hallo,
    habe ein Audio Delay beim konvertieren:

    Software Vdub MPEG2 1.6.19
    Codec x.264vfw Rev. 1195
    Lame MP3
    Eingangsvideo MPEG2
    Ausgangsvideo x.264 + Mp3 in avi Container

    Vor paar Tagen habe ich die CPU erweitert und seitdem beim konvertieren ein Audio Delay von ca. 150ms. Das kenne ich so nur wenn man B-Frames nutzt und läßt sich über den Vdub Hack fixen oder alternativ in dem man kein Audio interleaving macht, das ist aber wenig sinnvoll weil das encoding dann länger dauert und mir der X6 unterm Strich geschwindikgeitsmäßig dann gar nix bringt zum alten X4.

    Habe nunmal die neuste x.264vfw (rev. 1895) probiert, die stürzt interessanterweise im Hyperhtreathingmode mit dem X6 ab und läuft nur im (sehr langsamen) Sliced Mode. Da ich hier mehrere AMD CPUs rumliegen habe - steckte ich mal testweise einen X2 6000+ und den X4 955 nochmals rein.
    Mit keinen dieser CPUs ist dieses Audio Delay.
    Wieso nur mit dem X6 die Probleme? :huh:

    Mit den anderen CPUs liegt die Auslastung bei 96-99%, der X6 kommt auch "nur" auf max. 85% Auslastung. Ist das normall so?
    Hatte vorher den DualCore Optimizer im System drin, denn habe ich nun deinstalliert - nur ist der dann auch wirklich raus - oder anders rum gefragt, benötigt der X6 einen Core Optimizer in XP?
    thx. Olaf

    3 Mal editiert, zuletzt von Der_Lurchi (27. Januar 2011 um 17:41)

  • x264 hat keinen Punkt im Namen.

    Und wozu den VfW-Codec? Und vor allem: Wozu den AVI-Kontainer? Es hat schon seinen Grund, warum der EXE-Encoder und MP4 oder MKV empfohlen werden. Mag ja sein, dass es mit VirtualDub-MPEG2 "einfacher" scheint; aber es ist dann eben nicht zuverlässig und korrekt.

    Der "Dual Core Optimizer" ist nicht zwangsweise notwendig. Der soll eventuell helfen, mehrere Prozesse auf mehrere Kerne zu verteilen, wenn das Betriebssystem das nicht richtig macht. Aber im Falle des x264-Encoders als EXE spielt der keine messbare Rolle.

  • Zitat

    aber es ist dann eben nicht zuverlässig und korrekt


    Das ist eine Pauschalaussage die du einfach fällst, ohne überhaupt die vorgenommenen Einstellungen im Encoder oder sonstwo zu kennen - denn schließlich ist es auch denkbar, das im Multithreading Menü oder sonstwo irgendetwas anders eingestellt werden müßte was mir vielleicht entgangen ist. Zum anderen gibt es "soviele Jahre" den X6 nunmal noch nicht und da mit anderen CPUs vom singlecore bis rauf zum Quad dieses Problem nachweislich nunmal nicht reproduzierbar ist, stellt sich daher auch wieder die Eingangsfrage:

    Warum entsteht mit dem 6 Kerner dieses Delay?

    Warum gibt es dieses Delay nicht wenn man ohne "interleaved audio" encodet?
    (das Audio wird ja dann in einem Stück am Schluß geschrieben)
    Ist das dann also letzlich überhaupt ein Problem des encoders oder eher von vdub oder hängts doch OS seitig?
    In der installierten Software sehe ich nämlich immer noch einen "AMD Processor Driver 1.3.2.053" datiert mit Installationsdatum von 2009.
    Was ist das für ein Softwareding (von MS ist es zumindest nicht)?

    3 Mal editiert, zuletzt von Der_Lurchi (27. Januar 2011 um 22:51)

  • Hat x264vfw auch einen "threads"-Parameter? Wenn ja, probier' doch mal probehalber threads=6 zu setzen. (Soviel Threads müssten ja auf einem X4 zur Anwendung kommen.) Vielleicht hat der vfw-Codec einfach einen Bug mit "vielen" Threads.

    Auch wenn's viele nicht hören wollen - es hat schon seine Gründe, warum AVC nach Möglichkeit nicht in AVI gepackt werden sollte. Es geht, aber es ist technisch problematisch. Und wenn der Encoder "massiv" parallele Threads verwendet, werden die Probleme ... sicher nicht kleiner. Wenn, dann eher größer.

  • Hallo Didee
    Das sind die Settings:
    [Blockierte Grafik: http://www.abload.de/thumb/x264o76z.jpg]
    komischerweise macht es keinen nennenswerten Unterschied ob ich Threaths auf 5 oder 6 stelle (oder auch höher)
    Mit dem X4 ist das hingegen anders, denn da macht es sehr wohl einen Unterschied in der Encodingspeed wie auch CPU Auslastung was man da ab 4 Threaths aufwärts einstellt. Nur anscheinend mit dem X6 nicht wesentlich (Auslastung bleibt recht gleich).
    Zeitlich sieht das so aus: Der Quad @3.8Ghz braucht ca. 30Minuten um einen Spielfilm in vdub zu konvertieren und der Sechskerner @3,5Ghz braucht auch 30Minuten.
    Keine Ahnung, kann es sein das das in der Relation vollkommen üblich ist?

    Wie gesagt scheint das Delay Problem sich über die Vdub Hack Flag fixen zu lassen, der genaue Grund würde mich aber schon interessieren und denke auch das es irgendwie mit den Threathing Optionen zusammenhängt - zumindest finde ich die relativ geringe CPU Auslastung mit max 85% eher unüblich. Man kann ja auch noch über die Command Line Befehle eingeben, die nicht in den Registerkarten sind - gibts darüber irgendwas das man probieren könnte?

    2 Mal editiert, zuletzt von Der_Lurchi (28. Januar 2011 um 02:31)

  • Hallo,
    da hier offensichtlich keiner was weiß, wurde das Thema mittlerweile mal auf Doom9.org behandelt und falls irgendjemand dasselbe Problem mal haben sollte:
    Ursache war ein CodecBug bei der MMX Befehlserweiterung für AMD CPUs, den der Entwickler daraufhin behob was ich sehr lobenswert finde. (x264vfw.1882kMod.x86 ist die gebugfixte)
    Der Rest liegt am Vdub Mod, man muß bei dem Sechskerner auf mind. Vdub 1.9 + MPEG2 Plugin umswitchen. Es gibt u.a. eine vdub Exp Version womit sich das Delay anscheinend sogar beseitigen läßt ohne Direct Output, denn diese Version hat div. Settings die die normalle Vdub nunmal nicht hat. Die Schlüsselwerte sind:
    Video compression threath
    Video filter threathing
    Video fiilter process ahead
    Das ganze encodet nun auch erstaunlich schnell - einen ganzen Film dauert nur noch 18Minuten statt 30Minuten bei 98% CPU Auslastung.
    Bringt rund 30-40% mehr Speed. Sogar nicht Multithreathingfähige Codecs wie der VP7, verteilen sich interessanterweise nach Aktualisierung der Vdub auf alle 6 Kerne und laufen sogar gleich doppelt so schnell, ebenfalls xvid & Co. :lol:

    Selbst wenn keiner hier x264vfw nutzt,
    verwundert es aber schon das hier im ganzen Forum anscheinend auch niemand vdub (richtig) kennt
    Die jeweilige Vdub Version und die vorgenommen Settings dadrin :ja: ist nämlich der einzigste Grund für die schlechte Skalierung/Auslastung bei einem Sechskerner.

    Einmal editiert, zuletzt von Der_Lurchi (2. Februar 2011 um 15:04)

  • Zitat

    da hier offensichtlich keiner was weiß,


    Hört, hört! :D

    Dass im Quellcode ein AMD-spezifischer Bug drin war, das wird natürlich kaum jemand wissen. (Woher denn auch. VfW wird nur von wenigen verwendet. Und wenn mal etwas nicht wie vorgesehen funktioniert, dann wühlt man sich nicht durch zwanzig Kilometer abstrakten Quellcode, um zu sehen, ob irgendwo ein Plus und ein Minus vertauscht sind....)

    Der ganze Rest der Post ist ein Mix aus "unzutreffend", "Halbwissen" und "Fehlinformation". Ich erklär' später mal ein wenig, wie das alles zusammenhängt (ausser jemand anders ist schneller) - hab gerade nicht die Zeit, bin noch auf Arbeit.

    {Wenn ich bei Tankstelle B tanke, läuft mein Auto danach besser, als wenn ich bei Tankstelle A tanke. "Tanke B hat viel besseres Benzin als Tanke A!!!" - Falsch. Tanke A liegt in der Ebene. Tanke B liegt am Berg, und man fährt beim wegfahren bergab.}

    ***

    Es heißt "Threading", nicht "Threathing". BITTE! Danke.

  • Vielleicht eher "threatening". Aber das bedeutet schon was ganz anderes... :rolleyes:

    Wie schon erwähnt: MPEG4-AVC (H.264) ist für VfW nicht geeignet. Wer's trotzdem unbedingt erzwingen will, der muss mit überraschenden Problemen leben, die sonst keiner nachvollziehen kann.

    Na ja, aber trotzdem ... danke für die ansatzweise Klärung. Jetzt haben wir noch einen Grund, von x264vfw abzuraten.

  • Zitat

    x264 hat keinen Punkt im Namen.
    Vielleicht eher "threatening". Aber das bedeutet schon was ganz anderes...


    Anscheinend ist das dauernde Geunke wohl sowas wie ein Hobby und laß mich raten, dabei wird dir vermutlich auch nie langweilig. :D
    .

    @Didee
    Halbwissen? Na und, dann habe ich eben nur Halbwissen und wenn schon, dann sind wir ja immerhin schon zwei :zunge: - denn irgendeine Problemlösung hattest du doch auch nicht parat. Deine Äußerung (nicht nur hier) hab ich verstanden, nur verstehe ich aber auch das die wenigsten letzlich auf das eigentliche Thema eines Eingangspostings zurückkommen. ;)

  • Klar weiß ich auch nicht alles. Aber ich bin mir einigermaßen im Klaren darüber was ich weiß, und was nicht. Wenn ich irgend etwas behaupte, dann i.d.R. nur, wenn ich mir sehr sicher bin, damit auch Recht zu haben. Wenn ich einen Fehler mache gebe ich das auch zu - allerdings ist das lästig. Und deswegen achte ich darauf, nach Möglichkeit gar nicht erst in die Situation zu kommen. Und es ist tatsächlich ganz einfach: wer Recht hat, der muss auch nichts widerrufen.

    Weil ... im Ernst: um die gleiche Menge an Fehlinformation zu produzieren, die Du allein in Dein letztes Posting hineingepackt hast ... dafür brauch' ich mindestens ein ganzes Jahr! :D

    Angefangen mit der "Krönung":

    Zitat

    Sogar nicht Multithreathingfähige Codecs wie der VP7, verteilen sich interessanterweise nach Aktualisierung der Vdub auf alle 6 Kerne und laufen sogar gleich doppelt so schnell, ebenfalls xvid & Co


    Das ist Unsinn.

    (Ich weiß übrigens gar nicht, ob oder ob nicht der VP7-Codec nur Mono-Threaded arbeitet, aber...) ... WENN ein Codec nur Monothreaded arbeitet, dann kannste an noch so vielen Knöpfen der Vdub-Config drehen: der Codec wird immer noch nur monothreaded arbeiten. Etwas anderes ist technisch gar nicht möglich. Und auch Xvid & Co. verrichten ihr Werk deswegen nicht schneller, und schon gar nicht doppelt so schnell. (Da hast Du etwas verwechselt - siehe Benzinqualität vs. Geländegegebenheiten oben, oder die Klarstellung weiter unten.)

    Zitat

    [...]diese Version hat div. Settings die die normalle Vdub nunmal nicht hat. Die Schlüsselwerte sind:
    Video compression threath
    Video filter threathing
    Video fiilter process ahead
    Das ganze encodet nun auch erstaunlich schnell [...]


    "Video Compression Threads"
    Diese Option gibt's schon ... wasweißich, schon ziemlich lange. Sie sorgt dafür, dass DEkodierung der Quelle und ENkodierung des Outputs in verschiedenen Threads laufen. Heißt: der Thread, in dem der Encoder arbeitet, muss keine Zeitscheiben an den Dekodierer abgeben.
    Gibt's schon lange, ist standardmäßig sowieso aktiviert, und ... macht sich praktisch nur dann bemerkbar, wenn das Quellmaterial aufwändig zu dekodieren ist (HD-Material, langsame verlustlose Codecs, etc.). Bei Mpeg2-Input und der heutigen Rechnertechnik macht sich das kaum bemerkbar.

    "Video filter threading" + "Video filter process ahead"
    Diese Einstellungen betreffen ausschließlich die Video-Filter, die Vdub anwendet. Das heißt schon mal: wenn Vdub auf "Video: Fast Recompress" eingestellt ist, dann ändern diese Einstellungen gar nichts. Nur wenn Vdub Video-Filter anwendet, dann können diese Filter nunmehr multi-threaded und mit Read-Ahead arbeiten.

    Diese Einstellungen beschleunigen also Virtualdub. Sie beschleunigen aber NICHT den Video-Codec.

    Wenn Du also einen deutlichen Geschwindigkeits-Zuwachs bemerkt hast, dann liegt die Vermutung nahe, dass Du wohl beim Encoding auch noch den einen oder anderen Video-Filter von Vdub benutzt hast, und die ganze Geschichte im "Video: Full Processing Mode" abgelaufen ist. Davon hattest Du aber kein Sterbenswörtchen erwähnt ...

    Im Endeffekt hast also Du höchstpersönlich "Lösungen" präsentiert, die mit dem geschilderten Hauptproblem (Audio Versatz) gar nichts zu tun haben. Und mit dem geschilderten Sekundärproblem (CPU-Auslastung) auch nur unter Verdrehung der Gegebenheiten - die unvollständige Auslastung war ja kein "Fehler" des VfW-Codecs, sondern lag daran, dass der Codec darauf warten musste, dass Virtualdub mit den (von Dir nicht erwähnten) Videofiltern ums Carree kommt.


    So, das Halbwissen hat jetzt keine Lust mehr. ==> DIE Gelegenheit für das Centiwissen, um Zeter und Mordio zu schreien. :)

  • Das ist Unsinn.

    (Ich weiß übrigens gar nicht, ob oder ob nicht der VP7-Codec nur Mono-Threaded arbeitet, aber...) ... WENN ein Codec nur Monothreaded arbeitet, dann kannste an noch so vielen Knöpfen der Vdub-Config drehen: der Codec wird immer noch nur monothreaded arbeiten. Etwas anderes ist technisch gar nicht möglich.

    Ist mit der aktuellen, experimentellen VirtualDub-Version nur noch halb richtig: Die kann einen Encoder mehrfach aufrufen. Soll aber nur mit Encodern gehen, die nur I-Frames setzen - habe es aber selbst nicht getestet. Also für XviD und x264 müßte weiterhin das bisherige gelten. (Wenn man nicht das Keyframe-Intervall auf 1 stellt)

  • Hallo
    Sneaker,
    Den VP7 hatte ich damals für 15$ bei ON2 auf der Webseite gekauft und lastete in jeder Software immer nie mehr als 1Kern aus. (man kann im encoder auch nix einstellen diesbzgl.)
    Mit der EXP vdub 1.1 werden unter VP7 nun aufeinmal alle 6Kerne benutzt und das bringt bei dem codec fast die doppelte Speed.

    Zitat

    "Video Compression Threads"
    Bei Mpeg2-Input und der heutigen Rechnertechnik macht sich das kaum bemerkbar.

    Ja benutze Filter wie Resize etc, pp.
    Und ja ein aktivieren dieser Threaths Settings bringt bei meinem Quad auch faktisch nix an Zeitgewinn. Das verhält sich aber ganz anders bei dem X6 den die Encodingzeit verkürzt sich (auch bei MPEG2 input) durch aktivieren der Werte nämlich mal eben um fast 40% (!).
    Keine Ahnung wieso das bei dem X6 soviel bringt, vielleicht ist ja ein Bug in der vdub "Standartkonfig" die diese CPU aus welchen Gründen auch immer ausbremst, was u.u. erklären könnte wieso ein rumdrehen an den Werten soviel Leistungsplus (und das nicht nur beim x264vfw) bringt.


    Zitat

    Im Endeffekt hast also Du höchstpersönlich "Lösungen" präsentiert, die mit dem geschilderten Hauptproblem (Audio Versatz) gar nichts zu tun haben.


    Sry, aber das siehst du falsch, denn das kann doch jeder mit nem X6 nachprüfen der unter XP auch so ein Problem hat, das Audio Delay verschwindet nämlich in just dem Moment in dem man in vdub einfach nur folgendes einstellt:
    (Codec Threaths 6, deterministic off)
    Video Compression Threads "1"
    Video Filter threathing "1"
    Video Filter process ahead "auto"
    Und nein, diese Lösung stammt auch nicht aus Doom9.org, sondern das ist mir einfach nur per Zufall selbst aufgefallen.
    Und wie heißt es so schön: Ein blindes Huhn findet auch manchmal ein Korn.:D

    16 Mal editiert, zuletzt von Der_Lurchi (3. Februar 2011 um 01:41)


  • Mit der EXP vdub 1.1 werden unter VP7 nun aufeinmal alle 6Kerne benutzt und das bringt bei dem codec fast die doppelte Speed.

    Das heißt:

    Mit dem alten VirtualDub liefen der Codec und alle VirtualDub-Filter in einem einzigen Thread. Und der kann natürlich auch nur auf einem einzigen Kern laufen (es sei denn, der Codec selbst ist multithreaded programmiert und spaltet sich selbst in mehrere Kopien auf, die jeweils Teile des Videos relativ unabhängig verarbeiten).

    Mit dem neuen VirtualDub läuft der Codec in einem Thread, und alle VirtualDub-Filter auch jeweils in ihrem eigenen Thread. Diese mehreren Threads kann Windows auf mehrere Kerne verteilen. Wenn es dadurch nun doppelt so schnell läuft, heißt das außerdem, dass alle VirtualDub-Filter zusammen etwa so viel Rechenzeit brauchen wie der Codec alleine. Mehr oder weniger. Letztlich muss ja auch der eine noch auf den anderen warten.

    Würdest du auf AviSynth umsteigen, hättest du eine Reihe von Vorteilen: Multithreaded Decoder (FFmpegSource-MT), Filterung im optimalen Farbraum (in RGB24, welches VirtualDub im "Full Processing Mode" verwendet, müssen die Filter doppelt so viele Bytes berechnen wie in YV12, und manche Filterfunktionen arbeiten in einem YUV-Farbraum auch noch erheblich effizienter als in RGB), dann der eigenständige EXE-Encoder mit Multithreading, und erfahrene Nutzer können sogar mit AviSynth-MT noch die Ausführung von Videofiltern durch Multithreading optimieren und beschleunigen.

    Und dank AvsP(mod) ist das Arbeiten mit AviSynth-Skripten auch gar nicht mal so schwierig, damit wird auch eine Filtervorschau mit interaktiver Parameteränderung möglich.
    __

    Was nun den Audioversatz angeht ... wie schon gesagt, ist der AVI-Kontainer nicht geeignet für Videoformate mit B-Frames. Bereits Xvid hatte da zwei Lösungen (mit oder ohne "Packed bitstream", bzw. B-VOP / N-VOP), mit denen jeweils der eine oder andere Playerchipsatz nicht zurechtkam, und was eine weitere Bearbeitung durch den "B-Frame-Lag" erschwerte. Ich kann nur mutmaßen, dass auch in deinem Fall ein ähnliches Problem beim Multiplexen auftritt in Bezug auf die Zuordnung von B-Frames.

    Mit MP4 oder MKV passieren solche Probleme schon von vorn herein nicht, weil diese Kontainer mit B-Frames umgehen können.

  • Denke es ist genau so wie Ligh es erklärt hat.
    (Wenn man direkt in vdub nach YV12 encodet entsteht allerdings kein Zeitverlust)
    Das Delay kann man auch noch auf andere Art loswerden (die vermutlich auch die sicherste ist): Über die Commandozeile kann man per -o den x264 Encoder ja zum Directoutput veranlassen.
    Vdub erstellt beim encoden dann 2 avis: Eins mit dem videostream + Eins mit dem audiostream.
    Die 2 Streams braucht man dann anschließend nur noch wieder zusammenfügen. Ich glaube man kann diesen Schritt aber leider nicht automatisch über die vdub Batchfunktion machen. (bin mir aber nicht sicher, weil hab mich mit der Batchfunktion bislang nicht genauer beschäftigt)

    Avisynth ist sicherlich eine super Sache, wenn man da weiß wie man was tut.
    Ich weiß es allerdings nicht. :hm:

    3 Mal editiert, zuletzt von Der_Lurchi (4. Februar 2011 um 01:11)

  • Hallo,

    Zitat

    Die neueste, experimentelle VirtualDub-Version unterstützt externe Encoder/Muxer,


    die 2 avis die nachdem x264vfw encoden entstehen, kann man in vdub über "Audio from another file" wieder zu einem avi zusammenfügen ohne vorher alles manuell/einzeln zu demuxen. Wußte erst gar nicht das das sowas geht, weil kannte es bisher nur so das man eine Tonspur normallerweise zuerst aus einem Avi Container rausziehen muß, um sie in ein anderes avi wieder einzufügen. Dem vdub scheint es jedoch egal zu sein, wenn beides noch im Container liegt.

    Man kann das ganze nur irgendwie nicht so einfach automatisch über die Batch ablaufen lassen, da diese zum Schluß noch einmal zu muxenden Files vor Beenden des (fertigen) encoding ja noch nicht existieren um sie (vorher) in der Jobcontrol anlegen zu können.
    (aber vielleicht mach ich da auch einen Gedankenfehler)

    LigH
    Werd mir das alles auch mal angucken,
    sieht aber alles sehr kompliziert aus mit den Scripts. :eek:

  • Im Grunde macht man damit aber – im einfachen Fall – auch nichts wesentlich anderes als in VirtualDub: Videoquelle öffnen und einen Filter nach dem anderen anwenden.

    Nur mit dem Vorteil, dass man damit auch noch viel mehr tun kann, wenn es sein muss. AviSynth kann auch ein "Nicht-Linearer Editor" (NLE) für Videos sein, VirtualDub kann das nur mit einer Filter-Liste nicht.

Jetzt mitmachen!

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