Re: [whatwg] video tag: pixel aspect ratio

2008-11-18 Thread Sander van Zoest
On Mon, Nov 17, 2008 at 11:33 PM, Robert O'Callahan [EMAIL PROTECTED]wrote:

 On Tue, Nov 18, 2008 at 7:28 PM, Sander van Zoest [EMAIL PROTECTED]wrote:


 By the way, the pixel-aspect-ratio on video caps in the GStreamer
 framework has precisely the same meaning as this attribute, overriding
 it on a video sink also has an effect similar to what is suggested in
 the HTML5 spec. In other words, it's not so outlanding from a media
 framework's point of view.


 In the capture world it makes a lot of sense. You are converting analog
 content
 into digital. It is my understanding that HTML5 is presentation
 technology, not
 a video capture, transcoding or editing framework.


 Video capture is getting popular on the Web, so it would not be surprising
 to see HTML5 extend in that direction in the future.


Sure, let's cross that bridge when we get there. I certainly can see
usb-type cams and mics, but that is quite different then a full on video
capture framework.

-- Sander


Re: [whatwg] video tag: pixel aspect ratio

2008-11-14 Thread Sander van Zoest
On Thu, Nov 13, 2008 at 9:12 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote:

 In any case, if this attribute really needs to be present, we should rename
 it at the minimum (picking a term from the professional video world
 requires taking the constraints that come with it), maybe displayRatio or
 something?


If you are going to keep it, how about pixelfloat, as it clearly is not
presented as a ratio. The word display makes me think DAR.

-- Sander


Re: [whatwg] video tag: pixel aspect ratio

2008-10-15 Thread Sander van Zoest
On Wed, Oct 15, 2008 at 8:14 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:

 On Wed, 15 Oct 2008 17:01:22 +0200, Sander van Zoest [EMAIL PROTECTED]
 wrote:

 I hate to say it, but if it was enough, I wouldn't be commenting here. It
 simply isn't accurate
 enough to store it as a float.


 How is not accurate? In terms of precision it shouldn't really matter...


We are talking video here. Precision is at its core. If you consider the
majority of the broken
video out on the net today a good example of what you want more of then, I
see no reason
to accurately define PAR. I won't get into Frame Rates such as 59.94Hz,
since that is off topic
here, but you can not accurately convert video on the fly if you do not have
the exact ratio. All
this stems from the conversion from analog to digital and in the analog
world we did a lot of funky
tricks to make things work better on hardware of those days, but as our
computers and electronics
in general get faster and faster, putting in inaccuracies can cause for some
seriously ill side effects,
now and especially in the future. Because of the conversion from analog to
digital there are a lot of funky areas where you end up with a PAR/SAR that
would be rounded inaccurately if expressed as a float. 2 32-bit
integers is what is used today, with the hope that that will get us into a
fully square pixel world, by the time
the video quality gets good enough where we can no longer express PAR in
32-bit integers.

For some background on this see 
http://lipas.uwasa.fi/~f76998/video/conversion/. I really do not want to
add to the inaccuracies in the world, especially if we have a chance to do
it right.

There are already many of these types of mistakes in things like Media RSS,
I wouldn't know how to accurately express the frame rate of a 30M clip in
the framerate attribute of the content element. For some of the madness that
we are talking about here, see 
http://groups.google.com/group/sci.engr.advanced-tv/msg/108815e3089c4d53?pli=1.


I am sort of of the camp, if you are going to even provide pixelratio as an
attribute, then at least do it like every other container format out there,
rather then expressing it a manner that limits its use and forces
inaccuracies caused by rounding and human error (because they do not
understand why you want a 10 digit float).

Take it for what it is worth.

-- Sander


Re: [whatwg] video tag: pixel aspect ratio

2008-10-15 Thread Sander van Zoest
On Wed, Oct 15, 2008 at 11:11 AM, Ralph Giles [EMAIL PROTECTED] wrote:

 On Wed, Oct 15, 2008 at 2:40 AM, Ian Hickson [EMAIL PROTECTED] wrote:

  Is that not enough?

 It is enough. Sander and Eduard have provided excellent arguments why
 the pixel aspect ratio, and especially the frame rate, should be
 represented as rationals in video formats. But as an override for
 already broken video streams compliance to best practice does not
 justify another data type in html5.


Is an integer another data type? Also, having non-square pixels is not
broken. If we go this route, we might as well get rid of the distinction all
together.



 To put Anne's comment another way, one needs a gigapixel display
 device before the difference between 1.0925 (rounded to only 5
 figures) and 59/54 affects the behaviour of the scaling algorithm at
 all. There aren't so many aspect ratios is common use--you're welcome
 to choose the one nearest to the floating point value given if you
 think it's important.


I do not see why we are condoning hacks on top of hacks, when it is so
simple
to just specify hSpace and vSpace.

-- Sander


Re: [whatwg] video tag: pixel aspect ratio

2008-10-15 Thread Sander van Zoest
On Wed, Oct 15, 2008 at 2:48 PM, Eric Carlson [EMAIL PROTECTED]wrote:


 On Oct 15, 2008, at 1:04 PM, Ralph Giles wrote:

  On Wed, Oct 15, 2008 at 12:31 PM, Sander van Zoest [EMAIL PROTECTED]
 wrote:

  Following that logic, why add the attribute at all?


 Well, I like the pixelaspect attribute because incorrect aspect ratios
 drive me up the wall. Because the video and its embedding page are
 often served from different locations, it's nice to have a way to fix
 it the doesn't require editing the video file.

   I agree that incorrectly encoded videos are annoying, but I don't think
 we should have this attribute at all because I don't think it passes the
 will it be commonly used smell test.

  I am also afraid that it will difficult to use correctly, since you
 frequently have to use clean aperture in conjunction with pixel aspect ratio
 to get the correct display size. For example (you probably know this, but
 for the benefit of others following the discussion) DV NTSC video is
 720x480, has Rec.601 aspect ratio (10:11), and should be displayed at
 640x480. Multiplying 720x480 by 10:11 doesn't give 640x480 however, you have
 to crop to clean aperture (704x480) first. We *definitely* don't want to
 expose CLASP.

  I don't think it should be included in the first version of the spec.


Certainly not. I forgot about the required crop. I am now even more
convinced it doesn't belong in the spec.
Let the container handle this detail.

-- Sander


[whatwg] video tag: pixel aspect ratio

2008-10-14 Thread Sander van Zoest
Hi,

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:

video pixelratio=10:11 !-- 525 composite NTSC --
video pixelratio=59:54 !-- 625 composite PAL --
video pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 --

video parhSpacing=10 parvSpacing=11

Container formats tend to store this information in a ratio like this and
not in a float.

Best,

-- 
Sander van Zoest
[EMAIL PROTECTED]
San Diego, CA, USA
http://Sander.vanZoest.com/


Re: [whatwg] video tag: pixel aspect ratio

2008-10-14 Thread Sander van Zoest
On Tue, Oct 14, 2008 at 9:39 AM, Sander van Zoest [EMAIL PROTECTED]wrote:


 Hi,

 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:

 video pixelratio=10:11 !-- 525 composite NTSC --
 video pixelratio=59:54 !-- 625 composite PAL --
 video pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 --

 video parhSpacing=10 parvSpacing=11

 Container formats tend to store this information in a ratio like this and
 not in a float.


Please excuse me for referencing the video tag as, after further reading, it
is apparent that the pixelratio attribute is applied to the source tag.
Regardless, I believe the same points apply, so therefore please mentally
/video/source/ . Thank you and sorry for the confusion and stress I may
caused.

-- Sander