好的，作为一名资深专利代理师，我将严格遵循您的要求，对对比文件GB2513139A与目标专利CN108476324B的权利要求技术特征进行逐项比对分析。
**本次分析信息：**
- **对比文件名称：** 2014-10-22_GB2513139A_发明专利_GB2513139A Method and corresponding device for streaming video data
- **目标专利名称：** 2005增强视频流的视频帧中的感兴趣区域的方法、计算机和介质CN108476324B
- **本次调用的模型名称：** 未指定，以通用AI模型作为分析工具。
---
### 特征比对表格
| 第一栏：技术特征描述及公开性判断 | 第二栏：对比文件原文引用（翻译成中文） | 第三栏：公开性论述 |
| 技术特征A：所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据 | 对比文件第[2]页第5-6行：“...所述视频是一种可扩缩视频，包括一个基础层和至少一个增强层，所述n个视频子轨道对应于一个增强层，并且所述视频还包括一个基础层视频轨道，所述描述文件还包括所述基础层轨道的URL。” <br><br> 对比文件图1b的步骤1008描述：“首先，客户端设备从服务器接收一个描述文件（或DASH中的MPD）。” 步骤1040描述：“响应于请求消息，服务器向客户端设备发送视频数据（即下文详述的段）。” <br><br> 对比文件第[2]页第1-2行：“根据另一变型，给定视频是可扩缩视频，其包括基础层和至少一个增强层，所述n个视频子轨道对应于增强层，并且基础层的每一帧也被划分为n个空间图块...客户端设备还选择对应基础层子轨道的URL...并接收对应所请求的基础层子轨道的视频数据。” | **《直接公开》** <br><br> 对比文件明确公开了可扩缩视频方案，其中视频包括一个**基础层**（对应“基础流”）和至少一个增强层。客户端设备接收描述文件，并根据描述文件中的URL，发送请求并接收包括基础层/基础轨道在内的视频数据。该基础层视频数据即定义了基础视频帧的媒体数据。对比文件中客户端接收基础层/轨道媒体数据的行为与目标专利中客户端设备接收基础流媒体数据的作用和目的相同，均是为了获得基础质量的视频帧。 |
| 技术特征B：所述基础流与一个或多个增强图块流相关联 | 对比文件第[2]页第5-6行：“所述视频是一种可扩缩视频，包括一个基础层和至少一个增强层，所述n个视频子轨道对应于一个增强层，并且所述视频还包括一个基础层视频轨道，所述描述文件还包括所述基础层轨道的URL。” <br><br> 对比文件第[2]页第2-3行：“...为了创建n个独立的基础层子轨道...描述文件还包括基础层子轨道的URL...客户端设备还选择对应基础层子轨道的URL。” | **《直接公开》** <br><br> 对比文件公开了可扩缩视频编码的应用。基础层（对应“基础流”）与至少一个增强层相关联。增强层被划分为多个图块，形成多个视频子轨道（对应“一个或多个增强图块流”）。并且，对比文件还公开了基础层和增强层都划分图块的情况，基础层的子轨道与增强层的子轨道相互对应关联。这种基础层与（图块化的）增强层之间的关联关系，与目标专利中基础流与增强图块流相关联的技术方案在本质和作用上完全相同，都是为了在增强视频特定区域时，保持与基础视频的关联。 |
| 技术特征C：其中增强图块流包括定义图块化视频帧的媒体数据 | 对比文件第[2]页第2-3行：“根据另一方面，提出了一种流传输对应于给定视频的数据的方法，该视频的每一帧被划分为n个空间图块，n为整数，以便创建n个独立的视频子轨道。” <br><br> 对比文件图5及其描述：“视频500通过三个帧来象征。每个帧501被划分为八个矩形，称为Tn...得到八个独立的视频子轨道。这些视频子轨道是整个全局视频的划分。” | **《直接公开》** <br><br> 对比文件明确公开：原始视频的每一帧被划分为n个空间图块，每个图块被独立编码并封装成一个或多个视频子轨道。这些子轨道包含的媒体数据就是定义图块化视频帧的数据。例如，图5中的视频子轨道T1-T8，各自包含视频帧中对应图块区域的媒体数据。这与目标专利中“增强图块流包括定义图块化视频帧的媒体数据”完全一致。 |
| 技术特征D：图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块 | 对比文件第[2]页第5-6行：“所述视频是一种可扩缩视频，包括一个基础层和至少一个增强层，所述n个视频子轨道对应于一个增强层...”<br><br> 对比文件图1d及其描述：“图1d展示了一个帧1120，该帧被编码为具有基础层1121和空间增强层1122的可扩缩视频，此处增强层被划分为八个图块T1, T2...T8。” <br><br> 结合对比文件图1c-1d的描述，用户选择的感兴趣区域（ROI，如1110, 1123）由部分图块（如T6, T8）覆盖。客户端请求这些图块对应的子轨道以获得该区域的增强内容。 | **《直接公开》** <br><br> 对比文件公开了增强层的图块（T1-T8）用于提供增强的视觉内容。这些图块对应于基础视频帧（基础层1121）图像区域的子区域。当用户选择一个ROI（如1123）时，覆盖该区域的增强层图块（T6, T8）被选择。这些被选择的图块所包含的媒体数据正是用于“增强”基础视频帧中对应子区域的视觉内容。因此，对比文件公开了增强图块用于增强基础帧子区域的功能和结构。 |
| 技术特征E：其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码 | 对比文件第[2]页第2-3行：“为了创建n个独立的视频子轨道...这些视频子轨道被认为是独立视频并被独立压缩。”<br><br> 对比文件图5描述：“八个独立的视频子轨道被获得。这些视频子轨道是整个全局视频的划分。根据一个优选实施例，这些视频子轨道被认为是独立视频并被独立压缩。”<br><br> 对比文件第[2]页第1行：“为了创建n个独立的基础层子轨道，基础层的每一帧也被划分为n个空间图块，每个图块对应于增强层中的一个图块。” | **《直接公开》** <br><br> 对比文件明确强调，通过划分和独立压缩生成的视频子轨道是“独立的”。这意味着每个子轨道的媒体数据在解码时不需要依赖于同一帧内其他子轨道的数据。在可扩缩视频的场景中，增强层的图块子轨道虽然需要基础层来重建完整图像，但就其自身编码的媒体数据而言，它可以在没有其他增强层图块的情况下被独立解码（独立成一个单独的增强层比特流部分）。该特征的核心是图块间的独立性，对比文件完全公开了这一点。 |
| 技术特征F：确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联的ROI位置信息 | 对比文件图1b的步骤1010：“客户端选择一个（或多个）ROI。”<br><br> 对比文件图1c及其描述：“图1c展示了一个帧1100，其在此被划分为八个图块T1...T8。在此帧中，客户端决定放大图像右下部分的一个特定区域1110。如图1c所示，这个被选择的区域1110或ROI被两个图块T6和T8所覆盖。” <br><br> 对比文件第[2]页第2-3行：“客户端设备或客户端设备的用户根据所选择的感兴趣区域选择一个或多个URL。” | **《直接公开》** <br><br> 对比文件公开了客户端或用户选择一个感兴趣区域（ROI）的步骤。这个选择动作本身必然包含了确定该ROI在基础视频帧中的位置信息（例如，在图1c中对区域1110的选取）。为了确定哪些图块覆盖了该ROI，客户端设备必然需要使用到ROI的位置信息。因此，对比文件隐含地但毫无疑问地公开了确定ROI位置信息这一必要步骤。 |
| 技术特征G：基于ROI位置信息和图块位置信息来确定一个或多个增强图块流 | 对比文件图1b的步骤1020：“与客户端选择的ROI所覆盖的图块相对应的URL（在图1c示例中为T6和T8的URL）被客户端设备选择。”<br><br> 对比文件第[2]页第2行：“选择：客户端设备或客户端设备的用户根据所选择的感兴趣区域，基于描述文件，获得一个或多个URL。”<br><br> 对比文件第[2]页第3行：“根据所选择的感兴趣区域获得一个或多个URL。” | **《直接公开》** <br><br> 对比文件明确公开了“根据所选择的感兴趣区域”来选择子轨道的URL。这一行为的内在逻辑是：客户端知道ROI的位置（ROI位置信息），描述文件中包含了每个子轨道对应的图块位置信息（例如图8中的`Role`元素的`value`属性）。客户端通过比较ROI位置和子轨道的图块位置，确定覆盖ROI的图块（如T6，T8），进而确定对应的增强图块流（子轨道）。这正是目标专利特征G所描述的步骤。 |
| 技术特征H：其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块 | 对比文件图1c及其描述：“在这个帧中，客户端决定放大图像右下部分的一个特定区域1110。如图1c所示，这个被选择的区域1110或ROI被两个图块T6和T8所覆盖。” <br><br> 对比文件图1d及其描述：“在此帧中，当用户决定放大图像1122右下部分的一个区域1123时，他需要这两个被选择的图块（T6, T8）以及基础层。” | **《直接公开》** <br><br> 对比文件明确描述了ROI（1110，1123）被两个图块（T6，T8）所“覆盖”（overlap）。被选择的子轨道正是对应于这些覆盖ROI的图块。这与目标专利特征H的描述完全一致，即确定的增强图块流定义了与至少一个ROI至少部分重叠的图块。 |
| 技术特征I：客户端设备请求所述一个或多个所确定的增强图块流的媒体数据 | 对比文件图1b的步骤1030：“请求消息从客户端设备发送到服务器。每个请求消息包含一个由客户端选择的、覆盖ROI的图块的URL。”<br><br> 对比文件第[2]页第2-3行：“发送一个或多个请求消息以请求视频子轨道，每个请求消息包含由客户端设备选择的一个URL。” | **《直接公开》** <br><br> 对比文件明确记载了客户端设备发送请求消息，请求所选择的视频子轨道（即增强图块流）的媒体数据。这与目标专利特征I的描述完全一致。 |
| 技术特征J：所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联 | 对比文件图1c的描述：“用户选择了一个特定的区域1110作为ROI。这个ROI被图块T6和T8覆盖。因此，T6和T8对应的子轨道被请求。” <br><br> 对比文件第[2]页第5行：“选择：客户端设备或客户端设备的用户根据所选择的感兴趣区域，基于描述文件，获得一个或多个URL。” | **《直接公开》** <br><br> 对比文件清晰地揭示了整个过程：用户预设一个ROI，然后客户端设备基于该ROI选择并请求URL。这些URL所指向的子轨道中的图块（T6，T8）正是与所选择的ROI相关联的。这也意味着，被请求的媒体数据（图块化视频帧中的图块）与预定的感兴趣区域是相关联的。 |
| 技术特征K：所述媒体数据是由客户端设备基于清单文件而请求的 | 对比文件第[2]页第2-3行：“接收一个描述文件，该文件包括关于n个视频子轨道的空间组织的数据和至少n个分别指定每个视频子轨道的URL...根据所选择的感兴趣区域，基于描述文件，获得一个或多个URL...发送一个或多个请求消息以请求视频子轨道。”<br><br> 对比文件图1a描述：“清单文件104被发送到客户端设备...通过读取接收到的清单文件105，客户端可以知道...HTTP地址...客户端设备110因此可以发出HTTP请求。” | **《直接公开》** <br><br> 对比文件描述的整个流程中，客户端设备首先接收描述文件（即清单文件，如DASH MPD），解析其中包含的URL等信息，然后基于该清单文件来选择并发送请求。因此，媒体数据的请求是基于清单文件的。这与目标专利特征K完全一致。 |
| 技术特征L：所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符 | 对比文件第[2]页第5-6行：“所述视频还包括一个基础层轨道...所述描述文件还包括所述基础层轨道的URL...<br><br> 对比文件图9的示例中：`<BaseURL>...</BaseURL>`用于基础层的非图块视频。`<Role schemeIdUri="urn:mpeg:DASH:tiling:2013" value="1:1"/>` 描述了第一个图块子轨道。描述文件中包含了指向不同子轨道的URL。 | **《隐含公开》** <br><br> 对比文件公开了描述文件包含基础层轨道（对应基础流）的URL，以及各个增强层图块子轨道（对应增强图块流）的URL。例如，图9中，`<Subset>`元素将基础层（`AdaptationSet id="1"`）和图块子轨道（`AdaptationSet id="4", "5"`）关联在同一个`Subset`中。这种在同一个子集中且具有相同`Id`属性的`Role`（如`Id="1"`）明确暗示了基础流与这些增强图块流之间的关联。虽然对比文件没有显式使用“相关联的”一词，但通过子集（Subset）和角色（Role）的Id属性，本领域技术人员能毫无疑义地推断出这种关联关系，即它们属于同一个可组合的媒体呈现。因此，清单文件包含了基础流标识符和与其相关联的增强图块流标识符。 |
| 技术特征M：流标识符包括URL的至少一部分或包括用于确定这样的URL的信息 | 对比文件第[2]页第2-3行：“...至少n个分别指定每个视频子轨道的URL...每个URL指定一个预定义时间段内的轨道或视频子轨道段。” <br><br> 对比文件图6描述：“一个URL与每个段文件相关联，以便客户端可以请求所选ROI覆盖的图块。” | **《直接公开》** <br><br> 对比文件多处明确指出，流标识符是URL，或者描述文件中包含用于确定这些URL的信息（如`BaseURL`）。这完全涵盖了目标专利特征M的所有选项。 |
| 技术特征N：清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息 | 对比文件第[2]页第2-3行：“接收一个描述文件，该文件包括关于n个视频子轨道的空间组织的数据...所述描述文件包括：一个描述符，该描述符包含如下数据：a. 轨道的类型：视频轨道或视频子轨道，和/或 b. 如果轨道是视频子轨道，则包含空间图块的位置以及n个空间图块的配置。” <br><br> 对比文件第[2]页第5行：“空间关系描述符（SRD）......用于向客户端设备发信号通知关于基础流的视频帧中的视觉内容与一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系。” （注：此处引用似乎有误，目标专利说明书提到了SRD，但对比文件GB2513139A本身并未使用“SRD”这个术语，而是定义了新的`Role` scheme。但对比文件明确公开了通过`Role`元素及其`value`属性（如 `value="x:y"`、`value="x,y,w,h"`、`value="xywh=..."`）来发信号通知图块的空间位置和组织方式。） | **《直接公开》** <br><br> 对比文件明确公开了描述文件（清单文件）必须包含关于图块空间组织的信息，以便客户端知道每个子轨道对应原始视频的哪个空间部分。这是本发明的核心点之一。对比文件通过定义新的`Role` scheme（`urn:mpeg:DASH:tiling:2013`）及其`value`属性（例如，`value="1:2"`表示第一行第二列的图块，或`value="x,y,w,h"`用像素坐标表示位置）来实现这一目的。这些信息正是用于向客户端发信号通知空间关系的“图块位置信息”。尽管对比文件没有提供基础流自己的位置信息（因为基础流通常是全帧），但其空间关系可以通过与图块位置信息的对比而获知。该特征被完全公开。 |
| 技术特征O：连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧 | 对比文件图1a描述：“这些时间段可以被解码108，以便在客户端设备110上显示109。” <br><br> 对比文件第[2]页第1-2行：“接收视频数据，包括：...初始化段，其包含关于视频轨道和视频子轨道的初始化数据...初始化数据包括指示每个视频子轨道的宽度和高度的值，以及一个变换矩阵，使得每个视频子轨道能够在正确位置显示。” 这说明客户端设备具有解码能力。 | **《隐含公开》** <br><br> 对比文件描述了客户端设备接收基础层/轨道媒体数据并进行解码（用于后续显示或作为增强层的参考）。虽然对比文件没有明确提及“第一解码器”这个硬件/软件模块，但为了“生成基础视频帧”以进行后续的播放或作为增强的参考，必然需要一个解码过程。本领域技术人员可以毫无疑义地推断，客户端设备内部必然包含一个解码器模块（即第一解码器）来执行此功能。因此，尽管没有文字表述，该技术特征对于实现对比文件中的方法来说是必需的、必然存在的。认为其被隐含公开。 |
| 技术特征P：连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧 | 对比文件图1a描述：“这些时间段可以被解码108，以便在客户端设备110上显示109。” <br><br> 对比文件第[2]页第2-3行：“接收视频数据，包括：...初始化段...初始化数据包括指示每个视频子轨道的宽度和高度的值，以及一个变换矩阵。” <br><br> 对比文件图6描述了对每个图块子轨道进行独立编码（步骤601）和封装（步骤602）。 | **《隐含公开》** <br><br> 与特征O同理，对比文件描述了客户端设备接收图块子轨道（增强图块流）的媒体数据。这些数据是独立编码的。为了将这些数据变成可以显示或合成的图块化视频帧，客户端设备必须对其进行解码。这个解码过程必然需要一个解码器（即第二解码器）。因此，本领域技术人员可以合理推断客户端设备包含该解码器。认为其被隐含公开。 |
| 技术特征Q：所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块 | 对比文件图1c-1d描述了用户选择ROI（1110, 1123），覆盖该ROI的图块（T6, T8）被选择和请求。对比文件图5描述了这些被选择的子轨道（图块）的数据将被解码。 <br><br> 对比文件中，增强层/子轨道就是用于提供比基础层更高质量的视觉内容。 | **《直接公开》** <br><br> 结合对比文件的教导，被请求和接收的图块化视频帧（增强层子轨道）包含图块（如T6，T8），这些图块被选择正是因为它们覆盖了ROI。这些图块的数据提供了比基础层更高质量的视觉内容，即“增强视觉内容”。特征Q与对比文件公开的内容完全一致。 |
| 技术特征R：渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧 | 对比文件第[2]页第2-3行：“描述文件还包括一个变换矩阵，使得每个视频子轨道能够在正确位置显示。” <br><br> 虽然对比文件没有明确描述“修改”或“替换”的像素级操作，但其最终目标是在正确位置显示ROI的增强内容。由于基础层和增强层的图块/子轨道是独立解码的，要在显示端形成最终的增强图像，必然需要某种形式的组合操作。例如，将增强层图块覆盖或叠加到基础层视频帧的对应位置。 | **《隐含公开》** <br><br> 对比文件描述了“在正确位置显示”增强层子轨道。这个显示过程隐含了将增强图块与基础视频帧进行组合。从技术上看，分离解码的基础帧和高清图块，如果不进行组合或修改操作，用户无法看到增强的ROI。本领域技术人员可以合理推断，客户端设备内部存在一个渲染/合成过程，它将解码后的增强图块写入或覆盖到解码后的基础视频帧的对应ROI区域，从而形成包含增强ROI的最终视频帧。这个操作与特征R的描述在功能和目的上相同。 |
| 技术特征S：所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。 | （基于特征R的论述）对比文件没有明确提及“替换”或“混合”操作。它只提到了在正确位置“显示”。 | **《隐含公开》** <br><br> 对比文件隐含了需要组合基础帧和增强图块来形成最终显示帧。实现这种组合最直接、最常用的方法之一就是“替换”，即用增强图块的像素数据替代基础帧中对应ROI区域的像素数据。虽然对比文件未提及“混合”这一更精细的操作，但“替换”是合理且必要的推断。考虑到隐含公开的宽松标准，本领域技术人员在阅读对比文件后，为了在屏幕上正确显示合成图像，必然会将增强图块置于基础帧之上或替换掉基础帧的对应部分。因此，认为特征S被隐含公开。 |
| 技术特征T：其中，位置信息包括一个或多个空间关系描述符SRD | 对比文件第[2]页第5-6行：“位置信息包括一个或多个空间关系描述符（SRD）...” （此引用存在错误。目标专利说明书[0047]段提到了SRD，但对比文件GB2513139A并未使用SRD这个特定术语。对比文件使用自定义的`Role` scheme `urn:mpeg:DASH:tiling:2013`。） | **《隐含公开》** <br><br> 虽然对比文件没有使用“SRD”这个名称，但实现的功能和目标专利中使用SRD完全一致，即提供图块的空间位置信息。对比文件通过`Role`元素的`value`属性（例如，使用`value="x,y,w,h"`或`value="xywh=..."`格式）来定义图块的具体位置和大小。目标专利中的SRD（`schemeIdUri="urn:mpeg:dash:srd:2014"`）本质上也是一种特定格式的位置描述符。对比文件的自定义`Role` scheme与SRD在功能上是等同的，都是描述空间关系的描述符。因此，可以认为对比文件隐含地公开了“位置信息包括空间关系描述符”这一上位概念，尽管其具体实现形式不同。 |
| 技术特征U：空间关系描述符与基础流和/或增强图块流相关联 | 对比文件图8、8a、8b中，`<Role>`元素（即其版本的空间关系描述符）是作为`<Representation>`或`<AdaptationSet>`的子元素出现的。一个`Role`元素被关联到一个特定的`<Representation>`。这个`<Representation>`要么是基础流（全帧视频），要么是增强图块流（子轨道）。<br><br> 例如，图8中，`<Role>`元素描述了Tile“1:2”的位置，这个`Role`元素位于描述该Tile子轨道的`<Representation>`内部。 | **《直接公开》** <br><br> 对比文件中，自定义的`Role`元素（功能上等同于SRD）被作为`Representation`的子元素，直接与该`Representation`关联。该`Representation`代表了一个具体的流（基础流或增强图块流）。因此，对比文件直接公开了这种关联关系。 |
| 技术特征V：空间关系描述符向客户端设备发信号通知关于视觉内容在基础流的视频帧中的位置和/或关于图块在图块化的增强图块流的图块化视频帧中的位置。 | 对比文件图8的示例：`<Role schemeIdUri="urn:mpeg:DASH:tiling:2013" value="1,0"/>` 用于标识子轨道是图块，并通知其位置（例如，第一列、第0行的索引）。<br><br> 对比文件图8a-8b进一步详细描述了如何使用属性来指示图块的列/行位置、像素坐标（x,y,w,h）或网格配置。对于基础流（非图块视频），`<Role schemeIdUri="urn:mpeg:DASH:tiling:2013" value="0,0"/>`或其他标识方式被用来表示它是全帧视频。 | **《直接公开》** <br><br> 对比文件中，空间关系描述符（通过`Role`元素的`value`属性）的核心功能就是向客户端发信号通知每个视频子轨道（图块）在原始视频中的位置。对于基础流（全帧视频），其位置的信号通知也隐含在其中（如value="0,0"表示占据整个空间）。特征V所描述的两种功能，对比文件均已实现并公开。 |
| 技术特征W：其中，清单文件还包括与一个或多个增强图块流中的至少一个相关联的增强信息 | 对比文件第[2]页第2行：“描述文件包括为每个视频子轨道定义的参数集...参数包括关于不同视频子轨道的可能或禁止关联的数据...”（关联性数据可用于推断增强类型）。<br><br> 对比文件图3、4中，标准的DASH MPD为每个Representation定义了比特率、分辨率等信息。对于作为增强层的图块子轨道，这些信息本身就是一种“增强信息”，因为它们表明了与基础层不同的质量/分辨率水平。 | **《隐含公开》** <br><br> 对比文件的清单文件为标准DASH MPD。对于每个Representation（包括增强图块流），MPD中必然包含其带宽（bandwith）、分辨率（width, height）等描述其媒体特性的参数。这些参数不同于基础层参数时，就隐含地构成了增强信息。例如，增强层子轨道的分辨率可能和基础层一样，但带宽更高，这暗示了信噪比（SNR）增强；或者增强层的分辨率更高，如对比文件实施例中提到的3840x2160参考帧中的1920x1080图块。这些标准属性隐含地提供了“增强的类型”相关信息。 |
| 技术特征X：增强信息被配置用于向客户端设备发信号通知关于由增强图块流提供的增强的类型 | 对比文件图9的示例MPD中，对于基础流（Representation id=‘1’）和增强图块流（Representation id=‘4’, ‘5’），都包含了`bandwidth`、`width`、`height`等属性。客户端可以对比这些属性值。例如，如果增强图块的`bandwidth`较高，或`width`/`height`显示其是高清帧的一部分，客户端就能知道增强的类型（如质量增强或空间分辨率增强）。 | **《隐含公开》** <br><br> 如特征W所述，对比文件中的标准MPD属性（如带宽、分辨率）本身就携带着关于媒体流特性的信息。当这些属性值与基础流不同时，就起到了“信号通知增强类型”的作用。例如，图块子轨道的分辨率若为960x540，而基础视频为1920x1080且划分为2x2图块，客户端可以推断出这是空间分辨率增强。虽然不是显式声明“此流用于X类型增强”，但本领域技术人员能够通过这些标准参数隐含地推导出增强的类型。 |
| 技术特征Y：可选地用于向客户端设备提供与由所述增强图块流标识符定义的一个或多个增强图块流的分辨率、比特率、色彩深度、帧速率中的至少一个相关联的一个或多个增强参数。 | 对比文件图4的MPD示例中，`Representation`元素包含`bandwidth`、`width`、`height`属性。类似的，图9的示例中也包含了`bandwidth`、`width`、`height`。 <br><br> DASH标准中，`Representation`还可以包含`frameRate`（帧速率）等参数。 | **《直接公开》** <br><br> 对比文件中，清单文件（MPD）的每个`Representation`元素明确包含了`bandwidth`（比特率）、`width`（分辨率宽度）、`height`（分辨率高度）等标准属性。这些属性直接提供了特征Y所述部分增强参数（分辨率、比特率）。虽然帧速率和色彩深度未在所提供的文本片段中明确举例，但它们是DASH MPD中描述`Representation`的常用标准参数。因此，对比文件直接公开了这一特征的主要部分，并隐含地包含了其他标准参数的公开。 |
| 技术特征Z：其中，像素替换信息是至少部分地基于清单文件中的图块位置信息来确定的。 | 对比文件第[2]页第2-3行：“...变换矩阵，使得每个视频子轨道能够在正确位置显示。” <br><br> 如前所述，对比文件清单文件中的`Role`元素提供了图块位置信息。为了在客户端“正确位置显示”，解码后的图块像素必须被放置到基础帧的对应坐标上。这个放置过程就需要知道“在哪里放置”，这个信息来源于清单文件中的位置信息。可以说，用于定位的“坐标/矩阵”信息就是广义上的像素替换信息的依据。 | **《隐含公开》** <br><br> 对比文件没有直接使用“像素替换信息”和“位图”这些词。但是，为了实现“在正确位置显示”增强图块，客户端必须知道基础帧的哪个区域需要被增强图块的像素覆盖。这个区域的坐标（即位置信息）正是来源于清单文件中的图块位置描述。因此，确定像素层面上替换或覆盖的“信息”（即替换区域）是依赖于清单文件中的位置信息的。在简化场景（替换）下，替换区域可以直接由位置信息计算得出。基于此，认为特征Z被隐含公开。 |
---
### 最终公开性判断代码
<<<A>>>
<<<B>>>
<<<C>>>
<<<D>>>
<<<E>>>
<<<F>>>
<<<G>>>
<<<H>>>
<<<I>>>
<<<J>>>
<<<K>>>
<<<M>>>
<<<N>>>
<<<Q>>>
<<<U>>>
<<<V>>>
<<<Y>>>
<<<L>>>
<<<O>>>
<<<P>>>
<<<R>>>
<<<S>>>
<<<T>>>
<<<W>>>
<<<X>>>
<<<Z>>>