HTML5 audio starts from the wrong position in Firefox

后端 未结 5 989
栀梦
栀梦 2021-01-04 12:09

I\'m trying to play an mp3 file and I want to jump to specific location in the file. In Chrome 33 on Windows, the file jumps the correct position (as compared with VLC play

相关标签:
5条回答
  • 2021-01-04 12:20

    The problem lies in the VBR encoding of the mp3.

    Download that mp3 to disk and convert it to fixed bit rate, say with Audacity.

    Run the example from disk:

    <audio autoplay id="audio" src="./converted.mp3" controls preload></audio>
    <button onclick="javascript:document.getElementById('audio').currentTime = 10;">
    Jump to 10 secs "...be with us in, er, 1 minute...  ok" </button>
    

    and it works fine for me.

    So my suggestion for workaround is is to upload an alternative fixed-bit mp3 file in place of the one you are using. Then it should work in the current FFx.

    0 讨论(0)
  • 2021-01-04 12:25

    I work on SoundJS and while implementing audio sprites recently ran into similar issues. According to the spec, setting the position of html audio playhead can be inaccurate by up to 300ms. So that could explain some of the issues you are seeing.

    Interestingly, your fiddle plays correctly for me in FF 28 on win 8.1 if I just let it play through from the start.

    There are also some known issues with audio length accuracy that may also have an effect, which you can read about here.

    If you want precision, I would definitely recommend using Web Audio where possible or a library like SoundJS.

    Hope that helps.

    0 讨论(0)
  • 2021-01-04 12:30

    I just tried your code with another audio url here, it seemed to work and i did not experience a delay of any sort in Firefox( v29) which i did previously.

    <audio autoplay id="audio" src="http://mediaelementjs.com/media/AirReview-Landmarks-02-ChasingCorporate.mp3" controls preload></audio>
    

    I guess to jump around an audio file, your server must be configured properly.

    The client sends byte range requests to seek and play certain regions of a file, so the server must response adequately:

    In order to support seeking and playing back regions of the media that aren't yet downloaded, Gecko uses HTTP 1.1 byte-range requests to retrieve the media from the seek target position. In addition, if you don't serve X-Content-Duration headers, Gecko uses byte-range requests to seek to the end of the media (assuming you serve the Content-Length header) in order to determine the duration of the media.

    Hope this helps.. You could also try looking into Web Audio API for sound-effect-like playback which gives you some guarantees about the playback delays.

    0 讨论(0)
  • 2021-01-04 12:41

    I met the same issue, and I solved it by converting my MP3 file to the CBR(Constant Bit Rate) format. Then, it can solve the inconsistent issue between the currentTime and the real sound.

    Choose the CBR format


    Steps:

    • Download and install "Audacity" (it's a free for any platform)
    • Open your MP3 file
    • Click [File] -> [Export] -> [Options] -> [Constant] (See: Converting MP3 to Constant Bit Rate)
    • Audacity will ask you to provide the LAME MP3 encoder (See: [download and install the LAME MP3 encoder])

    There will be no inconsistent/asynchronous issue.


    Also see:

    • HTML5 audio starts from the wrong position in Firefox
    • Inconsistent seeking in HTML5 Audio player

    tsungjung411@gmail.com

    0 讨论(0)
  • 2021-01-04 12:41

    After testing the fiddle it is noticable that there is some issue with FF , anywho , after searching sometime , the issue is due to "Performance lag" , but the good news is that someone has found a solution to that issue , you may want to read this :

    http://lowlag.alienbill.com/

    a single script will solve it all.

    0 讨论(0)
提交回复
热议问题