<video> feedback

On Tue, 10 Mar 2009, Simon Pieters wrote:
>
> Currently the spec says to fire an error event in the Waiting step of 
> the resource selection algorithm:
> 
> # Waiting: Set the error attribute to a new MediaError object whose code
> # attribute is set to MEDIA_ERR_NONE_SUPPORTED.
>    -- http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm
> 
> This means that given the following:
> 
>   <video>
>    <!-- network pause -->
>    <source src=1>
>    <!-- network pause -->
>    <source src=2>
> 
> Consider that 2 would be of a supported format and 1 is not -- you would 
> get two error events with error.code being MEDIA_ERR_NONE_SUPPORTED. 
> This seems suboptimal, especially since it would depend on the network.

You wouldn't get an event before 1 (in the first network pause), because 
the algorithm waits for there to be a <source> (or src="") before firing 
any events at all.

You would get one or two events depending on the network in this case:

  <video>
    <source src=1>
    <!-- network pause -->
    <source src=2>
  </video>

If both videos are unsupported, you will get two events if the network 
pauses, and just one if it doesn't.


> It seems more predictable and useful to fire an error event at the media 
> element at the point you find a <source> (or <video src>) that is not 
> supported. (Also more consistent with <img> -- without a src="" you 
> don't get an error event.) error.code could say MEDIA_ERR_NOT_SUPPORTED 
> instead, and the MediaError interface could gain another attribute (say 
> error.src) that is set to the value of .currentSrc at the time the error 
> occurred. (Since the algorithm is async authors can't just look at 
> .currentSrc since it might have changed before the event handler looks 
> at it.)

The idea of the error event in this particular case is to let the page 
show a message, which would be overridden by the loadedmetadata event's 
handler, or some such. I suppose we could just fire an event for each 
unsupported resource, though... what are the other use cases?


On Tue, 10 Mar 2009, Simon Pieters wrote:
>
> The HTML <img> element always stretches images and <video> always 
> preserves aspect ratio. HTML5 doesn't restrict which formats <video> may 
> support.
> 
> Currently both WebKit and internal builds of Opera can show images in 
> <video>. (WebKit seems to render some other formats, too, e.g. fonts.)
> 
> It is very hard to achieve the effect of preserving aspect ratio of 
> images using <img> and CSS while having a (maximum) width and height. 
> Therefore there's a risk that authors will start to abuse <video> for 
> this effect.
> 
> Two things come to mind for preventing this abuse:
> 
>   1. Make images not work in <video> even though the media backend 
>      support them
>   2. Implement http://dev.w3.org/csswg/css3-page/#propdef-image-fit
> 
> We're considering both... (2) would also solve the use case for which 
> the pixelratio="" attribute was intended.

I think this is something to address at the CSS level.

In general I wouldn't recommend supporting non-video or audio formats in 
<video> and <audio>, though. That seems weird.


On Thu, 19 Mar 2009, Simon Pieters wrote:
> 
> As currently specced it seems like the load event could be delayed 
> indefinitely if the UA decided to stall the download of the video:
> 
> Step 2 of the resource selection algorithm sets delaying-the-load-event 
> flag to true.
> 
> Step 5.2 invokes the resource fetch algorithm.
> 
> Step 3 of the resource fetch algorithm allows the UA to stall the 
> download.
> 
> Is the above analysis correct?

Seems so.


> Surely we don't want to delay the load event indefinitely?

Fair enough. I've changed the spec to allow intentional stalls to unblock 
the load event delaying.


> Is the intent that UAs have to download enough video data to know the 
> dimensions of all videos before sending the load event?

Yes, but if the UA isn't going to try loading the file, it seems 
pointless to wait, I agree.


> On a related note, I think Opera doesn't download images that are 
> display:none or visibility:hidden or maybe have 0 height and width. Such 
> images don't delay the load event. Maybe the spec should allow this?

That seems incompatible with Web content.


On Fri, 20 Mar 2009, Robert O'Callahan wrote:
> 
> Perhaps the spec should be changed to suggest that UAs not stall the 
> download while the element is delaying the load event ... although it's 
> kind of obvious if you ask me.

Since stalling now stops delaying the load event, this is now moot.


> > We were thinking that if there's a poster image then when the poster 
> > image has loaded we can stop delayig the load event without 
> > downloading any video data at all (even though the video dimensions 
> > might be different -- if they are different then that's the author's 
> > fault).
> 
> That sounds reasonable to me. We'd want the spec to say that while the 
> poster image is being displayed, the intrinsic dimensions of the video 
> element are the dimensions of the image.

This is already the case.


> We'd also want the spec to say that if there is a poster image, then we 
> stop delaying the load event when the poster image has finished loading.

I've made the poster frame delay the load event.


On Fri, 20 Mar 2009, Simon Pieters wrote:
> > 
> > That sounds reasonable to me. We'd want the spec to say that while the 
> > poster image is being displayed, the intrinsic dimensions of the video 
> > element are the dimensions of the image.
> 
> Even if you know the dimensions of the video? Wouldn't you want to 
> resize to the video's real dimensions as soon as possible? (The spec 
> allows the poster image to be shown even when video data is available.)

The video size overrides the poster size if both are available.


On Sat, 21 Mar 2009, Robert O'Callahan wrote:
> 
> I don't think it makes much sense to start scaling the poster when the 
> video dimensions become available.
> 
> Normally authors should ensure that the poster is the same size as the 
> video. If they don't, then I think we should change the size of the 
> video when we switch from displaying the poster to displaying the video.

I'm not sure what you mean here. Surely the most important thing is to 
render the video at its native size in the absence of an override; the 
poster frame shouldn't affect this.


On Fri, 20 Mar 2009, Simon Pieters wrote:
> 
> Consider the following SVG image:
> 
>   <svg xmlns="http://www.w3.org/2000/svg" viewBox="-1 -1 2 2">
>    <circle r="1"/>
>   </svg>
> 
> It has an intrinsic ratio but no intrinsic dimensions.
> 
> Now reference that image in <video poster>. What should the size of the video
> element be?

300x150, with the poster frame rendered at 150x150 centered in the frame, 
assuming there is no video.

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

Received on Wednesday, 25 March 2009 22:12:38 UTC