Open dalecurtis opened 1 year ago
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.
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
.
Come to think of it, the VideoTrackConfiguration
shares more with visibleRect
from VideoFrame
than it does with VideoDecoderConfig
.
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.
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.
Instead of implementing new
AudioTrackConfiguration
andVideoTrackConfiguration
dictionaries, can the correspondingAudioDecoderConfig
andVideoDecoderConfig
dictionaries from WebCodecs be reused?The top requests we've gotten from developers are:
As a stop gap to providing a containers API, having this information available via tracks seems helpful.
Thanks for suggesting the API!