Re: [whatwg] Video proposals

[Ian Hickson]

On Mon, 26 Mar 2007, Benoit Piette wrote:
>
> Another thing I like about the  proposal apart from the 
> consistent API across browsers is that controls buttons could be 
> generated by the browser, which would leed to a consistent user 
> interface within the browser. This would be good for usability. Same 
> with . I don't think those two tags would replace  though 
> . and would be a simpler way to do 80% of the needs of 
> video / audio integration. I would be happy to use  for a more 
> complex need.
> 
> In the same train of thought, a  tag might be useful. I always 
> found anoying that for many embeded documents (word or pdf) you would 
> have a second user interface that have similar functionnality to the web 
> browser (ex: search within a document). Something like  type="application/ms-word" />. Having a consistent API and consistent 
> user interface for an embeded document would be certainly useful. 
> Imagine a consitent interface (user and API) for an embeded word 
> document, a pdf, or even an editable content / controls for a CMS, wiki 
> or a blog... Of course, creating an API that can edit both a PDF and a 
> Word document is something daunting to say the least... But something 
> that could be useful for simple content creation (like in a simple CMS, 
> blog or wiki, something that can actualy generate valid HTML!) and 
> general document embedding for viewing might be possible.

What you describe here seems to be exactly what  is.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Video proposals

[Matthew Raymond]

Laurens Holst wrote:
> Matthew Raymond schreef:
>>> Sure, native video playback, yay. But what has that got to do with 
>>> creating a  element instead of using . Objects can play 
>>> Theora, too, you know. Natively. Just like browsers can render SVG in 
>>>  tags, natively.
>>> 
>>It's all about ease of authoring. If you were new to HTML, would you
>> want to do this...
>>
>> | 
>>
>> ...Or this...
>>
>> | 
>>   
> 
> First of all, that isn’t so bad at all.

   As I pointed out, that requires you to know the MIME type (which I
apparently got wrong), so it is that bad. However, as pointed out,
|type| is not required on some browsers.

> Second, quote from the HTML 4 
> specification: “This attribute specifies the content type for the data 
> specified by data 
> . This 
> attribute is optional […]”.

   (Idle note: It's optional when |data| is specified only.)

> So the fair-comparison snippet would be:
> 
>

   That's assuming the extension is provided, but the fact of the matter
is that the extension is not required, so the reality is that you might
not be able to determine if the object is even a video:

|

   Compare that to this:

|

> Third, if you look at any actual embedded media, you will see that it is 
> not that simple. Being able to do the first would already be a huuge 
> improvement over the current -within- with all parameters 
> duplicated and both big amounts of plugin finder and ActiveX attributes. 
> Because  would also need to be pluggable, you can not avoid that 
> same cruft on the  tag as well.

   I'm not exactly clear on what you're talking about here. Are you
complaining that  is suboptimal for an interactive Flash
presentation or something? Because I don't think that's its use case in
the first place.

> It must be pluggable, because otherwise you’ll be limited to the 
> intersection of implemented codecs and file format (which might very 
> well yield an empty set), and hinder third-party developers from 
> creating new technologies or provide plugins for old ones so that they 
> can be more uniformly supported.

   Since we're not eliminating , and since nothing stops UA
developers from implementing  in a way that simply uses whatever
video plug-in that handles the file's MIME type, I don't see the limitation.

> Fourth, those two examples are not equivalent. The former is much more 
> specific. To the point of saying that even though the file has an 
> .mpeg-extension, it is really video/ogg-theora.

   Actually, that was a typo. It's irrelevant, though, because both
support |type|.

> Anyway, the current mess that is embedding via the  tag does not 
> reflect how it is specified, and how it /could/ be.

   I'm confused. What was your third solution?

>>Do you know the MIME type for Ogg Theora? I don't. I made it up. If
>> the MIME type on the object listed doesn't say "video" in it, would you
>> even know if the  element was for a video???
> 
> The MIME type is optional, so the point is rather moot.

   True, although the attribute |data| is not necessarily use in an
embedding context on other elements (See WF2.), so it may not be clear
to newbies what it does.

> Furthermore, 
> looking up a MIME type isn’t that troublesome.

   Really? What's the MIME type for VP3?

> Ogg seems to use application/ogg by the way, being the exception. It is 
> interesting to read their final summary message [1] on the matter (which 
> does mention a video/ogg-theora type), where they basically say that 
> making a distinction between video and audio and images isn’t important 
> enough to complicate matters by creating separate MIME types.

   That's specifically when the data is in an Ogg container. Independent
of Ogg, it says the type for Theora would be "video/theora".

> With regard to determining if it’s a video or not, if you do not know, 
> would that really matter?

   It would if you were trying to find the markup for a video that you
want to copy-paste to your website.

> The author puts in something in the page, that 
> he wants displayed there. Whether this be a still image or a video clip 
> or an audio clip or a small game… that knowledge is not really important.

   It is when he wants to provide his own UI for the video. It also
means that you don't necessarily get the same UI for all video types. If
 you're playing Ogg Theora, you might get the controls from an embedded
version of VLC, whereas if you're playing and MPEG, you might see the
controls from QuickTime. Such UI differences can confuse the user and
make it harder for them to determine how to perform certain operations
with the video.

   Requiring that plug-ins allow the browser to override the UI in the
 element with a native one for video would break existing
-based video plug-ins, and there would be no fallback save
, which means you're limiting how many levels of fallback you can
have.

Re: [whatwg] Video proposals

[Boris Zbarsky]

Laurens Holst wrote:
One of the main reasons that  is still broken on the web and why 
 needs to be used is Mozilla; their plugin finder doesn’t work 
with .


I'm sorry, but that's false.  See my other post (under "Re:  element 
feedback") and 
http://developer.mozilla.org/en/docs/Using_the_Right_Markup_to_Invoke_Plugins 
for details.


-Boris

Re: [whatwg] Video proposals

[Alexey Feldgendler]

On Mon, 26 Mar 2007 13:59:14 +0200, Benoit Piette <[EMAIL PROTECTED]> wrote:

> In the same train of thought, a  tag might be useful. I always
> found anoying that for many embeded documents (word or pdf) you would have a
> second user interface that have similar functionnality to the web browser
> (ex: search within a document). Something like  type="application/ms-word" />. Having a consistent API and consistent user
> interface for an embeded document would be certainly useful. Imagine a
> consitent interface (user and API) for an embeded word document, a pdf, or
> even an editable content / controls for a CMS, wiki or a blog... Of course,
> creating an API that can edit both a PDF and a Word document is something
> daunting to say the least... But something that could be useful for simple
> content creation (like in a simple CMS, blog or wiki, something that can
> actualy generate valid HTML!) and general document embedding for viewing
> might be possible.

There is  for this.


-- 
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] Video proposals

[Maciej Stachowiak]

On Mar 18, 2007, at 4:21 PM, Matthew Ratzloff wrote:



"Slightly" more complex use case:
http://www.apple.com/qtactivex/qtplugin.cab";
width="200"
height="16">


http://www.apple.com/quicktime/download/"; />



http://www.apple.com/quicktime/download/"; />



This is a description of my audio file.

vs.


This is a description of my audio file.



I don't think you can credit  for the simplification that  
results when you replace something that works across many browsers  
with something that doesn't.


Regards,
Maciej

Re: [whatwg] Video proposals

[James Justin Harrell]

>From HTML 4.01:

type = content-type [CI]
This attribute specifies the content type for the data specified by data. 
This attribute is
optional but recommended when data is specified since it allows the user agent 
to avoid loading
information for unsupported content types. If the value of this attribute 
differs from the HTTP
Content-Type returned by the server when the object is retrieved, the HTTP 
Content-Type takes
precedence.

The type attribute is already optional and only indicative. It can claim that 
something is
different from what it actually is and just be ignored. To someone reading the 
markup, it's no
better than a comment.

A video element not only lets people reading the markup know that something 
should be a video, it
also should prevent anything else from being loaded. So if I embed a video from 
another site, and
they change it to a nasty applet because they weren't too happy about my 
hotlinking, the applet
wouldn't get loaded and executed.


--- Matthew Raymond <[EMAIL PROTECTED]> wrote:

> Laurens Holst wrote:
> > So make the object mime type optional, only indicative. It will receive 
> > it from the server anyway.
> 
>The problem with dropping the MIME type is that files on the Internet
> don't require extensions. They already have MIME types. Therefore, as a
> web author looking at someone else's markup, how would you identify if
> the following are images, video or audio?...
> 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> 
> 
>With a  element, you know it's video just by looking at it.
> 

Re: [whatwg] Video proposals

[Martin Atkins]

Vladimir Vukicevic wrote:


 If providing content in non-Theora formats is important, the client
> should list the supported video formats in the Accept header, and the 
server can send
back the right thing. 

[snip]

Though as has been pointed out by someone else earlier in the thread, 
the MIME types are attached to the container formats rather than the 
codecs. Seeing video/quicktime doesn't tell you what codec is used 
inside, and likewise video/x-msvideo.


Perhaps something like an Accept-codec: header (though preferably 
something more generic than that) is needed:


Accept-codec: audio/mp3, video/theora, audio/vorbis

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Robert Brodrecht:

 > > Quality, size, etc. have all been goals of the Theora project, so it's
 > > not really fair to say that they haven't been considered.  There is no
 > > technical reason why Theora shouldn't be specified as a baseline format.
 > 
 > I think you took that out of context.  I wasn't making a judgement about
 > Theora.  I'm sure it will get the job done as a baseline codec.  I was
 > simply saying that the WHAT WG mailing list discussion went something
 > like: "We ought to use an open codec!" and someone said, "Theora is open!"

It wasn't quite like that. Opera's experimental build, which was
demoed the day the proposal went to the WHAT WG, had support for the
 element and a native Theora decoder. Some conscious thinking
went into picking Theora in the first place.

  http://my.opera.com/saito/blog/show.dml/787937 
  
http://coolastory.blogspot.com/2007/03/sv-web-builders-event-world-premier-of.html
  http://www.youtube.com/watch?v=hUqC1URVytk
  http://www.youtube.com/watch?v=tKXomOLraXg
  http://www.flickr.com/photos/biao/406571288/
  http://www.flickr.com/photos/mimizone/406561638/

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Vladimir Vukicevic]

