对比文件名称：2006-06-01_WO2006057938A_发明申请_WO2006057938A2 METHOD AND APPARATUS FOR CHANNEL CHANGE IN DSL SYSTEM
目标专利名称：379经译码多媒体数据的网络串流期间的表示之间的切换CN103843301B
本次调用的模型名称：DeepSeek-R1
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述方法包括:确定所述多媒体内容的第一表示的切换点之间的第一间隔和所述多媒体内容的第二表示的切换点之间的第二间隔。<br>**隐含公开** | [p0044] “Each picture in the channel change stream is associated with a normal stream picture, but not all pictures present in the normal stream need to have an associated picture in the channel change stream. Coded pictures in the channel change stream may be coded at a lower resolution than pictures in the normal stream. I pictures occur more frequently in the channel change stream, to enable more frequent random access.” <br> [p0050] “Once an I frame is received from the normal stream, the STB 250 sends a leave request for the channel change stream, and sends the normal stream data to the decoder 254. If an I frame is received in the channel change stream before an I frame is received in the normal stream, the channel change stream data is sent to the decoder 254, until an I frame is received in the normal stream.” | 对比文件公开了为同一节目提供两个并行码流：正常码流（normal stream）和频道更改码流（channel change stream）。其中明确说明，频道更改码流中的I帧（即随机接入点/切换点）出现得更频繁（“more frequently”），以实现更频繁的随机接入。这意味着频道更改码流的切换点间隔（第一间隔）小于正常码流的切换点间隔（第二间隔）。虽然对比文件未明确描述客户端“确定”这一间隔的步骤，但其整个频道切换方法（同时订阅两个码流并选择最先到达的I帧）正是基于这两个码流具有不同I帧频率（即不同切换点间隔）这一前提。本领域技术人员能够毫无疑义地从对比文件公开的内容中，推理出客户端（STB）需要知晓或能够确定这两个码流的切换点间隔差异，以执行其切换逻辑。因此，该技术特征被对比文件隐含公开。 |
| **技术特征B**：其中所述第一间隔小于所述第二间隔。<br>**直接公开** | [p0044] “I pictures occur more frequently in the channel change stream, to enable more frequent random access.” | 对比文件直接且明确地指出，频道更改码流（对应于第一表示）中的I帧比正常码流（对应于第二表示）中出现得更频繁。I帧更频繁即意味着切换点之间的间隔更小。因此，“第一间隔小于第二间隔”这一技术特征被对比文件直接公开。 |
| **技术特征C**：基于所述确定，提交对来自所述第一表示的相当数量的视频数据的一个或多个网络请求，来自所述第一表示的相当数量的视频数据具有至少等于所述第二表示中的切换点之间的重放时间的重放时间。<br>**隐含公开** | [p0050] “When a user indicates a channel change ... the channel change processing unit 259 sends to the DSLAM 230 both a join request for the channel change stream and a join request for the normal stream.” <br> [p0050] “If an I frame is received in the channel change stream before an I frame is received in the normal stream, the channel change stream data is sent to the decoder 254, until an I frame is received in the normal stream.” <br> [p0044] “I pictures occur more frequently in the channel change stream...” | 对比文件公开了在收到频道更改请求后，客户端（STB）同时提交对频道更改码流（第一表示）和正常码流（第二表示）的加入请求（join request）。客户端随后接收来自第一表示（频道更改码流）的数据，并在接收到第二表示（正常码流）的I帧之前，持续解码和/或缓冲第一表示的数据。本领域技术人员可以理解，客户端从第一表示接收并（可能）缓冲数据的过程，一直持续到第二表示的切换点（I帧）出现为止。这意味着客户端从第一表示获取的数据量（以重放时间计），至少需要覆盖从切换开始到第二表示第一个可用切换点之间的时间段，这个时间段实质上等于或至少关联于第二表示的切换点间隔。因此，对比文件隐含公开了基于两个表示切换点间隔不同的确定，提交对来自第一表示的视频数据的请求，且该请求所获取的数据量（在实际操作中）至少需要满足覆盖第二表示切换点间隔的重放时间，以实现无缝切换。 |
| **技术特征D**：在提交对来自所述第一表示的相当数量的视频数据的所述请求之后，检索来自所述第二表示的视频数据。<br>**直接公开** | [p0050] “Once an I frame is received from the normal stream, the STB 250 sends a leave request for the channel change stream, and sends the normal stream data to the decoder 254.” | 对比文件明确描述了在正常码流（第二表示）的I帧（切换点）到达后，客户端停止订阅频道更改码流（第一表示）并开始将正常码流的数据送至解码器。这直接对应于“在提交对来自第一表示的视频数据的请求之后，检索来自第二表示的视频数据”这一技术特征。 |
| **技术特征E**：其进一步包括缓冲来自所述第一表示的视频数据，以及基于所述经缓冲的视频数据的持续时间确定何时检索来自所述第二表示的视频数据。<br>**隐含公开** | [p0050] “If an I frame is received in the channel change stream before an I frame is received in the normal stream, the channel change stream data is sent to the decoder 254, until an I frame is received in the normal stream.” <br> 图3方法300中的决策块325、330、340和功能块335、345。 | 对比文件描述了客户端在切换后接收第一表示（频道更改码流）的数据并解码（解码过程必然涉及数据的缓冲）。切换至第二表示（正常码流）的决策点是基于“正常码流的I帧是否可用”（图3决策块325，340）。这个决策逻辑隐含着一种基于时间或数据接收状态的判断：客户端在接收和缓冲第一表示数据的同时，监视第二表示中切换点（I帧）的到来。一旦第二表示的切换点可用，就切换到第二表示。因此，“基于经缓冲的视频数据的持续时间确定何时检索来自第二表示的视频数据”这一技术方案，可以从对比文件公开的“等待并监视第二表示I帧到达”的操作中合理地推断出来，因为缓冲数据的持续时间与等待I帧到达的时间是相关联的。 |
| **技术特征F**：其中基于所述经缓冲的视频数据的所述持续时间检索来自所述第二表示的视频数据包括在缓冲来自所述第一表示的视频数据的持续时间之后检索来自所述第二表示的数据，来自所述第一表示的视频数据的所述持续时间等于所述第二表示中的切换点之间的所述重放时间。<br>**未公开** | 无对应原文引用。 | 对比文件虽然描述了在第二表示（正常码流）的I帧到达时切换，但并未将切换的触发条件明确关联到“缓冲来自第一表示的视频数据的持续时间等于第二表示中切换点之间的重放时间”。对比文件的切换触发是事件驱动的（I帧到达），而非基于对第一表示缓冲持续时间的量化计算或比较。本领域技术人员无法从对比文件中毫无疑义地得出或合理推断出这一具体的、量化的定时关系。因此，该技术特征未被对比文件公开。 |
| **技术特征G**：其进一步包括:确定当前可用网络带宽量。<br>**未公开** | 无对应原文引用。 | 对比文件主要解决频道切换延迟问题，其技术方案关注于通过并行码流减少等待I帧的时间，并未涉及根据实时变化的网络带宽条件来确定或选择码流。整个方案描述中未提及客户端需要确定当前可用网络带宽量。因此，该技术特征未被对比文件公开。 |
| **技术特征H**：接收指示所述第一表示和所述第二表示具有共同位速率的所述多媒体内容的清单。<br>**未公开** | 无对应原文引用。 | 对比文件中的第一表示（频道更改码流）和第二表示（正常码流）具有不同的特性，包括码率（channel change stream是“relatively low bitrate”[p0041]，“lower bitrate”[p0053]）。对比文件没有提及任何“清单”（如MPD文件），也没有描述这两个表示具有“共同位速率”。因此，该技术特征未被对比文件公开。 |
| **技术特征I**：以及在确定所述共同位速率可由所述当前可用网络带宽量满足之后选择所述第一表示和所述第二表示。<br>**未公开** | 无对应原文引用。 | 该技术特征依赖于特征G（确定当前带宽）和特征H（具有共同位速率的清单），这两个特征均未被对比文件公开。此外，对比文件中的码流选择是基于频道切换请求和I帧到达，而非基于对带宽与码率匹配性的动态评估。因此，该技术特征未被对比文件公开。 |
| **技术特征J**：其进一步包括:确定当前可用网络带宽量。<br>**未公开** | 无对应原文引用。 | 同技术特征G，未被公开。 |
| **技术特征K**：接收指示所述第一表示具有第一位速率且所述第二表示具有高于所述第一位速率的第二位速率的所述多媒体内容的清单。<br>**隐含公开** | [p0041] “...a relatively low bitrate, low resolution channel change stream is encoded, in addition to the normal coded stream.” <br> [p0053] “...the channel change stream coded pictures are coded at a lower bitrate than the normal stream pictures.” | 对比文件明确公开了第一表示（频道更改码流）是低码率（low bitrate）的，而第二表示（正常码流）是正常码率的。这隐含了第一位速率低于第二位速率。虽然对比文件未明确提及“清单”这一概念，但其描述了为每个节目编码这两种码流，并且客户端（STB）知道这两种码流的存在并能够订阅它们。本领域技术人员可以理解，客户端需要通过某种信令或信息（可广义理解为一种节目或流描述信息）来获知不同码流（表示）及其属性（如码率差异），以便发出正确的加入请求。因此，接收指示两个表示具有不同码率（第一较低，第二较高）的信息这一技术特征，可以被认为被对比文件隐含公开。 |
| **技术特征L**：确定所述第二位速率是否可由所述当前可用网络带宽量满足，其中请求来自所述第一表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后请求来自所述第一表示的所述视频数据，且其中在请求来自所述第一表示的所述视频数据之后检索来自所述第二表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后检索来自所述第二表示的所述视频数据。<br>**未公开** | 无对应原文引用。 | 该技术特征的核心在于根据实时网络带宽对高码率第二表示的“可满足性”进行评估，并基于此评估结果来决定是否以及何时请求第一表示并随后切换到第二表示。对比文件的方案是固定的：一旦用户发起频道切换请求，就立即同时请求两个码流，切换决策仅基于I帧的到达，完全不涉及对当前网络带宽是否足以支持高码率正常码流的判断。因此，该技术特征未被对比文件公开。 |
| **技术特征M**：其中请求来自所述第一表示的所述视频数据包括:将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置；经由单播接收来自所述第一表示的所述视频数据。<br>**未公开** | [p0049] “the normal stream and the channel change stream are multicast on separate flows” <br> [p0050] “sends to the DSLAM 230 both a join request for the channel change stream and a join request for the normal stream.” | 对比文件明确说明正常码流和频道更改码流是通过多播（multicast）方式传输的，客户端发送的是多播加入请求（join request）。这与技术特征M中明确限定的“单播”（unicast）接收方式不同。因此，该技术特征未被对比文件公开。 |
| **技术特征N**：且其中检索来自所述第二表示的所述视频数据包括经由多播或广播的至少一者从所述服务器装置检索所述视频数据。<br>**直接公开** | [p0049] “the normal stream and the channel change stream are multicast on separate flows” <br> [p0050] “sends to the DSLAM 230 both a join request for the channel change stream and a join request for the normal stream.” | 对比文件明确公开了第二表示（正常码流）是通过多播（multicast）流传输的，并且客户端通过发送加入请求（join request）来检索该多播流的数据。这直接对应于“经由多播从服务器装置检索所述视频数据”。因此，该技术特征被对比文件直接公开。 |
| **技术特征O**：其进一步包括接收所述多媒体内容的清单文件，其中确定所述第一间隔包括从所述清单文件中的信息确定所述第一间隔，且其中确定所述第二间隔包括从所述清单文件中的信息确定所述第二间隔。<br>**未公开** | 无对应原文引用。 | 对比文件未提及任何形式的“清单文件”（如MPD）。虽然客户端需要知道两个码流的存在和属性，但对比文件并未描述通过一个集中的清单文件来获取切换点间隔信息。切换点间隔的差异是通过对编码方案的描述（I pictures occur more frequently...）间接说明的，而非通过客户端可解析的文件来传达。因此，该技术特征未被对比文件公开。 |
| **技术特征P**：其中所述第一表示和所述第二表示具有共同位速率，所述方法进一步包括:在确定所述第一间隔和所述第二间隔之前，检索来自具有不同于所述共同位速率的位速率的第三不同表示的视频数据。<br>**未公开** | 无对应原文引用。 | 对比文件中的第一表示（频道更改码流）和第二表示（正常码流）不具有共同位速率（参见特征H、K）。此外，对比文件也未描述在频道切换流程中存在或需要检索第三个具有不同位速率的表示。因此，该技术特征未被对比文件公开。 |
| **技术特征Q**：确定当前可用网络带宽量。<br>**未公开** | 无对应原文引用。 | 同技术特征G、J，未被公开。 |
| **技术特征R**：基于所述第一表示和所述第二表示的所述共同位速率更适于所述当前可用网络带宽量的确定，确定所述第一间隔和所述第二间隔，提交对于来自所述第一表示的所述视频数据的所述一个或多个网络请求，以及检索来自所述第二表示的所述视频数据。<br>**未公开** | 无对应原文引用。 | 该技术特征涉及基于“共同位速率”对当前带宽的适应性评估来驱动整个流程（确定间隔、提交请求、检索数据）。如前述，对比文件不存在“共同位速率”的概念（特征H、P），也不存在基于实时带宽适应性的选择逻辑（特征G、L）。其流程由频道切换请求触发，由I帧到达事件驱动，与带宽适应性无关。因此，该技术特征未被对比文件公开。 |
| **技术特征S**：其中检索来自所述第二表示的视频数据包括从所述第二表示的切换点开始检索来自所述第二表示的视频数据。<br>**直接公开** | [p0050] “Once an I frame is received from the normal stream, the STB 250 ... sends the normal stream data to the decoder 254.” <br> 图3方法300中，功能块350“解码正常码流”是在功能块345“取消订阅频道更改码流程序”之后，而取消订阅动作发生在决策块325或340判断“正常码流中I帧可用”之后。 | 对比文件明确描述，切换到正常码流（第二表示）并开始解码的时刻，是在接收到正常码流的I帧（即切换点）之后。这意味着对第二表示数据的检索和解码正是从该切换点开始的。因此，该技术特征被对比文件直接公开。 |
<<<B>>><<<D>>><<<N>>><<<S>>><<<a>>><<<c>>><<<e>>><<<k>>>