% ffmpeg -decoders 2>/dev/null | rg fdk
A....D libfdk_aac           Fraunhofer FDK AAC (codec aac)

[...]It has to be enabled in [...] at build time. [...]

Ubuntu not enabling support in ffmpeg despite libfdk being already available in their repositories is their problem. And it's an easily fixable one.

ffmpeg requires --enable-nonfree for --enable-libfdk-aac, which means that fdk-aac enabled ffmpeg binary is not redistributable.

EXTERNAL_LIBRARY_NONFREE_LIST="
decklink
libfdk_aac
openssl
libtls
"

ffmpeg requires --enable-nonfree for --enable-libfdk-aac, which means that fdk-aac enabled ffmpeg binary is not redistributable.

So, if I understand correctly, USAC decoder is only able to start decoding from an independent AU where usacIndependencyFlag is set, and current default of exhale lib is once per 45 frames (but it can be arbitrary), right?

Is that mean, USAC decoder has to seek back (preroll) unpredictable number of frames on seek in order to find an independent AU where it can start decoding without the help of preroll sample group added by the patch?

If I understand the author of that issue correctly, no, but something similarly bad: the decoder would have to search through all AUs before or at the current seek point (start offsets of each AU are stored in the MPEG-4 file header, so that's still quite cheap) and find the closest one which is independently decodable (which may not be cheap!). The solution was to add another box to the MPEG-4 file header containing the period between successive tune-in AUs, allowing the decoder to simply pick out the independently decodable AU closest in time to the current seek point.

foobar2000 packet decoders implement seek for their callers by reporting the maximum dependency in floating point seconds, and in frame counts. The frontend, be it MP4, ADTS, ADIF, Matroska/WebM, etc, will seek backwards by this amount, ask the decoder to start decoding, then discard the dependency time from the start of the samples. Not terribly flexible, and definitely doesn't support keyframes to my knowledge.

For me it looks like conceptually similar to key frames of video, and I wonder if it's also possible to simply use good old Sync Sample Box (stss) to indicate them.

Yes, those are basically key frames. Don't know about the 'stss' part, the only use of that box that I know of (the one used by the exhale application) is to signal to the decoder, by means of entryCount = 0, that not every sample is a sync sample.

5.2.2.2 Random Access Point and Stream Access Point

A File Format sample containing a Random Access Point (RAP), i.e., a RAP into an MPEG-H
Audio Stream, is a “sync sample” in the ISOBMFF and shall consist of the following MHAS
packets, in the following order:
• PACTYP_MPEGH3DACFG
• PACTYP_AUDIOSCENEINFO (if Audio Scene Information is present)
• PACTYP_BUFFERINFO
• PACTYP_MPEGH3DAFRAME
Note that additional MHAS packets may be present between the MHAS packets listed above
or after the MHAS packet PACTYP_MPEGH3DAFRAME, with one exception: when present, the
PACTYP_AUDIOSCENEINFO packet shall directly follow the PACTYP_MPEGH3DACFG
packet, as defined in ISO/IEC 23008-3 Amendment 3 [4] Clause 14.4.
Additionally, the following constraints shall apply for sync samples:
• The audio data encapsulated in the MHAS packet PACTYP_MPEGH3DAFRAME shall
follow the rules for random access points as defined in ISO/IEC 23008-3, Clause 5.7 [2].
• All rules defined in ISO/IEC 23008-3 Amendment 2, Clause 20.6.1 [3] regarding sync
samples shall apply.
• The first sample of an ISOBMFF file shall be a RAP. In cases of fragmented ISOBMFF
files, the first sample of each Fragment shall be a RAP.
• In case of non-fragmented ISOBMFF files, a RAP shall be signaled by means of the File
Format sync sample box “stss,” as defined in ISO/IEC 23008-3 Amendment 2, Clause 20.2
[3].
• In case of fragmented ISOBMFF files, the sample flags in the Track Run Box ('trun') are
used to describe the sync samples. The “sample_is_non_sync_sample” flag SHALL be set
to “0” for a RAP; it shall be set to “1” for all other samples.

• In case of non-fragmented ISOBMFF files, a RAP shall be signaled by means of the File
Format sync sample box “stss,” as defined in ISO/IEC 23008-3 Amendment 2, Clause 20.2
[3].

Is that really necessary? I'm writing chunk information ('stsc' and 'stco' boxes), with each chunk starting with an independently decodable frame and a length up to the next independently decodable frame. I thought this is sufficient.

All IPFs {which are frame types that exhale doesn't write yet} are signaled by means of the SyncSampleBox.
{...}
In addition to the rather expensive IPFs, all AUs that have the usacIndependencyFlag set to 1 can be used to enable random access, e.g. for seeking operations. While these Independency Frames (IF) can be used to start decoding, a full audio signal is guaranteed only after decoding a certain number of AUs. This is referred to as roll distance in file format terms and can be signaled using the AudioPreRollEntry and the AudioSampleGroupEntry, respectively.

I've been testing the serialized 'csgp' atom for interoperability with Apple's current macOS developer preview, which is capable of parsing these atoms and of decoding xHE-AAC audio, by creating relatively lengthy encodings and seeking to a random access point near the end. Playback can proceed with little delay only if Apple's implementation has located an independently decodable frame near the point of resumption after a seek. Without 'csgp', a considerable amount of time is required to decode from the start before playback can resume.
It's also possible for me to use tools built upon Apple's APIs to convert exhale-produced .mp4 files to Apple-produced .mp4 files, which will contain the same information that the 'csgp' atom contains in the form of an 'sbgp' atom. These will accurately reflect the same random access interval.

Oh, I see.. so, exhale expects decoders to always preroll from the beginning of the chunk where the target sample is located?