[whatwg] video tag: pixel aspect ratio

[Kristof Zelechovski]

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 at 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.