cool.
comments inline:
On Oct 13, 2014, at 4:32 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
I've gotten some great review feedback from Gilles
on the desktop-web integration of my ogv.js JavaScript & Flash compatibility layers
for Ogg Theora/Vorbis media files -- thanks Gilles!
* libraries:
https://gerrit.wikimedia.org/r/#/c/165477/
* desktop integration:
https://gerrit.wikimedia.org/r/#/c/165478/
These are getting pretty close to ready to land, I think.
I would love to get some review on the mobile overlay I've whipped up as well. This
supports both native WebM playback (Android Chrome, Android Firefox, Firefox OS) and
ogv.js playback (iOS 7/8 Safari).
* mobile overlay:
https://gerrit.wikimedia.org/r/#/c/165479/
* Live demo:
https://ogvjs-testing.wmflabs.org/
A few open questions:
1) Is this the right way to do mobile overlay code? (It's basically a rip of the
existing photo viewer overlay in MobileFrontend, but lives in TimedMediaHandler.) Is the
overlay interface stable enough for other extensions to use it for mobile-specific
features? (I had to make updates for object-model and template things that changed since
this summer.)
2) Is the inline icon too huge/ugly here for audio files? Should it be arranged
differently, or display the player inline instead of as an overlay for audio?
yea the pop-up may not be needed for Audio, or otherwise change the display size of the
player in the popup.
3) Should more controls be added to the overlay's bottom toolbar, such as manual
resolution selection or an 'Open in VLC' link to support HD playback on iOS?
sounds good. I don’t think its possible to know ahead of time if VLC is available, but you
can detect a failure to switch the location to a particular application handler. So a bit
of UI flow would probably have to accompany that.
4) Should we autoplay when opening the overlay, or require a second tap?
Would make sense to auto play, do you need to capture click gestures to initiate audio API
in iOS ?
5) How should we handle devices with no native playback that are either too slow (iOS 6
Safari) or lack necessary features needed for the player (Windows Phone)?
I think we provide a download link today or at least intended to do so. Then its up to the
host machine to have any registered mime handler in browser or otherwise have a handler to
open the downloaded asset.
Current known bugs in the mobile overlay:
* CPU speed check not yet integrated to force to lowest resolution for old iPhones/iPads
(this exists on the desktop integration, just needs to be moved to common code)
* autoplay doesn't seem to work with native playback right now
* seek support ... I guess that is a more generalized issue.
-- brion
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia