Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-3-3:2011定义了UPnP MediaServer:3设备模板,这是通用即插即用音视频架构的基石。该标准规定了媒体服务器如何在家庭网络中发现、浏览和传输数字媒体内容。MediaServer:3设备封装了三大核心服务:内容目录服务(CDS)用于组织和导航媒体项目、连接管理器服务(CMS)用于管理设备间的数据传输,以及音视频传输服务(AVT)用于控制单个媒体流的播放。
从工程角度来看,MediaServer:3设备采用推送模型架构,服务器通过标准化的UPnP动作发布其能力和内容层次结构。控制点(客户端)调用服务器上的动作来浏览容器、搜索项目和发起传输。该标准强制要求支持关键状态变量,包括ContainerUpdateIDs、TransferIDs和ArgumentType,它们共同实现了稳健的会话管理。
CDS是媒体服务器的核心。它公开了一个容器和项目的分层树,类似于文件系统。每个对象携带元数据,包括Dublin Core属性(标题、创建者、日期)、UPnF特定属性(类、协议信息)和资源引用(比特率、分辨率、时长)。Browse()动作支持直接子项枚举和深度元数据检索,而Search()使用DIDL-Lite XML模式的子集实现按过滤条件查询。
Browse()动作的Filter参数允许客户端仅请求它们需要的元数据字段。这极大地减少了XML负载大小——对于电力线或Wi-Fi等带宽受限网络来说是一项关键优化。CMS管理媒体服务器和渲染器之间的数据平面。它维护一个活动连接列表,每个连接由ConnectionID标识。PrepareForConnection()动作在传输开始前分配资源,而GetCurrentConnectionInfo()返回传输协议和交付状态。CMS还公开GetProtocolInfo(),以便控制点可以协商双方支持的传输协议(HTTP GET、RTSP、RTP)。
| 状态变量 | 类型 | 描述 |
|---|---|---|
| ProtocolInfo | string (CSV) | 支持的协议逗号分隔列表(例如 http-get:*:audio/mpeg:*) |
| CurrentConnectionIDs | string | 活动连接标识符列表 |
| SourceProtocolInfo | string | 媒体服务器可发起的协议 |
| SinkProtocolInfo | string | 媒体服务器可接收的协议 |
AVT控制单个传输流的播放状态。其状态机包括STOPPED(停止)、PLAYING(播放中)、PAUSED(暂停)、TRANSITIONING(转换中)和NO_MEDIA_PRESENT(无媒体)。Play()、Pause()、Stop()、Seek()和Next()/Previous()等动作直接映射到媒体播放器控件。GetPositionInfo()和GetTransportInfo()查询实时报告播放进度。
TRANSITIONING状态期间执行AVT Seek()动作可能产生未定义行为。生产实现必须通过互斥锁保护的命令队列序列化查找请求,在分发任何传输动作前检查CurrentTransportState。在实现符合ISO/IEC 29341-3-3的媒体服务器时,工程师应特别注意事件通知架构。媒体服务器使用UPnP通用事件通知架构(GENA)将状态变更推送到已订阅的控制点。AVT服务中的LastChange事件变量将所有传输状态转换聚合到单个XML文档中,减少了网络通信量。对于内存有限的嵌入式设备,考虑采用双线程架构:一个低优先级的事件订阅管理器和一个高优先级的传输引擎。
另一个关键考虑因素是CMS中的TransferIDs状态变量。每个传输必须使用唯一的4字节整数标识符进行跟踪,服务器必须对已完成的传输进行垃圾回收以避免ID耗尽。对于大多数住宅用途,256个条目的循环缓冲区已足够。此外,CMS协议协商必须处理MIME类型通配符——这是不同厂商实现之间互操作性失败的常见原因。
ProtocolInfo设置为包含rtsp:*:*:*,并使用AVT的Seek()动作配合rel_time参数进行直播流缓冲控制。ConnectionIDs列表。每个客户端会话是独立的,但总并发连接数由实现定义。典型的家用服务器支持4-8个并发连接。超出此限制会导致PrepareForConnection()返回错误代码。