Michael A. Puls II
shadow2531 at gmail.com
Thu Oct 16 09:15:39 PDT 2008
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
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).
More information about the whatwg