html5 audio tag support
Laurent Savaete
I took a look at piwik stats hoping to figure out a way forward to
include audio in our static audio lesson views without having to rely
on too much javascript.
Based on visits to wiki-babel.org over the past 3 months, and looking
at http://helephant.com/2011/12/29/the-html5-audio-tag/#browser-support
for browser support of <audio>, I'm getting a figure of 75% support,
using one of the formats we provide (ogg is about 67%, and aac another
8%. Each browser supports the audio tag but only with a subset of
formats. And there is no single format that works everywhere).
The big chunk of visits not supporting <audio> are IE8 visitors (10%),
safari 4 (6%) and IE6/7 (4%).
(calculation spreadsheet available for anyone interested :)
(based on wikiotics stats over the past 10 days, support is a bit
higher, around 87%)
So we could simply throw in the audio tags in there, along with a note
to non supported browser users telling them to switch to something
free, and regard that as our contribution towards freeing the world
from infamous browsers :)
The alternative being to rely on jPlayer or equivalent
javascript+flash fallback solutions. From testing on long lessons (FSI
with about 200 rows), pages actually freeze the browser (FF 10 or
chrome 17/18) for about 10 seconds. I expect it would get much worse
with browsers that actually need the flash fallback. So I am very much
against that solution.
As an added use of piwik, we could also make use of the custom
variables system to actually test the browser for support of various
features we need, and get real stats for that. If this is only mildly
interesting for the audio tag support, it could be very helpful for
the html5 audio capture functionnality, to give us an actual view of
how many of our visitors support it, and when to turn of the flash
recorder. (I know it's very early to talk about this, since no stable
release browser even supports that yet, but stats are all about
amassing data, and it's not much work to setup)
Your thoughts are welcome.
Jim Garrison
as much as possible for people using the content, but not if they are
trying to edit it. So if we continue to use the <audio> tag in the
editor, and jPlayer in the different interactions, that should work. If
we choose to do that, we should show an informative note on the "edit"
page. And if we display the full lesson to users on a static page as we
are planning, we could also use the <audio> tag there if it works
better, since having audio functionality is not essential to the
functionality of that page.
In the past I have thought there might be a way to have a single jPlayer
instance on a page, and when we actually need to play a bit of audio,
tell it to load it and play it. I think there are methods in jPlayer
for loading up different audio, but I haven't looked at them in a while.
If it's possible, it would be nice to have an elegant javascript way of
handling this global jPlayer object. I'd of course be willing to help
out with that.
Laurent Savaete
> instance on a page, and when we actually need to play a bit of audio,
> tell it to load it and play it.
looked into it, there is a way to do it indeed. The problem is with
audio formats.
jPlayer supports formats that either the browser supports natively, or
something that flash supports.
So it boils down to "essential formats"
(http://www.jplayer.org/latest/developer-guide/#jPlayer-essential-formats)
either m4a or mp3 (I'm talking audio bits here, not full podcasts).
We only allow ogg or mp4/m4a (which apparently are the same) in the
database, so mp3 is of no concern.
So jPlayer won't make any difference for ogg files (flash doesn't play
the format). That is IE and safari users.
The benefit of jplayer will be for users with a browser that doesn't
natively support m4a/mp4/aac, but can use flash as a fallback, who
could then listen to the audio bits that have been uploaded in that
format. Which means IE6-8 (IE9 supports aac), firefox, chrome/chromium
from what I understand. I'm not sure about mobile platforms, but if
anything works, jPlayer will take care of it.
I've put together a solution which is probably not far from optimal,
using 2 instances of the player (see commit message for details). It's
on gitorious. Page loading time seems a lot more acceptable than the
original solution, even with 100+ items, and will improve further with
server side caching.
There is a bug with chromium (not chrome) and mp4 files for a reason I
can't understand. It simply won't play the files, and will fail
silently for now.
At this point, mp4 should be playable on all browsers barring the bug
above (not sure about IOS though...).
The only way to improve support for ogg now is to convert files to mp4
as they are uploaded or displayed or throw ogg support into jPlayer
flash. We may want to wait a bit on this one...
Laurent Savaete
> as much as possible for people using the content, but not if they are
> trying to edit it.
I put a draft doc page at
https://code.ductus.us/wiki/DuctusBrowserSupport about that. Feel free
to expand it!
Jim Garrison
>> In the past I have thought there might be a way to have a single jPlayer
>> instance on a page, and when we actually need to play a bit of audio,
>> tell it to load it and play it.
>
> looked into it, there is a way to do it indeed. The problem is with
> audio formats.
> jPlayer supports formats that either the browser supports natively, or
> something that flash supports.
> So it boils down to "essential formats"
> (http://www.jplayer.org/latest/developer-guide/#jPlayer-essential-formats)
> either m4a or mp3 (I'm talking audio bits here, not full podcasts).
> We only allow ogg or mp4/m4a (which apparently are the same) in the
> database, so mp3 is of no concern.
>
> So jPlayer won't make any difference for ogg files (flash doesn't play
> the format). That is IE and safari users.
> The benefit of jplayer will be for users with a browser that doesn't
> natively support m4a/mp4/aac, but can use flash as a fallback
i.e., browsers that don't support the html5 <audio> tag in any capacity.
>, who
> could then listen to the audio bits that have been uploaded in that
> format. Which means IE6-8 (IE9 supports aac), firefox, chrome/chromium
> from what I understand. I'm not sure about mobile platforms, but if
> anything works, jPlayer will take care of it.
>
> I've put together a solution which is probably not far from optimal,
> using 2 instances of the player (see commit message for details). It's
> on gitorious. Page loading time seems a lot more acceptable than the
> original solution, even with 100+ items, and will improve further with
> server side caching.
Thanks for this!
> There is a bug with chromium (not chrome) and mp4 files for a reason I
> can't understand. It simply won't play the files, and will fail
> silently for now.
See https://code.ductus.us/ticket/100
> At this point, mp4 should be playable on all browsers barring the bug
> above (not sure about IOS though...).
> The only way to improve support for ogg now is to convert files to mp4
> as they are uploaded or displayed or throw ogg support into jPlayer
> flash. We may want to wait a bit on this one...
I'm confused here. Although we accept either ogg or m4a, we will serve
both formats for any file that is uploaded. (We do the conversion in
the mediacache layer.) So pretty much everybody should be able to
listen to everything.
There's no real need for the logic of selecting which one to ask for.
Just tell jPlayer that both exist (and that we prefer Ogg), and it
should figure it out.
A few other things on my mind, too ...
I'm reworking the static-view-no-audio branch a bit (particularly the
way it deals with subviews), so don't build too seriously on top of it.
You added some css to choice.css that has nothing to do with the choice
interaction. That is fine if we want to consolidate things, but we
should rename choice.css if it is going to contain things unrelated to
"choice." (Doing something like this may seem like a more intrusive
change, but it is really the right way to go!) If you want, put in some
comments for what goes with what. Maybe flashcards.css would be a
better name.
Now that you have one jPlayer that can be used by many things, I would
absolutely love if you could do the same thing on the "choice"
interaction and get audio working there. That has been one of two
things holding up the migration from picture- and phrase- choice lessons
to the more generic flashcard interface (and the new flashcard editor).