【问题标题】:Azure Media Services Shared Access Policy limitationsAzure 媒体服务共享访问策略限制
【发布时间】:2013-02-20 04:10:18
【问题描述】:

我正在尝试创建限时 URL,以便在 Azure 媒体服务中顺畅传输媒体。

我正在处理此处提供的代码。 Windows Azure Smooth Streaming example

我将视频文件上传到新资产。我使用带有预设“H264 Adaptive Bitrate MP4 Set 720p”的 Azure 媒体服务编码对该视频文件进行编码。使用生成的编码资产,然后我尝试通过创建访问策略和定位器来创建流式 URL,我使用它来生成用于流式传输的 URL。

代码如下:

string urlForClientStreaming = "";

IAssetFile manifestFile = (from f in Asset.AssetFiles
                   where f.Name.EndsWith(".ism")
                   select f).FirstOrDefault();

if (manifestFile != null)
{ 
    // Create a 1 hour readonly access policy. 
    IAccessPolicy policy = _mediaContext.AccessPolicies.Create("Streaming policy",   TimeSpan.FromHours(1), AccessPermissions.Read);

    // Create a locator to the streaming content on an origin. 
    ILocator originLocator =     _mediaContext.Locators.CreateLocator(LocatorType.OnDemandOrigin, Asset,    policy, DateTime.UtcNow.AddMinutes(-5));

    urlForClientStreaming = originLocator.Path + manifestFile.Name + "/manifest";

    if (contentType == MediaContentType.HLS)
    urlForClientStreaming = String.Format("{0}{1}", urlForClientStreaming, "(format=m3u8-aapl)");
}

return urlForClientStreaming;

这很好用。直到第 6 次针对同一个资产执行该代码。然后你会收到这个错误:

“服务器不支持在单个容器上设置超过 5 个共享访问策略标识符。”

所以,没关系。我不需要每次都创建一个新的 AccessPolicy,我可以重用我之前创建的那个,使用相同的策略构建一个定位器。但是,即便如此,我仍然收到有关单个容器上的 5 个共享访问策略的错误。

以下是创建定位器的新代码,该定位器与之前使用的 AccessPolicy 相同:

string urlForClientStreaming = "";

IAssetFile manifestFile = (from f in Asset.AssetFiles
                   where f.Name.EndsWith(".ism")
                   select f).FirstOrDefault();

if (manifestFile != null)
{ 
    // Create a 1 hour readonly access policy
    IAccessPolicy accessPolicy = null;
    accessPolicy =
      (from p in _mediaContext.AccessPolicies where p.Name == "myaccesspolicy" select p).FirstOrDefault();

     if (accessPolicy == null)
     {
         accessPolicy = _mediaContext.AccessPolicies.Create("myaccesspolicy", TimeSpan.FromHours(1), AccessPermissions.Read);
     }

    // Create a locator to the streaming content on an origin. 
    ILocator originLocator =     _mediaContext.Locators.CreateLocator(LocatorType.OnDemandOrigin, Asset,    policy, DateTime.UtcNow.AddMinutes(-5));

    urlForClientStreaming = originLocator.Path + manifestFile.Name + "/manifest";

    if (contentType == MediaContentType.HLS)
    urlForClientStreaming = String.Format("{0}{1}", urlForClientStreaming, "(format=m3u8-aapl)");
}

return urlForClientStreaming;

我不明白为什么说我创建了 5 个共享访问策略。在第二个代码块的情况下,我只创建了一个访问策略。我可以通过查看_mediaContext.AccessPolicies 的内容来验证只有一个 AccessPolicy,该列表中始终只有一个访问策略。

在某些时候,这可能会有许多用户请求访问同一资产。根据我们客户的要求,提供给这些客户的 URL 需要有时间限制。

这不是为资产流畅流创建 URL 的适当方法吗?

【问题讨论】:

    标签: azure smooth-streaming azure-media-services


    【解决方案1】:

    我知道回复晚了...

    鉴于您需要创建一个可供任何人无限期使用的 URL,我建议您:

    1. 在创建资产时创建一个长寿命定位器,例如一年 - 您可以每次都使用相同的访问策略,就像您在第二个示例中使用的一样
    2. 在构建流式传输 URL 时,从资产中获取该定位器
    3. 检查资产上剩余的时间长度 - 如果少于一定时间(例如一个月),则使用 ILocator.Update 扩展定位器,例如再过一年。更新定位器的到期日期不会影响您用于创建定位器的原始访问策略。
    4. 利润。

    HTH

    【讨论】:

    • 谢谢Mike,不幸的是我们需要的不是任何人都可以无限期使用的单一网址,我们需要一个个人可以在很短的时间内使用,然后过期的网址.
    • 我们已经从 Azure 转移到 Amazon Web 服务,在那里创建限时 url 是一件非常简单的事情,并且没有 Azure。谢谢你的建议,我会接受的。
    【解决方案2】:

    现在借助 Azure 媒体服务内容保护功能,您可以使用 AES 或 PlayReady 加密您的媒体文件,生成一个长期存在的定位器。同时,您为内容密钥设置了 Token-Authorization 策略,令牌持续时间可以设置为较短的时间(足以让播放器检索内容密钥)。这样您就可以控制您的内容访问。更多信息可以参考我的博客:http://azure.microsoft.com/blog/2014/09/10/announcing-public-availability-of-azure-media-services-content-protection-services/

    【讨论】:

      【解决方案3】:

      定位器的设计目的不是针对每个用户进行访问控制。为此使用数字版权管理系统。他们有查看窗口、持久和非持久许可等概念。具体来说,我说的是在 WAMS 和 PlayReady 服务器中使用 PlayReady 加密来配置和提供许可证(Azure 门户中有 EzDRM,还有 BuyDRM 等)。

      定位器提供流媒体服务的基本开关。您最多可以创建 5 个,因为它们使用每个容器 5 个的底层 SAS 限制。

      【讨论】:

      • 感谢尼克的回复。假设我不再关心生成仅在一段时间内有效的流式 URL。如何创建一个任何人都可以无限期使用的流式 URL。我在网上看到的每个示例都会创建一个访问策略,以创建创建 URL 所需的定位器。我是否只需要创建一个持续时间较长的访问策略,创建定位器,当我再次需要 URL 时,只需从定位器集合中查找定位器?我可以设置多长时间有上限吗?
      • 有没有办法在不创建访问策略的情况下创建流式 URL?
      • 不,您需要一个访问策略来创建您的 Origin Locator 对象。我已经使用了 10 多年的 Origin Locators,不用担心。您可以使用 Locator.Update(newExpiryDateTime);进一步推迟日期。
      猜你喜欢
      • 1970-01-01
      • 2020-01-02
      • 2013-10-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-11-18
      • 1970-01-01
      相关资源
      最近更新 更多