As far as I remember, one of the primary reasons the Media links are
used is for "inline" audio fragments:
If you properly look at that use case, it comes down to the fact that
there is not TMH UI that tools to this use case, So I agree with Brian
on this, solve the UI problem and you will likely solve the usage of
direct media links in content pages.
DJ
On Wed, Jul 30, 2014 at 5:08 AM, Brian Wolff <bawolff(a)gmail.com> wrote:
[responded inline]
On 7/26/14, Brion Vibber <bvibber(a)wikimedia.org> wrote:
Today I took a stab at combining ogv.js
JavaScript-based media playback
with MobileFrontend by adding a loader shim to TimedMediaHandler on the
'mobile' target (the rest of TimedMediaHandler's desktop support code is
not loaded, so the UI is mobile-specific but very bare-bones).
Demo page can now play back audio and video in iOS 7's Safari in mobile
mode as well as desktop mode:
*
https://ogvjs-testing.wmflabs.org/
The TMH+ogv.js patch in progress:
*
https://gerrit.wikimedia.org/r/#/c/145756/
The mobile loader code checks for any <audio> or <video> elements and asks
them if they canPlayType() on any of their available sources, so it only
loads if non-native playback is actually required. (So for instance it
disengages on Android Chrome which can play Ogg Vorbis audio and WebM
video, or in theory in Safari if you have locally enabled MP4/H.264 files.)
It needs more work to check for browser compatibility, sufficient
JavaScript engine speed, etc, but I find it encouraging that it works so
far. :)
Some thoughts and questions:
* Currently ogv.js gets loaded if any audio/video elements are present that
require it to play, even if they don't get played. I can delay the loading
to when 'play' is clicked fairly easily.
* [[Media:]] or other direct file links, often used for pronunciation
markers in Wikipedia articles, are not picked up by this system. Need to
extend things a bit to detect clicks on such links and display a player
instead of just downloading the file. Same problem occurs in Safari and IE
on desktop mode.
Perhaps we should just tell users to stop using "Media:" links. Media
is supposed to be a direct link to a file. Linking to the image
description page would seem more appropriate in such a case (Ideally
with autoplay, although allowing users/potential vandals to autoplay
files seems like a giant bag of worms...).
To throw out a crazy idea, perhaps we should have a new parameter for
TMH files, something like [[File:Foo.ogg|displaylink|Some text here]],
which outputs "Some text here" as a link, and then launches the player
using js magic when somebody clicks on the link.
* Should we show the video in an overlay like the
mobile media viewer for
images, instead of playing inline? This is a good place to add additional
controls to reach file info details, as with images. If so should I try to
extend the same overlay code in MF or create a near-lookalike that lives in
TMH?
There's an overlay viewer in MF? I don't think that's ever popped up
on my phone.
Currently we have an overlay dialog on desktop for videos where the
thumb is < 800px wide. Personally I think on desktop we should reduce
that to something like <400px wide, as for a big thumb I think most
people expect inline playing unless the thumb is really tiny (and the
desktop overlay thing isn't actually that pretty imo). However on
mobile it may make sense to use a more full (perhaps almost
"full-screen") overlay. But I think either approach is fine for
mobile.
* If so, that should probably be used for *all*
mobile browsers, using the
native playback when available instead of loading ogv.js...
Consistency is nice. However, at this stage I'd settle for working
video everywhere :)
* Should we have a manual resolution switcher, as
on desktop? (Controlling
source selection via code could also fix a problem with Android being
unable to play Ogg Theora videos, to force it to WebM which does work
natively.)
Doesn't android automatically play the first <source> it knows how to
when left to its own devices? Thus skipping the ogg sources?
* On iOS, should the source selector offer to launch higher-res and WebM
videos in the external VLC app? 360p is about the limit of good performance
in ogv.js on current A7-based iOS devices, and slower models max out at
160p if they can even handle that.
That seems like the sort of thing that would be a nice feature, but of
minor importance.
This is all very awesome. Thanks for working on this.
--bawolff
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia