播放chrome中存储为天蓝色斑点的mp3时，音频标签无法正常工作 [英] audio tag not working correctly when playing an mp3 stored as azure blob in chrome
问题描述
使用Chrome播放存储为Azure中的Blob的mp3文件时，我们得到了奇怪的行为.所有其他浏览器似乎都能正确播放曲目，但是Chrome不允许用户跳到曲目的其他部分.
We are getting a strange behavior when using Chrome to play an mp3 file stored as a blob in Azure. All other browsers seem to play the track correctly but Chrome does not allow the user to skip to other parts of the track.
为了说明这一点，请在Chrome中打开以下两个网址-它们都是同一轨道.第一个可以让您跳到其他部分，第二个则不能.
To demonstrate this open the following two urls in Chrome - they are both the same track. The first one will let you skip to other sections, the second one won't.
http://scantopdf.eu/downloads/music/igygtrack.mp3
http://igygprodstore.blob.core.windows.net/igyg-site-blobs1/10b1122f-eb43-44fd-aa48-919d8b6955c1.mp3
这是Chrome问题还是Azure存储问题?是否有任何HTML5代码可以正确播放Blob?
Is this a Chrome issue or an Azure storage issue? Is there any HTML5 code that will play the blob correctly?
推荐答案
有什么不同:
Azure Blob存储终结点不会向您的浏览器返回 Accept-Ranges: Bytes 你找不到.
The Azure Blob Storage endpoint does not return Accept-Ranges: Bytes to your browser - that's why you can't seek.
现在，如果您仔细查看来自Azure存储的响应，您会发现x-ms-version标头的值看起来很古老:
Now if you look closer at the response coming from Azure Storage you'll notice a x-ms-version header with a value that looks ancient:
HTTP/1.1 200 OK
Content-Length: 13686118
Content-Type: audio/mp3
...
x-ms-version: 2009-09-19
新旧存储帐户都默认使用相同的API版本，因此它们不会破坏与现有代码的向后兼容性.
Both old and new storage accounts default to the same API version so they don't break backwards compatibility with code out there.
以下是存储API版本的版本历史记录:
https://msdn.microsoft.com/en-us/library/azure/dd894041.aspx
Here's the version history on storage API versions:
https://msdn.microsoft.com/en-us/library/azure/dd894041.aspx
我们强烈建议您将版本2011-08-18及更高版本用于需要带引号的ETag值或有效的接受范围响应标头的情况，因为浏览器和其他流媒体客户端需要这些才能高效下载和重试.
We highly recommend using version 2011-08-18 version and later for scenarios that require quoted ETag values or valid Accept-Ranges response headers, since browsers and other streaming clients require these for efficient download and retries.
您必须使用x-ms-version标头传递2011年8月之后的API版本(默认情况下会返回该标头)，
You either have to pass in x-ms-version header with a post-August-2011 API version (which by default returns that header),
例如
$ curl -I -s http://igygprodstore.blob.core.windows.net/igyg-site-blobs1/10b1122f-eb43-44fd-aa48-919d8b6955c1.mp3
HTTP/1.1 200 OK
Content-Length: 13686118
Content-Type: audio/mp3
...
↑没有Accept-Ranges标头！
↑ No Accept-Ranges header!
$ curl -I -s -H "x-ms-version: 2015-12-11" http://igygprodstore.blob.core.windows.net/igyg-site-blobs1/10b1122f-eb43-44fd-aa48-919d8b6955c1.mp3
HTTP/1.1 200 OK
Content-Length: 13686118
Content-Type: audio/mp3
...
Accept-Ranges: bytes
或者您需要在容器级别设置默认的API版本，例如 AzureBlobUtility :
or you need to set the default API version at the container level, with something like AzureBlobUtility: https://github.com/Plasma/AzureBlobUtility
这是我刚刚构建的二进制文件.但是，良好的实践表明，不要相信陌生人的二进制文件，而要自己构建它们.
Here's a binary I've just built. However good practice dictates don't trust binaries from strangers, build them yourself.
C:\AzureBlobUtility\bin\Release>BlobUtility.exe -k fH00xxxxxxxxxx7w== -a baboonstorage1 -c public --setDefaultServiceVersion 2015-12-11
[2016-09-20 01:59:45] INFO Program - Updating API Version from to 2015-12-11
[2016-09-20 01:59:45] INFO Program - Updated Ok
或者，使用Storage SDK在存储帐户级别设置默认API版本:
Or, use the Storage SDK to set the default API version at storage account level:
// From http://geekswithblogs.net/EltonStoneman/archive/2014/10/09/configure-azure-storage-to-return-proper-response-headers-for-blob.aspx
var connectionString = "DefaultEndpointsProtocol=https;AccountName={accountName};AccountKey={accountKey}";
var storageAccount = CloudStorageAccount.Parse(connectionString);
var blobClient = storageAccount.CreateCloudBlobClient();
var props = blobClient.GetServiceProperties();
props.DefaultServiceVersion = "2015-12-11";
blobClient.SetServiceProperties(props);
现在，在任何浏览器中尽情享受，尽享乐趣！ https://baboonstorage1.blob.core.windows.net/public/test. mp3
Now enjoy this in any browser, with seeking! https://baboonstorage1.blob.core.windows.net/public/test.mp3
$ curl -I -s https://baboonstorage1.blob.core.windows.net/public/test.mp3
HTTP/1.1 200 OK
Content-Length: 13686118
Content-Type: audio/mpeg
...
Accept-Ranges: bytes
...
x-ms-version: 2015-12-11
这篇关于播放chrome中存储为天蓝色斑点的mp3时，音频标签无法正常工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
