Last modified: 2014-01-03 15:53:04 UTC
Created attachment 6558 [details] Patch that prevents <audio> and <video> tags from being used, if the browser does not have support for the codecs used in a particular stream As HTML5 audio and video tags do not explicitly guarantee a set of supported codecs, it is not sufficient to check for the availability of the tags and the MIME type of the container. The JavaScript code should also check whether the codecs inside of the container are supported I attached a patch that fixes this problem.
AFAIK we're not doing this right now since implementations in the wild don't support it yet. Has this been resolved with Safari etc?
The patch leaves the detection of <audio>/<video> tag support alone. So, that part should continue to work as is. It then adds additional detection for codecs, but only does so if canPlay() is available and if it doesn't throw an exception. Hopefully, this does the right thing in Safari. I just found myself a MAC and installed Safari and the Ogg codec on it. As far as I can tell, Safari behaves exactly the same independent of whether my patch is enabled or not. Furthermore, the patch was tested with a recent development version of Chrome and works correctly there. Chrome currently doesn't support FLAC and Speex in Ogg containers.
You know, this was the feature that I suggested and campaigned for on the whatwg mailing list. It's nice to see it's made its way into the browsers now. The capability test in the patch, "if (dummyvid.canPlayType)", should be sufficient to deal with browsers that don't support it.
Do you have any estimate on when this change could find its way into the official release? And more interestingly, when it would typically go life on Wikipedia? I have to admit that I am blissfully unaware of the typical release cycle for Wikipedia... This problem is currently affecting Chrome, as (at least initially) it will only support Vorbis in Ogg containers. And as one of the developers of Chrome (for Linux) I have a vested interest in making the browser work properly on Wikipedia. If there is anything else I can to do help with testing or writing additional code, please let me know.
Created attachment 6635 [details] Same feature refactored and updated The JS in the patch wasn't properly factored out, there was some duplicated code with the Safari XiphQT checks. I've fixed that and updated the patch to a base of r57369. There remains quite a bit of confusion in the UI when the user selects the <video> player but the browser does not support the codec in the file. The player will appear to be selectable but won't do anything when selected, a random alternate player will be used instead. This should really be dealt with properly, and I'm reluctant to accept this feature as is. The UI would certainly be less confused if, like in Michael's Safari code, we just blacklisted any browser that didn't support Theora. But I suspect our friendly Chrome developer wouldn't like that solution. This version of the patch has not been properly tested.
OggHandler was replaced by TimedMediaHandler. Is this bug resolved–wontfix?
The OggHandler extension is not under active development anymore. It is unlikely that there will be any further active development. OggHandler has been superseded by TimedMediaHandler: http://www.mediawiki.org/wiki/Extension:TimedMediaHandler Please use TimedMediaHandler instead. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if either anyone takes the responsibility for active development of OggHandler again; or move this bug report from the "OggHandler" to the "TimedMediaHandler" component in Bugzilla if the same problem still happens when using TimedMediaHandler. Thanks.
