- From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
- Date: Wed, 15 Oct 2008 20:34:49 +0200
The user agent could calculate the best continued fraction approximation to recover the original ratio from the floating-point representation. That means the denominator should be limited somehow. Otherwise, the attribute could be split into two in order to avoid the microsyntax. The resulting attributes are guaranteed to have ugly names though. "pixelratiowidth" and "pixelratioheight" are better than "pixelratiox" and "pixelratioy" because they have the advantage of being readable. Chris -----Original Message----- From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson Sent: Wednesday, October 15, 2008 11:41 AM To: Sander van Zoest Cc: whatwg at lists.whatwg.org Subject: Re: [whatwg] video tag: pixel aspect ratio On Tue, 14 Oct 2008, Sander van Zoest wrote: > > I just recently started looking at HTML5 and noticed the video tag. Neat > addition. I also noticed that it as an attribute named 'pixelratio', > however, as you know this is never an integer, but rather is the result > of a fraction (i.e. ratio). As for proper playback of video frames, it > is important to understand exact float and therefore I would suggest > either expressing it as a ratio of two 32-bit integers separated by a > colon (or slash) or use two different attributes. This avoids > unintentional rounding. > > Something roughly along the lines of: > > <source pixelratio="10:11"> <!-- 525 composite NTSC --> > <source pixelratio="59:54"> <!-- 625 composite PAL --> > <source pixelratio="1018:1062"> <!-- 1920x1035 HDTV SMPTE RP 187-1995 --> Currently pixelratio is a floating point number, as in: <source pixelratio="0.909090909"> <!-- 525 composite NTSC --> <source pixelratio="1.09259259"> <!-- 625 composite PAL --> <source pixelratio="0.958568738"> <!-- 1920x1035 HDTV SMPTE RP 187-1995 --> Is that not enough? This isn't expected to be used often. It's really only provided to allow for simple override of the actual value in the video file, for when the video file is known to be wrong. I am very reluctant to make up a whole new microsyntax and corresponding parser algorithm, along with all the tests, etc, to handle this one case.
Received on Wednesday, 15 October 2008 11:34:49 UTC