Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-16-1:2011定义了UPnP AV Architecture:2规范,这是将所有UPnP音视频设备和服务模板统一为一致互操作性模型的总体框架。该标准确立了基本的设备角色——媒体服务器、媒体渲染器和控制点——并定义了这些角色通过协作在异构家庭和企业网络中提供无缝媒体流体验的交互模式。该架构建立在核心UPnP设备架构版本1.0之上,增加了用于内容管理、传输控制和连接处理的AV特定扩展。
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的协议信息数据结构设计为可扩展的——可以通过定义新的协议标识符来添加新的传输协议,而无需修订服务规范。
该规范还涉及内容格式识别的重要概念。每个媒体资源携带一个MIME类型,并可能通过protocolInfo属性包含额外的协议特定信息。架构建议实现使用完整的四字段协议信息格式而非缩写形式,以最大化互操作性。对于DLNA认证设备,额外的配置文件标识符被附加到additionalInfo字段以实现精确的能力匹配。
实现符合UPnP AV Architecture:2的系统需要仔细关注设备发现稳健性。SSDP发现协议使用默认TTL为4的UDP,意味着发现消息仅限于本地子网。对于多子网部署,在子网之间实现SSDP代理或多播路由。或者,使用UPnP UDA中定义的设备发现机制,该机制允许设备向已知的发现代理注册。
服务协调是另一个关键领域。当控制点跨多个服务调用动作时,它必须处理服务位于不同设备或同一设备上的情况。架构建议设备实现暴露单个设备描述XML,枚举所有嵌入服务及其控制/事件URL。控制点应解析此描述以在发起任何AV操作之前构建完整的服务拓扑。使用与SSDP广告间隔对齐的超时时间缓存设备描述可以最小化冗余网络请求。
架构级别的错误处理需要分层方法。网络级错误由传输层处理。服务级错误作为SOAP响应中的UPnP错误代码返回。应用级错误必须通过状态变量和事件进行通信。架构建议实现记录所有带有严重级别和时间戳的日志,以方便多厂商互操作性问题的调试。控制点内的集中式错误聚合器可以跨设备关联错误,以识别系统性问题。