基于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 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) …