search

w3c / webcodecs

WebCodecs is a flexible web API for encoding and decoding audio and video.
https://w3c.github.io/webcodecs/
Other
975 stars 137 forks source link

framerate vs frameRate #588

Closed dontcallmedom closed 1 year ago

dontcallmedom commented 1 year ago

VideoEncoderConfig uses lower-case framerate (as does media capabilities), when other specs (screen capture, media capture and streams, webxr) use the camel-case frameRate.

Aligning would be an improvement from a developer ergonomics perspective

dalecurtis commented 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"

padenot commented 1 year ago

Too bad, but it's a bit late at this point indeed. I assume this attribute sees a lot of use out there.

dontcallmedom commented 1 year ago

the future being longer than the past, can we move to frameRate and have implementation provides a backwards compat layer?

dalecurtis commented 1 year ago

I don't mind accepting both, but defer to @padenot @aboba @youennf.

youennf commented 1 year ago

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?

dalecurtis commented 1 year ago

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.

dalecurtis commented 1 year ago

A similar CamelCase or flatcase issue is coming up with https://github.com/w3c/webcodecs/pull/594

Djuffin commented 1 year ago

I don't think we'll be renaming anything at this point. So let's live with what we have.