Opened 5 years ago
Last modified 5 years ago
#7286 new enhancement
Audiotoolbox: Support decoding Opus and FLAC
|Reported by:||macdavis||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Since MacOS 10.13 / iOS 11, Apple has included "kAudioFormatOpus" (https://developer.apple.com/documentation/coreaudio/1572096-audio_data_format_identifiers/kaudioformatopus?language=objc) and "kAudioFormatFLAC" (https://developer.apple.com/documentation/coreaudio/1572096-audio_data_format_identifiers/kaudioformatflac?language=objc) into its Audio Data Format Identifiers, which makes it possible to decode those two codecs with Audiotoolbox. Please add this support, thanks!
Change History (7)
by , 5 years ago
by , 5 years ago
comment:1 by , 5 years ago
comment:2 by , 5 years ago
As tzahola mentioned in https://news.ycombinator.com/item?id=16320721,
It actually makes sense, because libFLAC has no public API for getting the compressed audio packets as is. Rice/huffmann/whatever decompression always happens inside libFLAC.
With Apple’s AudioFile API you can decide whether you want the decompressed PCM samples, or the underlying compressed packets. You can get better energy efficiency if you offload the decompression step to the dedicated coprocessor. The difference is smaller than with hardware vs software h.264 decoding, but there is a difference.
(For lossy codecs this also makes sense when you want to forward the compressed packets to a wireless speaker in order to avoid lossy recompression on Bluetooth transmission.)
comment:3 by , 5 years ago
|Component:||undetermined → avcodec|
|Type:||defect → enhancement|
|Version:||unspecified → git-master|
comment:4 by , 5 years ago
Yeah, no, that's wrong. I'll believe it when Apple designs and rolls out a hardware decoder for flac, which I really doubt they'll do.
And like the previous post states, the decoder is extremely slow.
Also don't reference HN, its not an accurate and unbiased source of information.
comment:5 by , 5 years ago
|Priority:||normal → wish|
What's the point when the implementations are likely to be slower than our native ones.