Re: [whatwg] video element feedback - integration, fragments, and queries
At 4:04 + 9/10/07, Ian Hickson wrote: This e-mail replies to e-mails sent to both [EMAIL PROTECTED] and [EMAIL PROTECTED], as the thread in question ended up spilling over both mailing lists. WHEN REPLYING TO THIS E-MAIL PLEASE PICK ONE MAILING LIST AND REPLY TO JUST THAT ONE. PLEASE DO NOT CROSS-POST THIS THREAD TO BOTH LISTS. OK, I choosewhatWG. Hope that's right. Alternatively (thinking of XSPF playlists), what if video's src attribute pointed to an XML (or text/html-esque) file which contained these separate elements? It would be a powerful way of building a level of transparent accessibility into the system, without requiring users to download and play high-bandwidth content to find out if it has the features they need. Most video formats already have support for timed text and other features for accessible content. So effectively what the spec says today is pretty much what you describe here, except that we side-step the problem of having to invent a new format. I agree. 'An XML file which contains separate elements' of timed media resources is almost a definition of SMIL. We should allow the embedding of SMIL in video and audio tags, and allow SMIL to be the integration language that it intends to be. By allowing both selecting of sources, and the selected source to be configured, we have the expressive power we need at the HTML level, IMHO. * * * * * Much of the rest of the message discusses fragment (#) and query (?) syntax and use. They are outside the scope of HTML (except for fragment syntax for HTML documents themselves) as query syntax is owned by the server hosting the resource, and interpreted there, and fragment syntax is owned by the MIME type of the resource and its user-side implementation. Having said that, I applaud the annodex effort, and the MPEG-21 query format effort, (both spearheaded from Australia, for some reason) to establish some good norms for what could be reasonably expected of timed resources. For true streams, and some resources, server-side 'time-slicing' is fairly easy (thing.xxx?start=10s;end=20s presents a 10 second resource over the link). For many media formats, they can interpret #start=10s;end=20s, and do the byte-range request to get any table of contents (e.g. an MP4 movie atom) and then the needed bytes. -- David Singer Apple/QuickTime
Re: [whatwg] video element feedback
At 11:37 +0200 29/03/07, Charles McCathieNevile wrote:
On Thu, 29 Mar 2007 07:04:33 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Laurens Holst wrote:
So, what do you think would be needed to fix this situation.
In my dream world, IE would support dispatch by MIME type and
authors who don't
care about targeting a specific plug-in binary could just stop
using the classid
mess.
For accessibility it is actually important that the *user* decides
what software they use, rather than the author.
dispatch by MIME type is problematic for public mime types supported
by several platforms but to different degrees ('that software handles
HI-profile AVC in MP4 and this software handles HE-AAC+ in MP4')
--
David Singer
Apple/QuickTime
Re: [whatwg] video element feedback
On Tue, 20 Mar 2007, Martin Atkins wrote: I must disagree with the focus on the comparatively complicated case (video as part of a web application) vs. the more obvious case of I just want to embed a video in my web page. The spec has since been updated to include the ability for client-side UI to be shown (using the controls attribute). I maintain, therefore, that the following two things should be catered for by the spec in addition to what's already there: * By default, browsers are expected to provide at minimum a play/pause toggle button which does not interfere with the size of the movie. (This implies that it must be some kind of overlay, ensuring that the size given by the page author is the size that the video will actually play.) This is allowed, though not required. * An attribute is provided to disable the default buttons so that apps providing their own branded UI don't end up with confusing interfaces. This is now present (though the attribute has to be specified to have controls appear). On Wed, 21 Mar 2007, Christoph P�per wrote: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I fear overloading forms so far. On Tue, 20 Mar 2007, Chris Adams wrote: Actually that sounds like a splendid idea to me. although I am not sure about using the form tag. what about something like? video src='some_file.ogg' button type='rewind' / button type='playpause' / button type='stop' / button type='fastforward' / /video This seems redundant, why not just have: video src=some_file.ogg controls/ ...? On Sun, 25 Mar 2007, Elliotte Harold wrote: Why should the page be specifying the controls? Shouldn't this be up to the browser? Indeed. On Sun, 25 Mar 2007, Chris Adams wrote: there can always be browser defaults that take over, but by allowing authors the ability to override the browsers controls will allow for the flexibility of a) allowing for disabled controls (perhaps disabling fast-forward for training videos) b) scripted controls (automatically pausing at various points) c) it allows for cross-browser standardization. Indeed, scripted controls are still available. On Sun, 25 Mar 2007, Elliotte Harold wrote: Seems to me the user shoudl be in control here, not the author. If they want to fast forward, the browser lets them. The spec allows user agents to expose controls even when page-provided UI is present. I have no interest in enabling or even suggesting the use of the silly DVD type controls where you can't fast forward through the ads or the FBI notice. Hear hear. c) it allows for cross-browser standardization. This is *not* a good thing. Browsers will and should be wildly different, What works for IE will not work for a cell phone or a screen reader. The point is to tell the client that there is a video, here';s where to get it, and let the browser choose how best to display that and present the controls that make sense in its environment. To some extent this is true, but there is clearly demand for authors controlling the user experience (or at least influencing it). On Sun, 25 Mar 2007, Kornel Lesinski wrote: I find these annoyng myself as well, but I don't think specification could stop anyone from doing that. Authors use unskippable ads in Flash videos already. If video won't let them do the same, most likely they simply won't use video. At the end of the day, if the video is provided in a decodable form, the user can do what he wants, even if it isn't necessarily easy. On Mon, 26 Mar 2007, Sander Tekelenburg wrote: By leaving the user in control a UA should per definition be compliant. Allowing authors to make suggestions is good. Removing control from the user is not. (An individual UA could still choose to favour authors over users, just like a UA can ignore anything else in the spec -- users can vote with their wallet. But specifically requiring UAs to give authors control on the WWW would be dead wrong.) Agreed. On Tue, 20 Mar 2007, Robert Brodrecht wrote: I was somewhat concerned with the script-only controls. Your's is a neat approach if you wanted a custom, scriptless UI for the element and I think it may be a good idea to have scriptless UI controls. I don't know what people would say about the form as extra code on the minimalistic video. That said, if the video controls are built in via a fade-in menu like iTunes video or (if they must) via a right-click menu, I think I could live without scriptless UI controls. They'd be nice, though. It's not clear to me that scriptless controls would provide enough control to the author. On Wed, 21 Mar 2007, liorean wrote: Hmm. I'd prefer to not add an artificial method on
Re: [whatwg] video element feedback
This e-mail replies to e-mails sent to both [EMAIL PROTECTED] and [EMAIL PROTECTED], as the thread in question ended up spilling over both mailing lists. WHEN REPLYING TO THIS E-MAIL PLEASE PICK ONE MAILING LIST AND REPLY TO JUST THAT ONE. PLEASE DO NOT CROSS-POST THIS THREAD TO BOTH LISTS. Also, please adjust the subject line appropriately to talk about just the issue you are responding to. Thanks! On Tue, 20 Mar 2007, Benjamin Hawkes-Lewis wrote: Obviously a preferable solution would be for everyone to create accessible content using open technologies in the first place, and we must do everything we can to encourage and enable that. But falling short of such revolutions, can anyone suggest an alternative way of limiting the disillusion caused by inaccessible downloads? In the case of multimedia content, the best place for content whose purpose is ensuring universal use is within the multimedia content itself, so that when the data is moved (e.g. when the user saves a video file to disk) the content remains universally useful (accessible). This also allows us to leverage industry expertise without reinventing any wheels ourselves. What would happen if the video element actually contained audio elements for the audio, audiodescription elements for the audio descriptions, caption elements for the captions, and subtitle elements for the subtitles? Would it be technologically possible for HTML elements to act as containers in that way? The result would be that using video in an HTML context required far more work for accessibility purposes than using the same video in non-HTML contexts (e.g. on an iPod). This would be bad for the end-user. Alternatively (thinking of XSPF playlists), what if video's src attribute pointed to an XML (or text/html-esque) file which contained these separate elements? It would be a powerful way of building a level of transparent accessibility into the system, without requiring users to download and play high-bandwidth content to find out if it has the features they need. Most video formats already have support for timed text and other features for accessible content. So effectively what the spec says today is pretty much what you describe here, except that we side-step the problem of having to invent a new format. On Tue, 20 Mar 2007, Benjamin Hawkes-Lewis wrote: I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I'll discuss img fallback as part of img feedback. On Wed, 21 Mar 2007, Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. image image/* video video/* application application/* audio audio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. That's pretty much where we are today with HTML5, except for the vague category application/*. On Wed, 21 Mar 2007, Martin Atkins wrote: What do you imagine application being used for? The application type category is pretty-much just miscellaneous. Indeed. On Tue, 20 Mar 2007, Robert Brodrecht wrote: Simon Pieters said: Oh. I thought video fallback would work pretty much like object fallback, but I see that's not the case. When I think about it it makes sense; video is pretty much like iframe, it never falls back in UAs that support it. Oh, damn it. I thought it'd work like object, too. I'm not sure I like the only-fallback-if-no-support idea. I'm getting the feeling that there won't be one common video format among the browsers. I think not having fallback to nested video elements to get at other formats would ultimately be a bad thing. We already have fallback for multiple formats through the use of multiple source elements. When PNG support sucked in IE6, I just didn't use alpha PNGs and opted for some other format. If there is no shared format, the only ways to support multiple video formats for multiple browsers would be: 1. Just have two video elements on screen (bad). 2. Swap the src with JavaScript (won't work if JS is off). 3. Delegate content on the server based on http-accept [?] (best of the three, but not very fun). 4. Maybe conditional comments if IE is the oddball (we'll see, but I don't like this option much either). 5. The source element. :-) Any thoughts on this or
Re: [whatwg] video element feedback
On 3/29/07, Laurens Holst [EMAIL PROTECTED] wrote: The URL parameter (as also seen in e.g. Quicktime and Flash) is imho a dirty hack to work around implementations not providing plugins with a streaming file reader object. At least, that is the only explanation I can come up with. There is a DATA attribute on the object, and that should be sufficient. There are a few problems with data for OBJECT and src for EMBED. 1. The plugin doesn't always support those params for a file resource and browsers have to hack in support on a per-plugin basis to make src / data work (if they choose to). The java plug-in, tcl plugin, wmp plugin, neptune plugin, videolan plugin, tcl plugin and the Real plugin all don't support a data param by theirselves. 2. They cause the browser to automatically download the resource. A plugin should support 3 different params for specifying a source file. 'data' to cause the browser to automatically download the resource via OBJECT: object data=file.ext/object 'src' to cause the browser to automatically download the resource via EMBED: embed src=file.ext 'another_param' to prevent the browser from automatically downloading the resource if a autoplay (for example) param is set to false: object type=type param name=another_param value=file.ext param name=autoplay value=false /object object.play() starts the downloading. embed type=type another_param=file.ext autoplay=false embed.play() starts the downloading (The effect of another_param could be simulated by just writing out the whole object with JS when ready, but ...) Anyway, with a VIDEO element, that stuff wouldn't be a problem as it can be dealt with specifically as opposed to OBJECT where you have to worry about all the existing behaviors. -- burnout426
Re: [whatwg] video element feedback
Henri Sivonen wrote: I've asked about this before but I still don't understand it: Why doesn't Gecko completely ignore the classid? Apart from the fact that this would technically be a spec violation, it actually breaks some pages (because the ActiveX and NPAPI versions of some plug-ins expose different APIs), last I checked. (IIRC, Opera on Mac and Mac IE 5 ignore the classid and dispatch on MIME.) Which fixes pages that don't use a fallback embed, but breaks some others. It's a tradeoff of which exact pages you want to work and how many of them there are... -Boris
Re: [whatwg] video element feedback
Laurens Holst wrote: As said, I tried a few things with embedding an image, video and SVG with the object tag: ... First of all, one annoying thing is that you have to provide sizes, otherwise the object will not be visible. At least in Mozilla, this is false for images. It should become false for SVG by Gecko 1.9, hopefully. The issue of sizing of object that's rendered via a plug-in remains in Gecko, due to limitations in the plug-in API. But that's not a fundamental issue with object itself. In all browsers the object is an inline replaced element. Unless styled to be a block, in which case it's a block-level replaced element. ;) Also, in reality everybody adds a two big attributes for Internet Explorer’s plugin finder, and an embed tag inside the object for Mozilla’s plugin finder (which still only works with embed and not object). Sorry, that's false. Plug-ins work fine with object in Mozilla, _unless_ you use a classid attribute with a value that is an ActiveX component ID. If you do that, Mozilla will fall back, since it doesn't support ActiveX plug-ins. Now the problem is that the _only_ way IE supports plug-ins via object is if they're ActiveX and the right component ID is specified. It doesn't support dispatch based on MIME type. So you get the nesting you mentioned. Oh, and IE does something broken if you nest object inside object; otherwise authors could use object inside object instead of embed inside object as they do now. However, if the image specifies dimensions, in Firefox they override the object dimensions and you get scroll bars on the object This is a bug, hopefully to be fixed for Gecko 1.9. -Boris
Re: [whatwg] video element feedback
At 22:17 + UTC, on 2007-03-25, Kornel Lesinski wrote: On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold [EMAIL PROTECTED] wrote: [...]allowing authors the ability to override the browsers controls [...] Seems to me the user shoudl be in control here [...] [...] Authors use unskippable ads in Flash videos already. If video won't let them do the same, most likely they simply won't use video. Lack of control hasn't stopped authors from using CSS, nor has it made them switch to PDF. By leaving the user in control a UA should per definition be compliant. Allowing authors to make suggestions is good. Removing control from the user is not. (An individual UA could still choose to favour authors over users, just like a UA can ignore anything else in the spec -- users can vote with their wallet. But specifically requiring UAs to give authors control on the WWW would be dead wrong.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
Chris Adams wrote: Actually that sounds like a splendid idea to me. although I am not sure about using the form tag. what about something like? video src='some_file.ogg' button type='rewind' / button type='playpause' / button type='stop' / button type='fastforward' / /video Why should the page be specifying the controls? Shouldn't this be up to the browser? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element feedback
The browser could control this, yes; however I believe that the browser should really be as transparent as possible as to not be a limiting factor in development. there can always be browser defaults that take over, but by allowing authors the ability to override the browsers controls will allow for the flexibility of a) allowing for disabled controls (perhaps disabling fast-forward for training videos) b) scripted controls (automatically pausing at various points ) c) it allows for cross-browser standardization. On 3/25/07, Elliotte Harold [EMAIL PROTECTED] wrote: Chris Adams wrote: Actually that sounds like a splendid idea to me. although I am not sure about using the form tag. what about something like? video src='some_file.ogg' button type='rewind' / button type='playpause' / button type='stop' / button type='fastforward' / /video Why should the page be specifying the controls? Shouldn't this be up to the browser? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ -- [EMAIL PROTECTED] http://www.tuesdaybegins.com
Re: [whatwg] video element feedback
Chris Adams wrote: there can always be browser defaults that take over, but by allowing authors the ability to override the browsers controls will allow for the flexibility of a) allowing for disabled controls (perhaps disabling fast-forward for training videos) Seems to me the user shoudl be in control here, not the author. If they want to fast forward, the browser lets them. I have no interest in enabling or even suggesting the use of the silly DVD type controls where you can't fast forward through the ads or the FBI notice. b) scripted controls (automatically pausing at various points ) Maybe, but is it really the control we want to script or the video itself? c) it allows for cross-browser standardization. This is *not* a good thing. Browsers will and should be wildly different, What works for IE will not work for a cell phone or a screen reader. The point is to tell the client that there is a video, here';s where to get it, and let the browser choose how best to display that and present the controls that make sense in its environment. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element feedback
On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold [EMAIL PROTECTED] wrote: there can always be browser defaults that take over, but by allowing authors the ability to override the browsers controls will allow for the flexibility of a) allowing for disabled controls (perhaps disabling fast-forward for training videos) Seems to me the user shoudl be in control here, not the author. If they want to fast forward, the browser lets them. I have no interest in enabling or even suggesting the use of the silly DVD type controls where you can't fast forward through the ads or the FBI notice. I find these annoyng myself as well, but I don't think specification could stop anyone from doing that. Authors use unskippable ads in Flash videos already. If video won't let them do the same, most likely they simply won't use video. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Fri, Mar 23, 2007 at 04:33:39PM -0700, Eric Carlson wrote: Yes, the UA needs the offset/chunking table in order to calculate a file offset for a time, but this is efficient in the case of container formats in which the table is stored together with other information that's needed to play the file. This is not the case for all container formats, of course. Just to be clear, this isn't strictly true; one can still perform bisection seek over HTTP with the byte Range header. As has been mentioned, VLC implements this. Alsaplayer is another example. It does work. It's of course less efficient than when one has a seek table, but not excessively so. Tangentially, I at some point looked at implementing 'seconds' as a Range header unit in Apache. (The HTTP Range header allows arbitrary, units, bytes is just the only one that is defined by the spec). The idea was to have the server do the seeking and return a valid file starting at the requested time offset, or list of intervals. Then a client could do very naive seeking and just play what it got. In the end I abandonded it over worry with cache interaction. If you request a sequence of intervals you don't in general get the same byte stream as if you request the whole file, because the server is re-packaging the data for each request. With Ogg this sort of works, because concatenated streams are still in spec, so the decoded result is the same, but it doesn't work for all containers. The annodex query path seemed a better choice. -r
Re: [whatwg] video element feedback
On Sat, Mar 24, 2007 at 01:57:45AM -0700, Kevin Marks wrote: How does one seek a Vorbis file with video in and recover framing? It looks like you skip to an arbitrary point and scan for 'OggS' then do a 64kB CRC to make sure this isn't a fluke. Then you have some packets that correspond to some part of a frame of video or audio. You recover a timestamp, and thus you can pick another random point and do a binary chop until you hit the timestamp before the one you wanted. Then you need to read pages until the timestamp changes and you have resynced that stream. Any other interleaved streams are presumably being resync'd in parallel so you can then get back to the read and skip framing. Try doing that from a CD-ROM. Do let me know if that has since been fixed. Nope. That's still the algorithm. Also add that for a keyframe-based codec you need to (conceptually) seek again, after you've found the desired start point, to feed the decoder from the nearest previous restart point. In practice, not everyone tries for sample-accurate seeking. I gather the situation is similar with DVD playback. Streamability (in the unix pipe sense of an unseekable file stream) was a design goal for Ogg. This seek algorithm is a consequence. Decoders must handle seeking without an index table, so we have regarded the use of one, whether cached in the file or not, as an implementation detail. FWIW, -r
Re: [whatwg] video element feedback
Geoffrey Sneddon schrieb: That sort of info is held within the container, so everything within Ogg (so both Theora and Dirac) will suffer from it. H.264 being part of the MPEG-4 standard follows what Kevin Marks said: On 24 Mar 2007, at 08:57, Kevin Marks wrote: 2. define a chunk/offset table that maps media to time, and look this up ahead of any seeking. (this is the QT approach, and that of MPEG4 Well, with Ogg you can just fetch a bit of the start (seems that's needed for MPEG, too - I just killed a few bytes from the beginning of a .mp4 files and it won't play) and get an educated guess about bitrate etc. to directly jump to a position in the file (you there get a precise timestamp). If you ended up jumping too far away from the destination you can repeat once or twice and you're close enough. That has been done before, works like a charm. http://stream.fluendo.com/demos.php?stream=ondemand (that's a Java Ogg Theora streaming applet) I can see the value of having a direct seek table, but omitting that has it's nice sides, too: You can just concatenate two Ogg files and you directly have a valid Ogg stream again. That's used extensively with playlist streaming (e.g. using the Icecast server) and is pretty popular. In worst case it should be easily possible to define a simple format for an external jumping table that can be fetched by the user agent (video.ogg.idx or whatever) or even embed that in another logical stream at the beginning of an Ogg file.
Re: [whatwg] video element feedback
In this case, there is a big difference between streamed data, which can be played from various positions, and non-streamed data which requires a complete download, or at least the start of the file. Perhaps there should be some reflection of this in the tag? On 23 Mar 2007, at 03:15, liorean wrote: On 23/03/07, Sander Tekelenburg [EMAIL PROTECTED] wrote: While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Well, it would be nice to not have to download an hour long lecture to see the 30 second interval of interest starting at at 47:26... However, as I understand the Ogg Theora format, it contains essential data for decoding in the start of the file, so unless the server has some format specific knowledge and handling the client must either have already gotten that information somehow, or must request the entire file. I have no idea whether the other codecs I've heard discussed (Dirac and H.264) have a similar issue or not. -- David liorean Andersson
Re: [whatwg] video element feedback
On 3/23/07, Sander Tekelenburg [EMAIL PROTECTED] wrote: I don't know of a video container format that allows named anchors to be specified, though. QuickTime let's authors define points in a .mov container as chapters, which, in the cotext of the Web, could function as named anchors I'd think. I believe this is in fact already possible today with QT authored movies. The Annodex file format (http://annodex.net/TR/draft-pfeiffer-annodex-02.txt), in conjunction with the CMML XML format (http://annodex.net/TR/draft-pfeiffer-cmml-03.txt) is providing a named anchors functionality for Ogg Theora files. Regards, Silvia.
Re: [whatwg] video element feedback
On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
Let's say there's http://example.com/example.html page which contains
embedded video:
...video src=video.ogg...
I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from 12:35.
That would be hard, because how would you identify which embedded
video or audio file on the example.html page this temporal offset is
referring to?
I think it might work like this: when play() is called on a video
element, and it hasn't been called on any other video element in this
document yet, read time from location.hash and call seek().
This would work with dynamically created video elements and would
probably be the best choice even if there are multiple video elements in
the document.
If such altered behavior of play() is not unacceptable, then that might
work:
http://example.com/[EMAIL PROTECTED]:35
Where myvideo part is interpreted as ID of element in the document (and
if there's no such element - assume document.body).
If the element is a video, then seek() that video.
If it isn't, then seek first video descendant of that element (something
like: (document.getElementById(myvideo) ||
document.body).getElementsByTagName('video')[0].seek(12*6+35000))).
My rationale:
* it doesn't require any changes to the document, so user can control
starting position in any document, even if author didn't think of such
possibility
* It's part of document's URL, not URL of the video file, so user doesn't
have to extract video file URL from the document and can still use the
page (which provides controls for the video).
* it can be implemented in JavaScript with current video API (also in
User JavaScript, but I think for interoperability it's important to be
part of the spec).
* it's orthogonal to server-side support for seeking
Also, it could be interpreted by the UA only, since
everything after # will not be transferred to the server.
Yes, that's intentional. It allows user to modify *any* URL without risk
of breaking it (some servers/applications may not like extra query
string). I think use of hash for this is appropriate - just like UA
scrolls HTML to given element, UA would scroll the video - it's just a
change of axis from Y to time :)
--
regards, Kornel Lesiński
Re: [whatwg] video element feedback
The difference between streaming and non-streaming is artificial and not technically necessary - except for life content, where you cannot jump into the future. Silvia. On 3/23/07, Gareth Hay [EMAIL PROTECTED] wrote: In this case, there is a big difference between streamed data, which can be played from various positions, and non-streamed data which requires a complete download, or at least the start of the file. Perhaps there should be some reflection of this in the tag? On 23 Mar 2007, at 03:15, liorean wrote: On 23/03/07, Sander Tekelenburg [EMAIL PROTECTED] wrote: While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Well, it would be nice to not have to download an hour long lecture to see the 30 second interval of interest starting at at 47:26... However, as I understand the Ogg Theora format, it contains essential data for decoding in the start of the file, so unless the server has some format specific knowledge and handling the client must either have already gotten that information somehow, or must request the entire file. I have no idea whether the other codecs I've heard discussed (Dirac and H.264) have a similar issue or not. -- David liorean Andersson
Re: [whatwg] video element feedback
How about the following idea:
Example.html contains:
video id=myvideo_1 src=video.ogg
to provide the full video
video id=myvideo_2 src=video.ogg?t=0:12:35
to provide the video from offset 12:35
video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40
to provide the video segment between offset 12:35 and 20:40
video id=myvideo_4 src=video.ogg?id=section4
to provide the video from named offset section4
These provide the Web page author with the power to do offsets.
And example URLs relating to the webpage:
http://example.com/example.html#myvideo_1t=0:12:35
to provide the Web page with the first video playing from offset 12:35,
offset action provided by the UA (i.e. video gets fully downloaded)
http://example.com/example.html#myvideo_1?t=0:12:35/0:20:40
to provide the Web page with the first video playing section 12:35-20:40,
UA resolves this to create a query for video.ogg?t=0:12:35/0:20:40,
offset action provided by the server
These provide the user with control over the start points of the
videos on the Webpage.
These two URIs with fragment offsets would currently not work in a Web
browser. However the set of URIs that I provided inside the video
tag above already work through the Annodex framework for ogg files.
Regards,
Silvia.
On 3/24/07, Kornel Lesinski [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
Let's say there's http://example.com/example.html page which contains
embedded video:
...video src=video.ogg...
I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from 12:35.
That would be hard, because how would you identify which embedded
video or audio file on the example.html page this temporal offset is
referring to?
I think it might work like this: when play() is called on a video
element, and it hasn't been called on any other video element in this
document yet, read time from location.hash and call seek().
This would work with dynamically created video elements and would
probably be the best choice even if there are multiple video elements in
the document.
If such altered behavior of play() is not unacceptable, then that might
work:
http://example.com/[EMAIL PROTECTED]:35
Where myvideo part is interpreted as ID of element in the document (and
if there's no such element - assume document.body).
If the element is a video, then seek() that video.
If it isn't, then seek first video descendant of that element (something
like: (document.getElementById(myvideo) ||
document.body).getElementsByTagName('video')[0].seek(12*6+35000))).
My rationale:
* it doesn't require any changes to the document, so user can control
starting position in any document, even if author didn't think of such
possibility
* It's part of document's URL, not URL of the video file, so user doesn't
have to extract video file URL from the document and can still use the
page (which provides controls for the video).
* it can be implemented in JavaScript with current video API (also in
User JavaScript, but I think for interoperability it's important to be
part of the spec).
* it's orthogonal to server-side support for seeking
Also, it could be interpreted by the UA only, since
everything after # will not be transferred to the server.
Yes, that's intentional. It allows user to modify *any* URL without risk
of breaking it (some servers/applications may not like extra query
string). I think use of hash for this is appropriate - just like UA
scrolls HTML to given element, UA would scroll the video - it's just a
change of axis from Y to time :)
--
regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Mar 23, 2007, at 1:27 PM, Silvia Pfeiffer wrote: On 3/23/07, Nicholas Shanks [EMAIL PROTECTED] wrote: Can't we have all of: 1) A way for authors to match up timecodes with fragment identifiers in the fallback content 2) A way for UAs to skip to that time code if a fragment identifier is requested and it's contained within fallback the UA isn't displaying 3) And a way for users to link to timecodes that aren't marked up at all. I completely agree. Since we have to stick with the way that URIs are defined and the way that HTTP works, we can realise these in the following ways: 1. Either the fallback content has a means in which fragment identifiers are encoded into the video (as e.g. CMML/Annodex provides for Ogg Theora, or chapter markers in QuickTime), or the UA can request this information from the server, where it may be stored in a DB or in a XML file (such as CMML) and can be returned to the UA. 2. Again, there are two alternatives that are possible - either using the fragment (#) for identifiers or using queries (?) to provide the offset (or named anchor, or time section) in the URI. When using fragments, the UA first has to download the full file and then undertake the offset for playback itself. When using queries, a server module can do the offset and thus avoid potentially large amounts of binary data to be downloaded to the UA which the users may never want to look at. The use of queries will be absolutely necessary for mobile phones for example, where you pay through the nose for bandwidth use. 3. covered in my reply to 2. I know of only one format that provides for all this functionality at the moment and that is Ogg Theora with the Annodex and CMML extensions. In particular the part where a server component is required to provide a valid file from a time offset (and - don't get me wrong - a anchor is nothing else but a named time offset) is unique. Annodex has a apache module called mod_annodex to provide this functionality. And it has python, php and perl bindings to provide this functionality through typical Web scripting languages. Even without a server component, #2 and #3 do not require the UA to download the full file if it can use byte range requests for random access and the file format has time to offset tables (eg. the 'moov' resource in a QuickTime movie or ISO-based file, the 'movi' LIST chunk in an AVI file, etc). eric
Re: [whatwg] video element feedback
On Fri, 23 Mar 2007 20:57:24 -, Silvia Pfeiffer [EMAIL PROTECTED] wrote: video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40 to provide the video segment between offset 12:35 and 20:40 video id=myvideo_4 src=video.ogg?id=section4 to provide the video from named offset section4 These provide the Web page author with the power to do offsets. How would that be used? Do you expect UA to change query string arguments when video.seek() is invoked? If src=video.ogg?t=0:12:35 is specified, how would user see the beginning of the video? http://example.com/example.html#myvideo_1?t=0:12:35/0:20:40 to provide the Web page with the first video playing section 12:35-20:40, It's fine although ofcourse I'm biased towards simpler and more compact syntax I've suggested :) These two URIs with fragment offsets would currently not work in a Web browser. However the set of URIs that I provided inside the video tag above already work through the Annodex framework for ogg files. What if server does not support it or site uses another video format? -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Mar 23, 2007, at 3:49 PM, Silvia Pfeiffer wrote: Hi Eric, On 3/24/07, Eric Carlson [EMAIL PROTECTED] wrote: Even without a server component, #2 and #3 do not require the UA to download the full file if it can use byte range requests for random access and the file format has time to offset tables (eg. the 'moov' resource in a QuickTime movie or ISO-based file, the 'movi' LIST chunk in an AVI file, etc). I agree partially. You're right - it doesn't need to download everything. But there are two catches: 1) The UA doesn't know what byterange a timecode or timerange maps to. So, it has to request this information from the server, who has access to the file. For QuickTime movies, the UA would need to request the offset table from the server and for AVI it would need to request the chunking information. 2) Just streaming from an offset of a video file often breaks the file format. For nearly all video formats, there are headers at the beginning of a video file which determine how to decode the video file. Lacking this information, the video files cannot be decoded. Therefore, a simple byterange request of a subpart of the video only results in undecodable content. The server actually has to be more intelligent and provide a re-assembled correct video file if it is to stream from an offset. Yes, the UA needs the offset/chunking table in order to calculate a file offset for a time, but this is efficient in the case of container formats in which the table is stored together with other information that's needed to play the file. This is not the case for all container formats, of course. The UA would first use byte range requests to download the header. If the information is stored somewhere other than the beginning of the file, it may take several byterange requests to find it, but this is not much less efficient with ISO-derived or RIFF type formats. Once is has the headers, it will able to calculate the offset for any time in the file and it can request and play the media for *any* time range in the file. This scheme has the added benefit of not requiring the header to be downloaded again if the user requests another time range in the same file. eric
Re: [whatwg] video element feedback
Sorry to jump into this conversation at such a late point, but I only just joined the mailing list. About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. This makes it impossible to use them for play from this offset since obviously the offsetting should be done by the server and avoid downloading the bunch of data that comes before the offset point. The only solution was to use the query ? identifier for defining offsets. This has been done and specified in http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.txt, though we never took it through full standardisation. An implementation of that feature can be seen at http://media.annodex.net/cmmlwiki/ where the videos are marked-up with sections and the sections are referred to through URIs such as http://media.annodex.net/cmmlwiki/SFD2005-Trailer?t=0:00:01.962. Another example is used by the metavid guys: e.g. http://metavid.ucsc.edu/overlay/video_player/webview?stream_name=house_proceeding_12-07-06t=0:14:02/0:14:37 which provides a section out of the video. Both of the above given examples use Ogg Theora as the video, though the files are being served through a server plugin (in both cases it is mod_annodex) that provides for the offset functionality without breaking the file format. Regards, Silvia. On 3/23/07, Nicholas Shanks [EMAIL PROTECTED] wrote: On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote: At 18:31 + UTC, on 2007-03-21, Nicholas Shanks wrote: On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. [...] Well besides the fact that fragment ids cannot start with a number We're not talking about IDs, just fragment identifiers. My point was that with video, you could use fragment identifiers *without* the need for the author to provide IDs. I see your point, but i would like for fragment identifiers within a video to be equal to fragment IDs in text fallback content. Therefore they have to be constrained to the same limits. the client doing the request should be smart enough to know to escape the colon Wikipedia section IDs have lots of escaping, but it's all done by the wiki server, not the UA. I don't know if this is because UAs can't be trusted to get it right or not. - Nicholas.
Re: [whatwg] video element feedback
On 22 Mar 2007, at 20:53, Silvia Pfeiffer wrote: Sorry to jump into this conversation at such a late point, but I only just joined the mailing list. About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. There's a good discussion about that here: http://1997.webhistory.org/www.lists/www-talk.1993q2/0551.html (read through the rest of the thread for more info) This makes it impossible to use them for play from this offset since obviously the offsetting should be done by the server and avoid downloading the bunch of data that comes before the offset point. But it doesn't stop the UA from taking cues from the markup (such as my gegenschein example from yesterday) and generating a query such as ?start=17:33. They don't have to request the exact value of the src attribute. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On Thu, 22 Mar 2007 20:53:48 -, Silvia Pfeiffer [EMAIL PROTECTED] wrote: About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. I think we had in mind (at least I did) URL of the page that contains the video, not the URL of the video file itself. Because of this indirection it's completly up to UA to read fragment identifier and translate it into appropriate HTTP request for the video file (which could use Range header that's more proxy-friendly than query string). Let's say there's http://example.com/example.html page which contains embedded video: ...video src=video.ogg... I'd like to be able to construct URL like: http://example.com/[EMAIL PROTECTED]:35 that would cause UA to start playing the embedded video.ogg from 12:35. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
Kornel Lesinski: http://example.com/[EMAIL PROTECTED]:35 that would cause UA to start playing the embedded video.ogg from 12:35. That would limit documents to one |video| (or |audio|) element.
Re: [whatwg] video element feedback
[My apologies for initially responding off-list. That was unintentional. I'm posting an updated version.] At 20:04 + UTC, on 2007-03-21, Martin Atkins wrote: Sander Tekelenburg wrote: [...] URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. [...] When using this with HTML we don't link to #line50, or #paragraph3, or #section9, we link to an anchor in the document itself. We do this to avoid tying the link to a specific representation of the resource, and to allow the document to change to a certain extent without breaking the links. FWIW, RFC 3986, under 3.5, seems to me to specifically mentions this [...] Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively. Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification. It seems to me that what I'm proposing is very much in the spirit of this. I don't know of a video container format that allows named anchors to be specified, though. QuickTime let's authors define points in a .mov container as chapters, which, in the cotext of the Web, could function as named anchors I'd think. I believe this is in fact already possible today with QT authored movies. But I didn't get the impression that this authoring aspect matters. In fact, the essence of my suggestion is exactly that this would be an opportunity to allow for fragment identifiers without any need for authors to do any extra work. If the spec requires UAs to be able to return the movie's duration and current position, etc. (which I got the impression is the intention of both Opera and Apple's proposals), to for instance allow, through javascript, playing from a certain point, then I don't see why it would not be possible to trigger the same event through a fragment identifier. I don't see how this would require anything from the author. The interpretation of fragment identifiers on video is a bit out of scope for an HTML specification regardless of whether it's specified as time or a bookmark. If someone invents a video format that allows named anchors, they can write in their own specification how fragment identifiers are to be interpreted. It's none of HTML's business. Quoting that last bit of RFC 3986, section 3.5 again: [...] Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification. The discussion here of a video element, for native playback of even a specific codec, seems to come quite close to that. (That aside, a lot of what is being defined on this list is javascript, not HTML. The popular term HTML5 is misguiding. The offical name Web Apps 1.0 is more descriptive.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 19:46 + UTC, on 2007-03-22, Nicholas Shanks wrote: On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote: [...] We're not talking about IDs, just fragment identifiers. My point was that with video, you could use fragment identifiers *without* the need for the author to provide IDs. I see your point, but i would like for fragment identifiers within a video to be equal to fragment IDs in text fallback content. I completely agree that that would be ideal. But I consider it an argument to try to find a solution for that, or if that's not possible, live with that. I don't see it as an argument to give up on such a useful feature for users who do not need/choose to fetch non-video fallback content. (Note that a mechanism to allow authors to define anchors in videos is not a solution, because it's then still the author who is in control. What I'm suggesting is about giving the user control.) [...] the client doing the request should be smart enough to know to escape the colon Wikipedia section IDs have lots of escaping, but it's all done by the wiki server, not the UA. I don't know if this is because UAs can't be trusted to get it right or not. I'm getting the impression from RFC 3986 that it is up to the app that sends the request to ensure the URL is properly percent-encode (meaning special characters are escaped). For instance Section 2.2: [...] URI producing applications should percent-encode data octets that correspond to characters in the reserved set [...]. And section 2.4: [...] Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form [...] -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
On 23 Mar 2007, at 01:30, Sander Tekelenburg wrote: (Note that a mechanism to allow authors to define anchors in videos is not a solution, because it's then still the author who is in control. What I'm suggesting is about giving the user control.) Can't we have all of: 1) A way for authors to match up timecodes with fragment identifiers in the fallback content 2) A way for UAs to skip to that time code if a fragment identifier is requested and it's contained within fallback the UA isn't displaying 3) And a way for users to link to timecodes that aren't marked up at all. the client doing the request should be smart enough to know to escape the colon Wikipedia section IDs have lots of escaping, but it's all done by the wiki server, not the UA. I don't know if this is because UAs can't be trusted to get it right or not. I'm getting the impression from RFC 3986 that it is up to the app... RFCs are one thing, implementations are another. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
At 07:53 +1100 UTC, on 2007-03-23, Silvia Pfeiffer wrote: [...] About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. Right. See RFC 3986, section 3.5: [...] the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. [...] This makes it impossible to use them for play from this offset since obviously the offsetting should be done by the server While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Sure, with 'big' files and 'slow' connections, that would mean having to wait longer. But big and slow are relative values. And when you want to watch something only from point x on, even if that means having to wait, that's still much better than having to first watch all of the video before that point. At least while you're waiting, you can still do something useful ;) [...] The only solution was to use the query ? identifier for defining offsets. Unless I'm misunderstanding something, that makes things server-dependant. I recognise that the benefit of this approach is being able to only fetch the data you want, but it doesn't offer the user the benefit of easily being able to refer to a specific point in any movie (in a video element). -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
On 23/03/07, Sander Tekelenburg [EMAIL PROTECTED] wrote: While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Well, it would be nice to not have to download an hour long lecture to see the 30 second interval of interest starting at at 47:26... However, as I understand the Ogg Theora format, it contains essential data for decoding in the start of the file, so unless the server has some format specific knowledge and handling the client must either have already gotten that information somehow, or must request the entire file. I have no idea whether the other codecs I've heard discussed (Dirac and H.264) have a similar issue or not. -- David liorean Andersson
Re: [whatwg] video element feedback
Also sprach Laurens Holst: object is *very badly* implemented. It has been a decade since object was first created and browsers STILL don't do it right in all cases (or even in most cases, frankly). Adding more complexity to such a disaster zone is bad design. If the existing problems with object are so severe that it can
Re: [whatwg] video element feedback
This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. image image/* video video/* application application/* audio audio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. Gaz On 20 Mar 2007, at 23:42, Nicholas Shanks wrote: On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote: Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: • As video would cater for video/* MIME types, image would cater for image/* • The alt and longdesc attributes can be part of the fallback content, allowing markup. • You don't have to provide a type attribute and match on: object [type^=image/] • and more… - Nicholas.
Re: [whatwg] video element feedback
On 3/20/07, Christoph Päper [EMAIL PROTECTED] wrote: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I thought about this myself. My thought looked like this: form action=video: target=video element id input type=button name=play /form However, my thought would abuse a possible video: protocol and make input or button or forms in general even more complicated. I don't think implementors would be interested in hacking up forms this way, but I could be wrong. -- burnout426
Re: [whatwg] video element feedback
Ian Hickson [EMAIL PROTECTED] wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. When encountering an object element IE7 seems to block all embedding by default and it issues security warnings [1] . Afaics that virtually drives the final nail in the object coffin [2]. That makes tutorials that haven't taken this into account outdated, and since UAs are not going to drop their existing support for the element I don't see why this should be an issue with regard to deprecation. [1] IE7 Information bar displayed when it encounters an object element (embedding a PNG image): To help protect your security, Internet Explorer has restricted this webpage from running scripts or ActiveX controls that could access your computer. Click here for more options. A further Security Warning dialog is produced if a user were to consider allowing it: ! Allowing active content such as script and ActiveX controls can be useful, but active content might also harm your computer. Are you sure you want to let this file run active content? Yes / No [2] Virtually since there are some cases where by using conditional comments authors can still use the advantages of the object element whilst feeding IE an img element instead. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element feedback
At 09:25 + UTC, on 2007-03-20, Ian Hickson wrote: [...] ON NATIVE UI: [...] I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. I thought the idea of the Web was that the user is always in control (because the author cannot know the user's browsing environment). Why would authors ever have to be in control? [...] If JS is turned off, applications won't work. :-) Just like when you turn JS off and try to use Google Calendar, or turn off Flash and try to use YouTube. If video is to be a first-class Netizen, it'd better not be javascript-dependant. Currently Flash and QT plug-ins handle embedded video just fine without JS (unless when misguided authors purposely made it javascript-dependant). If video is specced to be javascript-dependant, you make it too difficult for both users and authors. I'd have to vote against that. Simply video src=URL should suffice. (I'm all for allowing more sophisicated things through javascript, just not for *dependancy*.) Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Without this/currently, video consumption just costs too much time. It's usually much more practical to deal with text, because users can imediately go to the part they're interested in. With video (and audio) you are forced to watch the whole thing to find out if there is anything interesting. It seems to me that's one of the main reasons video is very much a second-class Netizen today. Note that such an implicit anchor mechanism would in a sense make video even better than text, because this wouldn't require authors to bother to provide anchors. The less work for authors, the better the chance at first-class Netizenry. (Btw, the same mechanism could be used to, through cookies, or even through a cache-like local mechanism (and thus again not author-dependant), allow UAs to provide a bookmarkish function for a start playing from where I left last time feature.) [...] I agree that video needs a standard UI (in v2, at least). It needs it right from the start, in v1.0. Without it, it would be like a browser without its own back button, relying on authors to provide such functionality. IMO this is no different than CSS being icing on the cake. It's nice to allow authors to suggest UI-styling and even add functionaility, but it's a mistake to make basic functinality (start, stop, pause, (fast)forward, etc.) author-dependant. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 23:02 +0100 UTC, on 2007-03-20, Håkon Wium Lie wrote: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? Agreed. On the right-click menu or somewhere where it doesn't take up space? Implementation should be left up to the browser author, but it would probably be useful if the spec lists some suggestions. Both to help browser authors understand what the spec means, and to help content authors realise that how their favourite browser behaves may not be how some other browser behaves. I agree it would probably be important to state that the UI must not take up extra space. (An author-provided UI however should be allowed to take up author-defined space.) Btw, please let's not have the spec say right-click, when contextual menu is meant. How to bring up a contextual menu is entirely environment-dependant: my mouse has no right button at all, but I use contextual menus all the time. Also, my preferred OS offers a native Action button/menu (typically in a toolbar) to contextually provide access to actions. Another possible UI would be straight from the keyboard, as is already the case with the QT plug-in for example. The mouse hover-based UI of QT and VLC that has been mentioned is probably another good example (although requiring users to hover over the video will mean many won't ever discover this functonality, just like the contextual menu -- I imagine this is what Apple's Action button aims to solve). -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote: Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Well besides the fact that fragment ids cannot start with a number nor contain a colon, you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: pYou a href=#gegenscheinsee the gegenschein/a if you really squint./p video src=video-with-visual-splash.mpeg fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:13 / audio src=audio-with-spoken-splash.aiff fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:24 / !-- transcript fallback -- section id=splashpProduced by Foo Corporation/p/section … section id=gegenschein … /audio /video - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. imageimage/* videovideo/* application application/* audioaudio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. What do you imagine application being used for? The application type category is pretty-much just miscellaneous.
Re: [whatwg] video element feedback
On Wed, 21 Mar 2007 18:31:29 -, Nicholas Shanks [EMAIL PROTECTED] wrote: Well besides the fact that fragment ids cannot start with a number nor contain a colon I've checked syntax for fragment identifiers in URIs (RFC 2396) and haven't found such limitation. If such fragments cannot match any current HTML IDs, that's even better. you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: On the other hand it depends on authors providing metadata. Most likely very few will do that, and even then provided chapters may not cover all interesting fragments in the video/audio. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
Are we speaking MIME type or tag here? Looking at the list of issued MIME types, it seems pdf and ogg can fall under this category. Under these conditions, I would imagine that application would be a download, where the author wants you to get the content, as opposed to stream it or view it in-place. On 21 Mar 2007, at 19:50, Martin Atkins wrote: Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. imageimage/* videovideo/* application application/* audioaudio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. What do you imagine application being used for? The application type category is pretty-much just miscellaneous.
Re: [whatwg] video element feedback
Once upon a time Spartanicus shaped the electrons to say... But if I'm wrong and this fight hasn't yet been lost, I'd like to add my voice to not relying on JS for anything essential at least from a specification angle. Strongly agreed. I know more than a few people who are (still) rabidly anti-JavaScript as end-users, because of the repeated security issues in various implementations - and how it keeps popping up in things like Quicktime where you wouldn't necessarily expect it. I am all for using JavaScript to improve a site, and I understand that there are some online applications that just don't work without it, but I'm against throwing in the towel and making ever more content, and pages, depend on JavaScript. -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
[whatwg] video element feedback
Thanks for all the feedback on video. There were several topics discussed. I'll cover the three most important ones first. ON THE CODEC: A number of people put forth many arguments for and against all kinds of codecs. However, very little of the feedback introduced any information that wasn't taken into account when I first drafted the proposal. The spec can't require MPEG4 or other proprietary or patent-encumbered formats or suites of formats, because of the patent situation. Unless someone is willing to do the work and pay for licenses, or get MPEG-LA and/or similar groups to waive their rights for implementations of this spec, we can't require them, as it would require certain implementors to either expose themselves to known legal risks, or be non-conformant. This doesn't stop anyone from implementing such formats if they so desire, of course. The spec doesn't require Dirac or any of the other freely implementable codecs and container formats other than Ogg, because requiring more than one would reduce the likelihood of any being implemented, and of those available, the Ogg family is more widely recognised and is arguably more mature. The spec doesn't prohibit any codec from being implemented, because doing so would be an exercise in futility -- specifications are supposed to foster interoperability, not block innovation. After all, it is from extensions to specs that most of the HTML5 features were derived. ON NATIVE UI: A large portion of the feedback concerned the way that the current spec doesn't have any features for native browser-provided UI. I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. If we want to have this implemented well, we need to focus the browser vendors' concentration on specific features. Since it is easier to implement first an API then a native UI, rather than first a native UI and then an API, the API has to come first. Similarly, because authors can make a UI with an API but can't sanely make an API with a native UI, providing an API provides authors with more options. If LiveJournal on YouTube or some other site wanted to allow authors to embed video without requiring the authors to have to deal with JavaScript, they could create a page that contained just the video and video playback UI, with the video URI being taken out of the query parameters of the page, and then could give people markup that embedded the video using an iframe, as in: iframe src=http://video.example.com/video.html?src=http://example.net/v193;/iframe This would be a safe mechanism, and would be relatively easy to set up. (It doesn't even require server-side support.) ON HANDLING OTHER MEDIA FORMATS: A lot of feedback concerned the necessity of introducing an element specifically for video in the first place. We could use object for this, adding multiple APIs to object for each kind of media file, defining the semantics for changing from one to the other, for content-negotiation, for disambiguating similar media types that have overlapping but not identical APIs, and so forth. However, the browser vendors would hate us. Browser vendors have repeatedly and loudly stated that overloading elements leads to implementation difficulties, resulting in poor interoperability, edge cases with strange behaviour, security bugs, and the works. Good examples of this in existing HTML browsers are object and input, both of which have had huge interoperability problems over the years, and both of which still have big issues. When it takes more than 10 years to get an element implemented well in every single browser that has tried to implement it, you have to look at why that is, and you have to learn from the mistake. In this case, the mistake is adding too much functionality to one element. Similarly, for backwards-compatibility reasons, adding anything to object is a nightmare. We'd have to carefully examine every addition to make sure it didn't clash with existing content, for instance. Furthermore, overloading an element with various APIs results in difficulties for authors. An author dealing with audio doesn't want to think about aspect ratios, and an author dealing with video doesn't want to think about plugin parameters. This doesn't mean we have to specify everything as its own element. There are media types that it doesn't make sense to support with a specific element (at least not yet); we don't want to have six dozen elements with each type having its own set of features (and bugs). We _do_ have a generic element, object, which does work for generic inclusion. It doesn't support media-specific features (like the Video API) but it works as a stop-gap until the media in question is important enough
Re: [whatwg] video element feedback
I do fully understand the points you make below, but I am not sure I fully subscribe to the logic. embed is in HTML5 specifically for plugins. However, for embed, object, iframe, and video, the spec doesn't require that UAs implement the features using plugins or using native code. For example, Mozilla natively supports SVG in embed (it doesn't require a plugin). Similarly, you could see video be implemented as a special-case plugin. That's an implementation detail and doesn't really affect the spec. I think we have then arrived at tags-for-everything. (imgvideoaudioembediframe cover everything do they not?) However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. On 20 Mar 2007, at 09:25, Ian Hickson wrote: Similarly, for backwards-compatibility reasons, adding anything to object is a nightmare. We'd have to carefully examine every addition to make sure it didn't clash with existing content, for instance. Furthermore, overloading an element with various APIs results in difficulties for authors. An author dealing with audio doesn't want to think about aspect ratios, and an author dealing with video doesn't want to think about plugin parameters. This doesn't mean we have to specify everything as its own element. There are media types that it doesn't make sense to support with a specific element (at least not yet); we don't want to have six dozen elements with each type having its own set of features (and bugs). We _do_ have a generic element, object, which does work for generic inclusion. It doesn't support media-specific features (like the Video API) but it works as a stop-gap until the media in question is important enough to deserve special treatment, if that happens.
Re: [whatwg] video element feedback
Ian Hickson wrote:
On Sun, 18 Mar 2007, Anne van Kesteren wrote:
I just played some more with our internal implementation (Opera's) and
noticed that our pause() really is like togglePause() in the HTML5
Having pause() always pause is better because it means that you're not
likely to end up in state where the UI says one thing but the UA does
another (especially when you combine this with UA-provided UI).
Agreed.
I only included togglePause() because Flash supports it and some people asked for
it; I'm not convinced we should keep it.
I'm in favour of dropping it. It's an unnecessary API for browsers to
support. It adds nothing that can't be done with play()/pause() and an
if statement.
if (video.state == HTMLVideoElement.PAUSED) {
video.play();
} else {
video.pause();
}
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] video element feedback
Lachlan Hunt wrote: Ian Hickson wrote: I only included togglePause() because Flash supports it and some people asked for it; I'm not convinced we should keep it. I'm in favour of dropping it. +1. Jeff Cutsinger
Re: [whatwg] video element feedback
On 3/20/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 17 Mar 2007, Shadow2531 wrote:
Video content must be rendered inside the element's playback area such
that the video content is shown centered in the playback area at the
largest possible size that fits completely within it, with the video
content's aspect ratio being preserved. Thus, if the aspect ratio of the
playback area does not match the aspect ratio of the video, the video
will be shown letterboxed.
So, that also means that scaletofit in my examples is implied by that?
Yes.
Thanks.
So, if one used video src=200x200.ogg style=width: 800px; height:
800px;/video , there'd be no way to make the video display at 200
x 200 because it would always scale?
If so, if one wanted to simulate the look I'm describing, would one
have to do the following for example?
figure style=width: 800px; height: 800px; background: #000;
video src=200x200.ogg style=width: 200px; height: 200px;/video
/figure
(Just want to be sure.)
On Fri, 16 Mar 2007, Shadow2531 wrote:
A video might be split into separate files (chapters). A playlist is
needed to provide consecutive playback without user interaction and to
provide view of your choices. If you've ever watched episodes in parts
on youtube, you might see why this is important.
Does YouTube support this? I thought YouTube didn't support this, which
would suggest it's not a high priority...
For youtube, if you play a show that's split up into parts, after the
first part is finished, the flash will *sometimes* display a link to
the next part that you can click on. However, because it's not
automatic, it's not as friendly (depending on the desire of the user).
But, when the next part is not provided at all, it's really
unfriendly.
So, you are correct. Youtube does not do playlists to the extent I was
referring.
Given the low priority for them and the note about JS being required,
a JS simulation of playlists will do.
However, what if JS is turned off and you want to do playlists?
If JS is turned off, applications won't work. :-) Just like when you turn
JS off and try to use Google Calendar, or turn off Flash and try to use
YouTube. In v2 we can add UI features to handle this, though, such as:
True. Without a default UI and or support for params that provide
initial state, with JS off, the video won't do anything.
.loop, .startpos
loop = false | true
autostart = true | false
startpos = 0 | specified pos
Could you elaborate on the use cases for these?
video src=VideoIWasWatching.ogg
param name=startpos value=value gotten from cookie where I left off
at
/video
If the data has to be gotten from a cookie, wouldn't a JS seek() not be
better? You'll need JS to save the position anyway.
This is another case where I assumed the video element would be usable
without JS. Anyway, the cookie value written out by a php script was
just one example. The saved position could be gotten other ways.
video src=AwesomeMusicVideo.ogg
param name=loop value=true
/video
Wouldn't the decision of whether to loop or not be a user decision? UAs
can provide a loop option as a checkable item on a context menu. I'd hate
to go to a site and have a video keep looping.
I'm thinking more along the lines of a local HTML page that embeds a
local video (one of your favorites for example) where when you load
the page (via a bookmark or a panel for example), it automatically
starts and is set to loop (because you authored it that way).
This is also another use case for playlists. One might create a local
Opera video player panel, which like winamp, foobar, vlc etc., would
support playlists. (Many have already used OBJECT and plugins for
that.)
In the cases where you just want to play the video, it seems odd to
require JS to do it (not saying it's difficult). However, one can get
used to that. When Audio() was added, JS being a requirement was a
given because there was no element to go along with it.
Page where a user is expecting a video to play.
video src=file.ogg
param name=autostart value=true
/video
We got a bunch of feedback from people saying never autoplay!. :-)
Again, the spec allows users to control this now.
Because it's abused by many. Not allowing it would probably be a good deterrent.
So, this is all that is needed to do autostart?
window.onload = function() {
document.getElementsByTagName(video)[0].play();
};
However, if JS is needed for the video element to function at all, then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var
Re: [whatwg] video element feedback
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
Disagreed. You can still start the video with the context menu or from the
separate window mode or full screen, or whatever (non-inline) UI the
browser provides. Also, as soon as browsers have implemented what is
currently specced, it is expected that declarative features for a native
UI will be added, so then it should *not* fall back with JS off. Making it
fall back for v1 but not for v2 would just cause interoperability problems.
You would have to script the fallback, as everything else with v1. ;-)
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
That wouldn't help, as without JS you wouldn't access the fallback
content. You could do this:
p id=videofallbackfallback/p
script
var video = document.createElement(video);
video.src = foo.ogg;
var fallback = document.getElementById(videofallback);
var parent = fallback.parentNode;
var pos = fallback.nextSibling;
video.appendChild(fallback);
parent.insertBefore(video, pos);
/script
BTW, this would be a lot simpler to do if the src= attribute was made
optional:
videopfallback/p/video
script
document.getElementsByTagName(video)[0].src = foo.ogg;
/script
I think this should be allowed. Without the src attribute, the video
element could represent a placeholder where a video might have been
relevant (e.g. if scripting was enabled).
--
Simon Pieters
Re: [whatwg] video element feedback
On 3/20/07, Simon Pieters [EMAIL PROTECTED] wrote:
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
Disagreed. You can still start the video with the context menu or from the
separate window mode or full screen, or whatever (non-inline) UI the
browser provides. Also, as soon as browsers have implemented what is
currently specced, it is expected that declarative features for a native
UI will be added, so then it should *not* fall back with JS off. Making it
fall back for v1 but not for v2 would just cause interoperability problems.
You would have to script the fallback, as everything else with v1. ;-)
:) Understood.
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
That wouldn't help, as without JS you wouldn't access the fallback
content. You could do this:
p id=videofallbackfallback/p
script
var video = document.createElement(video);
video.src = foo.ogg;
var fallback = document.getElementById(videofallback);
var parent = fallback.parentNode;
var pos = fallback.nextSibling;
video.appendChild(fallback);
parent.insertBefore(video, pos);
/script
BTW, this would be a lot simpler to do if the src= attribute was made
optional:
videopfallback/p/video
script
document.getElementsByTagName(video)[0].src = foo.ogg;
/script
I think this should be allowed. Without the src attribute, the video
element could represent a placeholder where a video might have been
relevant (e.g. if scripting was enabled).
I see what you're saying. If the video object is still going to start
up without JS on, then you have to omit src or just do src= so it
falls back. Then, if JS is on, you can set the file so the alternate
content hides and the video object initializes.
Or, just create the element with JS and add it where you want.
--
burnout426
Re: [whatwg] video element feedback
Ian Hickson wrote: A large portion of the feedback concerned the way that the current spec doesn't have any features for native browser-provided UI. I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. If we want to have this implemented well, we need to focus the browser vendors' concentration on specific features. Since it is easier to implement first an API then a native UI, rather than first a native UI and then an API, the API has to come first. Similarly, because authors can make a UI with an API but can't sanely make an API with a native UI, providing an API provides authors with more options. If LiveJournal on YouTube or some other site wanted to allow authors to embed video without requiring the authors to have to deal with JavaScript, they could create a page that contained just the video and video playback UI, with the video URI being taken out of the query parameters of the page, and then could give people markup that embedded the video using an iframe, as in: iframe src=http://video.example.com/video.html?src=http://example.net/v193;/iframe This would be a safe mechanism, and would be relatively easy to set up. (It doesn't even require server-side support.) I must disagree with the focus on the comparatively complicated case (video as part of a web application) vs. the more obvious case of I just want to embed a video in my web page. If I want to embed an image in my page or blog, I just upload it somewhere and write: img src=pretty.png If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Currently I do not routinely post video in my blog nor on any of my web pages because it is non-trivial to offer it in a portable manner. Your proposed solution is still too much work for the casual author: unless some other website is prepared to help me, I have to not only upload the video but also prepare a second page containing some script and markup to implement a user-interface. (And incidentally, LiveJournal doesn't allow iframes to be used either. I'm not sure if that's a LiveJournal peculiarity or a common thing in hosted weblog systems.) Please reconsider what you are focusing on as the simple case. I'd argue that these services like Google Video and YouTube have come about largely *because* embedding video on a web page is such a pain right now. If it were just a matter of uploading the video somewhere and linking to it, authors would be able to do this themselves in most cases without the assistance of sites like YouTube, much as right now most authors don't need a website to help them present static images. I won't disagree that specifying a full user interface to be provided along with the video element is a non-trivial task, but providing just a simple UI with a play/pause button and nothing else would, I expect, pacify most people after native UI for now. Browser vendors would be free to innovate their provided UIs much as Internet Explorer and Mozilla have with their image toolbars. I maintain, therefore, that the following two things should be catered for by the spec in addition to what's already there: * By default, browsers are expected to provide at minimum a play/pause toggle button which does not interfere with the size of the movie. (This implies that it must be some kind of overlay, ensuring that the size given by the page author is the size that the video will actually play.) * An attribute is provided to disable the default buttons so that apps providing their own branded UI don't end up with confusing interfaces. I'd be interested to hear what is so difficult about the above. Browsers already do much more complicated things than this.
[whatwg] video element feedback
On Tue, 20 Mar 2007, Gareth Hay wrote:
I do fully understand the points you make below, but I am not sure I fully
subscribe to the logic.
embed is in HTML5 specifically for plugins.
However, for embed, object, iframe, and video, the spec
doesn't require that UAs implement the features using plugins or using
native code. For example, Mozilla natively supports SVG in embed (it
doesn't require a plugin). Similarly, you could see video be
implemented as a special-case plugin. That's an implementation detail
and doesn't really affect the spec.
I think we have then arrived at tags-for-everything.
(imgvideoaudioembediframe cover everything do they not?)
Oh no, there are many more types of media that exist or can exist. 3d,
smell, animation, tactile... some media don't exist in digital form
yet, but they will in due course; others exist in niche markets but may
become more popular... some simply haven't been thought of yet.
However, I think if object is so widely derided by everyone, than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't think we can
actually do it given the large amount of legacy content, e.g. tutorials
for how to embed flash which encourage use of object.
On Wed, 21 Mar 2007, Lachlan Hunt wrote:
I only included togglePause() because Flash supports it and some
people asked for it; I'm not convinced we should keep it.
I'm in favour of dropping it. It's an unnecessary API for browsers to
support. It adds nothing that can't be done with play()/pause() and an
if statement.
if (video.state == HTMLVideoElement.PAUSED) {
video.play();
} else {
video.pause();
}
On Tue, 20 Mar 2007, Jeff Cutsinger wrote:
+1.
I've commented it out for now. Let's see how many people complain.
On Tue, 20 Mar 2007, Shadow2531 wrote:
So, if one used video src=200x200.ogg style=width: 800px; height:
800px;/video , there'd be no way to make the video display at 200 x
200 because it would always scale?
Currently, correct.
If so, if one wanted to simulate the look I'm describing, would one have
to do the following for example?
figure style=width: 800px; height: 800px; background: #000;
video src=200x200.ogg style=width: 200px; height: 200px;/video
/figure
(Just want to be sure.)
Yeah, you could do that.
I'm thinking more along the lines of a local HTML page that embeds a
local video (one of your favorites for example) where when you load the
page (via a bookmark or a panel for example), it automatically starts
and is set to loop (because you authored it that way).
Well for local content we don't need to worry about interoperability
(since the user makes it for himself on his user agent), so user agents
are free to add vendor extensions to do this, or the user could use JS, or
the user could do something that doesn't involve HTML at all, that's not
really our problem.
So, this is all that is needed to do autostart?
window.onload = function() {
document.getElementsByTagName(video)[0].play();
};
That will do it, yes, assuming the user agent doesn't block it (the spec
allows that, under use control).
However, if JS is needed for the video element to function at all,
then the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display the
alternate content.
You can do this with JS, of course (and that's the preferred way; hide
the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
No, I meant something like:
section id=video
pYou need JavaScript turned on to do video./p
/section
script
// clear the fallback
var v = document.getElementById('video');
while (v.hasChildNodes) v.removeChild(v.firstChild);
// get the data to play
var src = 'video.ogg';
// create the UI
default xml namespace = http://www.w3.org/1999/xhtml;;
var ui = div
pvideo src={src}/video/p
p
input type=button value=Play onclick=vPlay()/
input type=button value=Pause onclick=vPause()/
/p
/div;
var video = ui..video.domNode();
function vPlay() { video.play() }
function vPause() { video.pause() }
v.appendChild(ui.domNode());
// start playback
video.play();
/script
Or, probably better:
section id=no-js-warning
pYou need JavaScript turned on to do video./p
/section
section id=video
pvideo src=video.ogg/p
p
input type=button value=Play onclick=vPlay()/
input
Re: [whatwg] video element feedback
Ian Hickson wrote: I don't think such metadata attributes would help. They would just be ignored by most authors and incorrectly set by many others. I absolutely agree, but this is opt-in metadata so the first flaw (ignored by most authors) is by design. Such authors are precisely the sort of authors who cannot be trusted to produce accessible content or rate content correctly. The alt attribute is often incorrectly set by many authors, but on balance it's still better than no alt attribute. If most deliberately accessible content is labelled as such, then that would be an improvement on the current situation, since the number of false positives would be vastly reduced. It's true that such attributes might cause some unlabelled accessible content to be ignored, but such content is perhaps at an even /higher/ risk of being ignored when people with differing abilities dismiss entire technologies as inaccessible wholesale. Having said that, such flags might be good material for some sort of complex microformat. Obviously a preferable solution would be for everyone to create accessible content using open technologies in the first place, and we must do everything we can to encourage and enable that. But falling short of such revolutions, can anyone suggest an alternative way of limiting the disillusion caused by inaccessible downloads? What would happen if the video element actually contained audio elements for the audio, audiodescription elements for the audio descriptions, caption elements for the captions, and subtitle elements for the subtitles? Would it be technologically possible for HTML elements to act as containers in that way? Alternatively (thinking of XSPF playlists), what if video's src attribute pointed to an XML (or text/html-esque) file which contained these separate elements? It would be a powerful way of building a level of transparent accessibility into the system, without requiring users to download and play high-bandwidth content to find out if it has the features they need. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element feedback
Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? Browsers should see if a video is unsupported and show the fallback message, which would contain a link to download the appropriate software. For example, video src=example.wmv This is a Windows Media Video file, but you need to download such-and-such to display it in your browser. /video The fallback isn't done that way in the spec today because that kind of fallback has been a source of bugs in browsers when it comes to other features (e.g. object); however, the spec provides the information to the script, though 'error' events, so you can achieve the same effect. Error events are in any case preferable, so that text alternatives can be separated from download suggestions. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element feedback
Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element feedback
Håkon Wium Lie: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form
Re: [whatwg] video element feedback
Actually that sounds like a splendid idea to me. although I am not sure about using the form tag. what about something like? video src='some_file.ogg' button type='rewind' / button type='playpause' / button type='stop' / button type='fastforward' / /video On 3/20/07, Christoph Päper [EMAIL PROTECTED] wrote: Håkon Wium Lie: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form -- [EMAIL PROTECTED] http://www.tuesdaybegins.com
Re: [whatwg] video element feedback
Christoph Päper said: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I was somewhat concerned with the script-only controls. Your's is a neat approach if you wanted a custom, scriptless UI for the element and I think it may be a good idea to have scriptless UI controls. I don't know what people would say about the form as extra code on the minimalistic video. That said, if the video controls are built in via a fade-in menu like iTunes video or (if they must) via a right-click menu, I think I could live without scriptless UI controls. They'd be nice, though. -- Robert http://robertdot.org
Re: [whatwg] video element feedback
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote: Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: • As video would cater for video/* MIME types, image would cater for image/* • The alt and longdesc attributes can be part of the fallback content, allowing markup. • You don't have to provide a type attribute and match on: object [type^=image/] • and more… - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On 21/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: Christoph Päper said: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I was somewhat concerned with the script-only controls. Your's is a neat approach if you wanted a custom, scriptless UI for the element and I think it may be a good idea to have scriptless UI controls. I don't know what people would say about the form as extra code on the minimalistic video. That said, if the video controls are built in via a fade-in menu like iTunes video or (if they must) via a right-click menu, I think I could live without scriptless UI controls. They'd be nice, though. Hmm. I'd prefer to not add an artificial method on the form element. Instead I'd prefer something like this: button type=play for=idref_to_videoplay/button button type=pause for=idref_to_videopause/button button type=stop for=idref_to_videostop/button progress type=played for=idref_to_video/progress progress type=buffered for=idref_to_video/progress Where the buttons automatically without scripting do the equivalent of the API function with the same name, and where the progress elements gets it's value from the video as it plays/gets buffered. -- David liorean Andersson
