W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2014

Re: [Bug 26526] Fix aspect ratio constraint

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 15 Aug 2014 18:21:44 -0600
Message-ID: <CACQ=j+ednwObe4JHKkSBdKR3tZdbHvD0-Yw6LoJ6sR4qskrWKQ@mail.gmail.com>
To: Gili <cowwoc@bbs.darktech.org>
Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand <harald@alvestrand.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>, Martin Thomson <martin.thomson@gmail.com>
On Fri, Aug 15, 2014 at 4:29 PM, Gili <cowwoc@bbs.darktech.org> wrote:

> On 15/08/2014 12:35 PM, Jan-Ivar Bruaroey wrote:
> On 8/15/14 4:08 AM, Harald Alvestrand wrote:
> When something's a number in Javascript, it's perfectly legal to write an
> expression like 16/9 in that space.
> Your other alternatives - { num: 16, den: 9 } and "16/9" - are, to me,
> more complex and less readable - the author has to remember that while he
> thinks of it as a number, he has to remember that there is a special syntax
> that is only used for expressing numbers in this particular place.
> Specifying an epsilon allows the author to write the number in most
> fashions he's used to, and have the result of the comparision be the same.
> I believe the epsilon solution is the easiest one for authors.
> +1 on 16/9 (or width/height for that matter) being the ideal JS
> expression, and on the alternatives being atypical.
> I'm with Silvia on this: "16/9" is exact and readable. The fact that the
> author has to remember to use a String instead of a Number is not a
> readability concern, it is a question of whether the API is intuitive
> (behaves as expected without users having to read the documentation).
> I agree that 16/9 *looks* more intuitive than "16/9" but it *behaves* less
> intuitively.
> Looks: if we require a String and the user passes a float, the system will
> fail-fast and little harm is done.
> Behavior: when the user specifies 16/9 he means *exactly* 16/9, not some
> approximation. The epsilon you mentioned might work today but will break in
> unpredictable ways in the future (as implementations are exposed to
> resolutions we did not foresee ahead of time, such as 4k). In that case,
> the float comparison will fail and the system will violate the principal of
> least surprise.
> Nobody NEEDS to specify an aspect ratio of 1.3334 and not have it match
> 1.3333.
> You don't know that. You have no way of predicting what kind of
> resolutions webcams will support, or what level of accuracy users will
> want/need in the future. You're forcing implementation details on end-users
> instead of hiding them under the hood. You shouldn't make such a decision
> purely for the sake of simplifying the algorithm implementation.
> Implementation details change over time, but API design is locked for life.

We had a similar problem in TTML with respect to expressing media frame
rate precisely. For example, a common video frame rate (NTSC drop frame
mode) is exactly 30 * 1000/1001 or repeating decimal 29.97002997002997...
We specified separate frameRate [1] and frameRateMultiplier [2] value
expressions, the former being a non-negative integer, the latter a pair of
non-negative integers (numerator and denominator).


So for NTSC rates, one would specify attributes:

   - ttp:frameRate="30"
   - ttp:frameRateMultiplier="1000 1001"

> Gili
Received on Saturday, 16 August 2014 00:22:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:29 UTC