On Wed, Oct 15, 2014 at 10:30 AM, Michael Dale <mdale@wikimedia.org> wrote:

On Oct 13, 2014, at 4:32 PM, Brion Vibber <bvibber@wikimedia.org> wrote:

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. 

*nod* I'm especially thinking it might be nice to start audio playing and keep scrolling/reading without being visually interrupted. But not sure offhand how to squeeze good mobile-y UI into a smaller space than the currently displayed icon.
 


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. 

Yeah, as I recall from our attempt to do this on TimedMediaHandler in the desktop view (before we switched iPads to show the mobile view by default) we basically had to try launching it and see if it fails, then if it failed send the user over to the App Store entry for VLC.
 


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 ? 

I've now got autoplay-after-tap working on iOS Safari (with ogv.js) and Android Chrome/Android Firefox/Firefox OS (native playback). iOS requires a little shuffling to initiate audio but it seems to work. :D



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. 

*nod* will have to devise a nice mobile-friendly download UI...



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)
fixed
 

* autoplay doesn't seem to work with native playback right now
fixed

* seek support ... I guess that is a more generalized issue. 

Yeah, there's two main possibilities for seeking:

1) Buffer the whole file into memory, and allow seeking anywhere within the area that's been buffered.

This sounds awful, but we actually have to buffer the whole file into memory currently on Safari anyway -- I'm kind of banking on most videos being short-ish and loading relatively low-resolution files that aren't too huge. :(

Adding seeking on top of that shouldn't be super hard, I just haven't gotten to it yet.


2) Break up the files into a manifest and small chunks (as with WebM-DASH or Apple's HTTP Live Streaming) that can be individually loaded.

With chunked files, we could seek by jumping to a different chunk and picking up where needed in the stream. This would require more infrastructure work, including generation of files. Sounds hard.


Soo....... I'll probably do number 1) at some point. :)

-- brion