Re: still image on <video>

Ben Boyle wrote:
> 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.

Can we (authors) have

img="posterframe:sample.mp4"
or img="sample.jpg" height= width= (where height and width of image and video
should be the same)

audio=sample.mp3 or audio=sample.wav or audio="sample.ogg" (ogg audio could
require a flac or vorbis decoder could be streaming
<http://lists.w3.org/Archives/Public/public-html/2007Oct/0097.html>)

video=sample.mp4 or video="sample.ogg" (requires theora decoder) or video=sample.mov

Could video and audio just be an attributes of object?

I like using the right mouse button to show properties - play or download audio,
play or download video, sample audio/video (say play 1 minute or low quality 
version advise user of size unless streaming)

Marghanita
> 
> 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
>>
>>


-- 
Marghanita da Cruz
http://www.ramin.com.au
Phone: (+61)0414 869202

Received on Thursday, 11 October 2007 23:16:07 UTC