89764 2012-06-22 09:39:00 -0700 Prefer PluginDocument over MediaDocument 2022-07-12 11:37:36 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 0 dsd webkit-unassigned ahmad.saleem792 ap bfulgham darin eric.carlson jer.noble philn pnormand rniwa oldest_to_newest 655511 0 dsd 2012-06-22 09:39:00 -0700 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. 655515 1 149043 dsd 2012-06-22 09:44:16 -0700 Created attachment 149043 Patch 655533 2 eric.carlson 2012-06-22 10:00:58 -0700 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. 655547 3 dsd 2012-06-22 10:14:52 -0700 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? 655574 4 darin 2012-06-22 10:42:24 -0700 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. 655594 5 dsd 2012-06-22 10:55:32 -0700 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 655608 6 darin 2012-06-22 11:03:46 -0700 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. 655688 7 dsd 2012-06-22 12:27:08 -0700 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. 655701 8 eric.carlson 2012-06-22 12:54:00 -0700 (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. 1882439 9 ahmad.saleem792 2022-07-12 11:30:51 -0700 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! 1882442 10 philn 2022-07-12 11:37:36 -0700 NPAPI support was removed. 149043 2012-06-22 09:44:16 -0700 2012-06-22 10:01:16 -0700 Patch bug-89764-20120622124415.patch text/plain 3034 dsd SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEyMTAyOSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIzIEBACisyMDEyLTA2LTIyICBEYW5pZWwg RHJha2UgIDxkc2RAbGFwdG9wLm9yZz4KKworICAgICAgICBQcmVmZXIgUGx1Z2luRG9jdW1lbnQg b3ZlciBNZWRpYURvY3VtZW50CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD04OTc2NAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgor CisgICAgICAgIFByb3ZpZGUgdGhlIHVzZXIvYWRtaW4gd2l0aCB0aGUgYWJpbGl0eSB0byBzdXBw bHkgdGhlaXIgb3duCisgICAgICAgIG1lZGlhIHBsYXliYWNrIHBsdWdpbiBlLmcuIGZvciBtZWRp YSBvcGVuZWQgdmlhIGFuIDxhPiBsaW5rLAorICAgICAgICBjb250aW51aW5nIHRvIGZhbGxiYWNr IG9uIHdlYmtpdCdzIGludGVybmFsIG1lZGlhIHN1cHBvcnQgaWYKKyAgICAgICAgbm8gcGx1Z2lu IGlzIGF2YWlsYWJsZS4KKworICAgICAgICBUaGlzIGlzIGJlY2F1c2UgYSBwbHVnaW4gbWF5IGJl IG1vcmUgYXBwcm9wcmlhdGUgdGhhbiB0aGUgaW5idWlsdAorICAgICAgICBzdXBwb3J0LiBJbiBP TFBDJ3MgY2FzZSwgdGhlIHBsdWdpbiBpcyB1c2VkIHRvIHByb3ZpZGUgaGFyZHdhcmUKKyAgICAg ICAgYWNjZWxlcmF0ZWQgdmlkZW8gcGxheWJhY2suCisKKyAgICAgICAgKiBkb20vRE9NSW1wbGVt ZW50YXRpb24uY3BwOgorICAgICAgICAoV2ViQ29yZTo6RE9NSW1wbGVtZW50YXRpb246OmNyZWF0 ZURvY3VtZW50KToKKyAgICAgICAgUmVvcmRlcmVkIGNvZGUgdG8gdHJ5IFBsdWdpbkRvY3VtZW50 IGJlZm9yZSBNZWRpYURvY3VtZW50LgorCiAyMDEyLTA2LTIyICBQZXRlciBCZXZlcmxvbyAgPHBl dGVyQGNocm9taXVtLm9yZz4KIAogICAgICAgICBbQ2hyb21pdW1dIERpc2FibGUgYysrMHggY29t cGF0aWJpbGl0eSB3YXJuaW5ncyBpbiBKYXZhU2NyaXB0Q29yZS5neXAgd2hlbiBidWlsZGluZyBm b3IgQW5kcm9pZApJbmRleDogU291cmNlL1dlYkNvcmUvZG9tL0RPTUltcGxlbWVudGF0aW9uLmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9kb20vRE9NSW1wbGVtZW50YXRpb24uY3Bw CShyZXZpc2lvbiAxMjEwMjkpCisrKyBTb3VyY2UvV2ViQ29yZS9kb20vRE9NSW1wbGVtZW50YXRp b24uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC00MDYsMTQgKzQwNiw2IEBAIFBhc3NSZWZQdHI8RG9j dW1lbnQ+IERPTUltcGxlbWVudGF0aW9uOjoKICAgICBpZiAoSW1hZ2U6OnN1cHBvcnRzVHlwZSh0 eXBlKSkKICAgICAgICAgcmV0dXJuIEltYWdlRG9jdW1lbnQ6OmNyZWF0ZShmcmFtZSwgdXJsKTsK IAotI2lmIEVOQUJMRShWSURFTykKLSAgICAgLy8gQ2hlY2sgdG8gc2VlIGlmIHRoZSB0eXBlIGNh biBiZSBwbGF5ZWQgYnkgb3VyIE1lZGlhUGxheWVyLCBpZiBzbyBjcmVhdGUgYSBNZWRpYURvY3Vt ZW50Ci0gICAgLy8gS2V5IHN5c3RlbSBpcyBub3QgYXBwbGljYWJsZSBoZXJlLgotICAgIERPTUlt cGxlbWVudGF0aW9uU3VwcG9ydHNUeXBlQ2xpZW50IGNsaWVudChmcmFtZSAmJiBmcmFtZS0+c2V0 dGluZ3MoKSAmJiBmcmFtZS0+c2V0dGluZ3MoKS0+bmVlZHNTaXRlU3BlY2lmaWNRdWlya3MoKSwg dXJsLmhvc3QoKSk7Ci0gICAgaWYgKE1lZGlhUGxheWVyOjpzdXBwb3J0c1R5cGUoQ29udGVudFR5 cGUodHlwZSksIFN0cmluZygpLCAmY2xpZW50KSkKLSAgICAgICAgIHJldHVybiBNZWRpYURvY3Vt ZW50OjpjcmVhdGUoZnJhbWUsIHVybCk7Ci0jZW5kaWYKLQogICAgIC8vIEV2ZXJ5dGhpbmcgZWxz ZSBleGNlcHQgdGV4dC9wbGFpbiBjYW4gYmUgb3ZlcnJpZGRlbiBieSBwbHVnaW5zLiBJbiBwYXJ0 aWN1bGFyLCBBZG9iZSBTVkcgVmlld2VyIHNob3VsZCBiZSB1c2VkIGZvciBTVkcsIGlmIGluc3Rh bGxlZC4KICAgICAvLyBEaXNhbGxvd2luZyBwbHVnLWlucyB0byB1c2UgdGV4dC9wbGFpbiBwcmV2 ZW50cyBwbHVnLWlucyBmcm9tIGhpamFja2luZyBhIGZ1bmRhbWVudGFsIHR5cGUgdGhhdCB0aGUg YnJvd3NlciBpcyBleHBlY3RlZCB0byBoYW5kbGUsCiAgICAgLy8gYW5kIGFsc28gc2VydmVzIGFz IGFuIG9wdGltaXphdGlvbiB0byBwcmV2ZW50IGxvYWRpbmcgdGhlIHBsdWctaW4gZGF0YWJhc2Ug aW4gdGhlIGNvbW1vbiBjYXNlLgpAQCAtNDIyLDYgKzQxNCwxNCBAQCBQYXNzUmVmUHRyPERvY3Vt ZW50PiBET01JbXBsZW1lbnRhdGlvbjo6CiAgICAgaWYgKGlzVGV4dE1JTUVUeXBlKHR5cGUpKQog ICAgICAgICByZXR1cm4gVGV4dERvY3VtZW50OjpjcmVhdGUoZnJhbWUsIHVybCk7CiAKKyNpZiBF TkFCTEUoVklERU8pCisgICAgIC8vIENoZWNrIHRvIHNlZSBpZiB0aGUgdHlwZSBjYW4gYmUgcGxh eWVkIGJ5IG91ciBNZWRpYVBsYXllciwgaWYgc28gY3JlYXRlIGEgTWVkaWFEb2N1bWVudAorICAg IC8vIEtleSBzeXN0ZW0gaXMgbm90IGFwcGxpY2FibGUgaGVyZS4KKyAgICBET01JbXBsZW1lbnRh dGlvblN1cHBvcnRzVHlwZUNsaWVudCBjbGllbnQoZnJhbWUgJiYgZnJhbWUtPnNldHRpbmdzKCkg JiYgZnJhbWUtPnNldHRpbmdzKCktPm5lZWRzU2l0ZVNwZWNpZmljUXVpcmtzKCksIHVybC5ob3N0 KCkpOworICAgIGlmIChNZWRpYVBsYXllcjo6c3VwcG9ydHNUeXBlKENvbnRlbnRUeXBlKHR5cGUp LCBTdHJpbmcoKSwgJmNsaWVudCkpCisgICAgICAgICByZXR1cm4gTWVkaWFEb2N1bWVudDo6Y3Jl YXRlKGZyYW1lLCB1cmwpOworI2VuZGlmCisKICNpZiBFTkFCTEUoU1ZHKQogICAgIGlmICh0eXBl ID09ICJpbWFnZS9zdmcreG1sIikKICAgICAgICAgcmV0dXJuIFNWR0RvY3VtZW50OjpjcmVhdGUo ZnJhbWUsIHVybCk7Cg==