ISO/IEC IEC 29341-16-1:2011 — UPnP AV架构:2

通用即插即用音视频设备互操作性的框架

UPnP AV架构基础

ISO/IEC 29341-16-1:2011定义了UPnP AV Architecture:2规范,这是将所有UPnP音视频设备和服务模板统一为一致互操作性模型的总体框架。该标准确立了基本的设备角色——媒体服务器、媒体渲染器和控制点——并定义了这些角色通过协作在异构家庭和企业网络中提供无缝媒体流体验的交互模式。该架构建立在核心UPnP设备架构版本1.0之上,增加了用于内容管理、传输控制和连接处理的AV特定扩展。

AV Architecture:2规范是所有其他UPnP AV标准引用的概念蓝图。理解本文档对于设计多设备媒体生态系统的系统架构师至关重要。它定义了确保来自一个制造商的电视可以从另一个制造商的NAS流传输的”交战规则”。

AV Architecture:2规范引入了三角色模型。媒体服务器(DMS——数字媒体服务器)托管内容并使其可用于流传输。媒体渲染器(DMR——数字媒体渲染器)接收和渲染内容。控制点(DMC——数字媒体控制器)编排交互:它在服务器上发现内容,识别合适的渲染器,在它们之间建立连接,并控制播放。控制点可以嵌入在服务器或渲染器的同一设备中,也可以作为独立实体运行。

版本2中的一个关键架构创新是引入了AVTransport:2服务,该服务比版本1更清晰地将传输控制与连接管理分离。该架构还定义了虚拟通道的概念——可以同时承载多个媒体流的逻辑路径,支持画中画、多房间音频同步以及在同一设备上同时录制和播放等功能。

设备角色与服务交互

媒体服务器角色捆绑了三个核心服务:ContentDirectory(用于浏览和搜索内容)、ConnectionManager(用于建立数据传输)以及可选的AVTransport(用于控制播放)。媒体渲染器角色捆绑了ConnectionManager、AVTransport和RenderingControl(用于调节音量、亮度等)。控制点不暴露服务而是消费服务——它通过SSDP发现设备,查询其能力,并调用动作来建立和控制媒体流。

设备角色 必需服务 可选服务 示例设备
媒体服务器 (DMS) ContentDirectory:2, ConnectionManager:2 AVTransport:2 NAS、媒体服务器软件、智能手机
媒体渲染器 (DMR) ConnectionManager:2, AVTransport:2, RenderingControl:2 智能电视、流媒体盒子、无线音箱
控制点 (DMC) 无(作为服务器/渲染器) 智能手机应用、平板电脑、智能家居中枢
媒体播放器 (DMP) ContentDirectory:2, ConnectionManager:2, AVTransport:2, RenderingControl:2 带集成UI的机顶盒、游戏主机

交互流程遵循一个明确的序列。首先,控制点通过SSDP多播发现发现网络上的可用媒体服务器和媒体渲染器。其次,它在服务器上浏览ContentDirectory服务以找到所需的媒体项目。第三,它检查每个项目的res元素以确定可用的传输协议和内容格式。第四,它查询服务器和渲染器上的ConnectionManager服务以验证协议兼容性并建立连接。最后,它使用AVTransport动作控制渲染器上的播放,并使用RenderingControl动作调整音视频呈现参数。此序列可以通过缓存发现和能力信息来优化,以减少常用设备的延迟。

媒体流模式与传输机制

AV Architecture:2规范定义了多种媒体流模式。最常见的是两箱推送模型:控制点指示媒体服务器直接向媒体渲染器发送内容。控制点不参与数据路径——它只管理信令。这是DLNA Push Controller应用使用的模式。另一种是三箱模型,其中控制点、服务器和渲染器都是独立的物理设备。该架构还支持两箱拉取模型,其中渲染器自身充当控制点并从服务器拉取内容。

