Document recommended way for Base/Simple profile device to use v1.1.0 software.

[jwcullen]

What's the recommended way for a device that wants to use Simple or Base profile to upgrade their software version to v1.1.0? They may want to upgrade for bug-fixes or other reasons, without being forced to use the new profiles.

Should they just use IAMF_decoder_get_codec_capability and reject any unexpected streams? What if IAMF_decoder_get_codec_capability notes there are two profiles, how should they find which mix they should decode?

Asking because of #145 (comment).

[yilun-zhangs]

Hi @jwcullen
libiamf has a branch named v1.1.0-branch, how about using it as the branch to upgrade for bug-fixes or other reasons?

[jwcullen]

Oh, I thought there would be a way to select older profiles on the newer software versions. Some devices have resource restrictions so they would prefer to use the older profiles. But those devices still want bug-fixes or optimizations.

I'm asking because the older branches look unmaintained. I see several PRs with bugfixes or optimizations that apply to Simple or Base profile, but have not made it to the older branches.

Future versions of IAMF with new profiles will result in another one of these branches

[yilun-zhangs]

I'd like to share my understanding to your idea.
For example, IAMF v2.0 decoder supports profile from 0 to 5, the decoder has the capability of rendering object-based audio and supporting 28 channels, but devices want to use profile 1 and set it to decoder.
Then decoder will work based on profile 1, even if the decoder still has object-based rendering logic internally, right?
That is to say, all the implementations still are in decoder, but the work logic is different based on setting profile by device?

[jwcullen]

Yeah, your understanding is correct.

I think the benefit here is some production devices could want to upgrade software without automatically forcing higher profile to be used. It's possible a mix isn't available in their target profile, that is OK, just let them know.

Some devices may be concerned about CPU usage and intentionally want to restrict the available profiles. Seems cleaner to have this configurable via software, instead of requiring them to use an older software branch indefinitely.

Even under (planned) v2.0.0 software, I'm curious how a device is supposed to be configured as a profile 3 or 4 device (18 ch)?

[yilun-zhangs]

Thanks for your explanation, I think it makes sense.

Even under (planned) v2.0.0 software, I'm curious how a device is supposed to be configured as a profile 3 or 4 device (18 ch)?

In my opinion, the most important factors affecting the CPU are the channel numbers, object rendering and 2 submixes if only considering profiles(0 ~ 5).
So we can add interface to set mandated profile from outside, iamf decoder can process to drop the audio elements which don't meet the mandated profile internally.