对比文件名称：2003-01-16_US2003014705A_发明申请_US20030014705A1 Apparatus for system decoder and method for error correction of packet data
目标专利名称：399视频解码器错误处置CN101960853B
本次调用模型名称：DeepSeek-R1
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**: 确定经编码视频数据的当前单元的起点《隐含公开》 | [0061] “The inputted packet data is converted to a packet in transport layer by a packet data processing unit 301.”<br>[0066] “At the packet data processing unit 301, the inputted data link protocol packet is converted to a network packet and transport packet in this order. Only the transport payload is outputted to a memory 207.”<br>[0096] “First, the position of the first MB (macroblock_number) of the video packet is detected (Step 3308).” | 对比文件公开了系统解码器接收并处理输入的数据包（包括数据包处理单元301），从中提取有效载荷（如视频数据）输出到存储器。在媒体数据纠正算法中（图36，步骤3308），明确提到需要检测视频包（video packet）中第一个宏块（MB）的位置（macroblock_number）。这对应于确定当前视频数据单元（如视频包）的起点。虽然对比文件未明确使用“当前单元”的表述，但其描述的“视频包”及其第一个宏块位置的确定，实质上公开了“确定经编码视频数据的当前单元的起点”这一技术特征。该特征在对比文件中用于定位视频数据的起始点以进行后续处理或错误纠正，与目标专利中用于错误处置的起点确定作用类似。因此，该技术特征被对比文件隐含公开。 |
| **技术特征B**: 在未确定所述经编码视频数据的下一可用单元的起点的情况下，解码所述当前单元的至少一部分《未公开》 | 对比文件未公开在解码当前单元时，不预先确定下一可用单元起点的技术思想。 | 目标专利的特征B强调“在未确定下一可用单元的起点的情况下”进行解码，这是其“循序错误处置”技术的核心，旨在避免先行操作。对比文件描述了系统解码器处理数据包流，并在检测到包丢失时插入错误检测数据或进行数据纠正。其处理流程通常是顺序处理接收到的数据包（例如，[0061]-[0066]），但并未揭示在解码当前视频数据单元（如视频包）时，有意地不事先去确定下一个可用视频数据单元（如下一个视频包）起点的技术方案或设计思想。对比文件的重点在于错误位置的标识和数据的纠正，而非在解码策略上避免先行确定下一单元的起点。因此，本领域技术人员无法从对比文件中毫无疑义地得出或合理推断出该技术特征。 |
| **技术特征C**: 在所述当前单元中检测解码错误《直接公开》 | [0073] “At the TCP analysis unit 910, error detection process is carried out by analyzing checksum contained in the header part of the TCP packet...”<br>[0073] “At the RTP analysis unit 913, the payload 307 is sent to the media data reconstruction unit 308, and the time-stamp&null;sequence number&null;payload type 801 is sent to the packet detection unit 802 and the media data reconstruction unit 308.”<br>[0084] “At a decoding and error detection unit 5012, analysis of the input data and the error detection are performed. For error detection, there are various methods. In general, it is carried out by detection of variable length code, which is not present in the code book of MPEG-4 video coding.”<br>[0010] “For instance, as shown in FIG. 3, let us assume a case where a packet string ... is transmitted ... a second packet ... does not arrive at the system decoder, or ... transmission error is included in the second packet...” | 对比文件多处公开了在数据中检测错误。系统解码器中的包数据处理单元（301）会分析TCP/UDP/RTP包头中的错误检测信息（如校验和）以检测传输错误或包丢失（[0073]）。此外，在应用解码器（如MPEG-4视频解码器）层面，也描述了通过分析输入数据（如检测不在码本中的变长码）来进行错误检测（[0084]）。这些错误包括因包未到达或包含传输错误而导致的解码错误（[0010]）。这与目标专利中在“当前单元中检测解码错误”的技术特征相同。该特征在对比文件中用于识别通信错误或数据损坏，与目标专利中用于触发错误处置流程的作用相同。因此，该技术特征被对比文件直接公开。 |
| **技术特征D**: 当检测到所述解码错误时，确定所述经编码视频数据的所述下一可用单元的所述起点《隐含公开》 | [0061] “In case the received packet contains an error, the packet is discarded at the packet data processing unit 301.”<br>[0061] “In case the received UDP packet does not contain error, RTP packet is analyzed, and a payload data 307 and a time-stamp&null;sequence number&null;payload type 801 are outputted ... the time-stamp&null;sequence number&null;payload type 801 is also outputted to a packet loss detection unit 802. As a result, by analyzing the sequence number ... at the packet loss detection unit 802, it is possible to detect the packet data not arrived yet...”<br>[0095] “Using coded macroblock number information in the video packet and the media data 208 in the video packet, macroblock data correction processing 3310 shown in FIG. 37 is performed.”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).” | 对比文件公开了在检测到包错误或丢失（解码错误的一种形式）后，系统解码器会分析序列号以检测未到达的包（[0061]）。在媒体数据纠正算法中（图36），当发现错误区间后，会执行步骤3309：“搜索存储器207中的媒体数据208，并检测下一个VP的第一个MB的位置，即当前VP中的编码MB数量”。这里的“下一个VP的第一个MB的位置”即对应于“下一可用单元的起点”。虽然对比文件是在数据纠正的上下文中进行此操作，且“单元”可能指“视频包（VP）”，但该操作的本质是在检测到错误后，去确定下一个可用数据单元的起始位置。这与目标专利特征D的技术手段一致。因此，该技术特征被对比文件隐含公开。 |
| **技术特征E**: 基于所述下一可用单元的所述起点来确定被破坏数据段的终点《隐含公开》 | [0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309). As the result of retrieving, if the start code is detected before resync-marker of the next VP, it is judged that the final MB in the VP is the final MB of the VOP.” | 对比文件在媒体数据纠正算法步骤3309中，通过搜索并确定“下一个VP的第一个MB的位置”，可以推断出当前VP中编码MB的数量。紧接着说明，如果检索结果在下一个VP的重新同步标记之前检测到起始码，则判断该VP中的最后一个MB就是VOP的最后一个MB。这意味着，基于下一个VP的起点（或下一个重新同步点）的信息，可以确定当前被处理（可能被破坏）的数据段（VP）的终点（最后一个MB）。这实质上公开了“基于下一可用单元的起点来确定被破坏数据段的终点”。虽然该操作发生在数据纠正模块中，且“被破坏数据段”的界定可能不完全相同，但技术手段和逻辑关系是相同的。因此，该技术特征被对比文件隐含公开。 |
| **技术特征F**: 基于所述当前单元的所述起点和所述被破坏数据段的所述终点来隐藏所述被破坏数据段。《隐含公开》 | [0080] “In the present application, it is proposed to adopt a method to correct the media data with packet loss to a data to comply with the specification or the standards of video, audio, etc in the service of file transfer type, before processing is performed at the application decoder using the insertion data for error correction.”<br>[0096] “Using coded macroblock number information in the video packet and the media data 208 in the video packet, macroblock data correction processing 3310 shown in FIG. 37 is performed.”<br>图37及对应描述（[0096]-[0105]）详细说明了根据错误发生在视频包的不同部分（包头、优先级数据部分、DCT数据部分等），采用不同的处理（Processing I, II, III）来纠正或生成宏块数据。例如，Processing I: 将not_coded标志设置为1并删除初始数据；Processing II: 将所有DC系数设0，mb_type设为intra等。 | 对比文件公开了在媒体数据输入应用解码器之前，对受包丢失影响的媒体数据进行纠正，使其符合规范的方法（[0080]）。具体地，在宏块数据纠正处理（图37，步骤3310）中，会利用视频包中的编码宏块数量信息以及视频包中的媒体数据，根据错误区间的位置，执行一系列数据纠正操作（[0096]）。这些操作包括将宏块标记为“未编码”（Processing I）、用特定值填充或替换宏块数据（Processing II）、或删除系数数据（Processing III）等（[0096]-[0105]）。这些纠正操作的目的是使损坏的数据变得可解码或减少错误影响，实质上是一种“隐藏”被破坏数据的形式（例如，通过使用来自前帧的预测或填充默认值）。虽然术语“隐藏”未明确使用，但“纠正（correction）”以达到符合标准的数据，其功能和效果与“隐藏”相似，都是处理错误数据以避免显示错误。该操作基于当前视频包的起点（第一个MB位置）和终点（通过下一VP起点推断）所界定的错误区间进行。因此，该技术特征被对比文件隐含公开。 |
| **技术特征G**: 其中所述当前单元和所述下一可用单元中的每一者包括一视频数据片。《直接公开》 | [0085] “The video packet is a unit of coding data with several macroblocks being put together.”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).”<br>图26展示了视频包（video packet）的划分实例。 | 对比文件明确描述了“视频包（video packet）”的概念，它是将多个宏块（MB）组合在一起的编码数据单元（[0085]）。在数据纠正流程中，也反复提到当前VP和下一个VP（[0096]）。目标专利中的“视频数据片（slice）”是视频编码中的一种数据单元，通常包含多个宏块并以重新同步标记开始。对比文件中的“视频包（video packet）”在MPEG-4标准中具有类似的作用和结构（包含重新同步标记和多个宏块）。因此，对比文件公开的“视频包”对应于目标专利的“视频数据片”。该特征在对比文件中作为错误恢复和数据处理的基本单元，与目标专利中的作用相同。因此，该技术特征被对比文件直接公开。 |
| **技术特征H**: 其中所述被破坏数据段包括经编码视频数据的所述当前单元和至少一个额外单元。《隐含公开》 | [0096] “In case resync_marker of the next VP header is included in the error internal, the VP detected by the processing of Step 3309 of FIG. 36 is actually VP after the next (two steps after). Therefore, it is necessary to process MBs in the next VP as MBs in the current VP.” | 对比文件在描述宏块数据纠正处理时提到（[0096]），如果错误区间包含了下一个VP头的重新同步标记，那么通过步骤3309检测到的VP实际上是下下一个VP。因此，需要将下一个VP中的宏块作为当前VP中的宏块来处理。这暗示了错误区间（被破坏数据段）可能跨越了多个视频包（VP），即包括了当前单元（当前VP）和至少一个额外单元（下一个VP）。这与特征H的描述“被破坏数据段包括当前单元和至少一个额外单元”相符。因此，该技术特征被对比文件隐含公开。 |
| **技术特征I**: 其中所述当前单元是第一帧的当前片，且所述被破坏数据段包括所述当前片和来自第二帧的经编码视频数据的至少一个额外片。《未公开》 | 对比文件未明确描述被破坏数据段跨越不同视频帧（VOP）并包含来自第二帧的视频包的具体实施例或技术方案。 | 对比文件虽然提到了VOP（视频对象平面，即帧）和视频包（VP），并在错误纠正时考虑了VOP类型（I-VOP, P-VOP等）（例如步骤3307），但其公开的错误区间处理主要围绕单个VOP内的视频包展开（如图36，步骤3309-3310）。虽然理论上包丢失可能影响多帧，但对比文件说明书的具体描述和算法流程（图36，37）并未明确揭示或教导一种处理跨越两个不同帧（例如，第一帧的当前片和第二帧的额外片）的被破坏数据段的具体技术方案。本领域技术人员不能从对比文件中直接或合理地推断出该特定技术特征。因此，该技术特征未被对比文件公开。 |
| **技术特征J**: 其进一步包含：如果检测到所述解码错误，那么设置错误旗标以指示所述检测到所述解码错误《隐含公开》 | [0061] “... the time-stamp&null;sequence number&null;payload type 801 is also outputted to a packet loss detection unit 802. As a result, by analyzing the sequence number and the payload type at the packet loss detection unit 802, it is possible to detect the packet data not arrived yet and the packet data with a transmission error for each payload type.”<br>[0066] “At the packet loss detection unit 802, if a packet is not received yet after a predetermined time ... has elapsed ..., it is regarded as a loss packet, and its sequence number 807 is delivered to the retransmission judgment unit 304.”<br>[0085] “When data error is detected, the decoding and error detection unit 5012 outputs the data to the error correction unit 509.” | 对比文件描述了通过包丢失检测单元（802）分析序列号来检测未到达或传输错误的包，并将其视为丢失包（loss packet），然后将其序列号（807）传递给重传判断单元（[0061], [0066]）。在应用解码器层面，当检测到数据错误时，解码和错误检测单元（5012）会将数据输出到错误纠正单元（509）（[0085]）。这些操作都隐含着一种状态或信号的设置，用以指示“检测到解码错误”。虽然未明确使用“错误旗标（error flag）”一词，但“将序列号807传递给...”或“将数据输出到错误纠正单元...”这些动作本身就是一种错误指示机制。因此，该技术特征被对比文件隐含公开。 |
| **技术特征K**: 当所述错误旗标被设置时，基于所述下一可用单元的所述起点来确定所述被破坏数据段的所述终点。《隐含公开》 | [0066] “At the packet loss detection unit 802, if a packet is not received yet after a predetermined time ... has elapsed ..., it is regarded as a loss packet, and its sequence number 807 is delivered to the retransmission judgment unit 304.”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).” | 结合特征J和特征D/E的论述，对比文件公开了：当包丢失检测单元（802）判断一个包为丢失包（相当于设置错误指示）后，会触发后续处理。在媒体数据纠正算法中（图36），当错误被检测到（即处于“错误状态”）后，会执行步骤3309，即搜索并确定“下一个VP的第一个MB的位置”。如特征E所述，基于此信息可以确定被破坏数据段的终点。因此，整个逻辑链是：检测到错误（设置指示）→ 确定下一可用单元起点 → 基于该起点确定被破坏数据段终点。这符合特征K的描述。因此，该技术特征被对比文件隐含公开。 |
| **技术特征L**: 其中所述下一可用单元包含至少一个片，所述方法进一步包含在检测到所述解码错误时寻找与所述片相关联的片标头。《直接公开》 | [0085] “At the beginning of each video packet data, resync marker and video packet header including macroblock position in the frame are arranged.”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).”<br>图36流程涉及检索“resync marker”（重新同步标记），该标记是视频包头的起始部分。 | 对比文件明确公开了视频包（VP）以重新同步标记（resync marker）和视频包头（video packet header）开始（[0085]）。在数据纠正算法步骤3309中，描述了对媒体数据进行搜索以检测“下一个VP的第一个MB的位置”。要完成这个操作，必然需要寻找并识别下一个VP的起始点，即其重新同步标记或包头。这与“在检测到解码错误时寻找与所述片相关联的片标头”的技术特征相同。该特征在对比文件中用于定位下一个数据单元以进行错误区间界定或同步恢复，与目标专利中的作用相同。因此，该技术特征被对比文件直接公开。 |
| **技术特征M**: 其进一步包含，如果检测到所述解码错误，那么停止解码所述当前单元，且着手解码所述下一可用单元。《隐含公开》 | [0061] “In case the received packet contains an error, the packet is discarded at the packet data processing unit 301.”<br>[0080] “... correct the media data with packet loss to a data to comply with the specification or the standards ... before processing is performed at the application decoder ...”<br>图36的纠正流程本质上是在应用解码器正式解码之前，对包含错误的媒体数据区间进行纠正或“重新包装”，然后输出合规数据。这个过程隐含了跳过或停止对原始错误数据的直接解码，转而处理下一个可用数据单元（或纠正后的数据）。 | 对比文件公开了当接收到包含错误的数据包时，该包会被丢弃（[0061]）。此外，核心思想之一是在应用解码器处理之前，将受包丢失影响的媒体数据纠正为符合标准的数据（[0080]）。这意味着，当系统检测到错误（包丢失或损坏）时，不会将原始的错误数据直接送给解码器进行“解码”，而是会介入处理（丢弃、纠正），然后提供可解码的数据。这实质上相当于“停止解码当前单元（错误数据）”，并“着手解码下一可用单元（或纠正后的数据）”。虽然具体表述不同，但技术效果是类似的。因此，该技术特征被对比文件隐含公开。 |
| **技术特征N**: 其进一步包含，如果未检测到所述解码错误，那么解码整个当前单元。《隐含公开》 | [0061] “In case the received UDP packet does not contain error, RTP packet is analyzed, and a payload data 307 and a time-stamp&null;sequence number&null;payload type 801 are outputted ...”<br>[0084] 图19展示了一个标准的MPEG-4视频解码框图，该解码过程默认是针对完整、无误的数据进行的。 | 对比文件描述了当接收到的数据包没有错误时，系统会正常分析数据包并将其有效载荷输出以供后续处理或解码（[0061]）。这是通信和数据处理系统中的常规操作逻辑。此外，对比文件引用了标准的MPEG-4解码流程（[0084], 图19），该流程默认是对输入的正确媒体数据进行完整解码。虽然对比文件没有用明确的“如果未检测到错误，则解码整个当前单元”的语句来描述目标专利的循序错误处置流程，但“对无错误的数据进行正常完整解码”是本领域技术人员的公知常识和必然操作。因此，该技术特征被对比文件隐含公开。 |
| **技术特征O**: 其中所述解码错误包含语法错误、语义错误或熵译码错误中的至少一者。《直接公开》 | [0084] “For error detection, there are various methods. In general, it is carried out by detection of variable length code, which is not present in the code book of MPEG-4 video coding.”<br>[0010] “... in case a combination of the data string not complying with the applicable standard decoding scheme is detected in the inputted data, it is judged that a transmission error has occurred.” | 对比文件明确公开了错误检测的方法，包括检测不在MPEG-4视频编码码本中的变长码（这属于熵译码错误）（[0084]）。同时，也提到当检测到输入数据中存在不遵守适用标准解码方案的数据串时，就判断发生了传输错误（[0010]）。不遵守解码方案的数据串可能包含语法错误或语义错误。因此，对比文件公开的解码错误类型涵盖了熵译码错误、语法错误和语义错误。这与特征O的描述完全一致。该特征在对比文件中用于识别数据损坏，与目标专利中用于触发错误检测的作用相同。因此，该技术特征被对比文件直接公开。 |
| **技术特征P**: 其中确定所述当前单元的起点包含确定与所述当前单元的所述起点相关联的第一宏块MB编号，确定所述被破坏数据段的终点包含确定在第二单元的起点之前的第二MB编号，且隐藏包含隐藏从所述第一MB编号到所述第二MB编号的所述被破坏数据段。《隐含公开》 | [0096] “First, the position of the first MB (macroblock_number) of the video packet is detected (Step 3308).”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).”<br>[0096] “Using coded macroblock number information in the video packet and the media data 208 in the video packet, macroblock data correction processing 3310 shown in FIG. 37 is performed.”<br>图37的宏块数据纠正处理（Processing I, II, III）实质上是针对特定区间的宏块进行数据替换或修改，是一种隐藏形式。 | 对比文件在数据纠正流程中，检测当前视频包（VP）的第一个MB的位置（macroblock_number）（步骤3308，第一MB编号），并搜索下一个VP的第一个MB的位置（步骤3309）。下一个VP的第一个MB的位置减1，即可得到当前VP的最后一个MB的编号（第二MB编号）。然后，利用这些信息对当前VP中的宏块执行数据纠正处理（Processing I, II, III）（步骤3310）。这些纠正处理（如将宏块标记为未编码、填充默认值等）实质上是对从第一MB编号到第二MB编号之间的数据段进行“隐藏”。因此，对比文件隐含公开了通过确定第一MB编号和第二MB编号，并对该区间进行数据纠正（隐藏）的技术方案。 |
| **技术特征Q**: 其中确定所述第二单元的起点包含确定与所述第二单元的所述起点相关联的第三MB编号，且其中确定所述第二MB编号包含从所述第三MB编号减去一以产生所述第二MB编号。《隐含公开》 | [0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).” | 对比文件步骤3309描述了搜索并确定“下一个VP的第一个MB的位置”。如果将该位置视为“第三MB编号”，那么当前VP的最后一个MB的编号（第二MB编号）自然就是“第三MB编号减一”。这是根据视频数据顺序排列的必然逻辑关系。虽然对比文件没有明确写出“减一”这个算术操作，但“下一个VP的第一个MB的位置”这一概念本身已经隐含了前一个VP的结束位置就在此位置之前。因此，本领域技术人员可以毫无困难地推断出“第二MB编号 = 第三MB编号 - 1”。该技术特征被对比文件隐含公开。 |
| **技术特征R**: 其中确定所述当前单元的起点包含确定与所述当前单元的起点相关联的第一宏块MB编号和第一帧编号，确定所述被破坏数据段的终点包含确定与所述被破坏数据段的所述终点相关联的第二MB编号和第二帧编号，且隐藏包含基于所述第一MB编号和所述第二MB编号以及所述第一帧编号和所述第二帧编号来隐藏所述被破坏数据段的至少一部分，其中所述第一帧编号和所述第二帧编号可相同或不同。《隐含公开》 | [0096] 步骤3308-3310涉及检测视频包中的MB位置。<br>[0096] “As the result of retrieving, if the start code is detected before resync-marker of the next VP, it is judged that the final MB in the VP is the final MB of the VOP.”<br>对比文件提到了VOP（视频对象平面，即帧）以及VOP头中的时间戳信息（modulo_time_base, vop_time_increment）（[0085]-[0086]）。在纠正算法中，需要判断VOP类型（I, P, B）（步骤3307）并可能生成VOP头（步骤3317）。 | 对比文件的数据纠正处理是在媒体数据流（可能包含多个VOP/帧）的上下文中进行的。要准确定位一个视频包（VP），不仅需要知道它在帧内的MB编号，还需要知道它属于哪个帧（VOP）。对比文件提到了VOP头中的时间戳信息，这可用于区分不同的帧。虽然纠正算法（图36）的步骤描述主要围绕VP内的MB位置，但其处理逻辑必然建立在知晓当前处理的数据属于哪个VOP的基础上（例如，步骤3307判断vop_coding_type）。因此，在确定当前单元的起点和终点时，隐含了需要确定其所在的帧编号（第一帧编号和第二帧编号）。纠正操作（隐藏）也是基于这些位置信息进行的。帧编号相同或不同的情况对应于错误是否跨越帧边界，这在数据处理中是可能发生的。因此，该技术特征被对比文件隐含公开。 |
| **技术特征S**: 其进一步包含：检测一个或一个以上帧的丢失《隐含公开》 | [0066] “At the packet loss detection unit 802, if a packet is not received yet after a predetermined time ... has elapsed ..., it is regarded as a loss packet...”<br>[0096] 步骤3307判断vop_coding_type是否为B-VOP，这涉及帧类型识别。如果连续的数据包丢失导致一个完整的VOP（帧）数据缺失，通过分析序列号、时间戳或VOP起始码的缺失，可以推断出帧丢失。 | 对比文件公开了检测包丢失的方法（[0066]）。在视频流中，数据包承载着帧（VOP）的数据。多个连续包的丢失或关键数据（如VOP起始码）的丢失，很可能导致一个或多个完整帧无法被解码，即帧丢失。虽然对比文件没有明确表述“检测帧丢失”，但基于其公开的包丢失检测能力，以及其对视频数据结构（VOP）的认识（[0096]步骤3307），本领域技术人员能够通过分析接收到的数据流，推断出是否发生了帧丢失（例如，通过发现预期的VOP起始码缺失）。因此，该技术特征被对比文件隐含公开。 |
| **技术特征T**: 替换所述一个或一个以上丢失帧以隐藏另一帧的参考帧失配。《未公开》 | 对比文件未描述通过替换丢失的帧（例如，重复前一帧或插入内插帧）来校正后续帧因参考帧丢失而导致的预测失配（reference frame mismatch）的具体技术方案。 | 对比文件主要关注于在包丢失位置插入错误检测标识，以及在数据送入应用解码器前对媒体数据进行纠正，使其语法合规。其纠正处理（如图37）主要针对视频包或宏块级别的数据替换或修改，以达到解码器可接受的形式。然而，对比文件并未公开或教导一种为了解决“参考帧失配”问题而采取的特定操作，即：当检测到一个或多个完整帧丢失时，通过生成并插入替换帧（如重复前一帧）来维持后续帧的正确预测参考关系，从而“隐藏”参考帧失配。这是目标专利中针对多参考帧预测场景的一种特定错误隐藏技术。对比文件缺乏对该技术方案的揭示。因此，该技术特征未被对比文件公开。 |
| **技术特征U**: 用于确定经编码视频数据的当前单元的起点的装置《隐含公开》 | [0061] “The inputted packet data is converted to a packet in transport layer by a packet data processing unit 301.”<br>[0096] “First, the position of the first MB (macroblock_number) of the video packet is detected (Step 3308).”<br>执行该步骤的模块（如数据纠正处理单元707及其控制逻辑）可以视为实现该功能的装置。 | 参见技术特征A的论述。对比文件公开了确定视频数据单元（视频包）起点的功能，实现该功能的模块（如包数据处理单元301、媒体数据重建单元308、数据纠正处理单元707及其相关算法逻辑）构成了“用于确定经编码视频数据的当前单元的起点的装置”。该技术特征被隐含公开。 |
| **技术特征V**: 用于在未检测到所述经编码视频数据的下一可用单元的起点的情况下解码所述当前单元的至少一部分的装置《未公开》 | 对比文件未公开相应的装置。 | 参见技术特征B的论述。对比文件未公开在解码时不预先确定下一可用单元起点的技术思想，因此也不存在实现该功能的专门装置。该技术特征未被公开。 |
| **技术特征W**: 用于在所述当前单元中检测解码错误的装置《直接公开》 | [0073] “At the TCP analysis unit 910, error detection process is carried out...”<br>[0073] “At the RTP analysis unit 913...”<br>[0084] “At a decoding and error detection unit 5012, analysis of the input data and the error detection are performed...” | 参见技术特征C的论述。对比文件明确公开了执行错误检测的模块，如TCP分析单元910、RTP分析单元913、以及解码和错误检测单元5012。这些模块构成了“用于在所述当前单元中检测解码错误的装置”。该技术特征被直接公开。 |
| **技术特征X**: 用于在检测到所述解码错误时确定所述经编码视频数据的所述下一可用单元的所述起点的装置《隐含公开》 | [0061] “... the time-stamp&null;sequence number&null;payload type 801 is also outputted to a packet loss detection unit 802.”<br>[0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309).”<br>执行该功能的模块（如包丢失检测单元802、数据纠正处理单元707及其搜索逻辑）可以视为实现该功能的装置。 | 参见技术特征D的论述。对比文件公开了在检测到错误（包丢失）后，通过分析序列号或搜索媒体数据来确定下一个可用数据单元（如视频包）起点的功能。实现该功能的模块（如包丢失检测单元802、数据纠正处理单元707）构成了“用于在检测到所述解码错误时确定所述经编码视频数据的所述下一可用单元的所述起点的装置”。该技术特征被隐含公开。 |
| **技术特征Y**: 用于基于所述下一可用单元的所述起点来确定被破坏数据段的终点的装置《隐含公开》 | [0096] “Next, the media data 208 in the memory 207 is searched, and the position of the first MB of the next VP, i.e. the number of coding MB in the current VP, is detected (Step 3309). As the result of retrieving, if the start code is detected before resync-marker of the next VP, it is judged that the final MB in the VP is the final MB of the VOP.”<br>执行该判断和推理逻辑的模块（数据纠正处理单元707）可以视为实现该功能的装置。 | 参见技术特征E的论述。对比文件公开了基于下一个VP的起点信息来推断当前被处理数据段终点的功能。执行该逻辑的数据纠正处理单元707可以视为“用于基于所述下一可用单元的所述起点来确定被破坏数据段的终点的装置”。该技术特征被隐含公开。 |
| **技术特征Z**: 用于基于所述当前单元的所述起点和所述被破坏数据段的所述终点来隐藏所述被破坏数据段的装置。《隐含公开》 | [0080] “... adopt a method to correct the media data with packet loss to a data to comply with the specification or the standards...”<br>[0096] “Using coded macroblock number information in the video packet and the media data 208 in the video packet, macroblock data correction processing 3310 shown in FIG. 37 is performed.”<br>执行宏块数据纠正处理（图37）的模块（数据纠正处理单元707）可以视为实现该功能的装置。 | 参见技术特征F的论述。对比文件公开了基于当前视频包的起点和终点（所界定的错误区间）对媒体数据进行纠正（隐藏）的功能。执行该功能的数据纠正处理单元707构成了“用于基于所述当前单元的所述起点和所述被破坏数据段的所述终点来隐藏所述被破坏数据段的装置”。该技术特征被隐含公开。 |
<<<C>>><<<G>>><<<L>>><<<O>>><<<W>>><<<a>>><<<d>>><<<e>>><<<f>>><<<h>>><<<j>>><<<k>>><<<m>>><<<n>>><<<p>>><<<q>>><<<r>>><<<s>>><<<u>>><<<x>>><<<y>>><<<z>>>