Strategies for compensating for AAC encoder delay/priming when exporting MP4? #444

I had recently tried using Mediabunny for export, and I think I’m hitting the same AAC encoder priming delay problems from the other side (vs #199).

When exporting to MP4/AAC with Mediabunny, an encoding delay is applied, but no elst box is added. There also seems to be an inconsistency between at least Chrome and Safari. On Chrome, real audio is shifted ~1024 samples later (not exact) with leading priming silence; annoying, but real data is intact. Safari is worse -- audio is shifted ~1024 samples like Chrome, but the first 2112 samples are silenced. Since the silenced region (2112) extends past the shift (~1024), it zeroes out roughly the first 1000 samples of legit audio, so real data is lost.

1024 sample frames selected:

2112 sample frames selected:

Here are the source and exported files, if useful:

Source wav file: beeps.wav
Exported from Chrome: beeps_aac_chrome.mp4
Exported from Safari: beeps_aac_safari.mp4

Based on Vanilagy’s comment on this WebCodecs thread, it sounds like the encoder doesn't surface any priming/delay information, so Mediabunny has nothing reliable to build a correct elst from. Given that constraint, I'm wondering if there are workarounds, even imperfect/hacky ones, that I could do through Mediabunny’s APIs:

• Could I do something like manipulate packet timestamps via EncodedAudioPacketSource that would make Mediabunny generate a elst that would trim into the media?
• Or, is there a way to add a custom elst with my own manual per-platform guess for the delay (e.g. 1024 vs. 2112)?

Thanks for any help!