Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#9375 closed defect (duplicate)

AAC decoder priming not discarded

Reported by: neXyon Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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).

Change History (7)

comment:1 by Marton Balint, 3 years ago

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.

comment:2 by Balling, 3 years ago

Is not this the same as in #2325? Last comment there says what should be done (what metadata should be written) to fix this. As for raw aac it cannot be fixed, only guessed by the program that wrote it.

Last edited 3 years ago by Balling (previous) (diff)

comment:3 by neXyon, 3 years ago

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.

comment:4 by Balling, 3 years ago

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.

Last edited 3 years ago by Balling (previous) (diff)

comment:5 by Balling, 3 years ago

It writes stuff into media time in mp4 container. But

Version 0, edited 3 years ago by Balling (next)

comment:6 by Balling, 3 years ago

Resolution: duplicate
Status: newclosed

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

comment:7 by Balling, 3 years ago

Keywords: AAC aac priming removed
Last edited 3 years ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.