Håkon Wium Lie wrote:

Also sprach Robert Brodrecht:

 > As I said before, I think we have a lot better chance at getting a common,
 > cross-browser, cross-platform format with MPEG 4.  The reason WHAT WG
 > proposed Theora is *because* it is FOSS, not for quality, size, ease of
 > implementation, or anything else (as far as I know).


Quality, size, etc. have all been goals of the Theora project, so it's 
not really fair to say that they haven't been considered.  There is no 
technical reason why Theora shouldn't be specified as a baseline format.



Due to software patents, MPEG 4 costs money. Also, it requires more
processing power than many devices have. Who will pay for licenses to
OLPC's machines? And, how will the get the power to decode?

I think it's vital that we find an open format that the free world can
use.

If MPEG4 is the alternative, we might as well continue using Flash and
. But it's not a world I want to live in.


I see no problem with an implementation supporting MPEG4 etc. in 
addition to Theora (provided they can legally do so).  If providing 
content in non-Theora formats is important, the client should list the 
supported video formats in the Accept header, and the server can send 
back the right thing.  Arguing over which format is supported isn't 
really productive, because due to legal realities, there are very few 
high quality options for a common baseline format.  Theora is probably 
the best of that bunch.  (The BBC format whose name I can't think of atm 
might be another, but I think it's much earlier along the development 
process.)


- Vlad

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Robert Brodrecht:

 > As I said before, I think we have a lot better chance at getting a common,
 > cross-browser, cross-platform format with MPEG 4.  The reason WHAT WG
 > proposed Theora is *because* it is FOSS, not for quality, size, ease of
 > implementation, or anything else (as far as I know).

Due to software patents, MPEG 4 costs money. Also, it requires more
processing power than many devices have. Who will pay for licenses to
OLPC's machines? And, how will the get the power to decode?

I think it's vital that we find an open format that the free world can
use.

If MPEG4 is the alternative, we might as well continue using Flash and
. But it's not a world I want to live in.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Maik Merten]

Håkon Wium Lie schrieb:
>  > What WHATWG has been shooting for, is one common codec.  At this point,
>  > WHATWG folks want Theora.
> 
> Yes, it's a likable format. If anyone has better ideas, this is the
> time to step forward.

There's Dirac in development right now. That's a next generation wavelet
codec, developed by the BBC. There's also an implementation of that
codec integrating with the Ogg family of codecs - Schrödinger.

However, that codec isn't stable yet (the bitstream format isn't fixed
yet so future decoders most likely won't play content encoded today) and
even both the Dirac reference implementation and Schrödinger write
different formats thanks to the spec being in flux.

http://dirac.sourceforge.net/
http://schrodinger.sourceforge.net/

Once this is solved and once it performs nicely it may be a serious
alternative to Ogg Theora. Currently it's just not ready yet for
production use.

As for licensing: "The terms of the MPL mean that as far as the BBC is
concerned, there will be no charges or royalties for the Dirac software."

Perhaps it's advisable to keep an eye on that codec for future versions
of the whatwg specification work.

>  > Apparently, that may still have some licensing
>  > issues.
> 
> Some unnamed vendor has said it's unlikely they will ship a Theora
> decoder, for whatever reason. Hopefully they will reconsider when
> Wikipedia starts using it for real.

If somehow possible it might be valuable to encourage them to talk about
the problems they have with supporting that codec. Perhaps those
problems can be resolved.

Actually it seems Wikipedia is already using Theora as their format of
choice. http://commons.wikimedia.org/wiki/Category:Video
Seems there are several hundred videos already (notice the "next 200"
link on the page).

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Robert Brodrecht:

 > > I  don't see how you're going to avoid that with
 > >  unless you intend  to make it a non-pluggable system, which does
 > > not seem like a good idea.
 > 
 > I think that was the idea.  I don't need plugins for certain media files,
 > e.g., GIF, JPEG, and PNG (and maybe WAV, MP3, and MIDI using bgsound in IE
 > if that is still around).  If a certain set of cross-platform video codecs
 > could be supported, there would be no need for a plugin.

Exactly.

 > What WHATWG has been shooting for, is one common codec.  At this point,
 > WHATWG folks want Theora.