架构支持的传输机制包括HTTP GET(最常用,用于渐进式下载和流传输)、HTTP POST(用于向服务器上传内容)、RTP(用于带时序信息的实时流传输)以及厂商可扩展的协议。该架构还定义了传输层的概念,可以在不修改核心服务接口的情况下封装DRM、链路保护和QoS标记。ConnectionManager的协议信息数据结构设计为可扩展的——可以通过定义新的协议标识符来添加新的传输协议,而无需修订服务规范。

架构层考虑:三箱模型引入了一个协调挑战——控制点必须确保服务器和渲染器就相同的传输协议和内容格式达成一致。ConnectionManager的协议信息协商处理了这一点,但控制点必须设计为能够通过建议替代格式或转码选项来优雅处理协商失败。

该规范还涉及内容格式识别的重要概念。每个媒体资源携带一个MIME类型,并可能通过protocolInfo属性包含额外的协议特定信息。架构建议实现使用完整的四字段协议信息格式而非缩写形式,以最大化互操作性。对于DLNA认证设备,额外的配置文件标识符被附加到additionalInfo字段以实现精确的能力匹配。

架构实现的工程要点

实现符合UPnP AV Architecture:2的系统需要仔细关注设备发现稳健性。SSDP发现协议使用默认TTL为4的UDP,意味着发现消息仅限于本地子网。对于多子网部署,在子网之间实现SSDP代理或多播路由。或者,使用UPnP UDA中定义的设备发现机制,该机制允许设备向已知的发现代理注册。

服务协调是另一个关键领域。当控制点跨多个服务调用动作时,它必须处理服务位于不同设备或同一设备上的情况。架构建议设备实现暴露单个设备描述XML,枚举所有嵌入服务及其控制/事件URL。控制点应解析此描述以在发起任何AV操作之前构建完整的服务拓扑。使用与SSDP广告间隔对齐的超时时间缓存设备描述可以最小化冗余网络请求。

架构优化:为实现低延迟媒体流传输,实现”直接连接提示”机制。当媒体服务器响应Browse请求时,它可以在资源元素中包含一个提示,告诉渲染器如何建立直接点对点连接,绕过控制点。这通过消除经过控制点的往返行程减少了连接建立延迟。这种方法对于实时视频监控或实时游戏等时间敏感应用特别有益。

架构级别的错误处理需要分层方法。网络级错误由传输层处理。服务级错误作为SOAP响应中的UPnP错误代码返回。应用级错误必须通过状态变量和事件进行通信。架构建议实现记录所有带有严重级别和时间戳的日志,以方便多厂商互操作性问题的调试。控制点内的集中式错误聚合器可以跨设备关联错误,以识别系统性问题。

安全考虑:AV Architecture:2不强制要求媒体流的加密或认证。在企业或敏感住宅部署中,为控制通道实现TLS,为媒体通道实现DTCP-IP或类似的链路保护。设备保护服务可以为UPnP动作提供认证。对于HIPAA合规或GDPR敏感的环境,可能需要额外的媒体元数据加密以保护内容发现隐私。

常见问题

问:AV Architecture:1和:2有什么区别?
AV Architecture:2增加了对双向流传输的支持、带有功能列表的增强协议协商、改进的服务状态变化事件粒度以及针对DLNA互操作性的澄清指南。版本2服务向后兼容版本1的控制点。
问:单个设备可以同时充当媒体服务器和媒体渲染器吗?
可以。架构允许设备组合角色。例如,智能电视既可以作为渲染器(显示来自NAS的内容)也可以作为服务器(向其他设备共享录制的节目)。每个角色独立并通过单独的设备描述实例暴露。
问:AV架构如何确保跨厂商的互操作性?
规范为每个设备角色定义了强制的最低能力要求。此外,UPnP论坛(现为开放连接基金会)提供认证测试,DLNA增加了配置文件特定的要求。架构的协议协商机制自动适应连接设备的能力。
问:架构支持哪些传输协议?
架构与传输协议无关。HTTP GET和RTP是最常用的,但任何协议都可以通过定义适当的协议信息条目来支持。实际实现主要使用HTTP以兼容Web基础设施和防火墙穿越。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注