Delay bei AAC in MKV geht nicht mit MKVMerge

Ja, laut dem Thread gibt es beides. Wobei der Decoder ja ein negatives Delay anwenden müßte, wollte er das positive Delay des Encoders ausgleichen. Einige Decoder scheinen dies nicht zu tun.

Scheint aber alles noch etwas komplizierter und wirklich Encoder-/Decoderabhängig zu sein. Und auch für u.a. AC3, MP3 und Vorbis zu gelten.

Zitat von Nel-son

Hab das jetzt auch mal gemacht. Bei mir beginnt das erste (und einzige) Kapitel bei 0:00:00.097. Das wäre auch der vom AAC-Encoder erzeugte Delay? 0,097 Sekunden, d.h. 97ms?

So ist zumindest meine Vermutung. Also dann testweise mit -160ms-97ms=-257ms Delay muxen.

Zitat von Nel-son

Da ich leider in o.g. Fällen die Kapiteldatei nicht mitgemuxt habe (weil ja aus der originalen Disk schon eien Datei war) bekommt man wohl den exakten, vom AAC-Encoder erzeugten Delay nicht mehr raus?

Das weiß ich nicht. Ich habe nicht verstanden, warum der Delay nicht konstant ist, wenn er doch angeblich immer 1024 (IIRC) Samples lang sein soll.

Da ich zugegebener Maßen nicht gerade ein Crack bin was die Audioverarbeitung betrifft, hier mal was ich im Kopf habe, was gerade zum Thema Audioformatwandlung passt und zu dem ich gerne wissen würde ob es so stimmt.

Beim Konvertieren von Audioformaten kann es immer zu einem Delay kommen, der sich einfach aus der kleinsten Größe der Audioelemente (im weiteren Frames genannt) ergibt. (Delays die durch eventuelle Decoder und Container erzeugt werden mal außen vor.)
Soweit ich mich entsinne war die Länge der Frames doch so:
Format Framelänge in ms
mp3 -> 24.000ms
aac -> 32.000ms
ac3 -> 40.000ms
dts -> 10.667ms
falls ich hier etwas falsch im Kopf habe bitte korrigieren!

das hieße also:
wenn ich 10 mp3 frames = 240ms
- nach ac3 umwandle passt das genau 240/40 = 8 ac3 frames -> kein neuer delay
- nach aac umwandle hab ich 240/32 = 7,5 also 8 aac frames (= 256ms) -> 16ms neuer delay
- nach dts umwandle habe ich 240/10.667 = 22,5 als 23 dts frames (=246ms) -> 6ms delay

wenn ich nun 10 ac3 frames = 400ms
- nach mp3 umwandle werden also 17 mp3 frames (= 408) encode und man hat 8ms delay
...
usw.

Der Punkt meiner Betrachtung ist, dass der Delay, der so entsteht immer kleiner als die Länge eines Frames im Zielformat ist,... da wir i.d.R. 25fps Material haben, bei dem ein Bild also 40ms gezeigt wird, sollte dies eigentlich nie auffallen, so Lange nicht mehrere Formatkonvertierungen hintereinander gemacht werden, ohne dass der delay wieder korrigiert wird.

Da ich mir so nicht erklären kann wie es zu einem Delay von 50ms oder mehr kommen kann durch das Umwandeln, würde ich mich interessieren:
1. kann jemand mal theoretisch darlegen, wie so hohe delays entstehen ?
2. kann jemand mal erklären was ihr da mit dem Kapiteleditor macht ? (das macht für mich momentan irgendwie keinen Sinn, da ich dem nicht folgen kann :))

Cu Selur

Ps.: Ach ja, ist es eigentlich immer noch so, dass DirectShow Decoder teilweise noch mal ein zusätzliches frame an delay hinzufügen.

