News for hackers. Stuff that matters.

A comment on Apple Backs AV1: What Does This Mean for the Future of Video Codecs. Parent comment

Re:Apple Backs AV1: What Does This Mean for the Future of Vi... by tzahola on Tuesday February 06, 2018 @05:53PM (#16320721)
Actually FLAC and Opus support was added to the Core Audio / AudioToolbox / AVFoundation APIs in iOS 11. Though the Opus decoder only supports raw packet decoding, i.e. you still need something to decode the container (usually ogg).

Also, FLAC file decoding is horribly slow - compared to the FOSS reference decoder -, because for some reason the whole file is scanned through on the first read when using the AudioFile APIs (AudioFileReadPacketData). (I’m gonna make a demonstration project for this and send them a bugreport tomorrow.)

[ Parent | on HN ]
Re:Apple Backs AV1: What Does This Mean for the Future of Vi... by tzahola on Thursday February 08, 2018 @06:42PM (#16336585)
Fyi, here’s the demonstration project I talked about: https://github.com/tzahola/AudioFileFLACBug
[ Parent | on HN ]
Re:Apple Backs AV1: What Does This Mean for the Future of Vi... by microcolonel on Wednesday February 07, 2018 @08:48AM (#16324322)
So bizarre to write their own decoder, especially given libFLAC is BSD licensed.
[ Parent | on HN ]
Re:Apple Backs AV1: What Does This Mean for the Future of Vi... by tzahola on Wednesday February 07, 2018 @12:36PM (#16326295)
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.)

[ Parent | on HN ]