*Configuration needs to be subclassed into *DecodingConfiguration

[vi-dot-cpp]

Due to additions to AudioConfiguration and VideoConfiguration that only apply to decodingInfo, these classes need to be subclassed into AudioDecodingConfiguration and VideoDecodingConfiguration, respectively.

cc: @chcunningham @gregwhitworth

[chcunningham]

Sounds good. Lets make a list on what to move out.

Audio: this one's obvious

• boolean spatialRendering

For video its less clear. We recently added these

• boolean hasAlphaChannel
• HdrMetadataType hdrMetadataType
• ColorGamut colorGamut
• TransferFunction transferFunction

Most of these aren't really decode specific. I'm not aware of any econding pipeline in Chrome that would produce HDR, but maybe one day.

hasAlphaChannel is weird for encoding. Its weird grammatically, but I also can't think of a practical use. Its easy to imagine an encoding with an alpha channel, but to be useful you'd need to say a lot more about how the alpha channel is constructed (e.g. are you removing the background behind a talking head from a camera stream)? I'd be happy to move this one to decode-only.

[vi-dot-cpp]

Thanks for enumerating the items to move out. I think the list makes a lot of sense. Unless anyone objects, I will prepare the change in the upcoming weeks.

[markafoltz]

The only properties that are obvious to move to inherited dictionaries are AudioConfiguration.spatialRendering and VideoConfiguration.hasAlphaChannel. The HDR related properties may have future use cases for encoding?

I am wondering if it is worth complicating the IDL (and code that relies on it) for two properties.