微软云平台媒体服务实践系列 3- 基于媒体服务REST API及Xamarin进行iOS, Android , Windows 应用开发

据统计,在Internet Traffic中,Video 所占的量超过了一半;相对于只使用电视机看节目的用户而言,使用移动设备的用户会多看接近50%的节目。可见,视频支持的终端设备越多,意味着越高的收视率,拥有越多的用户群,但是如果视频的缓冲时间长、画质差,用户很可能放弃观看。自适应流媒体技术可以根据客户端的网络带宽、系统资源等自动地选择恰当分辨率的媒体内容进行播放,为用户提供画质清晰流畅的播放体验。本文基于微软云平台媒体服务,介绍如何制定一个跨iOS,Android,Windows移动平台的自适应流媒体视频点播(VoD)方案,以期望在当今3大移动平台上,进行流媒体的制作与播放。 在移动平台上使用Azure Media Services (AMS) 的第一大难点就是对于iOS, Android,Windows Store 或Windows Phone app,没有可以直接使用的AMS SDK,也没有相应的移动应用使用媒体服务的code 样例;此外,各个移动平台拥有不同的开发环境与开发语言,那是否意味着需要分别去学习objective-c/swift, java,C#/VB.Net等才能完成整个方案? 而且该过程所耗费的时间及成本都不低。虽然困难重重,但是我们还是有机会的:一是媒体服务提供了可供所有平台调用的REST APIs;二是Xamarin的出现为我们解决了高效开发跨平台应用的难题,当然Cordova也是一个选择;三是媒体服务有相应的.Net code 样例供参考使用。(总结如下图所示)                                            基于AMS REST APIs和Xamarin, 整个方案如下图所示,主要分为移动客户端和媒体服务端,首先移动客户端负责将原始媒体文件上传到云端,再让媒体服务完成编码、流媒体发布等任务,最后再由客户端播放使用。那么针对不同的客户端,是不是就需要3个开发团队完成各自平台的项目开发及维护、修正等,有没有一种一次编写、到处运行的方案呢?                    …


微软云平台媒体服务实践系列 2- 使用动态封装为iOS, Android , Windows 等多平台提供视频点播(VoD)方案

