Do we need to accurately represent non-integer frame rates ?

[mwatson2]

Non-integer frame rates, such as 24000/1001, are common and aren't precisely representable in binary floating point. Typically, video frame rates are specified as rational numbers or with an enumeration (or both).

We should discuss whether we need to accurately represent the non-integer rates for this API.

[philcluff]

I'd say Yes. We frequently deliver video content which is best expressed in this manner. Otherwise, a common use case might be:

• Get a DASH manifest where the frame rate is specified as "24000/1001"
• Convert to a floating point (23.976, throwing away some accuracy), pass the payload to the MediaCapabilities API

It'd be nice not to have to convert for the MediaCapabilities API

[chcunningham]

I'm flexible on how we represent it. Internally this will probably be represented as floating point either way. Maybe even rounded to the nearest integer. Our answers for smoothness capabilities likely wont change based on small differences in fractional fps.

[mounirlamouri]

@geneticgenesis there is no API I'm aware of on the Web Platform that will take input such as "24000/1001". As @chcunningham mentioned, this would be converted to a double internally as we don't use fancy representations for fps.

Allowing to pass something else than a double would require adding a type in the Web Platform. I don't think it is worth it. Unless someone disagrees, I will mark this as WontFix and add a note to the spec pointing out this limitation. WDYT?

[mwatson2]

You don't need a new type, just two integers or an enumeration (which you could take from MPEG Codec Independent Code Points as has been done for the VP9 codec string values).

There isn't a problem for simple queries, but I worry about people mistakenly relying on the value they read back from this attribute because, for example, 24000 / 1001 != 23.967. Suppose you want to filter an array of MediaCapabilities objects - you need to be consistent about whether you are using exact (24000 / 1001) or approximate (23.967) frame rates. This could be a source of error, especially if you are using some third party library and you need to be consistent with what that does.

[mounirlamouri]

You seem to assume that implementations will return different values for 23.9, 23.967 and 24. Is there a specific reason that makes you think this? Does DASH allows for framerate expressed like this?

[mwatson2]

I'm not sure how DASH represents frame rate. I'm thinking of the case where a user creates a VideoConfiguration object and sets the framerate attribute to some value. I assume the attribute will retain the value that is set, rather than normalizing it to a canonical representation for each frame rate (the latter would solve my problem, but would need to be specified and would make this attribute rather odd).

So, the problem is that the attribute is set to, say, (24000/1001) and later someone tries to compare it to 23.967. They are not equal, but the same frame rate is intended.

[mounirlamouri]

I would be surprised if an implementation returns a different value for 23.967 and 24. I'm happy to add a note in the specification for implementation to consider this rounding error case. Would that resolve your concern?

[mwatson2]

The problem is that 24000 / 1001 != 23.967 either mathematically or as a JavaScript statement.

[mounirlamouri]

I think we should fix this indeed. I propose to match the DASH manifest specification and take a DOMString instead of a double. The DOMString will accept standard double or x/y format.

@mwatson2 @geneticgenesis @chcunningham WDYT?

[mounirlamouri]

This has landed as part of #51. Closing.

[chcunningham]

FYI, latest resolution discussion on this issue moved to
#96 (comment)