PPs.: Wer der Sache auf den Grund gehen will, kann ja mal als Quelle das Avisynthskript von http://forum.doom9.org/showthread.php?t=163597 nehmen, da kann man sehr schöne Wavefront und Framegrenze sehen,.. wenn man das Skript encoded (z.B. nach avc,aac in mkv) und wieder in Avisynth (mittels FFMpegSource öffnet) und Virtual Dub (View->Audio display aktivieren!) anguckt, sollte man eventuelle Delays ja sehen können,..
-> Im Anhang hab ich es mal versucht und da ist ein neuer Delay von 1 1/2 Frames also ca. ~60ms zu sehen, Frage ist: Hab ich was falsch gemacht (bitte mal jemand gegen testen) ? Ist FFMpegSource das Problem? ist mkv das Problem? Sieht es mit mp4 anders aus?

Mit Deiner Vemutung liegst Du meines Wissens nach falsch. Warum sollte der Encoder das Delay am Anfang setzen, anstatt am Ende? Wenn ich z.B. mit einer Pipe arbeite, kann der Encoder auch noch nicht wissen, wie lang die Spur wird.

Es hat wohl eher etwas damit zu tun:
http://de.wikipedia.org/wiki/Modifizie…stransformation

Zum Kapiteleditor:
NeroAacEnc bringt die AAC-Spur in einem MP4-Container unter und schreibt anscheinend einen Kapiteleintrag für das Delay hinein. Ich wußte nicht, wie man das direkt aus der MP4-Datei auslesen kann, aber mkvmerge kann die Kapitel aus mp4-Dateien übernehmen und anschließend die Kapitel der mka-Datei darstellen.

Ich persönlich bin mir auch unschlüssig, ob ich das Delay bei meinen eigenen "Projekten" beachten werde oder nicht. Wenn im Standard steht, daß der Decoder das Delay beachten muß, wäre es falsch, es mit mkvmerge zu korrigieren. Letztendlich nehme ich solch kurze Delays auch nicht wahr (glücklicherweise).

Bei mp4 als container ist der delay auf < 1 frame,.. (siehe Anhang) -> liegt also vermutlich an FFMpegSource oder mkv. (wenn ich das mp4 einfach nach mkv umpacke ist der delay genau wie wenn ich direkt nach mkv encode)

Zitat von Selur

Bei mp4 als container ist der delay auf < 1 frame

Interessant - der mp4-Container scheint das also zu berücksichtigen. Jetzt wo Du es schreibt, fällt mir auch wieder ein, daß z.B. L-Smash die explizite Angabe eines Encoder-Delays erlaubt.

Werde morgen Nachmittag, wenn ich wieder @home bin (und es nicht vergesse) mal anstatt FFMpegSource mal DirectShowSource verwenden, um zu gucken ob sich dann etwas ändert,...

