W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] video tag javascript library for contemporary browsers

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Thu, 16 Oct 2008 12:15:39 -0400
Message-ID: <6b9c91b20810160915j7a7f913dma7b7997a38a3d20a@mail.gmail.com>
On 10/16/08, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Thu, Oct 16, 2008 at 5:03 PM, Michael A. Puls II
> <shadow2531 at gmail.com>wrote:
>> Maybe <video> needs something (currently. maybe not in a few years)
>> like a wmode param where the author can suggest (and the user can
>> ultimately override if necessary) whether it's accelerated or not.
>> Then, a site might provide <video wmode="something"> all  by itself on
>> a separate page as an alternative to the normal
>> all-cpu-driven-can-be-overlayed  version.
> No, that is definitely not the right way to go.
> We could actually detect situations where an overlay could be used, and use
> it automatically, if that makes sense. I'm not sure it does.


That would be cool to do it automatically. But, does using an overlay
guarantee that other elements can't be placed on top of it? If so,
then only the author of the page would know (by testing) that nothing
needs to go over the top of it. Or, is it trivial to code the browser
to look at the css applied on the page (and any behavior that might
later apply css) to determine that an overlay won't interfere with any
thing? If not, it seems like doing it automatically might break
things. But, like you said "if that makes sense".

Just, fwiw, when a video playing in flash doesn't play at full speed
and smoothly, there are 4 main steps to fix that.

1. Make sure that wmode="window" (the default) is set. 'transparent'
and 'opaque' hurt performance. I think there's a new value for it
though that's supposed to help performance.

2. Make sure the video is shown at its original size. Scaling it hurts
performance. Some flash players allow the user to adjust this so the
video isn't scaled.

3. Pause the video and let it download all the way before watching.
This seems to work because the network code and the video renderer are
not fighting over the cpu and causing the video to download really
slow or not at all. (Maybe that's some type of npapi threading issue
or something)

4. Lower the quality.

<video> is not flash though, but those are some things to think about
(if you haven't already of course).

> Let us work on
> general video performance first and if we can't get close to VLC that way,


> then we'll see if overlay tricks are needed.


> We know we can improve
> performance quite a bit already without fundamental changes (e.g. we don't
> use MMX on Windows yet, and we're making some big improvements to the
> organization of our Ogg decoder).

Sounds promising.

Received on Thursday, 16 October 2008 09:15:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC