次のように、OGG ファイルと MP3 ファイルの 2 つのソースを使用して HTML5 オーディオ タグを設定しました。
<audio controls="controls" id="audioplayer1">
<source src="podcast.mp3" type="audio/mpeg" />
<source src="podcast.ogg" type="audio/ogg" />
</audio>
Chrome で OGG ファイルを再生し、バッファリングされていない位置を探すと、バッファリングは古い位置で停止し、この新しい位置から続行されるため、再生はほぼ即座に続行されます。これは、Internet Explorer 9 の MP3 と、Firefox 14.0.1 および Opera 12.01 ビルド 1532 の OGG に対しても正しく機能します。ただし、Chrome で MP3 ファイルを再生する場合、バッファリングは最初から続行され、バッファリングが到達するまで再生が停止します。新しい再生位置。大きなオーディオ ファイルの場合、これには時間がかかる場合があります。例: http://mvcpeer.be/uhbpmedia/web/test.html
私のサーバーは適切に構成されている必要があります：
AddType audio/mpeg mp3
AddType audio/ogg ogg
およびバイト範囲がサポートされています。ブラウザが OGG と MP3 に対して行うリクエストを比較したところ、奇妙なことに気付きました。
OGG の場合、Chrome は最初に を含むリクエストを作成し、次のRange: bytes=0-ようにヘッダーに合計ファイル サイズ (この例では 136.320.012 バイト) を含む 206 レスポンスを受け取ります。
リクエスト
GET /audio/podcast.ogg HTTP/1.1
Host: inderdaad.be
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1
Accept: */*
Referer: http://mvcpeer.be/uhbpmedia/web/web.php
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Range: bytes=0-
応答
HTTP/1.1 206 Partial Content
Date: Mon, 27 Aug 2012 18:18:41 GMT
Server: Apache/2
Last-Modified: Mon, 27 Aug 2012 10:08:56 GMT
ETag: "26016c4-820140c-4c83c837ab335"
Accept-Ranges: bytes
Content-Length: 136.320.012
Vary: Accept-Encoding,User-Agent
Content-Range: bytes 0-136320011/136320012
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: audio/ogg
バッファリングされていない位置にスキップすると、ファイルの末尾の小さな部分に対して 2 番目の要求が行われ、プロパティRange:はbytes=136241821-136255487(おそらくいくつかのメタデータの場合、応答は 200) になり、続いて(応答 206にRange:設定された 3 番目の要求が続きます) bytes=37340471-136242175）。この時点からバッファリングが開始されます。
ただし、MP3 の場合、Chrome は を含む 1 つのリクエストのみを作成しRange: bytes=0-ます。バッファリングされていない位置をシークするときに 2 番目または 3 番目のリクエストが行われないため、シーク ポイントでバッファリングを開始できません。
これは Chrome の問題ですか? (Chrome 21.0.1180.83 m を使用)
どうもありがとう！