Bug 89764 – Prefer PluginDocument over MediaDocument

• Component: DOM
• Status: RESOLVED INVALID

[Daniel Drake]

Currently, WebCore/dom/DOMImplementation.cpp createDocument() prefers MediaDocument over PluginDocument for a file loaded by clicking on a link such as <a href="foo.ogg">link</a>

For OLPC, this is not ideal: we have already-deployed content shipped in this way, but the inbuilt WebKit media support does not use Xv hardware acceleration (and seems to be moving even further away from that, towards OpenGL). This means that the video playback is so choppy that videos are un-watchable.

It also seems that in the general case, there would be some value in letting the user/deployer have power here to define which technologies are used for media playback.

Preferring PluginDocument over MediaDocument, a simple reordering of the code, would solve such issues in the same way that plugins can be used for SVG. Would this be acceptable? Patch coming up.

[Daniel Drake]

Created attachment 149043 [details]
Patch

[Eric Carlson]

The general trend on the Web to use <video> *instead of* <embed> for embedded video, so I think this is absolutely the wrong approach. This change may improve the performance of <a href=myvideo>, but it does nothing for the far the more common case of <video src=myvideo>, so how can it possibly make sense?

If <video> is slower than a plug-in on OLPC, move the logic from the plug-in down into the media element.

[Daniel Drake]

OLPC has never had support for <video> and <audio>, so our projects have built up content around <a>. Thats why it makes sense for us - we're breaking a lot of our existing content with our move to webkit :( <a> *is* the common case in our corner of the world.

But I can see your point about <video> being the way forward, at least in the wider view of things.

I did not get a very encouraging response about adding Xv acceleration into the inbuilt video code - I was told it will move to OpenGL, which would mean we would be left with absolutely no webkit-internal video support on our platform, we don't have OpenGL. Anyway, I will poke a bit more with your response in mind.

If I don't make progress on that track, would you consider a similar patch to the one posted here, but controlled by a runtime configuration option, off by default?

[Darin Adler]

Have OLPC engineers been making other contributions to WebKit? Generally we don’t welcome a new contribution that is simply adding a specific option or tweak for their use of WebKit without other contributions.

[Daniel Drake]

Yes, we have, but not a huge amount - we're new here :)
So far we have contributed:

bug #87283 [GTK] run-file-chooser signal for WebKit1
bug #87687 Check for GTK2/GTK3 symbol mismatch earlier
bug #84149 [GTK] Enable back double buffering on WebKitWebView to fix flickering

[Darin Adler]

Before we add this feature for OLPC, we should think this through a bit more:

Which clients will want this? I suppose the answer is “platforms where plug-ins have superior support for types that are also handled by built-in media machinery”. I’m not sure this is happening on a lot of platforms.

If we really do need it, we can do this with a compile time switch. The name should somehow express the “built-in media is assumed to be not as good as plug-in handling of same types” I suppose.

Maybe it’s the other platforms that are strange, where the plug-ins are old so they handle types that are better handled by the built-in media machinery.

[Daniel Drake]

Regarding improving the <video> handling to use Xv hardware acceleration:

After some discussion, this seems unlikely to happen. 

The existing maintainer would not be willing to maintain such code, and is not really keen on the idea of a co-maintainer looking after it either.

It also seems like it would be impossible: <video> elements need to blend with the page, can have CSS transformations applied, etc. However, Xv does not support this, and applying transformations and so on is not realistic because Xv must render to its own X window.

If we are going to land something to fix this that is of use to OLPC, it needs to either be the default, or configurable at runtime. We use distribution packages from Fedora so changing compile time options is unfortunately not an option.

Sorry if this is a pain - but it seems like <video> is powerful enough that it mandates the use of OpenGL or similar for good performance, and we're in the process of moving around 2 million users to webkit on a low-power platform that can't run OpenGL. For this reason it seems most sensible for us to focus on the plugin experience as before.

[Eric Carlson]

(In reply to comment #7)
> Regarding improving the <video> handling to use Xv hardware acceleration:
> 
> After some discussion, this seems unlikely to happen. 
> 
> The existing maintainer would not be willing to maintain such code, and is not really keen on the idea of a co-maintainer looking after it either.
> 
> It also seems like it would be impossible: <video> elements need to blend with the page, can have CSS transformations applied, etc. However, Xv does not support this, and applying transformations and so on is not realistic because Xv must render to its own X window.
> 
> If we are going to land something to fix this that is of use to OLPC, it needs to either be the default, or configurable at runtime. We use distribution packages from Fedora so changing compile time options is unfortunately not an option.
> 
> Sorry if this is a pain - but it seems like <video> is powerful enough that it mandates the use of OpenGL or similar for good performance, and we're in the process of moving around 2 million users to webkit on a low-power platform that can't run OpenGL. For this reason it seems most sensible for us to focus on the plugin experience as before.

If your port has such poor support for the <video> element, why not turn it off?

A MediaDocument will not be created unless your implementation of MediaPlayerPrivate::supportsType says it supports the MIME type, so another options is to have your <video> element only support MIME types not supported by the plug-in.

[Ahmad Saleem]

Can this be closed considering <video> tag is not defect standard to make videos available on the web and this patch was focused on old <a> tag? Thanks!

[Philippe Normand]

NPAPI support was removed.