cool.

comments inline:


On Oct 13, 2014, at 4:32 PM, Brion Vibber <bvibber@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia