[whatwg] video tag: pixel aspect ratio

[Eduard Pascual]

On Wed, Oct 15, 2008 at 10:40 AM, Ian Hickson <ian at hixie.ch> wrote:
> 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?

Close is only enough for hand grenades.
The issue is that, for most (probably all cases), the limitations of
representation of floating numbers are a guarantee that the value will
be wrong. It is not the same 0.909090909 that
0.90909090909090909090909090909090909090909... and that wouldn't still
be the same that 10:11. Although the difference may seem negligible,
simple image scaling algorythms tend to yield horribel results for
slight scaling (you can try to render a PDF document at 101% zoom to
see what I'm speaking about; especially one with images). The
alternative, bilinear or trilinear scaling, could be too much of a
strain for video: there is a higly noticeable difference between
running such algorythm once and running it 25 or 30 times each second.
If we add to the mix that pages might be including several videos;
that most probably there is also audio playing along with the video,
the computation cost of decoding, and the fact that not every user on
the web (probably, not even the majority of them) uses a high end
computer; then scaling needs to be quick and simple enough to achieve
decent rendering without mass-frying CPUs.

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

I still don't understand why the spec has to define each and every
parser algorythm (IMO, it should only define the syntax, and then the
implementation should define its own algorythm that parses that syntax
as defined); but if that's the issue then a microsyntax can be
perfectly avoided by splitting the argument into two separate ones,
such as pixelratiox and pixelratioy.


Just my opinion.