Audio-delay von AAC (und auch MP3, AC3, DTS, AAC-HE, ...) in MKVs

    Hallo,
    ich hab jetzt schon viel dazu gelesen, irgendwie wird's aber nicht klar. Ich fang jetzt mal so an:

    Warum braucht AAC-LE in MKVs ein delay (mkvmerge setzt automatisch 20ms), AC3, DTS (mkvmerge setzt 0ms) aber zB nicht?
    - obwohl AC3/DTS auch MDCT-Algorithmen verwendet (wie fast alle) und somit _auch_ ein sog. priming des decoders braucht.

    Insb. schneidet eac3to ein vorhandenes delay eines Audiostreams weg (=PTS Differenz zwischen Video+Audio), aber beim neuen Multiplexen in mkvmerge als:
    DTS: wird kein delay hinzugefügt, eine DTS-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
    AC3: wird kein delay hinzugefügt, eine AC3-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
    MP3: wird kein delay hinzugefügt, eine MP3-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
    AAC: wird aber ein delay hinzugefügt.

    Diese En/DEcoder-Verzögerungen sind unterschiedlich und leider oft im Bereich, dass man es kaum merkt. Manchmal ist's aber doch störend - bei seamless-play ist eine exakte Synch sowieso erforderlich.
    Am TV kommen noch zusätzliche Video-Verzögerungen dazu, weil da irgendwelche Aufbereiter arbeiten und dann murkst man selber noch am HDMI-delay rum, aber *immer* passt's nie.

    Jetzt gibt's einige Verwirrungen meinerseits, wg ENcoder und DEcoder-delay:
    1. welcher ENcoder hat welches delay? Insb. wieviel leer-frames/ms werden eingefügt, die dann auch beim decoding wieder verschluckt werden?
    2. Welcher DEcoder hat welches delay? Insb. tritt dies nur am PC auf oder auch bei hardware-decoder (AV-receiver)?
    3. Kann man bei Kontainerformaten generell eine Synchronität erwarten? Immerhin hat man video und audio, aber warum bekommt AAC +20ms, AC3 aber nicht?

    Etwas zum Nachlesen zum MP3-delay:
    http://mp3decoders.mp3-tech.org/decoders_lame.html
    http://lame.sourceforge.net/tech-FAQ.txt
    aber naja, diejenigen wissen schon, wo die Quellen sind. ;)

    Hat da jemand Durchblick? Wie (wo was warum) man das synchron bekommt?
    Grüße...

    shh

    Die Grundüberlegung ist richtig: alle diese Formate haben entsprechende Delays, welche ausgeglichen werden müssen.

    Jetzt geht es eher um die Frage, warum z.B. MediaInfo nach Muxen von aac mit mkvmerge +20ms delay anzeigt, aber nichts bei ac3, mp3 und dts? Die Antwort ist recht einfach: mkvmerge kann das Encoder-Delay aus bestimmten Dateien (hier: aac im mp4-Container, bei der der Encoder eine Delay-Info hinterlegt hat) auslesen, aber nicht aus mp3-, ac3- oder dts-Dateien. D.h. man müßte diese Delays manuell eingeben (oder den Encoder mit vorne bereits um das spätere Delay gekürzten Rohdaten füttern).

    Zum Wert "+20ms": dieser ist nicht für alle aac-Formate konstant, sondern encoder-(Apple, Fraunhofer, Nero etc.) und profil-(LC, HE)-abhängig. Zweitens: da es sich um ein positives Delay handelt, muß man es mit negativen Eingaben in mkvmerge ausgleichen (falls mkvmerge diese nicht automatisch erkennen kann). Der positive Wert (trotz negativer Eingabe in mkvmerge) in der Endatei ergibt sich daher, daß mkvmerge die Audiopakete die durch das Anwenden einer negativen Verschiebung vor Zeitpunkt 0ms starten würden, einfach löscht. Da das meist nicht genau bei 0 aufgeht, entsteht ein kleines positives Delay (< Größe eines Audiopakets). Seamless-play ist mit mkv nicht oder nur eingeschränkt möglich.

    Siehe auch:
    http://forum.gleitz.info/showthread.php…ht-mit-MKVMerge

    3 Mal editiert, zuletzt von sneaker2 (3. Juni 2013 um 08:03)

    Es dürfte auch zwei verschiedene Ursachen für eine verzögerte Ausgabe der Tonspur geben:

    a) "Decoder lag": Manche Decoder geben erst den decodierten Ton aus, wenn der Anfang des folgenden Audio-Frames gelesen wurde, also sicher ist, dass der aktuelle Audio-Frame komplett ist. Je nach Multiplexing-Parametern und -Software kann es ja durchaus passieren, dass die Granularität des Audioformates vom Multiplexer des Containers nicht beachtet wird, sondern nur die durchschnittliche Bitrate. VirtualDubMod kann beispielsweise konfiguriert werden, ob es diesen Vorlauf beim Multiplexen von MP3-Tonspuren beachten soll.

    b) "Audio Skew": Die Tonspur lag in der Original-Mediendatei absichtlich verschoben vor, um sie zum Video synchron zu bekommen. Diese Verschiebung entsteht beim Multiplexen des Containers und ist nach dem Demultiplexen der Tonspur natürlich nicht mehr bekannt, außer sie wird beim Demultiplexen z.B. in den Dateinamen geschrieben.

    +20ms:
    Ok, hab's gerade nochmal gechecked. Mkvmerge hat beim AAC tatsächlich am Anfang was weggeschnitten und musste den Rest dann mit +20ms verzögern.
    Das dürfte so i.O. sein, weil der QuickTime-Encoder (den ich verwendet hatte) ja 2112-leer-Samples am Anfang einfügt. Sogar wenn man selber DELAY-Werte eingibt, wird das implizite priming vom Encoder nicht vergessen. Gut!
    Nur beim Demuxen mit MKVExtractGUI zu AAC und Remuxen läuft irgendwas verkehrt: Beispieleingaben von je -2ms bringen bei .M4A am Ende +18ms, jedoch beim .AAC komischerweise +19ms. Hmm.


    Priming:
    Nun gibt's ja auch zertifizierte Player am PC und Standalones mit zertifizierten DTS AC3 und auch LPCM und MP2. Ich denke, man kann davon ausgehen, dass der PTS-delay bei DVDs so passt, dass audio+video am Player "so synchron werden, wie sie beabsichtigt waren." D.h. Producer/Sound-Decoder haben die impliziten delays miteinbezogen.
    Jetzt könnte es sein, dass man sich vom Konvertieren eines LPCM-Tons einer DVD nach zB AC3 einen impliziten Delay zuzieht. Sei's wg priming oder decoder-lag. Auch wenn man den AudioSkew (= PTS-diff) beachtet.
    Fügen denn DTS/AC3-ENcoder am Anfang Leersamples ein, oder verwenden die zum Priming echte Audiodaten, die dann später auch ausgegeben werden?
    Beim Abspielen wird dann wahrscheinlich auf das Initialisieren aller substreams gewartet, bevor alles synchron wiedergegeben wird.
    Falls keine Leersamples eingefügt werden, wäre das encoder-Priming von DTS/AC3 zu ignorieren und man kann wild von DTS->AC3->FLAC->LPCM->... konvertieren, ohne Synchronität zu verlieren.
    - wenn denn die DTS/AC3-decoder keinen decoder lag haben.


    Decoder-lag:
    Verbleibendes Problem sind aber Formate wie MP3. Dies ist nicht für Containerformate zertifiziert und muss von den Playern (egal ob Standalone oder PC) nach PCM konvertiert werden, um etwa einen AV-Receiver zu füttern.
    Für Synchronität wird aber der "Audio Skew"-Wert hergenommen, also die entsprechenden PTSs des Containers. Die Folge wäre asynchrone streams, wenn der MP3-decoder die Priming-LeerSamples (528: http://lame.sourceforge.net/tech-FAQ.txt) nicht wegschneidet. LAME tut das zwar "neuerdings" schon (http://mp3decoders.mp3-tech.org/decoders_lame.html#delays), aber tut's auch libav, oder andere (hardware)Player-decoder?

    Problem ist vielleicht auch bei FLAC vorhanden denke ich, nur etwas anders. Hier könnte der FLAC-decoder einen Ausgabe-lag haben (wenn auch keine zusätzl. priming-samples encodet werden)

    Gibt's eigentlich einen Decoder-Lag von DTS, AC3, FLAC, AAC? Wurde das schon irgendwo getestet?
    Hmm, daneben könnte es auch sein, dass hardware-decoder (am AV-receiver) keinen lag haben, Software-decoder aber schon.

    NACHTRAG: Moment mal, decoder lag, nicht richtig darüber nachgedacht.
    Das würde zumindest am PC bedeuten, dass die decoder am Anfang Leersamples ausgeben. Dies ist aber glaube ich noch keinem aufgefallen, ich denke der Aufschrei wäre doch recht groß.
    Zumindest sowas wie XBMC, mplayer, ffdshow oder andere müssten die substreams doch eigentlich synchron bekommen, wenn der encoder nicht irgendwo implizit Leersamples einfügt.
    Zwischenstatus:
    Video: Priming: bestimmt!, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
    DTS: priming: echte audio-samples?, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
    AC3: priming: echte audio-samples?, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
    AAC: priming: ja (Leersamples) -> fix beim multiplexen, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoding von AAC.
    FLAC: priming: nein, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoding von FLAC.
    MP3: priming: ja -> fix beim multiplexen? bei lame nicht???, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoder von MP3.
    Gerade MP3 wirft hier in jeder Hinsicht Fragen auf: Selbst, wenn normales Audio von lame bzgl encoder-priming/decoder-lag gefixt wird, ist das dann auch so, wenn MP3 in Containern wie MKV verwendet wird, oder werden da die leeren priming-Samples einfach abgespielt, sodass der Audiostream hinterherhinkt...?

    NACHTRAG2: Gerade darüber gestolpert: http://forum.doom9.org/showthread.php?p=1563801#post1563801
    Anscheinend fügen AC3-encoder doch auch Leersamples ein, zwar "unmerkbare" 5.33ms aber sie tun es.
    DTS wahrscheinlich auch. Hmm, wieder zurück an den Start.


    Grüße...

    p.s. auf MP3 reite ich so rum, weil ich das gerne auch in MKVs hernehme. Bei 2ch besser als AC3 und echte VBR nach erforderlicher Quali: zB -V2 ;)

    shh

    3 Mal editiert, zuletzt von shh (3. Juni 2013 um 17:07)

    Zitat von shh

    +20ms:
    Ok, hab's gerade nochmal gechecked. Mkvmerge hat beim AAC tatsächlich am Anfang was weggeschnitten und musste den Rest dann mit +20ms verzögern.
    Das dürfte so i.O. sein, weil der QuickTime-Encoder (den ich verwendet hatte) ja 2112-leer-Samples am Anfang einfügt.

    Wobei die Samples nicht wirklich nur nutzlose "Leer-Samples" sind - ansonsten würde kein Encoder sie ausgeben. Und selbst wenn man diese Vereinfachung zugrunde legen würde, würden trotzdem noch 20ms wertvolle Daten weggeschnitten.

    Zitat von shh

    Nur beim Demuxen mit MKVExtractGUI zu AAC und Remuxen läuft irgendwas verkehrt: Beispieleingaben von je -2ms bringen bei .M4A am Ende +18ms, jedoch beim .AAC komischerweise +19ms. Hmm.

    Mkvextract schreibt keine Delay-Info in die Ausgabedatei - dies ist bei AAC-Rohdaten (ADTS) auch gar nicht möglich. Wenn Du diese Daten erneut muxt, verschiebt sich der Ton auf der Zeitleiste also noch weiter nach links, ein weiteres Paket wird gelöscht. Ein AAC-Frame hat 1024 Samples, ist bei 48kHz also etwa 21ms lang. 21ms - 2ms = 19ms


    Zitat von shh

    Fügen denn DTS/AC3-ENcoder am Anfang Leersamples ein, oder verwenden die zum Priming echte Audiodaten, die dann später auch ausgegeben werden?

    Wie weiter oben angedeutet: es handelt sich nicht um "echte" Leersamples.

    Zitat von shh

    Decoder-lag:
    Verbleibendes Problem sind aber Formate wie MP3. Dies ist nicht für Containerformate zertifiziert und muss von den Playern (egal ob Standalone oder PC) nach PCM konvertiert werden, um etwa einen AV-Receiver zu füttern.
    Für Synchronität wird aber der "Audio Skew"-Wert hergenommen, also die entsprechenden PTSs des Containers. Die Folge wäre asynchrone streams, wenn der MP3-decoder die Priming-LeerSamples (528: http://lame.sourceforge.net/tech-FAQ.txt) nicht wegschneidet. LAME tut das zwar "neuerdings" schon (http://mp3decoders.mp3-tech.org/decoders_lame.html#delays), aber tut's auch libav, oder andere (hardware)Player-decoder?

    Libav/ffmpeg tut es meiner Erfahrung nach für mp4 und mkv nicht. Keine Ahnung was Hardware angeht - dürfte schwer sein, dort an verläßliche Infos zu kommen. Da verschiedene Encoder auch unterschiedliche Delays erzeugen, läßt sich dies eh nicht zuverlässig durchführen.

    Zitat von shh

    Problem ist vielleicht auch bei FLAC vorhanden denke ich, nur etwas anders. Hier könnte der FLAC-decoder einen Ausgabe-lag haben (wenn auch keine zusätzl. priming-samples encodet werden)

    Gibt's eigentlich einen Decoder-Lag von DTS, AC3, FLAC, AAC? Wurde das schon irgendwo getestet?
    Hmm, daneben könnte es auch sein, dass hardware-decoder (am AV-receiver) keinen lag haben, Software-decoder aber schon.

    NACHTRAG: Moment mal, decoder lag, nicht richtig darüber nachgedacht.
    Das würde zumindest am PC bedeuten, dass die decoder am Anfang Leersamples ausgeben. Dies ist aber glaube ich noch keinem aufgefallen, ich denke der Aufschrei wäre doch recht groß.
    Zumindest sowas wie XBMC, mplayer, ffdshow oder andere müssten die substreams doch eigentlich synchron bekommen, wenn der encoder nicht irgendwo implizit Leersamples einfügt.

    Eine technische Notwendigkeit für Decoderlags besteht IMHO nicht.
    Generell gibt es aber in jeder Audio/Video-Kette irgendwelche Delays, aber zumindest beim Decoding muß es das nicht geben. Z.B. Umschaltzeiten von LC-Kristallen in Bildschirmen, Ausbreitung des Schalls in Schallgeschwindigkeit und andere Feinheiten.

    Zitat von shh

    Video: Priming: bestimmt!

    Nein, warum?

    Zitat von shh

    Gerade MP3 wirft hier in jeder Hinsicht Fragen auf: Selbst, wenn normales Audio von lame bzgl encoder-priming/decoder-lag gefixt wird, ist das dann auch so, wenn MP3 in Containern wie MKV verwendet wird, oder werden da die leeren priming-Samples einfach abgespielt, sodass der Audiostream hinterherhinkt...?

    Hängt alles vom Hersteller ab. Vermutlich wird das Priming mit abgespielt - ist aber nur eine Vermutung meinerseits. Die meisten Receiver brauchen eh schon länger als das Priming, um überhaupt auf das neue Eingangssignal zu reagieren. An verläßliche Infos zu kommen dürfte aber wie gesagt schwer werden. Letztendlich müßte man sich dann auch auf ein Gerät festlegen - beim Neukauf wären dann alles wieder für die Katz. Ich persönlich encode so, als ob der Decoder kein implizites Delay annimmt (falls ich ans Delay denke) und belasse es dabei.

    Dank für die ausführliche Antwort.

    Nur mal so als Zwischenstand:
    DTS ist ja auch lustig. Alles mit eac3to und dem (empfohlenen) ArcSoft-decoder decodiert, der glaube ich auch DTS zertifiziert ist.

    Surcode encoder (kann bis 5.1 DVD-DTS): WAV->DTS->WAV: hier wird kein priming hinzugefügt.
    DTS-HD Master Audio Suite (Referenz): WAV->.DTSHD->WAV: 1024 Samples priming -> audio hat ab dann 0.02133s delay.
    DTS-HD Master Audio Suite (Referenz): WAV->.CPT->WAV: 0 Samples priming, also so wie bei Surcode.
    Dieses .CPT ist anscheinend ein "Komtatiblitätsformat" von DTS, was zumindest bei der Konvertierung keine Leersamples einfügt.
    Bei allen .dtshd Formaten hat man übrigens zB 768000bps statt 754500bps und 1509000bps statt 1509.750bps, k.A. ob das schon jemandem aufgefallen ist.
    Komischerweise kann man mit der DTS-HD Master Audio Suite aber auch ein normales DTS Digital Surround bauen, was zwar meiner Ansicht nach DVD-kompatibel sein sollte, aber eac3to und den ArcSoft-decoder dazu bringt, 1024 priming-samples einzufügen.

    Kann das sein, dass eac3to für die "Spezial"bitraten (754500 und 1509750) ein Handling hat, 1024 Samples am Start autom. abzuschneiden?

    shh

    Zitat von shh

    Surcode encoder (kann bis 5.1 DVD-DTS): WAV->DTS->WAV: hier wird kein priming hinzugefügt.
    DTS-HD Master Audio Suite (Referenz): WAV->.DTSHD->WAV: 1024 Samples priming -> audio hat ab dann 0.02133s delay.
    DTS-HD Master Audio Suite (Referenz): WAV->.CPT->WAV: 0 Samples priming, also so wie bei Surcode.

    Hier müßte man noch mal mit dem ffmpeg-Decoder vergleichen, denn wenn der Surcode-Decoder ein konstantes Delay annimmt und entfernt, sind die Schlußfolgerungen falsch.

    Zitat von shh

    Dieses .CPT ist anscheinend ein "Komtatiblitätsformat" von DTS, was zumindest bei der Konvertierung keine Leersamples einfügt.
    Bei allen .dtshd Formaten hat man übrigens zB 768000bps statt 754500bps und 1509000bps statt 1509.750bps, k.A. ob das schon jemandem aufgefallen ist.
    Komischerweise kann man mit der DTS-HD Master Audio Suite aber auch ein normales DTS Digital Surround bauen, was zwar meiner Ansicht nach DVD-kompatibel sein sollte, aber eac3to und den ArcSoft-decoder dazu bringt, 1024 priming-samples einzufügen.

    Dazu kann ich nichts sagen.

    Zitat von shh

    Kann das sein, dass eac3to für die "Spezial"bitraten (754500 und 1509750) ein Handling hat, 1024 Samples am Start autom. abzuschneiden?

    Dazu müßtest Du wohl selbst madshi im englischen Doom9 fragen, aber ich vermute eher nicht. Vielleicht handelt es sich auch nur um Fehler in der Bitratenanzeige/-berechnung.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden