返回项目页面
对比文件列表
1975-08-29_None_发明专利_JPS5026202B1 JPS5026202B1 -_+++D_S_a_c_e+++.docx
2026-03-23 23:53
1998-09-14_None_发明专利_JPH10247485A Separator for secondary battery_+++A_a+++.docx
2026-03-23 23:53
2006-06-01_WO2006057938A_发明申请_WO2006057938A2 METHOD AND APPARATUS FOR CHANNEL CHANGE IN DSL SYSTEM_+++B_D_N_S_a_c_e_k+++.docx
2026-03-23 23:53
2007-08-08_EP1815684A_发明公开_EP1815684A2 METHOD AND APPARATUS FOR CHANNEL CHANGE IN DSL SYSTEM_+++A_B_d_m_s+++.docx
2026-03-23 23:53
2008-08-14_US2008196061A_发明申请_US20080196061A1 Method and Apparatus for Channel Change in Dsl System_+++B_D_M_S_a_c_k_n+++.docx
2026-03-23 23:53
2009-07-30_JP2009170985A_发明专利_JP2009170985A On-demand data distribution system_+++N_a_c_d_e_g_j_m_q+++.docx
2026-03-23 23:53
2010-01-21_WO2010008416A_发明申请_WO2010008416A1 A SCALABLE VIDEO CODING METHOD FOR FAST CHANNEL CHANGE TO INCREASE CODING EFFICIENCY_+++A_B_d_s+++.docx
2026-03-23 23:53
2010-10-13_CN101061718B_发明授权_CN101061718B 用于数字订户线路系统中的频道改变的方法和设备_+++B_a_d_e_s+++.docx
2026-03-23 23:53
2011-02-24_WO2011022432A_发明申请_WO2011022432A1 ENCODING VIDEO STREAMS FOR ADAPTIVE VIDEO STREAMING_+++G_J_Q_S_a_d_k_m_p+++.docx
2026-03-23 23:53
2011-03-30_EP2301252A_发明公开_EP2301252A1 A SCALABLE VIDEO CODING METHOD FOR FAST CHANNEL CHANGE TO INCREASE CODING EFFICIENCY_+++B_a_d_s+++.docx
2026-03-23 23:53
2011-04-19_KR1020110039531A_发明公开_KR1020110039531A 코딩 효율을 증가시키기 위하여 고속 채널 변경을 위한 스케일러블 비디오 코딩 방법_+++B_a_d_s+++.docx
2026-03-23 23:53
2011-05-12_US2011110418A_发明申请_US20110110418A1 SCALABLE VIDEO CODING METHOD FOR FAST CHANNEL CHANGE TO INCREASE CODING EFFICIENCY_+++A_B_c_d_e_f_s+++.docx
2026-03-23 23:53
2011-05-19_US2011116772A_发明申请_US20110116772A1 METHOD AND APPARATUS FOR PROVIDING TRICK PLAY SERVICE_+++A_B_M_S_g_j_o+++.docx
2026-03-23 23:53
2011-06-15_CN102100069A_发明公开_CN102100069A 用于快速信道改变以增大编码效率的可分级视频编码方法_+++B_a_s+++.docx
2026-03-23 23:53
2011-09-08_US2011219063A_发明申请_US20110219063A1 APPARATUS AND METHOD FOR PLAYING MEDIA CONTENT DATA_+++B_S_a_o+++.docx
2026-03-23 23:53
2011-05-12_US2011110418A_发明申请_US20110110418A1 SCALABLE VIDEO CODING METHOD FOR FAST CHANNEL CHANGE TO INCREASE CODING EFFICIENCY_+++A_B_c_d_e_f_s+++.docx

本次调用的模型名称:GPT-4。

**对比文件名称**:2011-05-12_US2011110418A_发明申请_US20110110418A1 SCALABLE VIDEO CODING METHOD FOR FAST CHANNEL CHANGE TO INCREASE CODING EFFICIENCY

**目标专利名称**:379经译码多媒体数据的网络串流期间的表示之间的切换CN103843301B

**特征比对表格**

技术特征描述及公开性判断结果对比文件原文引用公开性论述
**A:所述方法包括:确定所述多媒体内容的第一表示的切换点之间的第一间隔和所述多媒体内容的第二表示的切换点之间的第二间隔,《直接公开》**[0030] “...the scalable video encoder encodes the video signal such that IDR slices are inserted more frequently into the base layer than any other layer of the resulting SVC signal. For example, the scalable video encoder is responsive to a coding parameter ... that specifies different IDR intervals at different spatial layers.”<br>[0035] “...the scalable video encoder encodes the video signal such that IDR slices are inserted more frequently into the base layer than the enhancement layer of SVC signal 206...”对比文件明确公开了在可伸缩视频编码(SVC)中,编码器为不同的空间层(即不同的表示)设置不同的IDR间隔(IDR intervals)。IDR切片是切换点(随机接入点)的一种实现方式。因此,编码器或接收端需要“确定”不同层(即第一表示和第二表示)的切换点(IDR)之间的间隔。这与目标专利特征A“确定第一表示的切换点之间的第一间隔和第二表示的切换点之间的第二间隔”的技术方案相同。在对比文件中,确定不同层的IDR间隔是编码策略的一部分,目的是减少频道切换延迟;在目标专利中,确定间隔是为了优化客户端在表示间的切换策略。虽然应用场景(编码端策略 vs. 客户端自适应流)和目的略有不同,但“确定不同表示的切换点间隔”这一技术手段本身被对比文件直接且明确地公开。
**B:其中所述第一间隔小于所述第二间隔,《直接公开》**[0030] “...IDR slices are inserted more frequently into the base layer than any other layer...”<br>[0035] “...IDR slices are inserted more frequently into the base layer than the enhancement layer...”<br>(结合图6,基层的IDR切片出现在访问单元4和7,增强层的IDR切片出现在访问单元1和9,直观上基层的IDR更频繁,即间隔更小。)对比文件多次明确指出IDR切片(切换点)在基层(第一表示)中插入得比增强层(第二表示)更频繁(more frequently)。更频繁的插入意味着切换点之间的时间间隔更短。因此,“第一间隔小于第二间隔”这一关系被对比文件直接公开。
**C:基于所述确定,提交对来自所述第一表示的相当数量的视频数据的一个或多个网络请求,来自所述第一表示的相当数量的视频数据具有至少等于所述第二表示中的切换点之间的重放时间的重放时间,《隐含公开》**[0035] “...when a receiving device changes (or first tunes) to a channel that conveys SVC signal 206 at a time T as illustrated by arrow 401, the receiving device only has to wait a time Tw as represented by arrow 402 before being able to begin decoding the base layer of SVC signal 206...”<br>[0041] “...processor 360 sets decoding to an initial targeted dependency layer, e.g., the designated channel change layer. In this example, this is represented by the base layer...”<br>[0041] “...if the received base layer is an IDR slice, then processor 360 starts decoding of the SVC base layer in step 430...”对比文件公开了接收装置在频道切换时,首先以基层(第一表示)作为初始目标层进行解码(图9步骤405,430)。为了实现从基层开始播放并随后无缝切换到增强层(第二表示),接收装置必须首先获取并缓冲来自基层的数据。虽然对比文件未明确描述“提交网络请求”的动作,但在网络流媒体背景下,获取数据必然隐含了向服务器提交请求的过程。此外,对比文件图9的逻辑(步骤430-445)表明,在从基层开始解码后,接收装置会持续检查增强层直到发现其IDR切片,然后切换到增强层。要保证在切换到增强层IDR点时播放不中断,客户端在切换前缓冲的基层数据量,其重放时间应至少能覆盖从基层开始播放到增强层下一个IDR点的时间。这个时间至少等于(或可能超过)增强层IDR点之间的间隔(即第二间隔)。因此,本领域技术人员根据对比文件公开的“以基层启动解码并在增强层IDR点切换”的方案,能够合理推断出需要请求并缓冲来自基层的、量至少等于增强层切换点间隔重放时间的数据。故该特征被隐含公开。
**D:在提交对来自所述第一表示的相当数量的视频数据的所述请求之后,检索来自所述第二表示的视频数据。《隐含公开》**[0041] “Then, in step 435, processor 360 receives an access unit and checks, in step 440, if the upper layer of the received access unit is an IDR slice. If it is not an IDR slice, then processor 360 returns to step 435 for receiving the next access unit. However, if the upper layer of the received access unit is an IDR slice, then processor 360 starts decoding of the SVC upper layer in step 445...”对比文件图9的流程(步骤435-445)明确描述了接收端在已开始解码基层(第一表示)后,持续接收访问单元并检查增强层(第二表示)是否为IDR切片,一旦检测到增强层的IDR切片,则开始解码增强层。开始解码增强层必然以检索到其视频数据为前提。虽然对比文件没有明确使用“在提交对第一表示的请求之后”这样的时序描述,但其流程逻辑清晰地表明:接收端先处理(隐含了请求和获取)基层数据并开始解码,然后才在条件满足时处理(检索和解码)增强层数据。这隐含了“在获取第一表示数据之后,检索第二表示数据”的步骤。
**E:其进一步包括缓冲来自所述第一表示的视频数据,以及基于所述经缓冲的视频数据的持续时间确定何时检索来自所述第二表示的视频数据。《隐含公开》**[0041] “...processor 360 starts decoding of the SVC base layer in step 430 for providing a video signal albeit at reduced resolution. Then, in step 435, processor 360 receives an access unit and checks, in step 440, if the upper layer of the received access unit is an IDR slice...”<br>[0035] “...the receiving device only has to wait a time Tw... before being able to begin decoding the base layer...”对比文件公开了接收端开始解码基层(缓冲并播放),然后通过检查接收到的访问单元中增强层是否存在IDR来决定何时开始解码(即检索和处理)增强层(步骤435-440)。决定何时切换到增强层的逻辑(即“检测到增强层IDR”)是基于持续接收和检查数据流,这本身依赖于对已接收(缓冲)数据的处理。虽然对比文件未明确提及“基于缓冲持续时间”做出决定,但为了确保在切换到增强层时播放的连续性,客户端需要管理其缓冲区。本领域技术人员可以理解,在等待增强层IDR出现期间,客户端需要缓冲足够的基础层数据以维持播放,而切换决策(何时开始检索/解码增强层)实质上与缓冲区的状态(是否有足够的数据覆盖到切换点)紧密相关。因此,“缓冲第一表示数据并基于此(或结合其他条件)确定何时检索第二表示数据”的技术方案可以被合理推断出来。
**F:其中基于所述经缓冲的视频数据的所述持续时间检索来自所述第二表示的视频数据包括在缓冲来自所述第一表示的视频数据的持续时间之后检索来自所述第二表示的数据,来自所述第一表示的视频数据的所述持续时间等于所述第二表示中的切换点之间的所述重放时间。《隐含公开》**[0035] “...when a receiving device changes ... at a time T ... the receiving device only has to wait a time Tw ... before being able to begin decoding the base layer...” <br>结合[0041]中等待增强层IDR的流程。对比文件公开了接收端从时间T开始,需要等待时间Tw(对应于接收到基层IDR所需的时间)才能开始解码基层。随后,为了切换到增强层,它需要继续等待直到接收到增强层的IDR(图9步骤440)。从开始解码基层到切换到增强层IDR,客户端需要持续缓冲来自基层的数据以维持播放。为了确保无缝切换,在切换点(增强层IDR)到来时,客户端缓冲的基层数据量应能覆盖从开始播放到该切换点的重放时间。这个所需的缓冲时间,在理想情况下(如果切换点时间对齐),至少需要等于增强层IDR之间的间隔(第二间隔),以确保在下一个增强层IDR出现时客户端已准备就绪。虽然对比文件没有精确描述“缓冲持续时间等于第二间隔”,但本领域技术人员为了实现从基层到增强层的可靠切换,能够推导出需要缓冲足够时长的基层数据,而这个“足够时长”至少需要覆盖到下一个增强层随机接入点,即至少等于增强层切换点间的重放时间。因此,该特征被隐含公开。
**G:其进一步包括:确定当前可用网络带宽量《未公开》**无相关内容。对比文件涉及的是在广播/多播环境中通过编码层设计减少频道切换延迟,其核心是编码端的IDR插入策略和接收端的解码切换逻辑。全文未提及网络带宽自适应、测量当前可用网络带宽量、或根据带宽选择不同码率表示等内容。这与目标专利中基于网络带宽进行自适应流媒体传输的技术特征无关。
**H:接收指示所述第一表示和所述第二表示具有共同位速率的所述多媒体内容的清单《未公开》**无相关内容。对比文件描述的是SVC编码的层级(基层和增强层),这些层具有不同的空间分辨率(如CIF和SD),因此它们的位速率通常是不同的(基层位速率较低)。对比文件没有提及“表示具有共同位速率”的概念,也没有提及任何描述多媒体内容表示的“清单”(如MPD文件)。
**I:以及在确定所述共同位速率可由所述当前可用网络带宽量满足之后选择所述第一表示和所述第二表示。《未公开》**无相关内容。该特征依赖于特征G和H(确定带宽和接收指示共同位速率的清单),这些特征均未被对比文件公开。因此,基于这些信息进行表示选择的特征I也未被公开。
**J:其进一步包括:确定当前可用网络带宽量《未公开》**无相关内容。同特征G,对比文件未涉及网络带宽确定。
**K:接收指示所述第一表示具有第一位速率且所述第二表示具有高于所述第一位速率的第二位速率的所述多媒体内容的清单《未公开》**无相关内容。对比文件虽然暗示了基层和增强层具有不同的位速率(基层较低),但并未明确描述“第一位速率”和“第二位速率”的概念,更没有提及通过“清单”来接收指示这些位速率的信息。
**L:确定所述第二位速率是否可由所述当前可用网络带宽量满足,其中请求来自所述第一表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后请求来自所述第一表示的所述视频数据,且其中在请求来自所述第一表示的所述视频数据之后检索来自所述第二表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后检索来自所述第二表示的所述视频数据。《未公开》**无相关内容。该特征涉及基于网络带宽判断是否能够满足较高位速率的表示,并据此决定初始请求和后续切换。对比文件完全未涉及网络带宽自适应决策流程,其切换决策是基于是否存在IDR切片,而非带宽条件。
**M:其中请求来自所述第一表示的所述视频数据包括:将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置《未公开》**无相关内容。对比文件描述的是广播/多播环境下的接收和解码过程。接收端被动接收包含多层数据的流,并未描述客户端主动向服务器发送针对特定表示的HTTP GET或部分GET请求(这是DASH等自适应流媒体的典型特征)。其“开始解码基层”隐含了接收数据,但未公开“发送请求”的动作。
**N:经由单播接收来自所述第一表示的所述视频数据,且其中检索来自所述第二表示的所述视频数据包括经由多播或广播的至少一者从所述服务器装置检索所述视频数据。《未公开》**[0002] “The present invention generally relates to communications systems, e.g., wired and wireless systems such as terrestrial broadcast, cellular, Wireless-Fidelity (Wi-Fi), satellite, etc.”<br>[0025] “As noted earlier, when a receiver initially turns on, or even during a channel change...”对比文件背景技术提及了广播系统,说明书通篇也假设了广播/多播传输环境。然而,它没有具体描述“单播”与“多播/广播”相结合的数据检索模式,即没有公开客户端通过单播请求获取第一表示(如低质量、高切换频率),而通过多播/广播获取第二表示(如高质量、低切换频率)。它描述的是一个包含多层(基层和增强层)的单一广播/多播流。
**O:其进一步包括接收所述多媒体内容的清单文件,其中确定所述第一间隔包括从所述清单文件中的信息确定所述第一间隔,且其中确定所述第二间隔包括从所述清单文件中的信息确定所述第二间隔。《未公开》**无相关内容。对比文件未提及任何形式的清单文件(如MPD)。其中关于不同层IDR间隔的信息是编码器预设的策略或由编码参数指定,接收端是通过解析码流本身(检测NAL单元类型)来识别IDR切片,而非从独立的清单文件中获取间隔信息。
**P:其中所述第一表示和所述第二表示具有共同位速率,所述方法进一步包括:在确定所述第一间隔和所述第二间隔之前,检索来自具有不同于所述共同位速率的位速率的第三不同表示的视频数据《未公开》**无相关内容。对比文件未提及“共同位速率”的表示。其描述的基层和增强层本质上是不同分辨率的层,位速率不同。也未描述在确定间隔之前,先检索一个位速率不同的第三表示(例如在带宽变化时从高位速率表示切换到具有共同位速率但不同间隔的表示组)。
**Q:确定当前可用网络带宽量《未公开》**无相关内容。同特征G、J,未公开。
**R:基于所述第一表示和所述第二表示的所述共同位速率更适于所述当前可用网络带宽量的确定,确定所述第一间隔和所述第二间隔,提交对于来自所述第一表示的所述视频数据的所述一个或多个网络请求,以及检索来自所述第二表示的所述视频数据。《未公开》**无相关内容。该特征是基于网络带宽适应来选择具有共同位速率但不同间隔的表示组。对比文件完全不涉及网络带宽适应性的决策,其表示(层)的选择是基于设备能力(如支持的分辨率)和减少切换延迟的目的,而非当前网络带宽。
**S:其中检索来自所述第二表示的视频数据包括从所述第二表示的切换点开始检索来自所述第二表示的视频数据。《隐含公开》**[0041] “...if the upper layer of the received access unit is an IDR slice, then processor 360 starts decoding of the SVC upper layer in step 445...”<br>[0043] “Upon detection of an IDR slice in a dependency layer ... the receiver decodes the coded video in that dependency layer with the detected IDR slice.”对比文件明确公开了接收端在检测到增强层(第二表示)的IDR切片时,开始解码该增强层。开始解码必然意味着从该IDR切片(即切换点)所在的位置开始处理(检索和解码)该层的数据。因此,“从第二表示的切换点开始检索来自第二表示的视频数据”这一技术方案被对比文件隐含公开。

<<<A>>><<<B>>><<<c>>><<<d>>><<<e>>><<<f>>><<<s>>>

权利要求与技术特征
Powered by Django

网站备案号:渝ICP备2023012882号


重庆市非显而易见网络科技有限责任公司 A Anti NPE NPE