Yes, it's a likable format. If anyone has better ideas, this is the
time to step forward.

 > Apparently, that may still have some licensing
 > issues.

Some unnamed vendor has said it's unlikely they will ship a Theora
decoder, for whatever reason. Hopefully they will reconsider when
Wikipedia starts using it for real.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Gareth Hay]

Gareth Hay wrote:

   Sure. What happens if you're taking old videos of a page because
you moved them to a site like YouTube? How would you tell them apart
from other content in the page that might require , like SVG
graphics and such?


I think this kind of reasoning leads us logically to tags for
everything. (Which I don't think is a good idea fwiw)


   Not if new elements are based on significant use cases. Considering
the popularity of YouTube and other video sites, I'd say that a use  
case

for  is a safe bet.

   Also keep in mind that, using your logic, we should eliminate 
because you can use  instead. (In fact, that makes more sense
because  has better fallback than , whereas  has
equivalent fallback.)


I have actually argued this point previously.
I don't see how we can say 'for these use cases, we will generate  
very specific tags and for these use cases you just have to use a  
generic tag'.


Common sense would lead us to a one or the other approach.
I don't think it is a sensible argument to say, "well i use img all  
the time, so we should have a short hand for it"

It's not consistent, and lack of consistency leads to confusion.

I do not see why using  to display images is any worse than  
using .


The only case is from the API point of view, object.play() makes no  
sense for a static image, but then that leads to the other end of my  
argument, do away with  all together and have all content in  
specialized tags.





There are of course other use cases, such as wanting to specify an
object in general terms and have it change over time. For example if
I have a video file, I can swap codecs should I need to, and not need
to alter the page at all.


   Another issue is that while Flash may eventually disappear from the
'Net, video isn't going anywhere.


Yes, but in my use case, I can specify 
Then I can have a qt mov file if I like, but should I need to change  
to an ogg codec for some reason, all I do is put the ogg file in the  
same location, with the same name, no page changes required. While  
I'm not advocating this approach, it is clear there can be advantages  
in only having MIME specified at transfer time.

Re: [whatwg] Video proposals

[Matthew Raymond]

Gareth Hay wrote:
>>Sure. What happens if you're taking old videos of a page because  
>> you moved them to a site like YouTube? How would you tell them apart
>> from other content in the page that might require , like SVG
>> graphics and such?
> 
> I think this kind of reasoning leads us logically to tags for  
> everything. (Which I don't think is a good idea fwiw)

   Not if new elements are based on significant use cases. Considering
the popularity of YouTube and other video sites, I'd say that a use case
for  is a safe bet.

   Also keep in mind that, using your logic, we should eliminate 
because you can use  instead. (In fact, that makes more sense
because  has better fallback than , whereas  has
equivalent fallback.)

> If I wanted to isolate all SVG content from a page and [the page] also  
> contains flash but the previous incumbent didn't use MIME then I am  
> also stuck, but again, if the actual content has gone from the  
> [Internet] a MIME type isn't going to help me much.

   I would not consider pages with both SVG and Flash all that common.
It's far more likely that you'd see video and Flash. In fact, they may
be using Flash to play videos, so because there isn't a  element
to allow native, integrated video support, there may be no means of
determining of something is even a video without analyzing the Flash
data itself.

> There are of course other use cases, such as wanting to specify an  
> object in general terms and have it change over time. For example if  
> I have a video file, I can swap codecs should I need to, and not need  
> to alter the page at all.

   Another issue is that while Flash may eventually disappear from the
'Net, video isn't going anywhere.

Re: [whatwg] Video proposals

[Karl Dubost]

Le 16 mars 2007 à 20:23, Matthew Raymond a écrit :

Laurens Holst wrote:

| 


In fact
by http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT
type is optional, it is exactly the same


than

| 



   Do you know the MIME type for Ogg Theora? I don't. I made it up. If
the MIME type on the object listed doesn't say "video" in it, would  
you

even know if the  element was for a video???


The HTTP "Content-Type" has priority on any local specified "type"  
values.


--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] Video proposals

[Karl Dubost]

Hi Matthew,

Very cool set of test cases.
Would it be cool to make them as individual files and send them as  
attachments.


On the same line, this is a testing for object, W3C QA and WASP  
organised two years ago. Most recent information is missing. So if  
you have a browser please add it.


http://www.webstandards.org/learn/articles/askw3c/may2005/object-tests/
http://esw.w3.org/topic/ObjectTestResults



--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] Video proposals

[Alexey Feldgendler]

On Fri, 16 Mar 2007 17:57:01 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:



All said, it would be very useful if the startpos param could be
returned to the server when starting the download, or when scrubbing
forward into parts of the video that haven't yet downloaded. as that
would help avoid using bandwidth unnecessarily.

I see two ways to do that over HTTP:
1) As a HTTP header
2) In the URL


For a long time, HTTP provided support for this through non-default units  
in the Range header. Usually servers only support "bytes" as the  
measurement units, but the HTTP spec actually allows to use "seconds",  
"pages", "chapters" and so on, and defines a clear way for the server to  
indicate the support for this.


--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] Video proposals

[Benjamin Hawkes-Lewis]

Håkon Wium Lie wrote:

> On a mobile phone, it's expensive and slow to perform HEAD requests.

I can well believe that, but the question becomes: are the types
reported in the type attribute sufficiently reliable for mobile phone
purposes? i.e. can phone browsers safely ignore embedded content if its
HTML type attribute specifies a type they cannot play? And if so,
doesn't video need a type attribute, since different phones will support
different containers? And will type or even content-type be able to
solve that problem, since even if a phone pulls down a container it
supports, it might contain content in codecs it cannot play?

> Running personal spiders is out of the question. We should keep in
> mind that the specs we designs must be usable in many types of
> enviroments.