Man möge mir Verzeihen, dass der Rest auf English ist, aber da ich den Tag über fast nur am Englisch quatschen war, hab ich ohne es wirklich zu merken auch alles auf Englisch geschrieben und momentan einfach zu faul es zu übersetzten, denke aber auch den 'Nicht-Englisch-Sprachig-Geübten' sollte das folgende verständlich sein. (Alle Bilder, Files und Dateien die angesprochen sind; außer die Encoder hab ich mal hochgeladen: http://www.multiupload.com/JGBOTZIOZ8

Here's what I did with the Merry Christmas avisynth script.

1. opened the 'Mery Christmas' script (test.avs) in Virtual Dub, activated View->Audio Display and took two screenshots, one at the start (source_0.png) and one after 11 frames (source_11.png)

2. converted video:

mencoder "test.avs" -ovc raw -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 -lavdopts threads=8 -really-quiet -ofps 24 -of rawvideo -o - | x264 --crf 18 --profile high --level 4.1 --direct auto --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --thread-input --fps 24 --input-res 440x440 --output "test.264" -

(I know I could use x264 directly,..)

3. extract Audio:

mplayer -aid 0 -msglevel statusline=5:all=0 -mc 0 -hardframedrop -vc dummy -nocorrect-pts -aid 0 "test.avs" -vo null -ao pcm:fast:waveheader:file=""""test.wav""""

4. convert extracted Audio:

ffmpeg -threads 8 -v -10 -y -i "test.wav" -ac 1 -acodec pcm_s16le -f wav - | neroAacEnc  -br 128000 -ignorelength -if - -of "D:\Encoding Temp\test__aid_0__17_03_35_651_02.aac"

5. mux Audio&Video to mp4:

MP4Box -fps 24 -add "test.264"#video:par=1/1 -brand avc1 -add "test.aac"#audio -new "test.mp4"

6. Wrote a small avisynth script (test2.avs):

FFMpegSource2("test.mp4", atrack=-1)

opened the script in analog to 1. in Virtual Dub and took screenshots (mp4_0.png, mp4_11.png)
-> wtf, there's a bit missing! (I would have expected to get some delay due to the aac frame size)

7. mux Audio&Video to mkv:

mkvmerge --ui-language en -o "test.mkv" -d 0 --default-track 0:yes --default-duration 0:24fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --forced-track 0:yes --no-audio --no-subtitles "test.264" --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "test.aac"

8. Wrote a small avisynth script (test3.avs):

FFMpegSource2("test.mkv", atrack=-1)

opened the script in analog to 1. in Virtual Dub and took screenshots (mkv_0.png, mkv_11.png)
-> wtf, seems like there's some additional delay ! (more than I would have expected)

1st brain storm:
Something -at least for me - suprising happend, neither mkv not mp4 show the audio the way I expected:

Could be:
a. the wav file produced by mplayer
b. ffmpeg piping to the encoder
c. a problem with the container
d. a problem with ffmpegsource
e. something I overlooked

9. Wrote a small avisynth script (test4.avs):

video = BlankClip(length=576, width=440, height=440, fps=24)audio = FFAudioSource("test.wav")AudioDub(video, audio)

opened the script in analog to 1. in Virtual Dub and took screenshots (wav_0.png, wav_1.png)
-> okay, it's not the wav file, output looks like I suspected

10. Wrote a small avisynth script (test5.avs):

video = BlankClip(length=576, width=440, height=440, fps=24)audio = FFAudioSource("test.aac")AudioDub(video, audio)

opened the script in analog to 1. in Virtual Dub and took screenshots (aac_0.png, aac_1.png)
-> okay, the aac it self looks like the mkv output, so is it an encoder 'problem'/characteristic?

11. convert Audio with qaac:

ffmpeg -threads 8 -v -10 -y -i "test.wav" -ac 1 -acodec pcm_s16le -f s16le - | qaac --raw-channels 1 --raw-rate 48000 --cvbr 128 --adts --raw - -o "test_q.aac"

12. Wrote a small avisynth script (test6.avs):

video = BlankClip(length=576, width=440, height=440, fps=24)audio = FFAudioSource("test_q.aac")AudioDub(video, audio)

opened the script in analog to 1. in Virtual Dub and took screenshots (qaac_0.png, qaac_1.png)
-> looks exactly like the nero output, so it's not the encoder

13. convert Audio with qaac directly (no ffmpeg)
qaac --cvbr 128 --adts "test.wav" -o "test_raw_q.aac"

14. Wrote a small avisynth script (test7.avs):

video = BlankClip(length=576, width=440, height=440, fps=24)audio = FFAudioSource("test_raw_q.aac")AudioDub(video, audio)

opened the script in analog to 1. in Virtual Dub and took screenshots (qaac_raw_0.png, qaac_raw_1.png)
-> didn't change anything compared to the ffmpeg decoding the output and piping to qaac, so does not look like that ffmpeg is at fault here

2nd brain storm:
Argh,.. not as simple as I hoped.

Could be:
a. a problem with the container -> might be
b. a problem with ffmpegsource -> don't think so otherwise the results would not
c. aac encoders in general -> might be, will try with mp3
d. something I overlooked

15. convert Audio to mp3:

ffmpeg -threads 8 -y -i "D:\Encoding Output\test.wav" -acodec libmp3lame -ab 128000 "D:\Encoding Output\test.mp3"

16. Wrote a small avisynth script (test8.avs):

video = BlankClip(length=576, width=440, height=440, fps=24)audio = FFAudioSource("test.mp3")AudioDub(video, audio)

opened the script in analog to 1. in Virtual Dub and took screenshots (mp3_0.png, mp3_11.png)
-> argh, still not ideal, but more in the regions I expected (did not expect the 'blip' at the beginning)

17. mux Audio&Video to mp4:

MP4Box -fps 24 -add "test.264"#video:par=1/1 -brand avc1 -add "test.mp3"#audio -new "test_mp3.mp4"

18. Wrote a small avisynth script (test9.avs):

FFMpegSource2("test_mp3.mp4", atrack=-1)

opened the script in analog to 1. in Virtual Dub and took screenshots (mp4_mp3_0.png, mp4_mp3_11.png)
-> same behaviour as with aac, but this time it results in stream where it's at expected at pos 11.

17. mux Audio&Video to mkv:

mkvmerge --ui-language en -o "d:\Encoding Output\test_mp3.mkv" -d 0 --default-track 0:yes --default-duration 0:24fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --forced-track 0:yes --no-audio --no-subtitles "test.264" --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "test.mp3"

18. Wrote a small avisynth script (test10.avs):

FFMpegSource2("test_mp3.mkv", atrack=-1)

opened the script in analog to 1. in Virtual Dub and took screenshots (mkv_mp3_0.png, mkv_mp3_11.png)
-> still a full frame behind

3rd brain storm:
For me this looks more and more like a container/muxer problem.

Wäre schöne, wenn sich jemand aufraffen könnte das Ganze mal zu verifizieren, nicht das ich hier einfach total neben der Spur laufe, weil ich irgendwas aus Dussligkeit verbockt habe.
Auch von den Leuten die sich das Ganze nur angucken wäre etwas Feedback nett, mir momentan nicht so ganz klar ist was da wo warum schief läuft.

Cu Selur

Habe ähnliche Tests durchgeführt (etwas simpler, andere Samples und kein MP3).

Genutzte Encoder: qaac (mp4 und adts) und NeroAacEnc
Genutzte Decoder: FFAudioSource und NeroAacDec
Genutzte Muxer: mkvmerge, l-smash und mp4box
Zum Vergleichen: wav-Datei mit FFAudioSource/avs2pipemod oder NeroAacDec erstellt und in Audacity das Delay festgestellt.

Meine Ergebnisse würden "2nd brain storm c. aac encoders in general" entsprechen.

Ob die AAC-Daten in einem Container waren und mit welchem Muxer dies geschah, hatte bei mir keinerlei Auswirkungen auf das Ergebnis. Das Delay blieb konstant und qaac and NeroAacEnc produzierten auch dasselbe Delay.
Meine Behauptungen/Ergebnisse:
1. Es gibt definitiv ein Encoderdelay bei AAC
2. Dieses ist bei qaac und NeroAacEnc identisch, also vermutlich bei allen standardkonformen Encodern
3. FFAudioSource gibt immer den ersten Audioframe, den es bei Timestamp 0ms findet, bei Position 0ms wieder. (Solange intdelay=-1 und erster Videoframe auch bei 0ms, was hier bei Dir und mir der Fall war)
4. FFAudioSource gleicht das Encoderdelay nicht aus
5. NeroAacDec gleicht das Encoderdelay zuverlässig aus. Dies ist unabhängig davon, ob mit NeroAacEnc oder qaac gearbeitet wurde.

Deine Vermutung, daß das Delay kleiner als die Framegröße sein muß, halte ich nach wie vor für falsch und hat sich in meinen Tests auch nicht bestätigen können.

Allerdings kann ich mir nicht erklären, warum Du bei 6. und 8. nicht zum selben Delay kommst. Bei mir war das beim entsprechenden Test der Fall. Allerdings sehe ich bei Deinem "Versuchsaufbau" auch keinen Fehler.

Hast Du es denn jetzt mal mit -257ms getestet?

Selur
Habe bei meinem Test etwas durcheinandergebracht und anscheinend nur qaac richtig getestet. Muß das alles nochmal nachprüfen, aber ich habe mit qaac und NeroAacEnc anscheinend doch verschiedene Delays. Aber beide male weit über der Framegröße.

Wie gesagt, bin kein Audioprofi und hatte nur das aufgeschrieben was ich so im Kopf habe zur genaueren Analyse müsste man vermutlich auch etwas anderes als Virtual Dub verwenden um sich die Audiowellen anzugucken und den Delay exakter auslesen zu können,..

Zitat

Im englischen Forum wurde darüber wohl noch nicht gesprochen?

k.A. zumindest von mir wurde kein Thread oder so erstellt,...

Cu Selur

http://forum.doom9.org/showthread.php?t=157411 <- da scheint es als ob die Decoder das Problem sind und laut Dark Shikari müsste der Delay immer 1024/(sample rate) sein.
Bei 48000 0,02133.. Sekunden also 21ms bei PAL gerade etwas mehr als ein halbes VideoBild wäre,..
Interessant wäre zu wissen wie das bei He-aac aussieht, da wird ja anstatt 48kHz nur 24 verwendet, verdoppelt sich der Delay dann auf 42ms, was einem Frame entspricht?

Cu Selur

Genau auf diesen Post von DS bezog ich mich hiermit:

Zitat von sneaker2

Das weiß ich nicht. Ich habe nicht verstanden, warum der Delay nicht konstant ist, wenn er doch angeblich immer 1024 (IIRC) Samples lang sein soll.

Ist mir auch immer noch nicht klar, warum das nicht hinhaut.

Yo, alles irgendwie merkwürdig.
Problem ist halt, dass wenn wirklich fast alle Decoder kaputt sind wird es definitiv problematisch da irgendwie durch zu blicken, vor allem wenn man nicht weiß ob die es alle gleich falsch machen.

Ein kleiner Nachtrag:
Auch qaac (bzw. wohl auch iTunes/QuickTime selbst) schreibt das Encoderdelay in den mp4-Container. Allerdings ist das Verfahren nicht im MP4-Standard vorgesehen und anders, als das von NeroAacEnc. Qaac schreibt einen Tag mit dem Namen "iTunSMPB".
Dieser enthält beispielsweise folgenden Wert:
"00000000 00000840 00000240 00000000002C1D80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000"

Der zweite Abschnitt ("840") ist das Delay als Anzahl der Samples in Hexadezimaldarstellung. Also in Dezimaldarstellung umwandeln: 840 (HEX) = 2112 (DEC)
Danach durch Samplerate teilen:
2112samples/(48000samples/s) = 0,044s = 44ms

Der dritte Abschnitt enthält dann die zusätzliche Länge am Ende der Datei, die durch die konstante Framegröße vorgegeben ist. Also 240 (HEX) = 576 (DEC)
576samples/(48000samples/s) = 0,012s = 12ms

Im L-Smash Bugtracker sind auch zwei Einträge als feature requests dazu vorhanden. Ich nehme also an, daß sich das Problem zumindest theoretisch im MP4-Container standardkonform lösen läßt.

/edit:
Nero schreibt ab Version 1.5.1 anscheinend auch dieses Tag, zusätzlich zum Kapiteleintrag.
Auch fhgaacenc schreibt es. Damit wären wohl die wichtigsten Encoder - mit Ausnahme von ffmpeg - abgedeckt.

Der MKV-Kontainer enthält nach Möglichkeit Tonspuren ohne Versatz, indem diese (negativ) geschnitten oder (positiv) anfangs mit Stille aufgefüllt werden.

Im Fall des Vorn-Auffüllens muss der Multiplexer da wohl typische Blöcke für verschiedene Tonspurformate zur Verfügung haben...