Changing HTML5 audio.currentTime on Safari 5 on Mac and iPad

[Mark P]

Hello Group,

I'm posting this info here so that you can feedback on it if you wish.

The Safari 5 browser on the Mac and the iPad's Mobile Safari browser,
both have problems with changing the HTMLAudioElement.currentTime
value. While most browsers do not like you changing audio.currentTime
before the audio element has downloaded some information, this is a
completely different issue. Here, changing currentTime causes the
HTMLAudioElement.buffered array of TimeRanges object to become
corrupt.

This issue only affects:
Safari 5 on the Mac
Mobile Safari on iOS4 (iPad/iPhone/iPod)

The PC version of Safari 5 does not have this problem.

Nature of the problem:
If the audio.currentTime is changed during the download phase of the
mp3 file, this problem occurs. Whatever time you change the
currentTime to that first time, appears to define the corruption
criteria. Moving the currentTime to a point less than that 1st change
to currentTime value causes the HTMLAudioElement.buffered information
to corrupt, where the array does not get any larger, but the first and
only TimeRanges object gives the values approx equal to the
currentTime value.

ie., Corruption causes:
HTMLAudioElement.buffered.end(0) ~= HTMLAudioElement.currentTime

This makes the load progress bar corrupt in jPlayer, since
audio.buffered.end(0) is compared with audio.duration to determine how
much has loaded.

At the moment, our view is that this is a fundamental bug with Safari
5 (Mac) and Mobile Safari iOS4.

Attempting to fix this issue would tend towards disabling the load
information for all HTML5 browsers, now and if and when that
information is available in the future. As most HTML5 browsers allow
you to jump forward in the download (assuming your server is accept-
range compliant), maybe the load bar is becoming redundant. The
problem is, some browsers would make you sit and wait for the rest of
the file to download before jumping to that point.

I'm not sure either, but it appears that Safari 5 (Mac) and Mobile
Safari (iOS4) have tried to implement the file seeking. It appeared to
download immediately from 3 minutes into the song during my tests, but
the audio.buffered information did not reflect this. Safari 5 (PC)
always loads from the start of the track and you'd have to wait for
the 3 minute mark to download before it begins playing.

Feel free to chip in!

Best regards,
Mark P.

[Andy Kelley]

Hello,

Great work on getting JPlayer to work on all platforms, even Safari.

However, I would like to request that you don't take away the ability
to see how much is loaded for browsers that support it. I really need
this feature.

Thanks!
Andy

[Mark P]

Hi Andy,

This is exactly why I brought it up. I wanted to know what the
community wants.

One thing at the back of my mind... Nagging away... Is that more and
more browsers are moving to a 'seeking' way of accessing the audio
files. If the browsers actually implement the audio.buffered array of
TimeRanges, then the loadbar would need to work in a different way.
(Safari are the only ones that implement it, and they broke it in
Safari 5.)

ie., We'd need to show the chunks downloaded, which may not all be in
1 piece. So the load bar info becomes a barcode of what is ready and
what is not. Also, clicking anywhere on the bar should always work,
since you can jump to any point regardless of whether it has
downloaded yet or not.

I'll keep that on the back burner and deal with it when browsers start
to catch up.

BTW. Currently, jPlayer takes the last element (N) of the
audio.buffered.end(N) and use that as the load bar. If DOM info not
implemented, then the load bar goes to 100% immediately.

Best regards,
Mark P.