I absolutely agree (that's why I offered some information on the
behaviour of a text browser, and talked about how content types don't
really meet the needs of users with different abilities). I was just
addressing your particular use-case, which (if I understood it right,
perhaps I didn't) involved a content administrator moving content from
one place to another. I'd expect a content administrator proficient in
such migrations to able to run wget or a similar GUI tool.

Should we have attributes to indicate whether  content has
subtitles, captions, audio descriptions, and transcriptions embedded, so
that videos are only downloaded and played if they are in fact going to
be accessible to the user? Or to flag content that is NSFW, so UAs can
be configured to not play it? Or to point to higher quality but higher
bandwidth alternatives? Or maybe to indicate licencing, so that
authoring tools could throw up a warning if one tried to mix up or
deeplink to content with a restrictive licence. (I don't actually think
authoring tools should prevent one doing so, because authoring tools
aren't lawyers.) All of this is stuff one might very much wish to
know /before/ downloading the video. Particularly on the accessibility
front, when users with disabilities go through the palaver of
downloading and opening content which could be made accessible, but
hasn't been, it damages their faith in the relevant technology. PDF is a
common offender here (never mind failure to use tagging, what about
failing to OCR scanned text before output to PDF?); for the response of
one of the many disillusioned, read:

http://www.accessibilitynews.ca/acnews/editorials/geof.php#a42

--
Benjamin Hawkes-Lewis

Re: [whatwg] Video proposals

[Gareth Hay]

According to the draft for object there is no requirement to specify  
the mime type in object tag anyway, so I'm guessing some people will  
never specify it.



f the file fails to load, you don't have a
MIME type at all, so what kind of presentation would a broken video  
have
on the page if you don't even have a MIME type to tell you it's a  
video?
If you have a  element, it could just give you a broken film  
icon.


For the matter of failing to load, what is your expectation?
If you mean for the user to be notified of a plugin or codec, you can  
specify fallback content anyway, and if the file is missing, then it  
doesn't matter if you have specified a MIME type or not, the file can  
no longer be found even if the user is told it's a video/ogg, or  
whatever.


   Sure. What happens if you're taking old videos of a page because  
you

moved them to a site like YouTube? How would you tell them apart from
other content in the page that might require , like SVG  
graphics

and such?


I think this kind of reasoning leads us logically to tags for  
everything. (Which I don't think is a good idea fwiw)
If I wanted to isolate all SVG content from a page and it also  
contains flash but the previous incumbent didn't use MIME then I am  
also stuck, but again, if the actual content has gone from the  
internet a MIME type isn't going to help me much.


There are of course other use cases, such as wanting to specify an  
object in general terms and have it change over time. For example if  
I have a video file, I can swap codecs should I need to, and not need  
to alter the page at all.


Gareth

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Geoffrey Sneddon:

 > > Yes. If a vendor, for some reason, is unable to support the Ogg
 > > codecs, I think it's better that they (a) do not support , than
 > > (b) they support  with proprietary codecs only.
 > >
 > > Interoperability has more value than conformace.
 > 
 > I think forcing browsers to support a codec when it is outdated is  
 > wrong.

In this context, I think the spec and the codec will be outdated
roughly at the same time. Likewise, I think HTML/GIF/JPEG/PNG will all
reach, roughly the same age. 

I have a long-standing bet that computers we buy 40 years from now
(the bet was entered into ten years ago) will be able to read web
pages from 1997.

I think it's time to add video and audio codecs to this select list.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Benjamin Hawkes-Lewis:

 > >Sure. What happens if you're taking old videos of a page because you
 > > moved them to a site like YouTube? How would you tell them apart from
 > > other content in the page that might require , like SVG graphics
 > > and such?
 > 
 > With HEAD requests? A personal spidering tool like wget could pull down
 > all linked videos based on content-type as specified by the server.

On a mobile phone, it's expensive and slow to perform HEAD requests.
Running personal spiders is out of the question. We should keep in
mind that the specs we designs must be usable in many types of
enviroments.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Geoffrey Sneddon]

On 16 Mar 2007, at 23:58, Håkon Wium Lie wrote:


Also sprach Robert Brodrecht:

I'd rather make  and  optional so that those who  
cannot

support these Ogg on these elements (for whatever reason) can still
comply with the spec. They can also support proprietary codecs  
through

.


Do you mean make the elements themselves optional to support?


Yes. If a vendor, for some reason, is unable to support the Ogg
codecs, I think it's better that they (a) do not support , than
(b) they support  with proprietary codecs only.

Interoperability has more value than conformace.


I think forcing browsers to support a codec when it is outdated is  
wrong. I don't want WA 1.0 to end up like RSS 2.0, having multiple  
versions incompatible with one another (in WA1.0's case different  
versions requiring different codecs).



- Geoffrey Sneddon

Re: [whatwg] Video proposals

[Benjamin Hawkes-Lewis]

Current browsers do treat  differently based on type. For
example, if an  has a type attribute in the set
"application/foobar" or "video/foobar" or "audio/foobar" or
"foobar/foobar" ELinks stable will stick a link to it above its
rendition of the fallback content. With no type attribute or
"image/foobar", it shows the fallback but no link. With "text/foobar" it
treats the  as an iframe but fails to parse following content
correctly. It's hard to see this example, at least, as a demonstration
of the utility of content types.

--
Benjamin Hawkes-Lewis

Re: [whatwg] Video proposals

[Benjamin Hawkes-Lewis]

In theory, standardized file extensions or type attributes allows
non-supporting browsers to not issue a request for the content, if they
could trust producers to correctly label content



Or at least it would, if user agents could trust producers to correctly
label their content. But even if user agents assume that authors can
correctly label content with the right element, type attribute, or file
extension, the efficiency gains may be more marginal than is sometimes
assumed. For example, you might think text browsers could just ignore
audio content. But actually people do configure such browsers to
dispatch audio to audio players (for example, Emacspeak can dispatch
audio to RealPlayer). You might think text browsers could just ignore
video content. Similarly, even if it only has audio captioning, it could
be dispatched to RealPlayer. Even if audio is not available, a text
browser might wish to access included transcriptions or text captions.

On Sat, 2007-03-17 at 15:26 +, Gareth Hay wrote:
> I don't see the problem with this.
> 
> Object is a tag to represent just about anything, even text/html  
> renders in an object.
> Can you identify a use case where you *need* to know before you get a  
> content-type header?
> 
> Gaz
> 
> On 17 Mar 2007, at 15:17, Matthew Raymond wrote:
> 
> > Laurens Holst wrote:
> >> So make the object mime type optional, only indicative. It will  
> >> receive
> >> it from the server anyway.
> >
> >The problem with dropping the MIME type is that files on the  
> > Internet
> > don't require extensions. They already have MIME types. Therefore,  
> > as a
> > web author looking at someone else's markup, how would you identify if
> > the following are images, video or audio?...
> >
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> > | 
> >
> >
> >With a  element, you know it's video just by looking at it.
> 

Re: [whatwg] Video proposals

[Benjamin Hawkes-Lewis]

Matthew Raymond wrote:
>Sure. What happens if you're taking old videos of a page because you
> moved them to a site like YouTube? How would you tell them apart from
> other content in the page that might require , like SVG graphics
> and such?

With HEAD requests? A personal spidering tool like wget could pull down
all linked videos based on content-type as specified by the server.

> For that matter, if the file fails to load, you don't have a
> MIME type at all, so what kind of presentation would a broken video have
> on the page if you don't even have a MIME type to tell you it's a video?
> If you have a  element, it could just give you a broken film icon.

Well, actually, you probably shouldn't see a broken film icon because
authors should include text/html alternatives using the fallback
mechanisms provided by both  and , and this will remain
the case until we have open container formats that are interoperable
with free and open source user agents, can serve people of differing
abilities, and have an accessibility feature-set that authors generally
use.

In any case, how does knowing the object missing was a video not (say) a
Flash object help the end-user?



--
Benjamin Hawkes-Lewis

Re: [whatwg] Video proposals

[Matthew Raymond]

Gareth Hay wrote:
> I don't see the problem with this.
> 
> Object is a tag to represent just about anything, even text/html  
> renders in an object.
> Can you identify a use case where you *need* to know before you get a  
> content-type header?

   Sure. What happens if you're taking old videos of a page because you
moved them to a site like YouTube? How would you tell them apart from
other content in the page that might require , like SVG graphics
and such? For that matter, if the file fails to load, you don't have a
MIME type at all, so what kind of presentation would a broken video have
on the page if you don't even have a MIME type to tell you it's a video?
If you have a  element, it could just give you a broken film icon.

Re: [whatwg] Video proposals

[Gareth Hay]

I don't see the problem with this.

Object is a tag to represent just about anything, even text/html  
renders in an object.
Can you identify a use case where you *need* to know before you get a  
content-type header?


Gaz

On 17 Mar 2007, at 15:17, Matthew Raymond wrote:


Laurens Holst wrote:
So make the object mime type optional, only indicative. It will  
receive

it from the server anyway.


   The problem with dropping the MIME type is that files on the  
Internet
don't require extensions. They already have MIME types. Therefore,  
as a

web author looking at someone else's markup, how would you identify if
the following are images, video or audio?...

| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


   With a  element, you know it's video just by looking at it.

Re: [whatwg] Video proposals

[Matthew Raymond]

Laurens Holst wrote:
> So make the object mime type optional, only indicative. It will receive 
> it from the server anyway.

   The problem with dropping the MIME type is that files on the Internet
don't require extensions. They already have MIME types. Therefore, as a
web author looking at someone else's markup, how would you identify if
the following are images, video or audio?...

| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


   With a  element, you know it's video just by looking at it.

Re: [whatwg] Video proposals

[Shadow2531]

On 3/17/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 17 Mar 2007 11:56:53 +0100, Shadow2531 <[EMAIL PROTECTED]>
wrote:
> For example, every video page on a site might have a 400 x 400 video
> element (to fit with the layout for example), but the video that plays
> in it will range in size and aspect ratio.
>
> A way to solve that so the layout of the page is not disrupted would
> be to have the video element represent the video screen area where the
> video itself can be scaled and centered inside it by the browser.
>
> For example, if the 400 x 400 video element plays a 640 x 480 video
> and keepaspect is set, the video would show centered inside the screen
> area at 400 x 300. If keepaspect is not set, the video would show at
> 400 x 400.

That's how  is defined now. Except that "keepaspect" is the default
behavior and there's no way to switch. Perhaps people should reread the
draft?


"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?

--
burnout426

Re: [whatwg] Video proposals

[Anne van Kesteren]

On Sat, 17 Mar 2007 11:56:53 +0100, Shadow2531 <[EMAIL PROTECTED]>  
wrote:

For example, every video page on a site might have a 400 x 400 video
element (to fit with the layout for example), but the video that plays
in it will range in size and aspect ratio.

A way to solve that so the layout of the page is not disrupted would
be to have the video element represent the video screen area where the
video itself can be scaled and centered inside it by the browser.

For example, if the 400 x 400 video element plays a 640 x 480 video
and keepaspect is set, the video would show centered inside the screen
area at 400 x 300. If keepaspect is not set, the video would show at
400 x 400.


That's how  is defined now. Except that "keepaspect" is the default  
behavior and there's no way to switch. Perhaps people should reread the  
draft?



--
Anne van Kesteren

Re: [whatwg] Video proposals

[Shadow2531]

On 3/16/07, Dean Edridge <[EMAIL PROTECTED]> wrote:

I think the idea of having an attribute for the aspect ratio of a video
is a great idea, especially given the fact that web sites today should
be as fluid / liquid as possible since there is a need to cater for a
range of different screen sizes.
So this gets my vote FWIW.


Just some thoughts...

I think some video sites might want to use a video element template of
a certain size.

For example, every video page on a site might have a 400 x 400 video
element (to fit with the layout for example), but the video that plays
in it will range in size and aspect ratio.

A way to solve that so the layout of the page is not disrupted would
be to have the video element represent the video screen area where the
video itself can be scaled and centered inside it by the browser.

For example, if the 400 x 400 video element plays a 640 x 480 video
and keepaspect is set, the video would show centered inside the screen
area at 400 x 300. If keepaspect is not set, the video would show at
400 x 400.

If the video was 300 x 120, it'd show at it's original size whether
keepaspect was set or not, unless scaletofit was set. If scaletofit
was set, then keepaspect would cause the video to show at 400 x 160.
If keepaspect wasn't set and scaletofit was, the video would show at
400 x 400.

Examples:

Video element is 400 x 400, but video shows at 400 x 300 inside it.


Video element is 400 x 400 and video shows at 400 x 400 inside it.


Video element is 400 x 400 and video shows at 300 x 120 inside it.


Video element is 400 x 400 and video shows at 300 x 120 inside it.


Video element is 400 x 400 and video shows at 400 x 400 inside it.


Video element is 400 x 400 and video shows at 400 x 160 inside it.


(scaletofit is implied when the video is larger than the video element)

You might be able to simulate all of that by putting the video element
in another element and playing with css, but that probably wouldn't be
as friendly.

--
burnout426

Re: [whatwg] Video proposals

[Dean Edridge]

Nicholas Shanks wrote:

Discussion on aspect ratio:


You may want to consider aspect ratio too:  ratio="preserve" being
default, ratio="1.333" could indicate 4:3 or get tricky and accept
"16:9" for precision reasons.


Wouldn't we simply always want to use the authored size?

Do videos encode what size they are best displayed in?  I hate
entering height and width for images.


The reason I requested this is because:

1) If you specify both a width and a height, video content that 
doesn't match that gets distorted.
2) If you want an element to have a fixed width, but variable height 
dependant on the aspect of the video, or fixed height and variable 
width, yet still have a non-zero initial value for the variable 
parameter (so that the  element occupies some screen area), you 
cannot achieve this without distorting the final image by setting both 
width and height.
3) Thinking about it more, the ratio should be explicitly advisory and 
only valid until the downloaded video can provide it's own width and 
height.