文章微软云平台媒体服务实践系列 1- 使用静态封装为iOS, Android 设备实现点播(VoD)方案  介绍了如何针对少数iOS, Android 客户端的场景,出于节约成本的目的使用媒体服务的静态封装实现视频点播方案。实际应用中,所支持的客户端越多,那么所获得的用户越多,客户端多种多样:PC端, Xbox, iOS, Android, Windows 等移动设备端,针对如此之大的客户端市场,能否搭建一套全面的点播方案呢?答案是肯定的,本文将基于微软云平台媒体服务介绍如何实现跨多移动客户端的视频点播方案。 微软的云平台媒体服务为流媒体服务提供了多种选择,在使用流媒体服务为企业做流媒体方案时,首先需要确认要流媒体接收目标,如针对广大iOS, Android移动设备,由于它们都支持HLS 格式的流媒体,微软平台支持smooth streaming 格式,基于该认知,比较推荐的是使用动态封装,但是必须额外添加流式处理单元,方法是在Azure 门户,点击媒体服务,然后点击所使用的媒体服务,选择流式处理端点标签页,选择需要编辑的流媒体端点,然后再缩放标签页下设置,如下截图所示:        使用动态封装制定支持Windows, iOS, Android 平台的视频点播方案的流程如下截图所示:原始媒体文件——>转码为MP4文件——>使用动态封装功能,按照客户端需求提供流媒体码流, 构造流媒体地址——>测试。    此外我们还可以在编码过程中为视频创建缩略图, 需要使用到相应的配置文件Thumbnail_Configuration.xml,内容如下: <?xml version=”1.0″ encoding=”utf-8″?> <Thumbnail Size=”100%,*” Type=”Jpeg” Filename=”{OriginalFilename}_{Size}_{ThumbnailTime}_{ThumbnailIndex}_{Date}_{Time}.{DefaultExtension}”>     <Time Value=”10%” Step=”10%” Stop=”95%”/> </Thumbnail>   整个代码流程可以参考如下:(使用流媒体服务.Net SDK,注意指定媒体服务的账号名字(accName)及key(accKey)) class Program     {         private static string accName =…


微软云平台媒体服务实践系列 1- 使用静态封装为iOS, Android 设备实现点播(VoD)方案

微软的云平台媒体服务为流媒体服务提供了多种选择,在使用流媒体服务为企业做流媒体方案时,首先需要确认要流媒体接收目标,如针对广大iOS, Android移动设备,由于它们都支持HLS 格式的流媒体,基于该认知,比较推荐的是使用动态封装,但是必须额外添加流式处理单元,方法是在Azure 门户,点击媒体服务,然后点击所使用的媒体服务,选择流式处理端点标签页,选择需要编辑的流媒体端点,然后再缩放标签页下设置,如下截图所示           使用流式处理单元需要支付一定的费用,且最小单元就是200mbps,根据文档Windows Azure Media Services Pricing Details内容引用如下,我们可以计算出:在使用1个流式处理单元,使用H264 Adaptive Bitrate MP4 Set 720p(范围从 3400 kbps 到 400 kbps)编码方式的情况下,同时可以观看流媒体的客户端个数约为47 个(160/3.4)。 “Question: How do I estimate # of on-demand streaming reserved unit I need? Answer: For the most conservative estimate you can go directly with SLA limitations – i.e. total bandwidth is 160 Mbps…


基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 5发布流媒体

在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 1 简介中介绍了基于Windows Azure Media Service(Windows Azure 媒体服务,简称WAMS)进行应用开发的相关信息及包含的基本流程,在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 2初始设置链接到WAMS中介绍了如何使用REST API进行WAMS的链接,然后在基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 3上传媒体到WAMS中少如何将媒体文件上传到媒体服务,并在基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 3媒体编码中详细介绍了如何对媒体服务中媒体文件创建编码作业对其编码,并查看编码进程。当编码工作结束后,我们就可以进行流媒体发布工作了,这也正是本文包含的内容。 本文将基于前面4篇内容进一步讲解如何对编码输出的文件进行流媒体的发布工作。 使用REST API发布流媒体,主要流程是: 创建具有读取权限的AccessPolicy 创建用于传输媒体内容的源URL,再在此URL上构建最终的流媒体URL 请注意,如前文所强调的在使用REST API时访问媒体服务中的实体时,必须在HTTP请求中添加如下必须的标头字段和值;WAMS…


基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 4媒体编码

在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 1 简介中介绍了基于Windows Azure Media Service(Windows Azure 媒体服务,简称WAMS)进行应用开发的相关信息及包含的基本流程,在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 2初始设置链接到WAMS中介绍了如何使用REST API进行WAMS的链接,然后在基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 3上传媒体到WAMS中少如何将媒体文件上传到媒体服务,本文将基于前面3篇内容进一步讲解如何对已经上传的媒体文件进行编码进而发布流媒体服务。 使用REST API对媒体文件进行编码,主要流程是: 创建作业 编码过程交由媒体服务完成 监视处理进程 请注意,如前文所强调的在使用REST API时访问媒体服务中的实体时,必须在HTTP请求中添加如下必须的标头字段和值;WAMS 的原始服务URI 为https://media.windows.net/,成功连接到此 URI后,会收到一个“301 重定向”响应指向另一个媒体服务URI,需要从该响应中提取出新的的媒体服务URI,随后的调用都是基于该 URI,详细内容参见Part2内容。 根据文档媒体服务 REST API 开发的设置可知,每次调用WAMS时,客户端必须在请求中包括必需的标头字段和值,列表如下: Header…


基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 3上传媒体到WAMS

在文章 基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 1 简介中介绍了基于Windows Azure Media Service(Windows Azure 媒体服务,简称WAMS)进行应用开发的相关信息及包含的基本流程,紧接着在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 2初始设置链接到WAMS中介绍了如何使用REST API链接到媒体服务,本文将基于此对如何上传媒体到媒体服务进行详细讲解。 使用REST API将媒体文件上传到媒体服务包含许多步骤,主要流程是: 创建资产(ASSET) 对资产进行加密(可选项)—本文暂时不予以考虑 将媒体文件上传到blob storage 请注意,在使用REST API时访问媒体服务时,必须在HTTP请求中添加如下必须的header;WAMS 的根 URI 为https://media.windows.net/,成功连接到此 URI后,会收到一个“301 重定向”响应并提取出新的媒体服务URI,随后调用新都是基于该 URI,详细内容参见Part2内容。 根据文档媒体服务 REST API 开发的设置可知,每次调用WAMS时,客户端必须在请求中包括必需的标头,列表如下: Header Type Value Authorization Bearer Bearer 是唯一接受的授权机制。 该值还必须包括由 ACS…


基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 2初始设置链接到WAMS

在文章基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 1 简介中介绍了基于Windows Azure Media Service(Windows Azure 媒体服务,简称WAMS)进行应用开发的相关信息及包含的基本流程,本文将对如何使用REST API进行WAMS的链接进行详细讲解。 WAMS接受基于 OData 的 HTTP 请求并能够以详细 JSON 或 atom+pub 做出响应。由于WAMS遵循 Azure 设计准则,因此在连接到 WAMS时,每个客户端必须使用一组必需的 HTTP 标头。根据文档媒体服务 REST API 开发的设置可知,每次调用WAMS时,客户端必须在请求中包括一组必需标头,媒体服务支持的标准 HTTP 请求必须的标头列表如下: Header Type Value Authorization Bearer Bearer 是唯一接受的授权机制。 该值还必须包括由 ACS 提供的访问令牌。 x-ms-version Decimal 2.7 DataServiceVersion Decimal 3.0 MaxDataServiceVersion Decimal 3.0…


基于Windows Azure Media Service REST API 进行Windows Store/Windows Phone 应用开发系列-Part 1 简介

在介绍基于Windows Azure Media Service REST API进行在Windows Store应用或Windows Phone应用的开发之前,我们首先对Windows Azure Media Service进行简要介绍,以便于快速理解媒体服务的使用及开发过程。 Windows Azure Media Service (Windows Azure 媒体服务,简称WAMS)是基于Windows Azure平台的灵活、可靠、可自定义的媒体服务。该服务为用户提供媒体上传、编码及视频下载、点播和实时播放等功能。 Azure 的管理门户针对WAMS提供丰富的UI操作,管理媒体服务的账户、内容、作业、点播流、编码及媒体处理器等。每个WAMS账户创建在一个特定的Windows Azure 数据中心,每个账户有一个帐户名称及账户密钥,在使用WAMS 的REST API或.NET API时,需要使用该账户名称及密钥发送验证请求及调用API进行后续编码、内容发布等。每个WAMS 账户都有一个或多个相关联的Azure Storage 账户,用于存储关联的WAMS 账户控制的媒体内容。用户可以登录http://www.windowsazure.cn/ 进行登记注册,成为Azure用户,登录后即可使用媒体服务。 在使用WAMS前,我们先来快速了解一些常用术语,部分内容可以参见 MSDN 文档Azure Media Services 概述: 资产(Asset)—— 资产是包含媒体信息的逻辑实体,它可能包含了一个或多个需要处理的数字文件(audio, video等)。 传送(Delivery)—— 传送/发布处理过的媒体,可能是以实时传送的方式或点播的方式发布到客户端,或者从cloud端获取/下载指定的媒体文件,或者部署媒体资产到其他的server端如Azure CDN server 等。 文件(File)—— 一个文件表示待处理的包含audio/video的blob对象 ,文件都是存储在Azure 的blob  storage里。一个文件总是与一个资产(asset)相关联,一个资产能够包含一个或多个文件。 引入/上载(Ingestion/uploading)—— 表示将资产上传给媒体服务的过程 。该过程包含上传文件到blob storage及对资产进行加密保护。 作业(Job)——…


使用Windows Azure Mobile Service 进行Azure Active Directory 身份验证

Windows Azure Mobile Service (WAMS) 对移动应用提供了多项功能,如数据交互/存储、用户身份认证、推送消息及调度作业(scheduled jobs)等,本文结合WAMS的身份认证功能介绍如何获取更多的用户信息如用户名用于应用显示。 微软官方文档Get started with authentication in Mobile Services详细介绍了如何使用所支持的identity provider 如Microsoft Account、Facebook login、Twitter login、Google login及Azure Active Directory(AAD)对移动应用提供身份验证功能,并且可以通过采用日志Expanded login scopes in Azure Mobile Services介绍的API获取用户ID信息,该文档介绍了如何通过Graph API获得Microsoft Account、Facebook login或Google login账号的用户信息,那么针对Azure Active Directory账号,该如何获取呢?AAD也提供了丰富的Graph API,可以用于获得用户信息。接下来我们以一个简单的Windows Store APP为例详细讲解如何使用Azure Active Directory进行用户身份认证并获取ID信息。  首先在Azure Management Portal上创建一个Azure Mobile Service,如名为wamsaad,                          点击新建的Mobile Service 的IDENTITY 标签,滚动到windows azure active directory,拷贝APP URL的值-如https://wamsaad.azure-mobile.net/login/aad,将用于后续Active Directory 配置。…


Windows Phone App 的本地自动测试

在上一篇blog 使用WACK 验证Windows Store App中,我们了解到为了加速Windows Store App的上架过程,强烈建议开发者使用Windows App Cert Kit-即WACK工具对APP进行测试验证,确保通过WACK测试之后再进行APP提交,因为Store对APP的审核过程也包含了WACK的测试过程。那么对于Windows Phone App,是否也遵循类似的审核逻辑呢?答案是肯定的,Windows Phone App的上架过程与Windows Store App的上架过程类似,只不过自动测试工具根据Windows Phone App的版本有所差别,本文将针对Windows Phone App的本地测试验证进行总结介绍。 我们从一个应用实例来看该测试过程的意义:有开发者发现对于Windows Phone OS 7.1的APP, 出于对用户安全隐私的考虑(如一些银行类的应用),其并没有在WMAppManifest.xml文件中声明使用ID_CAP_MEDIALIB(应用对媒体库的访问权限控制),但是当APP发布到Store后,App require 列表中却添加了Photo, music and video libraries内容,导致APP用户抱怨其安全隐患。这是为什么呢?原因在于Store在审核APP时,会使用一个工具对APP进行静态分析并自动添加所需要的Capabilities, 即若APP包含了使用媒体库的组件(如使用Microsoft.Xna.Framework.Media.MediaPlayer),那么ID_CAP_MEDIALIB会被自动添加。那么这个分析工具是什么呢?它即是Store Test Kit。这个工具集成在Windows Phone SDK8.0中,开发者可以使用Store Test Kit对使用某API的AP进行测试以判定其是否是依赖于某个capability。例如需要判别Microsoft.Xna.Framework.Media.MediaPlayer 类是否使用ID_CAP_MEDIALIB,使用Store Test Kit测试发现MediaPlayer 需要ID_CAP_MEDIALIB,简要过程为(基于Visual Studio 2012): 1)  创建一个新的基于Windows Phone 7.1 OS的Project 2)  添加code, code中包含调用相应的API 3)   “Release”编译APP 4) …