Closed Bug 1482706 Opened Last year Closed 7 months ago
HE-AAC/AAC-SBR Seek Broken
46 bytes, text/x-phabricator-request
|Details | Review|
On Mac, when seeking within a high-efficiency AAC audio file (i.e. one that use SBR to achieve such a bitrate), the first frame(s) are not decoded with SBR. As a result, there is a very perceptible "blip" in audio quality for about 0.1 seconds. Steps to reproduce (with a reasonable pair of headphones): 1. Open a HE-AAC audio file (sample: https://cdn.index.hm/f/rHkX0jIzMjFlMWM4ZjMyY/10.wav.aac) 2. Seek within this file 3. Note the 0.1 second blip in audio quality where the decoder does not decode SBR, resulting in effectively no treble. Neither Safari or Chromium have this behaviour on Mac. I have not tested other platforms. This may be related to bug 1387127, which oversaw the initial implementation of HE-AAC playback on Mac.
I think I can hear the same glitch in Safari 11.1.2, Chrome seems fine though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
I guess we could make the aac demuxer seeks slightly earlier.. we do that already for the mp4 and mse demuxer...
Officially, the CoreAudio AAC decoder doesn't support implicit signaling of SBR in a AAC stream... What we do has always been a bit hackish... Seeking 2112 frames prior may not be enough, if the glitch is heard for 0.1s (it's a bit hard to tell for me with this particular sample)
Could you please test with this version and let us know if it fixes the problem for you.. thank you https://queue.taskcluster.net/v1/task/TrBXXM06Sqed6xpsjQKcew/runs/0/artifacts/public/build/target.dmg
The attached build does not seem to solve the issue for me, I can still hear the decoding artefact. It sounds about the same as previous.
What about this one? https://queue.taskcluster.net/v1/task/YsifeQnmSe-8OeWyJ_2_RQ/runs/0/artifacts/public/build/target.dmg It's bizarre that you're still hearing the glitch with the earlier version. The scanning code for inband SBR does find one, and the audio decoder is initialized with it.
I can hear the glitch when I seek backwards or repeatedly to the same point (i.e. click the same time in the seek bar - it's particularly noticable at ~00:23.5). If I skip forward, about half of the time I do not hear the glitch. However, it's an improvement.
How is that file actually encoded? How spread is the SBR stuff ? Basically I need to know how far back we need to seek for the AAC decoder to be able to fully decode it.
Comment on attachment 9001549 [details] Bug 1482706 - Pre-roll seek by 2112 frames to account for encoder delay. r?kinetik Matthew Gregan [:kinetik] has approved the revision.
Attachment #9001549 - Flags: review+
Copying my comment in Phabricator to here (I should've made it here instead): Assuming 2112 seems harmless enough. Fishing the correct value out of the MP4 would be more correct, but it's a bit of a mess with three different places to look. 2112 is derived from 2x 1024 frame packets and a hard 64 frame encoder delay. Looking at 10.wav.aac, the HE/HEv2 parts of the tracks have 2048 frame packets - so this file might need to skip 4160 frames? I'm not sure how HE mode would affect encoder delay, so that's a complete guess! Curiously, afinfo doesn't list encoder delay for this file. Usually you get something like: audio 266176 valid frames + 2112 priming + 0 remainder = 268288 (from gizmo.mp4), but afinfo 10.wav.aac doesn't print that line at all.
The file is encoded using ffmpeg 3.3.7 compiled with fdk-aac. ffmpeg is built using the trunk version of fdk-aac (https://github.com/mstorsjo/fdk-aac at a50eecf65b5ce5d4f03768c5c2cb4b492d2badad). There's a Docker build script for this available at https://raw.githubusercontent.com/InsanityRadio/Nerve/master/docker/Dockerfile.worker which is exactly how this ffmpeg is built. Here is an example command used to generate the file. There are no special options, it's a very standard way of generating HE-AAC-v2. The sample rate is intentionally limited. > ffmpeg -i 10.wav -ar 44100 -c:a libfdk_aac -profile:a aac_he_v2 -b:a 48k 10.wav.aac
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/6f9bdd2e9187 Pre-roll seek by 2112 frames to account for encoder delay. r=kinetik
You need to log in before you can comment on or make changes to this bug.