I envisage:


Some content below the video

Then, when the video is finally downloaded and it's inherent 
dimensions (and thus aspect ratio) are known, re-layout can occur if 
the aspect values don't match, but more importantly can be avoided if 
they do.


The width given is an integer number of CSS pixels, by providing an 
aspect ratio, the UA can calculate the resultant height in device 
pixels without the user having to provide a height and associated 
rounding errors (or plain mistakes). The example above has an 
irrational height.


4) Only two of {width, height, aspect} can be specified on any video 
element.


- Nicholas.
I think the idea of having an attribute for the aspect ratio of a video 
is a great idea, especially given the fact that web sites today should 
be as fluid / liquid as possible since there is a need to cater for a 
range of different screen sizes.

So this gets my vote FWIW.

Dean Edridge

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Robert Brodrecht:

 > > I'd rather make  and  optional so that those who cannot
 > > support these Ogg on these elements (for whatever reason) can still
 > > comply with the spec. They can also support proprietary codecs through
 > > .
 > 
 > Do you mean make the elements themselves optional to support?

Yes. If a vendor, for some reason, is unable to support the Ogg
codecs, I think it's better that they (a) do not support , than
(b) they support  with proprietary codecs only.

Interoperability has more value than conformace.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Robert Brodrecht]

Håkon Wium Lie said:
> I'd rather make  and  optional so that those who cannot
> support these Ogg on these elements (for whatever reason) can still
> comply with the spec. They can also support proprietary codecs through
> .

Do you mean make the elements themselves optional to support?  If so, I
think that is a good way to make sure no one supports them.  If you mean
not having the codec be required, I might be willing to agree.  However, I
would also think that it would be a good way to make sure few, if any,
common formats are supported (I can't reliably get WMV files to play on my
Mac, for example, and Microsoft would certainly provide support for WMV).

PNG was "donated" to the W3C and has been implemented by the major vendors
(so, there are no problems with licensing, apparently).  I wonder if there
is any video format that could be similarly used since this
BSD-style-license'd format isn't up to spec for some vendors.  It doesn't
have to be the best.  It just has to be decent.

