Bug 219167 – HTML Audio Element does not play mp3s all the way. Stops at varying spots and restarts.

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Media

Created attachment 414600 [details]
Live Stream text appears rather than showing the Seek Bar for this mp3 file.

[Paying] Customers using our application on mobile report that in both Firefox and Safari on the iPhone HTML audio elements do not play all the way.  

Even when the user is on Wi-Fi, elements play to a certain point (about 30 or 45 seconds in) and stop.
  
The audio then loops from the beginning. 
 
As this is audio intended to "read the page" for the user it is quite annoying, because it does not read even close to the full page contents.  

This functionality appears to have been broken for a long while, and rather than showing a seek bar, 
the HTML Audio element displays the text "Live Stream" which is simply untrue.



The code we are using to provide this audio element has gone through several transformations, 
using the <source> tag, 
not using <source> and using src="~.mp3" instead, 
and trying variations on the supported tags for autoplay 
have not changed this experience for our end-user 
and while these elements operate fine on a desktop mac browsing via Firefox, 
or via a windows machine, 
they are not working on iOS mobile.

Here's some example code from our page, there's not much to see and not much to go wrong here, 
but the Audio HTML element on iOS mobile persists in its declaration of "Live Stream" and only playing back <45 sec of actual audio, 
many of the mp3s being multiple minutes, some being 15 minutes, in duration, all exhibit this "Live Stream" text behavior.

<audio class='audiolesson bottomout' style='width:100%' controls preload="auto" src='file.mp3' type="audio/mp3"></audio> 




How can I fix this for our customers using our site via iOS mobile?

Turns out 3 content headers must be set on the server, and this Stack Overflow comment was helpful: https://stackoverflow.com/a/44218051/440887

" Its necessary to set some headers for media file response.

as example:

Accept-Ranges:bytes
Content-Length:7437847
Content-Range:bytes 0-7437846/7437847
"


However, Content-Range is an optional header, so would it be possible to update WebKit to automatically place a "0-(dec len) / len" when no Content-Range is detected?  I personally cannot see any drawbacks to this failsafe.

Am testing this now, will update if encountering any further issues.

I have tried setting the headers of the request without success.
Not wanting to blow up your status messages with this stuff, but No Dice so far.

While I expect m4a to be a native iOS/Webkit compatible format, the Safari and Firefox mobile browsers prefer to fall back to the mp3, otherwise they simply say "Error"
When it falls back to mp3 it says "Live Broadcast" as noted earlier, and also stops playing the file sometimes as quickly as 10 seconds in.

The headers I have set in an effort to solve this issue include:
"Content-Type" "audio/x-m4a"
"Content-Length" size
"Content-Range" "bytes 0-(dec size)/size"
"Accept-Ranges" "bytes"

I also tried setting the Response Status to 206, did not help.

Is there a way to request an update to WebKit on mobile Safari/Firefox/Chrome to support more than baseline MP4?  I used Quicktime on a desktop mac to record this audio, and I find it quite perplexing that it will not play.


My goal here is to have a Seek Bar available for users.  If the mp3 fallback is used, there is no seek bar, just the text "Live Broadcast," and when I try to use an mp4 file as suggested in the official apple documentation, I simply get "Error" on the mobile webkit html5 audio element.

[Alexey Proskuryakov]

I think that there are two ways to look at this:

1. As a WebKit bug report, this looks like multiple different issues (inability to scrub; looping from 30-45 seconds into the file; not using audio/x-m4a as expected). A bug report is most useful when there is a way for us to reproduce an issue, as otherwise it can be a long back and forth asking for additional details. And that gets near impossible when talking about multiple issues at once.

2. I understand that you primarily need to get it working. Bugzilla is not a good place for providing help, please reach out to webkit-help (see <https://webkit.org/getting-started/#staying-in-touch>).

RESOLVED by providing absolute file path instead of relative file path to file.
I mean, it still says "Live Broadcast" but the mp3 fallback actually plays all the way now.

https://stackoverflow.com/a/43133607/440887

So yeah, if you guys could figure out why relative file paths are not working, that is my strongest lead.