Re: [whatwg] video tag : loop for ever
On Wed, 15 Oct 2008 13:06:20 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 03:40, Ian Hickson wrote: To be honest I'm not really convinced we need the looping feature at all. I agree. I never really understood what the use cases were for these attributes. I got the impression they were added because of feedback from Apple, but the reason was never clear to me. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. One benefit of getting authors to use a declarative attribute instead of a script is that a declarative attribute is easier to greasemonkey away if the user seriously doesn't like looping. If this really turns out to be a problem user agents could always add measures to prevent playing a video more than once. After all, they are in charge of the video stream now with video. Authors can merely try to interact with it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
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 : loop for ever
On Wed, 15 Oct 2008 17:38:50 +0200, João Eiras [EMAIL PROTECTED] wrote: Why not just assuming that playcount=0 means loops forever ? Why not drop the feature completely? What are the use cases for keeping looping attributes in the specification at all seems a much more important question to answer than how to potentially address infinite looping without resorting to scripting, no? :-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
Patterns may be ambiguous; an algorithm that is ambiguous would also be dubious and thus easily identified and rejected. Of course, patterns can be proven to be precise, but using explicit algorithms is safer. IMHO, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual Sent: Wednesday, October 15, 2008 5:22 PM To: Ian Hickson Cc: whatwg@lists.whatwg.org; Sander van Zoest Subject: Re: [whatwg] video tag: pixel aspect ratio On Wed, Oct 15, 2008 at 10:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: 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.
Re: [whatwg] video tag : loop for ever
Is there any possible usefulness whatsoever in making playcount=0 not play the video at all? That's what autoplay is for. On Wed, Oct 15, 2008 at 5:53 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 8:38 AM, João Eiras wrote: Why not just assuming that playcount=0 means loops forever ? This was exactly my thought. If playcount=5 causes the video to be played 5 times, what should the result of each of these be? playcount=1 playcount=0 playcount=-5 playcount=foobar Is there any possible usefulness whatsoever in making playcount=0 not play the video at all? If not, I don't see a good reason not to use that to mean infinite looping. Either that, or some keyword, but I don't know what it should be. infinite and forever come to mind. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] video tag javascript library for contemporary browsers
Am Mittwoch, den 15.10.2008, 09:52 -0400 schrieb Michael A. Puls II: Awesome! The vlc plugin has awesome performance! Way better than native video implementations currently. Maybe the Mozilla and Opera people can tell us why ? After all, the optimizations in VLC apparently are all open source ... Cheers, Nils
Re: [whatwg] video tag : loop for ever
On 10/14/08, Silvia Pfeiffer [EMAIL PROTECTED] wrote: YouTube has a loop parameter (loop=1), which you need to add to the URL of the video file in your embed code. It is a boolean, which puts the number of loops into the control of the user rather than the web page author. Cool. I might user UserJS to add that to all video embed URIs on youtube to have loop on by default. -- Michael
Re: [whatwg] Scripted querying of video capabilities
On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. On Mon, 13 Oct 2008, Maciej Stachowiak wrote: Also, should we make .load() asynchronous as far as selecting a media file goes? Right now, a media file has to be instantaneously and synchronously selected, so the UA can't try each one in turn. I believe the original design intent was to make selection completely static and not not based on a fallback-like approach of trying each in turn. Let's assume IE implements video at some point but does not support Ogg or MPEG-4 out of the box. Then an author wishing to provide 3 media streams could still likely get the job done, since browsers could likely determine whether or not particular basic content types are supported. It might be hard to get more complex cases right though. On Tue, 14 Oct 2008, Robert O'Callahan wrote: IMHO load() should be asynchronous and should try each in turn. That would dramatically increase the power of fallback and doesn't seem to cost too much. Chris Double points out that there are edge cases where some streams in a container are supported, but others aren't; for example a framework might support only Ogg Vorbis but not Theora, and you try to play a Vorbis+Theora file, and you get no error from the framework, but you might have preferred to fall back. However, if the author provided the right MIME information, the UA could know that there is supposed to be video, and detect that there isn't any video coming out, and fall back. On Tue, 14 Oct 2008, Robert O'Callahan wrote: We definitely have to change that! Having load() synchronous would be a disaster. On Tue, 14 Oct 2008, Eric Carlson wrote: I agree! A truly synchronous load() will result in a terrible user experience as a UA may need to download a significant amount of data before it knows if a file is playable. Right now the spec picks a resource *without checking with the server*, statically, and then the method returns, and then asynchronously it checks to see if the resource is usable. I am proposing changing the spec to make the load() not select a resource. Instead, load() would immediately return, and the user agent would then asynchronously try each resource that it might otherwise use in turn, firing a single loadstart event at the start, lots of progress events, and then a loadedmetadata or error event depending on how things go. On Tue, 14 Oct 2008, Dave Singer wrote: This brings up another point, which is, is the type attribute on source actually useful? Should we remove that and just have browsers probe the video subsystem for each resource? We can always add the attribute back later if it becomes useful again, but I'd rather not have something that isn't used by browsers, since then it'll be used wrong by authors, making it useless forever. I think it is. Without it, the UA would have to open each source and get its type via HTTP content-type, which is a lot slower, wouldn't it? Is it clear that if the type is supplied in the markup, the UA can (and probably will) use it for content selection, at least at the coarse level, thus avoiding opening connections for files it knows (from the type) it cannot support. If we make the load() asynchronous and allow probing from the client (testing each potentially supported resource in turn), should we make the type optional, then? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag javascript library for contemporary browsers
On Wed, 15 Oct 2008 13:13:17 -0400, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Mittwoch, den 15.10.2008, 09:52 -0400 schrieb Michael A. Puls II: Awesome! The vlc plugin has awesome performance! Way better than native video implementations currently. Maybe the Mozilla and Opera people can tell us why ? After all, the optimizations in VLC apparently are all open source ... Certainly in Opera's case VLC being open-source doesn't help: the code is released under a restrictive license (GPL), so unless I misunderstand the finer ponts of the license Opera would be unable to use it. -- J. King http://jking.dark-phantasy.com/
Re: [whatwg] video tag : loop for ever
Play count 9 means just that number, it does not mean forever by itself. It is only functionally like forever because no one is likely to let it loop till the play count specified is reached. A 32-bit quantity is enough to get this effect. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras Sent: Wednesday, October 15, 2008 1:19 PM To: Henri Sivonen Cc: whatwg group Subject: Re: [whatwg] video tag : loop for ever Using a high number like 9 is, IMO, stupid. You'd be forced to tell in the spec that playcount would have to be a 16, 32, 64, or X bit big integer, and if anything overflows the boundaries imposed by the internal integer representation, then playcount would have to be rounded to the highest possible boundary or assume infinite looping. Else, some browser will use a 64bit representation while its neighbour will use a 32bit integer (common sense might find 64bit too big and awkward) but then an authoring tool or author use playcount=99 (10 digits) and somehow the browser with 32bit playcount integer breaks.
Re: [whatwg] video tag : loop for ever
Am Mittwoch, den 15.10.2008, 00:40 + schrieb Ian Hickson: There is no way to say loop forever right now primarily because doing so would mean complicating the syntax of the playcount attribute to be not just a number. You can work around it with script (just add onended=currentTime=0 to the video element). Now that you mention it: why not just make loop a boolean to be turned off and on by scripting ? Cheers, Nils
Re: [whatwg] video tag: pixel aspect ratio
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. 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. -r -- Ralph Giles Xiph.org Foundation
Re: [whatwg] Scripted querying of video capabilities
That assignment makes the intuitive code if(canPlayType(_)) incorrect. Cannot should be 0, and enumeration symbols should be provided. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 15, 2008 10:44 AM To: Maciej Stachowiak; Robert O'Callahan; Dave Singer; Nils Dagsson Moskopp; Eric Carlson Cc: WHATWG List Subject: Re: [whatwg] Scripted querying of video capabilities On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses.
Re: [whatwg] video tag: pixel aspect ratio
We could also say that specifying only one coordinate has no effect. I think the requirement that both attributes have to be present or absent cannot be specified in a document type definition (if someone would like to have one nevertheless). Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sander van Zoest Sent: Wednesday, October 15, 2008 6:35 PM To: Eduard Pascual Cc: whatwg@lists.whatwg.org; Ian Hickson Subject: Re: [whatwg] video tag: pixel aspect ratio On Wed, Oct 15, 2008 at 8:22 AM, Eduard Pascual [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 10:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: snip 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. The only issue I have with splitting it into separate ones, is that we need to ensure that both exist or none exist, having just X or just Y is clearly confusing and should not be allowed. -- Sander
Re: [whatwg] Video : Slow motion, fast forward effects
Requiring some audio to play is a good idea but it should be more precise. If the implementors are required to play some audio, they can do away by playing silence, or play white noise at level 0. Authors should mute the audio if they don't actually want it. Setting muted to false is hardly the right way to do it. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 15, 2008 11:08 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Video : Slow motion, fast forward effects On Tue, 14 Oct 2008, Dave Singer wrote: If muting is needed, then it should be explicitly requested. We can get this by requiring that the user agent play _some_ audio, even if severely degraded, at all speeds including negative speeds. I'm happy to require that if people are ok with it. [snip] For the reasons described above, I'd rather change this to say that the audio _must_ play _despite_ the problems, and that authors should set muted to false if they don't actually want the audio. That way we won't end up inadvertently setting authors up for relying on a particular de-facto standard behavior. '
Re: [whatwg] video tag: pixel aspect ratio
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 15, 2008 11:41 AM To: Sander van Zoest Cc: whatwg@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.
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 03:40, Ian Hickson wrote: There is no way to say loop forever right now primarily because doing so would mean complicating the syntax of the playcount attribute to be not just a number. You can work around it with script (just add onended=currentTime=0 to the video element). To be honest I'm not really convinced we need the looping feature at all. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. One benefit of getting authors to use a declarative attribute instead of a script is that a declarative attribute is easier to greasemonkey away if the user seriously doesn't like looping. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video tag : loop for ever
On 10/15/08, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 8:38 AM, João Eiras wrote: Why not just assuming that playcount=0 means loops forever ? This was exactly my thought. If playcount=5 causes the video to be played 5 times, what should the result of each of these be? playcount=1 playcount=0 playcount=-5 playcount=foobar Is there any possible usefulness whatsoever in making playcount=0 not play the video at all? If not, I don't see a good reason not to use that to mean infinite looping. Either that, or some keyword, but I don't know what it should be. infinite and forever come to mind. FWIW, the Windows media plugin APIs (when used with np-mswmp.dll or npdsplay.dll with WMP 11 installed) have a playCount param. It's specified to be a long with a minimal value of 1 and a default of 1. If you set playCount to 0, the track will loop forever. If you set it to 0 or anything out of range or invalid, it'll default to 1. I think if you have older versions of wmp installed though, playCount of 0 will cause the track to not play and a playCount of -1 will cause the track to loop forever. Of course, a loop param would still show the intent better. -- Michael
Re: [whatwg] video tag: pixel aspect ratio
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
On Wed, Oct 15, 2008 at 12:04 PM, Sander van Zoest [EMAIL PROTECTED]wrote: I do not see why we are condoning hacks on top of hacks, when it is so simple to just specify hSpace and vSpace. The entire problem is that it is not simple. It is less simple to spec, less simple to declare, less simple to parse, and less simple to test, and there is zero real-world gain in it. It is not a hack to note that the floating-point precision available here is far higher than what any display could ever manage and therefore any rounding errors occur at levels many orders of magnitude to small to have any effect at all. PK
[whatwg] input type=hidden outside phrasing content
Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson
Re: [whatwg] video tag: pixel aspect ratio
The entire problem is that it is not simple. It is less simple to spec, less simple to declare, less simple to parse, and less simple to test, and there is zero real-world gain in it. sarcasmOh! Then just drop video completly. Better, drop html5 and there will be even less trouble with specifications./sarcasm If you can come up with a argument that supports a float value, like a real world use case, other than we don't feel like editing the spec to add better, more robust functionality, then you have my support :)
Re: [whatwg] video tag: pixel aspect ratio
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. eric
Re: [whatwg] video tag javascript library for contemporary browsers
On Thu, Oct 16, 2008 at 7:35 AM, Michael A. Puls II [EMAIL PROTECTED] wrote: I *think* it has to do with the lack of hardware acceleration (even in webkit's implementation). It seems like it's all CPU driving the video element. No beefy CPU, no usable video element. Yes, this is certainly an issue. A player using hardware acceleration will outperform a player that doesn't. You won't be able to do things like overlay HTML over the plugin area, perform effects and transformations, copy the image of the video frame to canvas, etc with the plugin as a result. But, I don't know details. Just know that the videolan plugin can play theora videos with very little cpu usage, while the *experimental* video implementations use 100% cpu, display video at like 2fps and play audio like crap, unless you have a fast computer where you can't notice. Can you provide details of the specs of the computer, operating system, and the page that you see these issues so I can test and fix any issues? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag: pixel aspect ratio
Anne van Kesteren 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... Every respected container stores the ratio as X x Y. Ian, you could generalize the algorithm for link sizes and use that I suppose. I think if we make the syntax really simple like: 1. Find the first ':' 2. Parse the value before as an integer 3. Parse the value after as an integer then adding a new syntax is pretty cheap. Of course having separate attributes is even cheaper. But if the 10:11 syntax is really common then I think it might help authoring to use it. / Jonas
Re: [whatwg] video tag: pixel aspect ratio
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
Re: [whatwg] video tag : loop for ever
On 15.10.2008, at 15:07, Eric Carlson wrote: It sounds like we agree that looping *can* definitely be implemented in JavaScript, but that it can be very difficult to do so without visible/audible artifacts. Would it be sufficient to have boolean attribute for enabling and disabling looping? Looping more than once but not forever seems like a pretty rare use case. antti eric
Re: [whatwg] input type=hidden outside phrasing content
On Wed, Oct 15, 2008 at 2:39 PM, Mike Wilson [EMAIL PROTECTED] wrote: Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson For arbitrary state accessible to in-page scripting (like javascript), html5 defines the data-* family of attributes on all elements. These can have any name (as long as it starts with data-) and can hold arbitrary data. For POSTable state, the state needs to be within the form that's being submitted in any case, so being able to place the hidden state outside of the form wouldn't get you much. Can you elaborate on what you're proposing? ~TJ
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 3:52 PM, Chris Double wrote: On Thu, Oct 16, 2008 at 10:14 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: That's not the question. The question is whether the looping attributes are needed at all. It seems that there's some desire for simple looping, e.g. background sounds. That does not require the five attributes the specification currently provides though. Rather, it requires one simple boolean attribute. I agree. I think the simple boolean attribute seems clearer and more useful. Which attributes exactly are being considered for removal? I'm assuming these ones: playCount loopStart loopEnd currentLoop start and end would remain, yes? After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. A developer can easily script the same functionality as long as they don't use the default controller, so it seems to me that attributes for this aren't warranted. eric
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 4:13 PM, Silvia Pfeiffer wrote: I like the simple boolean loop attribute. I am not sure we need loopStart and loopEnd, since we have start and end to reduce the looping to a segment. I would like to avoid going down the SMIL path and creating markup that defines interactive presentation - rather it should just be a video file (or segment) that we do stuff to - not multiple segments that we need to synchronise and sequence etc. I don't think we need loopstart and loopend either, looping over a segment of a media file seems a very uncommon use case. However I also think that playing just a segment of a media file will be a common use-case, so I don't think we need start and end either. As for playCount - I am unsure if aside from a boolean loop attribute we really need to enable the page author to specify how often a video/audio should be viewed/heard. Once, possibly with autoplay, and on loop should be enough for an author. I cannot see a use case for a fixed number of views, but am happy to be told otherwise. On Oct 15, 2008, at 4:57 PM, Antti Koivisto wrote: Would it be sufficient to have boolean attribute for enabling and disabling looping? Looping more than once but not forever seems like a pretty rare use case. I agree that looping a fixed number of times, and looping over a segment of a media file are likely to be very uncommon, so I think a simple boolean is enough. eric
Re: [whatwg] video tag : loop for ever
On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson [EMAIL PROTECTED] wrote: However I also think that playing just a segment of a media file will be a common use-case, so I don't think we need start and end either. How would you emulate end via JavaScript in a reasonably accurate manner? If I have a WAV audio file and I want to start and stop between specific points? For example a transcript of the audio may provide the ability to play a particular section of the transcript. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag javascript library for contemporary browsers
On 10/15/08, Chris Double [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 7:35 AM, Michael A. Puls II [EMAIL PROTECTED] wrote: I *think* it has to do with the lack of hardware acceleration (even in webkit's implementation). It seems like it's all CPU driving the video element. No beefy CPU, no usable video element. Yes, this is certainly an issue. A player using hardware acceleration will outperform a player that doesn't. You won't be able to do things like overlay HTML over the plugin area, perform effects and transformations, copy the image of the video frame to canvas, etc with the plugin as a result. Maybe video needs something (currently. maybe not in a few years) like a wmode param where the author can suggest (and the user can ultimately override if necessary) whether it's accelerated or not. Then, a site might provide video wmode=something all by itself on a separate page as an alternative to the normal all-cpu-driven-can-be-overlayed version. Would be something neat to play with to see if it helps. Something like video.mozWmode. But, I don't know details. Just know that the videolan plugin can play theora videos with very little cpu usage, while the *experimental* video implementations use 100% cpu, display video at like 2fps and play audio like crap, unless you have a fast computer where you can't notice. Can you provide details of the specs of the computer, operating system, and the page that you see these issues so I can test and fix any issues? Sure, no problem. Example hardware that *needs* the acceleration that VideoLan (and whatever flash does) provides: PIII 700MHz + 256MB ram + ATI Rage Mobility + 5400RPM hard drive + ESS Maestro PII 350MHz + 192MB ram + AGP TNT2 + 5400RPM ATA33 hard drive + Diamond sonic impact s90 PIII 733MHz + 320MB ram + PCI GeForce2 MX400 + ata100 7200RPM har drive + Sound blaster audigy 1.3GHz P4 + 256MB PC800 Rambus + ATA100 7200RPM + AGP TNT2 (better, but not perfect) + Sound Blaster live (WinXP, 8Mb net connection, lastest drivers available) To sum it up, if you have a P4 or below, video requires something like 1.6GHz (or way higher if ads are on a page I assume) or so, while a PII 350Mhz does well with the videolan plugin. http://people.opera.com/howcome/2007/video/controls.html (bad) http://people.opera.com/howcome/2007/video/wikipedia/macaw.html (absolutely horrible) http://tinyvid.tv/show/25tuo4iijnin8 (horrible) http://tinyvid.tv/show/3m2v1wnodj23i (even worse. Stops playing if Firefox is focused) In the case of Firefox, video performance is less bad if Firefox isn't focused (or if Firefox is done fetching the file). However, even then, it's still using 100% cpu and typing in any other application causes the audio to studder big time. Even when a video is paused, Firefox uses 100% cpu. The same type of results are present in webkit and Opera's experimental video builds, so it's not only Firefox. -- Michael
Re: [whatwg] video tag javascript library for contemporary browsers
On Thu, Oct 16, 2008 at 5:03 PM, Michael A. Puls II [EMAIL PROTECTED]wrote: Maybe video needs something (currently. maybe not in a few years) like a wmode param where the author can suggest (and the user can ultimately override if necessary) whether it's accelerated or not. Then, a site might provide video wmode=something all by itself on a separate page as an alternative to the normal all-cpu-driven-can-be-overlayed version. No, that is definitely not the right way to go. We could actually detect situations where an overlay could be used, and use it automatically, if that makes sense. I'm not sure it does. Let us work on general video performance first and if we can't get close to VLC that way, then we'll see if overlay tricks are needed. We know we can improve performance quite a bit already without fundamental changes (e.g. we don't use MMX on Windows yet, and we're making some big improvements to the organization of our Ogg decoder). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