-- 
Robert 

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Ian Hickson:

 > ON THE CODEC
 ...
 > > Given this, I would suggest Ogg Theora be the natively supported video 
 > > format common to all browsers.  It's designed from the beginning to be 
 > > unencumbed.  And implementations for it already exist under licenses 
 > > that should make everyone happy.
 > 
 > A number of other people said similar things about Ogg Theora.
 > 
 > For now, the spec says that UAs SHOULD support Theora for video and Vorbis 
 > for audio, and SHOULD support the Ogg container format (it's not a MUST 
 > because some vendors may have legal reasons why they can't or won't 
 > support it, and there's no point making them non-conforming when they have 
 > no choice in the matter).

I'd rather make  and  optional so that those who cannot
support these Ogg on these elements (for whatever reason) can still
comply with the spec. They can also support proprietary codecs through
.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Video proposals

[Robert Brodrecht]

Gareth Hay said:
> Ok, I could understand that approach, with things like 
> handled internally.
> Is there then a case for doing  properly by specifying a
> replacement, something like  / ?

Something that is bugging me over on the W3C HTMLWG mailing list is the
want to drop  in favor of .  I'm emotionally attached to
.  I use it a lot, and really do feel like it is semantically
different from .  Asbjørn Ulsberg suggest replacing both with
. [1]  The idea was a relief because it made the tag MUCH more
generic and (now that I think about it) could have more accurate and
broader references (e.g. microformats use  for shorter date format,
but  would make more sense).

The problem is that  is not backwards compatible, and it kills off
two elements at once.  What we need to do, instead, is disconnect from our
internal definitions of what a tag is, and reuse it to serve as what it
ought to have been called to be semantically correct.  So, I'll just have
to get over the idea that  really just means "the string in here is
a shortened version of a longer string" and not "the characters in here
are a shortened version of a long word."

In much the same way,  is now associated with "media other than
images (even though object will do images)."  Instead of killing it for
better semantics, backward compatibility be damned, we need to change our
thinking to:  means "a file that needs a plugin object to play." 
We'll still be able to play video and show pictures using the object tag. 
We'll need that for backward compatibility.  But, we should start using
 to play video once HTML 5 is finalized and use object for playing
video only as a fallback until browsers understand .

If we drop and change elements just because we think another would be
semantically better / cooler, we'll end up looking like XHTML 2.  We don't
want to be there, I promise.

[1] http://lists.w3.org/Archives/Public/public-html/2007JanMar/0140.html
-- 
Robert 

Re: [whatwg] Video proposals

[Gareth Hay]

Ok, I could understand that approach, with things like   
handled internally.
Is there then a case for doing  properly by specifying a  
replacement, something like  / ?


Gaz

On 16 Mar 2007, at 22:15, Robert Brodrecht wrote:



Andrew Sidwell said:

 would be a poor choice of
something to put in a spec, simply because its use case is already
handled by .


I wouldn't say it that way.  I'd say "because flash requires a browser
plugin, we use object."  Video is already handled by  but  
we don't
want it to be any more.  So, when you substitute "flash" with  
"video" in
your sentence above, it is self-defeating.  The reason Flash ought  
to stay
in the object tag is because it is proprietary and requires a  
plugin.  If
Flash is ever open and freely available from Adobe, then   
might not

be such a bad idea.  Several video formats, on the other hand, are
supported by major operating systems natively, and there is no need to
have web developers jumping through hoops to use it.  The theora  
codec, I
assume, would be contained inside the browser itself, thus making  
it one
format that would certainly be cross-browser and cross-platform  
whether

the OS supported it or not.

--
Robert 

Re: [whatwg] Video proposals

[Robert Brodrecht]

Andrew Sidwell said:
>  would be a poor choice of
> something to put in a spec, simply because its use case is already
> handled by .

I wouldn't say it that way.  I'd say "because flash requires a browser
plugin, we use object."  Video is already handled by  but we don't
want it to be any more.  So, when you substitute "flash" with "video" in
your sentence above, it is self-defeating.  The reason Flash ought to stay
in the object tag is because it is proprietary and requires a plugin.  If
Flash is ever open and freely available from Adobe, then  might not
be such a bad idea.  Several video formats, on the other hand, are
supported by major operating systems natively, and there is no need to
have web developers jumping through hoops to use it.  The theora codec, I
assume, would be contained inside the browser itself, thus making it one
format that would certainly be cross-browser and cross-platform whether
the OS supported it or not.

-- 
Robert 

Re: [whatwg] Video proposals

[Andrew Sidwell]

Gareth Hay wrote:
> Huh? Huh? I don't seem to recall stating a preference, just that in my
> opinion you have one or the other, but it's hard to justify both.
>
> So you are advocating the later approach then? dispose of the 
> tag and just have
> 

Re: [whatwg] Video proposals

[Josh Sled]

On Fri, 2007-03-16 at 20:55 +, Gareth Hay wrote:
> As I can't see how it can be a mix and match of the two approaches.

Why not?  It seems pretty pragmatic to have "first-class" support for
the handful of common cases and have an "escape hatch" for generic
objects.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: [whatwg] Video proposals

[Kornel Lesinski]

I think it would be useful if fragment identifiers in URL could specify  
starting position of video. This would let anyone to bookmark position in  
the video without having to worry about (lack of) site-specific navigation  
and UI for seeking.


[EMAIL PROTECTED]:mm:ss

(I'm not sure how should it be handled if  doesn't have an ID -  
maybe ID of any ancestor element could be used instead or fragment would  
affect any/first video on the page)


The use case however is quite simple and common:
If I'm watching long video and want to show interesting part of it to my  
friends (or bookmark it), I could right-click the video, choose "Copy link  
to this video" option and have URL with current playing position copied.


--
regards, Kornel Lesiński

Re: [whatwg] Video proposals

[Gareth Hay]

Huh? Huh? I don't seem to recall stating a preference, just that in  
my opinion you have one or the other, but it's hard to justify both.


So you are advocating the later approach then? dispose of the  
 tag and just have

Re: [whatwg] Video proposals

[Gareth Hay]

This topic is worrying me slightly, as I can only see two possible  
outcomes :-


using  for everything,
images  
video 

or defining separate tags for all possible content :-






As I can't see how it can be a mix and match of the two approaches.

Gareth

On 16 Mar 2007, at 19:40, James Justin Harrell wrote:



--- Matthew Raymond <[EMAIL PROTECTED]> wrote:

   It's all about ease of authoring. If you were new to HTML,  
would you

want to do this...

| 

...Or this...

| 

   Do you know the MIME type for Ogg Theora? I don't. I made it  
up. If
the MIME type on the object listed doesn't say "video" in it,  
would you

even know if the  element was for a video???


The type attribute for object elements is optional if the data  
attribute is present. That's not

new either - it was also specified that way in HTML 4.01.

Some browsers have not been compliant about it, but people will  
probably be able to use an object
element without a type attribute without worry before they're able  
to use a video element without

worry.

There's several good reasons for introducing a video element, but I  
don't consider easier markup

to be one of them.

Re: [whatwg] Video proposals

[James Justin Harrell]

--- Matthew Raymond <[EMAIL PROTECTED]> wrote:
 
