As far as I remember, one of the primary reasons the Media links are used is for "inline" audio fragments: https://en.wikipedia.org/wiki/Template:Audio
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 <[email protected]> wrote: > [responded inline] > > On 7/26/14, Brion Vibber <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia _______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
