[TrackConfiguration] Why not reuse WebCodec's configuration dictionaries?

[dalecurtis]

Instead of implementing new AudioTrackConfiguration and VideoTrackConfiguration dictionaries, can the corresponding AudioDecoderConfig and VideoDecoderConfig dictionaries from WebCodecs be reused?

The top requests we've gotten from developers are:

• What the heck is a codec string?
• How do I fill in AVC/HEVC description fields?

As a stop gap to providing a containers API, having this information available via tracks seems helpful.

Thanks for suggesting the API!

[jernoble]

I considered re-using AudioDecoderConfig and VideoDecoderConfig, but wanted to add framerate and bitrate fields.

The former is useful information to extract from a stream for displaying and validation, and the latter is useful for use with the MediaCapabilities' decodingInfo().

Perhaps rather than specifying this property as an interface, it could just be a dictionary. Then the underlying type matters less.

[jernoble]

So the one "conflict" between the two dictionaries is width and height in VideoTrackConfiguration vs codedWidth and codedHeight in VideoDecoderConfig. But codedWidth may include non-visible padding, and doesn't account for non-square pixels, whereas width (currently) declares the visible video dimensions. Maybe it's worth exposing both, but I don't think it's a matter of just replacing width with codedWidth.

[jernoble]

Come to think of it, the VideoTrackConfiguration shares more with visibleRect from VideoFrame than it does with VideoDecoderConfig.

[dalecurtis]

Ah, yeah I forgot about the visible rect / coded size / aspect ratio. They definitely aren't interchangeable and authors are more likely to want to know the visibleRect rather than being forced to calculate it.

+1 to a dictionary type, but you've convinced me just using the decoder config directly is more trouble than it's worth. Thanks for your consideration! Feel free to close if you're also convinced.

[jernoble]

Okay, landed the change to use a dictionary type rather than interface. Given this and @dalecurtis 's comment above, suggest closing this issue as fixed.