On Wed, Oct 15, 2014 at 10:30 AM, Michael Dale <mdale(a)wikimedia.org> wrote:
On Oct 13, 2014, at 4:32 PM, Brion Vibber <bvibber(a)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