设备布局中的音频/视频流送的制作方法
【专利说明】设备布局中的音频/视频流送
[0001] 本申请是申请号为201110037409. 7、申请日为2011年1月27日、发明名称为"设 备布局中的音频/视频流送"的发明专利申请的分案申请。
【背景技术】
[0002] 本发明一般地涉及提供和接收视频和音频数据的设备。
[0003] 显示端口（DisplayPort)是视频电子标准协会（VESA)的数字音频/视频互连标 准。其允许视频和音频从计算机耦合到视频显示器或者音频回放系统。DisplayPort连接 器支持主链路中的1、2或4个数据对，该主链路还以1. 62、2. 7或者5. 4千兆比特每秒的码 元速率传输时钟信号和可任选音频信号。2006年5月批准了 1.1标准，且2009年宣布了增 大数据速率的1. 2标准。该DisplayPort1. 2标准使1. 1标准的的带宽加倍。
[0004] 利用DisplayPort1. 2标准，两个WQXGA监视器可从单个源链路接收音频/视频 数据，或者四个WUXGA监视器可从单个源链路接收数据。此外，1. 2标准允许可用于以通用 串行总线（USB)外围设备数据传输、话筒音频传输或者摄像机视频传输这几种应用为例的 更高速AUX。
[0005] 显示器或者宿设备可直接或者通过所谓的分支设备连接到诸如个人计算机或 者消费电子设备的源设备。存在许多类型的分支设备，包括中继音频或视频信息的中继 器、将音频或视频信息从一个格式转换到另一格式的转换器、复制数据的复制器、以及将 来自两个或更多个源设备的流作为输入且在其下游链路上传输这些流的集中器。诸如 DisplayPort1. 2的接口标准允许多个流在一个链路上；在这种情况下，这些两个或多个 的输入流可被传输到单个下游链路上。一些集中器可以切换方式操作，即一次仅可传输一 个所选源。
[0006] 源、宿以及分支设备一起形成布局，在该布局中给定源通过零个或多个分支设备 向一个或多个宿流送视频。活动视频数据流过连接各种设备类型的链路。每个链路受其带 宽和其支持的流的数量约束。宿将具有有限数量的音频和视频端点来呈现流。因此，基于 该布局，可存在可用视频或者音频资源的竞争。
[0007] 如图1所示的一种此类布局可包括2个源和5个宿，如图所示。1号源希望将视频 流送至1号宿，而2号源希望将视频流送至2号宿，2号分支和3号分支之间的链路是两个 路径公用的。因此，在源处可发生与这种竞争相关的问题，包括沿着该路径的该链路或者任 何其它链路中有多少带宽可用。另一问题是可如何保留该路径上的资源。又一问题是可驱 动多少音频/视频流。其它问题包括可如何控制对共享资源的访问以及如何传达错误。
[0008] 附图简述
[0009] 图1是根据一个实施例的音频/视频分配布局的示意图；
[0010] 图2是根据一个实施例的用于枚举、提交和释放的序列图；
[0011] 图3是分支设备的一个实施例的示意图；
[0012] 图4是根据一个实施例的枚举软件的流程图；
[0013] 图5是根据一个实施例的消息序列图；
[0014] 图6是根据一个实施例的用于枚举路径资源的序列图；
[0015] 图7是示出针对图6所示的布局可如何建立各种显示配置的序列图；
[0016] 图8是根据一个实施例的两个源和两个宿之间的潜在映射的描绘；
[0017] 图9是一个实施例的流程图；
[0018] 图10是一个实施例的流程图；
[0019] 图11示出根据一个实施例的消息序列；
[0020] 图12是根据一个实施例的上动作作路径消息序列；
[0021] 图13是根据一个实施例的目的地序列的映射；
[0022] 图14是根据一个实施例的上行链路动作路径消息的消息序列图；
[0023] 图15是根据一个实施例的源和分支设备之间的连接的描绘；
[0024] 图16是根据一个实施例的多个源和分支设备的描绘；
[0025] 图17是根据一个实施例具有两个视频端点的布局的描绘；以及
[0026] 图18是一个实施例的流程图。
【具体实施方式】
[0027] 根据一些实施例，可在提供和接收视频和音频数据的设备之间交换特定消息。沿 着源和宿设备之间的路径的设备可响应于那些消息采取协调动作。消息可被发送到由其地 址指定的目标目的地。如图2所示，可使用消息枚举_路径_资源（ENUM_PATH_RESOURCES)、 提交 _ 路径 _ 资源（COMMIT_PATH_RESOURCES)和释放 _ 路径 _ 资源（RELEASE_PATH_ RESOURCES)。举例而言，在DisplayPort规范中，这些消息可在AUX信道上传送。
[0028] 在消息传输之前生成地址空间。每个源10向期望宿16发送ENUM_PATH_RESOURCE 消息18,以枚举主链路带宽和流的数量。仅靠期望宿16在上游的分支设备14用可用带宽 (BW=x)和流的数量（#流=s)来作出响应，如20所示。在该回复传播到更远的上游之 前，上游分支12改变来自下游分支14的可用带宽（BW=X'）和流数量（#流=s'），以反映 可从下游路径获得的内容，如22所示。
[0029] 最终，源10获得路径资源。在控制总线（诸如DisplayPort上的AUX)上发送消 息，但查询是针对主链路资源的。控制总线上不作带宽保留，且在布局中的设备之间交换控 制消息，即使在一个或两个源要求得到全部主链路资源时也是如此。
[0030] 作为消息处理的一部分，每个设备可能需要沿着特定路径训练主链路以确定作为 下游链路可用的带宽的量。作为该过程的一部分还枚举音频资源。这是为了确定在任何给 定时间点可用于流送的端点的数量。
[0031] 链路带宽枚举向操作系统馈送诸如视频模式枚举的操作。基于此以及由要排除的 视频模式的最终用户的异步选择，可使用如下的COMMIT_PATH_RESOURCES消息24来实现提 交过程。在提交时间枚举带宽是不可用的。举例而言，在任何给定时间不同源可向同一宿 发送不同ENUM_PATH_RESOURCES消息。它们还可对具有有公共链路的路径的不同宿发送这 些消息。作为示例，1号源枚举、接着2号源提交、接着1号源提交的序列之后是例如2号源 提交，该2号源提交由于之前的1号源提交而失败。
[0032] 源10向宿16发送COMMIT_PATH_RESOURCE消息24。该消息具有所需带宽和流数 量。沿着指定路径（例如，分支12和14)的所有设备为该源保留资源。回复26和28可指 示成功或失败。
[0033] 只有当能够成功地提交所需资源时，各设备才传播COMMIT_PATH_RESOURCES24。 除了来自不同源设备的独立资源提交，沿路径的中间链路有可能被重新训练至较低带宽， 从而提供失败的另一原因。链路训练是为了使发射器或者接收器对电气配置达成协议而执 行的握手。为考虑设备的布局，这一概念被扩展至整个路径，其中路径上的每个链路需要以 称为路径训练的协同方式训练。
[0034] 有可能一些设备在下游设备提交失败之前可能已经成功地提交了用于视频流的 资源。为了释放这些资源，源设备可在接收到COMMIT_PATH_RESOURCES的失败之后发送出 RELEASE_PATH_RESOURCES30 消息。
[0035] 活动视频在COMMIT_PATH_RESOURCES成功完成之后开始。相反，当该流要被终止 时，该源发出RELEASE_PATH_RESOURCES32以在沿着路径的设备处实现已提交资源的释 放。
[0036] 参考图3,源10、宿16、和在图3中以34示出的分支设备12或14的每一个包括处 理器36。该处理器可耦合到接收器38和发射器40。该处理器