Closed dontcallmedom closed 1 year ago
Defer to @padenot @aboba - since Chrome has already shipped we'd probably just have to add "frameRate" as equally valid versus removing "framerate"
Too bad, but it's a bit late at this point indeed. I assume this attribute sees a lot of use out there.
the future being longer than the past, can we move to frameRate and have implementation provides a backwards compat layer?
I don't mind accepting both, but defer to @padenot @aboba @youennf.
bitrate is a similar field in VideoEncoderConfig and is consistently lower cased in all APIs AFAIK. Is it fine to have frameRate but bitrate in the same dictionary?
We seem to use bitrate
everywhere AFAICT. bitrate
does seem to have "formal" recognition from dictionaries though: https://www.merriam-webster.com/dictionary/bit%20rate whereas I can't find an equivalent for framerate
.
I personally prefer framerate
and bitrate
but am always sympathetic to consistency arguments.
A similar CamelCase or flatcase issue is coming up with https://github.com/w3c/webcodecs/pull/594
I don't think we'll be renaming anything at this point. So let's live with what we have.
VideoEncoderConfig
uses lower-caseframerate
(as does media capabilities), when other specs (screen capture, media capture and streams, webxr) use the camel-caseframeRate
.Aligning would be an improvement from a developer ergonomics perspective