>It's all about ease of authoring. If you were new to HTML, would you
> want to do this...
> 
> | 
> 
> ...Or this...
> 
> | 
> 
>Do you know the MIME type for Ogg Theora? I don't. I made it up. If
> the MIME type on the object listed doesn't say "video" in it, would you
> even know if the  element was for a video??? 

The type attribute for object elements is optional if the data attribute is 
present. That's not
new either - it was also specified that way in HTML 4.01.

Some browsers have not been compliant about it, but people will probably be 
able to use an object
element without a type attribute without worry before they're able to use a 
video element without
worry.

There's several good reasons for introducing a video element, but I don't 
consider easier markup
to be one of them.

Re: [whatwg] Video proposals

[J. King]

On Fri, 16 Mar 2007 07:23:53 -0400, Matthew Raymond  
<[EMAIL PROTECTED]> wrote:



   Do you know the MIME type for Ogg Theora? I don't. I made it up. If
the MIME type on the object listed doesn't say "video" in it, would you
even know if the  element was for a video???


application/ogg, presumably.

--
J. King
http://jking.dark-phantasy.com/

Re: [whatwg] Video proposals

[Nicholas Shanks]

On 16 Mar 2007, at 15:32, Shadow2531 wrote:


.loop, .startpos
loop = false | true
autostart = true | false
startpos = 0 | specified pos


Could you elaborate on the use cases for these?



   




The downside of that is sites have to implement a cookie system. I  
don't want to do that on my own site and many personal website owners  
won't know how to either.
For the above usage case, I don't see why "remembering where you left  
off" can't be a user-agent feature rather than part of the  
specification. Granted that would fail if you switch browsers but  
people don't do that much.


All said, it would be very useful if the startpos param could be  
returned to the server when starting the download, or when scrubbing  
forward into parts of the video that haven't yet downloaded. as that  
would help avoid using bandwidth unnecessarily.


I see two ways to do that over HTTP:
1) As a HTTP header
2) In the URL

There is also currently this RTSP URL format understood by RealPlayer:
rtsp://rmv8.bbc.net.uk/french/fre0600.ra?start=%2220%22
Other formats may understand other parameters, or not define startpos  
as an integer number of seconds, but use hrs:mins:secs etc.
How would the UA then send the startpos if differing content types  
used different mechanisms?


- Nicholas.




smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Video proposals

[Shadow2531]

On 3/15/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

ON PLAYLISTS

On Mon, 30 Oct 2006, Shadow2531 wrote:
>
> The handler should also support some type of playlist like
> .

On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
>
> #3: Playlists.  (A single video file just won't cut it.)

These were the only requests for playlists. Could you elaborate on the use
cases for playlists? What are the needs for playlists?


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.

One could use the events and states to determine when a video is done
playing. Then, the src attribute could be changed to the next video.
The list of videos could be gotten from a JS array or by parsing an
xml playlist via self-written code or some playlist parsing JS
library.

However, what if JS is turned off and you want to do playlists?



The video element itself would need to handle the playlist. (Unless
you set up links to video pages that where targeted at an iframe. Even
then, user action would be required if consecutive playback was
desired.)


ON FEATURES
On Thu, 1 Mar 2007, Shadow2531 wrote:
>
> [long list of desired features]

I took your suggestions into account when desiging the API. I got feedback
from a number of people (including some off-list from people who didn't
want to express their interest publicly), some of which was contradictory,
so the proposed API doesn't have everything you asked for. Let me know if
there's anything that you think is missing that you really wanted.


Understood. Thanks.


> .loop, .startpos
> loop = false | true
> autostart = true | false
> startpos = 0 | specified pos

Could you elaborate on the use cases for these?



   



   


Page where a user is expecting a video to play.

   


Index page for example where a video starting up might not be expected.

   
   This is my index page

(From the list and the spec, it looks like the video will never play
on its own. It looks like you have to invoke play() with js or nothing
will ever happen.)

Again though, autostart, loop and startpos could be simulated with the
events and states provided.

However, what if JS is turned off?

You need params to provide initial state. JS should only be needed for
controlling/interface stuff. If you just want to have a video load and
play till the end (and loop possibly), that shouldn't require JS.

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.


On Thu, 1 Mar 2007, Shadow2531 wrote:
>
> I think it'd be cool if the video element *just* supported theora.

Supporting only one encoding is not going to fly: you can't stop browser
vendors from adding features; and you want to allow the standard to evolve
over time.


Understood. The SHOULD for theora is good enough.

--
burnout426

Re: [whatwg] Video proposals

[liorean]

On 16/03/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

ON PLAYLISTS
On Mon, 30 Oct 2006, Shadow2531 wrote:
> The handler should also support some type of playlist like
> .

On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
> #3: Playlists.  (A single video file just won't cut it.)

These were the only requests for playlists. Could you elaborate on the use
cases for playlists? What are the needs for playlists?


I immediately though of uses like this:

where the actual talk is split into 5 pieces for whatever reason, or
Douglas Crockford's JavaScript talks videos, among many others.


ON FEATURES
> #8: Alternate versions.
Could you elaborate on this?


How about the case where you want to provide a low and a high
bandwidth version, or a widescreen/normal screen aspect ratio version,
or something similar.


On Thu, 1 Mar 2007, Nicholas Shanks wrote:
>
> You may want to consider aspect ratio too:  ratio="preserve" being
> default, ratio="1.333" could indicate 4:3 or get tricky and accept
> "16:9" for precision reasons.

Wouldn't we simply always want to use the authored size?


How about if a user wants to view the video in a separate window,
separate tab or maybe fullscreen? Those are options where the size is
not necessarily corresponding to the video size. Another aspect here
is of course zooming/resizing/stretching and how to handle that.
--
David "liorean" Andersson

Re: [whatwg] Video proposals

[Matthew Raymond]

Laurens Holst wrote:
> Sure, native video playback, yay. But what has that got to do with 
> creating a  element instead of using . Objects can play 
> Theora, too, you know. Natively. Just like browsers can render SVG in 
>  tags, natively.

   It's all about ease of authoring. If you were new to HTML, would you
want to do this...

| 

...Or this...

| 

   Do you know the MIME type for Ogg Theora? I don't. I made it up. If
the MIME type on the object listed doesn't say "video" in it, would you
even know if the  element was for a video???

Re: [whatwg] Video proposals

[Nicholas Shanks]

On 16 Mar 2007, at 11:03, Magnus Kristiansen wrote:

When I think of playlists, the first thing that comes to mind are  
commercials. Some video sites show ad or promotion clips before and/ 
or after the main video. I imagine they'd see that as a use case.  
It could also be used to create medleys of several smaller clips,  
although it might not be a big need.


In that case I would really like a "skip to next video in playlist"  
button!


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Video proposals

[Nicholas Shanks]

Discussion on aspect ratio:


You may want to consider aspect ratio too:  ratio="preserve" being
default, ratio="1.333" could indicate 4:3 or get tricky and accept
"16:9" for precision reasons.


Wouldn't we simply always want to use the authored size?

Do videos encode what size they are best displayed in?  I hate
entering height and width for images.


The reason I requested this is because:

