AAC decoder priming not discarded

[neXyon]

Summary of the bug:

AAC priming samples should be discarded and not transcoded with ffmpeg. This issue exists when using ffmpeg on the command line, but we also experience it using avcodec as library directly in Blender.

How to reproduce:

Take any wav file and transcode it to aac and back to wav:

% ffmpeg -i original.wav -acodec aac intermediate.aac
% ffmpeg -i intermediate.aac final.wav

If you now compare the two wav files you'll see (besides some expected artifacts due to the compression of aac) that the final.wav has priming samples added at the beginning that shouldn't be there.

Using the API:

Using the API of ffmpeg, we would like to be able to discard the priming ourselves, but while AVPacket and AVFrame both have flags fields which can have either AV_PKT_FLAG_DISCARD or AV_FRAME_FLAG_DISCARD set, none of those are set for the respective packages. Is there another way to distinguish whether the start of an audio stream should be discard?

A possible solution for a video file where we have a video and an aac audio stream is to drop any audio before the first PTS of the video stream. However, this is not a good solution since there could be audio before the video stream that should be played back (so the audio stream starts before the video stream intentionally).

[Marton Balint]

AFAIK AAC priming is not constant, therefore the file container usually stores this information. As far as I know there is no way to determine priming in a raw AAC bitstream, so this can't be fixed, or at least not using the command lines you provided.

[Balling]

Is not this the same as in #2325? Last comment there says what should be done (what metadata should be written) to fix this.

[neXyon]

That's good to know, that this cannot really be fixed, at least without the container storing the information. And from #2325 I gather that only quick movie (.mov) would be able to do so? In our tests, we used matroska (.mkv) with a video stream added and I also just tried .mov - same result.

[Balling]

Ffmpeg can write a pgap inside the track's udta via -metadata:s:a gapless_playback=X where X is an 8-bit value. I suppose it is 1024 for native encoder.

After that AAC skipping and stuff will work no problem.

P.S. Oh, no that is just a flag.

[Balling]

It writes stuff into media time in editlist mp4 container. But media duration of editlist even though written correctly is not applied on decoding.

[Balling]

Anyway, it is a duplicate of at least 3 tickets.