Re: still image on <video> (was: width='' and height='' on <video>)

All these options are good, but I support choice for authors.
Precedence should be clearly defined in the spec. I suggest: image
referenced from HTML > poster frame > first frame.

There is a clear benefit for users on limited bandwidth or quotas in
having an image thumbnail downloaded in preference to a video file
that they may choose not to play and thus never need to waste
bandwidth on. What about pages that include multiple videos? Think
"video blogs" and the like. You want to download all those files just
to show thumbnails? Situations like that could benefit from the
explicit image thumbnail approach. In other situations, the
posterframe/first frame sounds excellent. I would like authors to have
the flexibility to choose the most appropriate for their publishing
needs.

As has been pointed out the spec already describes a complex method
for achieving this in markup. Authors can and will do this anyway, but
let's make it simple, as Hakon suggested.

cheers
Ben


On 10/11/07, Dave Singer <singer@apple.com> wrote:
>
> At 11:25  +0200 10/10/07, Håkon Wium Lie wrote:
> >Also sprach Henri Sivonen:
> >
> >  > The <video> element currently lacks width and height attributes on
> >  > the grounds that:
> >  >   1) They'd be presentational.
> >  >   2) YouTube and the like put all videos in the same box.
> >  >   3) Different dimensions are called for different media, so the
> >  > <div><style scoped media='...'> video { width: ...; height: ...; } </
> >  > style><style scoped media='...'> video { width: ...; height: ...; } </
> >  > style><video>...</video></div> would encourage media-independence
> >  > while <video width='...' height='...'>...</video> would not.
> >  >
> >  > And, yet, for *practical* purposes, authors seem to *expect* to have
> >  > width and height attributes at their disposal. (Based on expectations
> >  > voiced on IRC.) I suggest adding width and height attributes to <video>.
> >
> >I support this.
> >
> >While on the subject of pragmatic attributes, I would also like to
> >propose another attribute -- still -- to point to an image that is
> >shown until the video itself is played. The current specification
> >indicates that the first frame of the video should be used for this.
> >Often, the first frame will be black or otherwise not representative
> >for the video that follows.
>
> I certainly don't think we should mandate the
> first frame, agreed;  QuickTime files even have a
> field "poster time" which tells QT what time is a
> good one to get a poster still from.
>
> >Being able to explicitly set a still image
> >is a basic function in my DVD recorder; this is very useful as the
> >first frame of my home video snippets are often blank. Wikimedia have
> >started using the <video> element on their pages, but they start out
> >as <img> elements:
> >
> >   http://commons.wikimedia.org/wiki/Category:Video
> >
> >That is, they don't instantiate the <video> element until the user has
> >pressed play. A simple attribute would address their needs:
> >
> >    <video src="foo.ogg" still="foo.jpg">
> >
> >Other names for the attribute could be "img" or "index".
> >
> >>From a performance perspective, it seems simpler to fetch a small
> >still image of fixed length rater than fetching a part of the video
> >file and hoping that a full frame is included.
> >
> >>From an authoring perspective, it seems simpler to use the attribute
> >rather than editing the video file (e.g., by inserting the desired
> >still image in the beginning of the file).
> >
> >I don't think the proposed attribute add any new accessibility issues
> >as the still image -- one must assume -- is taken from within the video.
> >
> >An alternative approach is to specify a time -- say, "3.5s" -- into
> >the video from where the still should be fetched.
> >
> >The HTML5 spec, in section 3.4.6 has an example
> >showing how to encode still images:
> >
> >   <p>
> >    <input type="image" src="frame.png" alt="Play Video"
> >      onclick="   if (nextSibling.load) nextSibling.load();
> >                  disabled = true;
> >                  return false;"
> >    ><video src="video.ogg" controls="" irrelevant=""
> >      onloadedfirstframe="
> >                  irrelevant = false;
> >                  previousSibling.irrelevant = true;
> >                  autoplay = true"
> >      onerror="   parentNode.irrelevant = true;
> >                  parentNode.nextSibling.irrelevant = false">
> >    </video>
> >   </p><p irrelevant="">
> >    Playback unavailable.
> >    <a href="video.ogg">Download Video</a>
> >   </p>
> >
> >This seems complex to me; I'm a simple person.
> >
> >-h&kon (who only speaks for himself on this issue)
> >
> >               Håkon Wium Lie                          CTO °þe(r)ª
> >howcome@opera.com                  http://people.opera.com/howcome
>
>
> --
> David Singer
> Apple/QuickTime
>
>

Received on Thursday, 11 October 2007 11:59:49 UTC