1) If you specify both a width and a height, video content that  
doesn't match that gets distorted.
2) If you want an element to have a fixed width, but variable height  
dependant on the aspect of the video, or fixed height and variable  
width, yet still have a non-zero initial value for the variable  
parameter (so that the  element occupies some screen area),  
you cannot achieve this without distorting the final image by setting  
both width and height.
3) Thinking about it more, the ratio should be explicitly advisory  
and only valid until the downloaded video can provide it's own width  
and height.


I envisage:


Some content below the video

Then, when the video is finally downloaded and it's inherent  
dimensions (and thus aspect ratio) are known, re-layout can occur if  
the aspect values don't match, but more importantly can be avoided if  
they do.


The width given is an integer number of CSS pixels, by providing an  
aspect ratio, the UA can calculate the resultant height in device  
pixels without the user having to provide a height and associated  
rounding errors (or plain mistakes). The example above has an  
irrational height.


4) Only two of {width, height, aspect} can be specified on any video  
element.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Video proposals

[Magnus Kristiansen]

On Fri, 16 Mar 2007 04:39:07 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:


ON PLAYLISTS

On Mon, 30 Oct 2006, Shadow2531 wrote:


The handler should also support some type of playlist like
.


On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:


#3: Playlists.  (A single video file just won't cut it.)


These were the only requests for playlists. Could you elaborate on the  
use

cases for playlists? What are the needs for playlists?


When I think of playlists, the first thing that comes to mind are  
commercials. Some video sites show ad or promotion clips before and/or  
after the main video. I imagine they'd see that as a use case. It could  
also be used to create medleys of several smaller clips, although it might  
not be a big need.


--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."

Re: [whatwg] Video proposals

[Matthew Raymond]

Benjamin West wrote:
> On 3/15/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>>> .loop, .startpos
>>> loop = false | true
>>> autostart = true | false
>>> startpos = 0 | specified pos
>>
>> Could you elaborate on the use cases for these?
>
> Can't these be done in script?

   Those attributes are basic values you'd want to use to initialize the
video. For those that don't know Javascript very well and just want a
video to play a certain way right away, it would be a real pain to only
have access to these properties via scripting. Besides, I can't see the
author wanting to set |autostart| and |startpos| dynamically, as they
are clearly intended to be used when the page is loading. (The |loop|
attribute might be set dynamically, but I can see situations where one
would want the video to play in the background in a continuous loop from
the moment the page is loaded. Granted, most of those uses are
presentational.)

Re: [whatwg] Video proposals

[Håkon Wium Lie]

Also sprach Laurens Holst:

 > > http://www.whatwg.org/specs/web-apps/current-work/#video

 > Correct me if I

Re: [whatwg] Video proposals

[Benjamin West]

(oops, this is a re-send of an email I sent only to Ian Hixie.  I keep
pressing the wrong reply button :-(  )

On 3/15/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

In the meantime, here's replies to the comments I got.

Wow.  Nice.



On Wed, 28 Feb 2007, Anne van Kesteren wrote:
> Opera has some internal expiremental builds with an implementation of a
>  element. The element exposes a simple API (for the moment) much
> like the Audio() object:
>
>   play()
>   pause()
>   stop()
>
> The idea is that it works like  except that it has special
>  semantics much like  has image semantics. In markup you
> could prolly use it as follows:
>
>  
>
>  ...
>
>HTML5 in BBC News
>  
>
> I attached a proposal for the element and as you can see there are still
> some open issues. The element and its API are of course open for debate.
> We're not enforcing this upon the world ;-)

I have added such an element and its corresponding API (influenced by the
other feedback received) to the specification. Thank you for the proposal
and implementation experience!


What are the events?  I scanned the spec for events:
begin (can this be caught by script? is that what "at the 
element" means?)
progress
stalled
stopped
load
abort

Is this accurate?

I noticed the stop() method is used both to stop playback and to abort
any pending download.  Is this a good idea?  Wouldn't it be simpler to
add abort() to explicitly stop the download?

Are timeout's guaranteed to be in sync with the video?  For example:
// assume myvid.position = 0;
myvid.play();
myvid.setTimeout('alert(myvid.position);', 10);

What happens?

I have a hunch most authors will care more about time till the end
than time since the 0.  I don't have any evidence for this, and don't
know why I think it.  Except for...


ON PLAYLISTS

On Mon, 30 Oct 2006, Shadow2531 wrote:
>
> The handler should also support some type of playlist like
> .

On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
>
> #3: Playlists.  (A single video file just won't cut it.)

These were the only requests for playlists. Could you elaborate on the use
cases for playlists? What are the needs for playlists?


I don't see a need for this, if other things are reasonable, we can
implement continuous playback or a playlist using something like.

// could make a microformat to describe playlists... perhaps XOXO with an
// extra classname.  playlist could be parsed from the dom, or provided
// via some other mechanism.
var playlist = ['one', 'two', 'three'];
var current = 0;
var mainVideo = document.getElementById('myvideo');
var dummyVideo = document.getElementById('dummyvideo');
window.onload = function() {
 mainVideo = playlist[current];
};

// would *REALLY* prefer a finished event or something to tell the
difference between
// the user watching the video completely, and it having stopped, and
script or the
// user pressing a stop button.
// because otherwise, the code to tell if we've stopped looks something like:
video.stopEvent = function(callback) {
 // not sure these apply()'s do what I think they would do.
 callback = function(this) {
   if(this.state == PLAYING) {
 return callback.apply(this);
   }
 };
 setTimeout(callback.apply(this), video.length - video.position);
};
// which is pretty undesirable, as it still doesn't always do what you
would expect.
// (eg. if the time to finish changes because of a seek, or the video's src
// changes or something...)
// so assuming a stopped event existed...
mainVideo.finished = onFinishedMain;

onFinishedMain = function() {
 // uh... does the cache kick in, or do we need to clone and delete? :->
 mainVideo.src = dummyVideo.src;

 // uh.. if the src changes, does my event stick, or do I need to reassign it?
 //mainVideo.finished = onFinishedMain;
current++;

}

function queueNextVideo() {
 if(nearlyComplete(mainVideo) {
   // have the next one start downloading...
   dummyVideo.src = playlist[current+1];
 }
 if(current < playlist.length) {
   setTimeout(queueNextVideo, mainVideo.length*.20);
 }
}

function nearlyComplete(video) {
 if(video.state == PLAYING) {
   if(video.position/video.length > .80) {
 return true;
   }
 }
 return false;
}

Something like that would be pretty common, I think.  I suspect most
script authors will want to know when a video is nearing completion,
and when the user has finished watching it.  It's also a common
technique for authors to buffer images in the background, and then
swap them in when needed.  (BTW, one thing that is really annoying is
not knowing when resources [like images or scripts] failed to load.)

OHHH I see, there is a "played" range, and that you can use /that/ to
tell if the user has seen the whole thing or not...  still seems a bit
tricky to figure it out, if all you want is an event for "we've just
finished watching the whole thing now, thanks!"

What happens to the played range after we use seek()?



ON FEATURES

On Mon, 30 Oct 2006, Charles Iliya Krempeaux

Re: [whatwg] Video proposals

[Karl Dubost]

Le 16 mars 2007 à 12:39, Ian Hickson a écrit :
Wow, what a lot of feedback on video! I've added a  element,  
with
basic features, but really what we need is feedback from video  
experts.


http://www.whatwg.org/specs/web-apps/current-work/#video

--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***