CN113301387A - 数据编解码方法、相关设备及系统 - Google Patents

数据编解码方法、相关设备及系统 Download PDF

Info

Publication number
CN113301387A
CN113301387A CN202010107486.4A CN202010107486A CN113301387A CN 113301387 A CN113301387 A CN 113301387A CN 202010107486 A CN202010107486 A CN 202010107486A CN 113301387 A CN113301387 A CN 113301387A
Authority
CN
China
Prior art keywords
packet loss
burst
time delay
decoding
loss number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010107486.4A
Other languages
English (en)
Other versions
CN113301387B (zh
Inventor
陈军
周进华
李建平
郭建伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010107486.4A priority Critical patent/CN113301387B/zh
Priority to PCT/CN2020/137448 priority patent/WO2021164405A1/zh
Publication of CN113301387A publication Critical patent/CN113301387A/zh
Application granted granted Critical
Publication of CN113301387B publication Critical patent/CN113301387B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities

Abstract

本发明公开了一种数据编解码方法、相关设备及系统，应用于低时延敏感业务的数据的传输。该方法包括：在编码端，获取待编码数据，并获取时延T、在该时延T内最大连续丢包数B和最大突发丢包数N；根据时延T、最大连续丢包数B和最大突发丢包数N对待编码数据进行编码，以得到码流；在解码端，获取该码流，并根据时延T、最大连续丢包数B和最大突发丢包数N对码流进行解码，以得到待解码数据。采用本发明实施例有利于解决在数据传输中连续丢包和离散突发丢包的问题。

Description

数据编解码方法、相关设备及系统
技术领域
本发明涉及数据传输领域，尤其涉及一种数据编解码方法、相关设备及系统。
背景技术
未来的5G及B5G(Beyond 5G)演进网络需要满足各行各业的业务需求，同时能提供更低的时延.为应对实时交互类应用，其端到端时延小于150ms；到2020无线通信的数据面的时延控制需控制在4ms以内；更严格的要求来自于5G三大主要场景之一的超可靠低时延通信(ultra reliable low latency communication，uRLLC)，其对数据面的时延要求在ms级甚至低于1ms，同时要求保证数据的传输有很好的鲁棒性，如比特错误概率(biterrorrate，BER)小于10-6或更低，这就要系统不仅需要有较低的时延，同时需要有较好的纠错能力。
实际通信系统也多样千差万别，有线系统有光纤，铜线，无线系统有蜂窝和WiFi等。即使时有线网络，其带宽也会发生抖动,而无线系统由于存在信道的衰落和同频干扰也会有带宽的波动。为了对抗有线信道带宽的抖动和无线信道中的干扰或衰落，各种视频容错技术广泛的应用于现代通信系统中,例如基于重传自动重传请求(automatic repeatreQuest，HARQ)/混合自动重传请求(hybrid automatic repeat request，HARQ)，基于反馈的参考帧选择(reference picture selection,RPS)和前项纠错(forward errorcorrection，FEC)的方案等。由于网络往返传输时延,ARQ/RPS方案引入较长的时延不太合适对时延有较强要求的实时通信场景，而FEC成为相对有效的方案。
对于FEC，传统而FEC方案如安全可靠传输(secure reliable transport，SRT)系统自带的基于“异或”运算的纠错码只能纠正实际系统中特定的错误包，但该系统不具有满足5G系统中海量应用和不同的信道的不同需求的自适应能力。而里所(Reed-Solomon，RS)码的设计仅仅能保障纠正丢包时能正常恢复,并考虑业务的时延要求,即如何保证在应用的要求的前提下，如时延敏感业务要求10ms或5ms内，时间窗口内恢复丢失的数据包。因此RS码也无法满足5G及B5G系统中业务对于时延的要求。现有的5G网络中时延敏感业务(如AR/VR，视频直播业务)要求系统能在特定的时间窗口(如10ms内)纠正连续的丢包和突发的离散丢包,传统的系统编码设计如FEC方案无法满足对时延敏感的业务的需求。
发明内容
本发明实施例提供一种数据编解码方法、相关设备及系统，采用本发明实施例有利于解决在数据传输中连续丢包和离散突发丢包的问题。
第一方面，本发明实施例提供一种数据编码方法，包括：
获取待编码数据，并获取目标时延T和获取在该目标时延T内连续丢包数B和突发丢包数N，目标时延T为在数据传输过程中所需要的时延；根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流。
其中，突发丢包数N由信道引起。
优选地，目标时延T为在数据传输过程中所需要的最大时延，比如应用需要使用待编码数据，目标时延T为该应用所需要的最大时延。连续丢包数B为在目标时延T内最大连续丢包数，突发丢包数N为在目标时延T内最大的突发丢包数。
通过根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流，有利于解决在数据传输中连续丢包和离散突发丢包的问题，同时满足了数据传输过程中国对时延的需求。
在一个可行的实施例中，根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流，包括：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为编码前的码字数，n为编码后的码字数；根据k和n对待编码数据进行编码，以得到码流。
在一个可行的实施例中，根据目标时延T、连续丢包数B和突发丢包数N确定k和n，包括：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定容量C，并根据容量C确定k和n。其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，获取目标时延T，包括：
获取待编码数据对应的业务类型，并根据待编码数据对应的业务类型确定目标时延T。在传输不同类型业务的数据时采用不同的时延，满足了不同类型业务对时延的需求。
进一步地，在获取目标时延T后，将该目标时延T通过广播发送至多个用户端，或者通过单播发送至多个用户端。
将目标时延T发送至用户端，使得服务器和用户端在编码和解码时使用的时延T保持一致，从而保证用户端能够正确解码，克服了时延的问题。
在一个可行的实施例中，获取在目标时延T内连续丢包数B和突发丢包数N，包括：
获取在与用户端U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N，用户端U为接收待编码数据的用户端中的任一个；或者；
获取在与多个用户端进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N；多个用户端均为接收待编码数据的用户端。
通过对每个用户端单独确定连续丢包数B和突发丢包数N，实现在进行数据编码和解码时，对每个用户端进行最优的编译码适配，进而最大限度保证每个用户的体验；通过对多个用户同时进行连续丢包数B和突发丢包数N的确定，提高了优化统计的效率，并且由于连续丢包数B和突发丢包数N的传递需要占用带宽，从而提高了信道利用率。
进一步地，在获取在目标时延T内连续丢包数B和突发丢包数N之后，数据编码方法还包括：
将连续丢包数B和突发丢包数N通过单播至用户端U，或者；将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
将连续丢包数B和突发丢包数N发送至用户端，使得服务器和用户端在编码和解码时使用的B和N保持一致，从而保证用户端能够正确解码，克服了连续丢包和突发丢包的问题。
在一个可行的实施例中，获取目标时延T，包括：
接收多个用户端发送的参考时延，用户端U的参考时延为用户端U所需要时延；该用户端U为多个用户端中的任一个；根据多个用户端发送的参考时延确定目标时延T。
在此需要说明的是，用户端U的参考时延为在数据传输过程中，用户端U的应用不卡顿或者花屏的情况下，业务传输时帧与帧之间的最大时间差。
在一个可行的实施例中，在获取目标时延T后，数据编码方法还包括：
将目标时延T通过广播发送至多个用户端，或者；将目标时延T通过单播发送至多个用户端。
将目标时延T发送至用户端，使得服务器和用户端在编码和解码时使用的T保持一致，从而保证用户端能够正确解码，克服了时延的问题。
在一个可行的实施例中，获取在目标时延T内连续丢包数B和突发丢包数N，包括：
获取多个用户端发送的参考连续丢包数和参考突发丢包数；根据多个用户端发送的参考连续丢包数确定连续丢包数B、以及根据多个用户端的参考突发丢包数确定突发丢包数N；
其中，参考连续丢包数和参考突发丢包数分别为在上述参考时延内最大的连续丢包数和突发丢包数。
在一个可行的实施例中，获取在目标时延T内最大连续丢包数B和最大突发丢包数N之后，数据编码方法还包括：
将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
将连续丢包数B和突发丢包数N发送至用户端，使得服务器和用户端在编码和解码时使用的B和N保持一致，从而保证用户端能够正确解码，克服了连续丢包和突发丢包的问题。
可选地，在通过广播方式或单播方式发送目标时延T、连续丢包数B和突发丢包数N时，可通过与用户端之间新建的信令通道发送，该信令通道不同于传输数据的数据信道；或者通过传输数据的数据信道发送。
在一个可行的实施例中，多个用户端为：多个接收待编码数据所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
通过对用户端进行分类，使得不同类型的用户端与服务器进行数据传输时，可以获取对应的T,B,N，从而可以更好的克服时延和丢包的问题。
第二方面，本发明实施例提供一种数据解码方法，包括：
获取码流，并获取目标时延T，及获取在目标时延T内连续丢包数B和突发丢包数N；目标时延T为在数据传输过程中所需要的时延；根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据。
优选地，目标时延T为在数据传输过程中所需要的最大时延，比如应用需要使用解码后的数据，目标时延T为该应用所需要的最大时延。连续丢包数B为在目标时延T内最大连续丢包数，突发丢包数N为在目标时延T内最大的突发丢包数。
通过根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据，有利于解决在数据传输中连续丢包和离散突发丢包的问题，同时满足了在数据传输过程中时延的需求。
在一个可行的实施例中，根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据，包括：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为解码后的码字数，n为解码前的码字数；
根据k和n待解码数据进行解码，以得到解码后的数据。
在一个可行的实施例中，根据目标时延T、连续丢包数B和突发丢包数N确定k和n，包括：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定为容量C，并根据容量C确定k和n，其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，获取目标时延T，包括：
将从服务器接收到的时延确定为目标时延T，或者；将用户端U所需要的时延确定为目标时延T。
将接收服务器发送的目标时延T，使得服务器和用户端在编码和解码时使用的时延T保持一致，从而保证用户端能够正确解码，克服了时延的问题。
在一个可行的实施例中，获取目标时延T，包括：
向服务器发送参考时延，参考时延为用户端所需要的时延；接收服务器发送的目标时延T，目标时延T为服务器根据多个用户端发送的参考时延得到的。
在此需要说明的是，用户端U所需要时延可以理解为在数据传输过程中，用户端的应用不卡顿或花屏的情况下，业务传输时帧与帧之间的时间差。
在一个可行的实施例中，获取在目标时延T内连续丢包数B和突发丢包数N，包括：
获取在与服务器进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N。
在一个可行的实施例中，根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N之后，数据解码方法还包括：
向服务器发送连续丢包数B和突发丢包数N。
将连续丢包数B和突发丢包数N发送至服务器，使得服务器和用户端在编码和解码时使用的B和N保持一致，从而保证用户端能够正确解码，克服了连续丢包和突发丢包的问题
在一个可行的实施例中，获取在目标时延T内连续丢包数B和突发丢包数N，包括：
向服务器发送参考连续丢包数和参考突发丢包数，参考连续丢包数为用户端U根据多个历史连续丢包数得到的，参考突发丢包数为用户端U根据多个历史突发丢包数得到的；
接收服务器发送的连续丢包数B和突发丢包数N，连续丢包数B为服务器根据多个用户端的参考连续丢包数得到的，突发丢包数N为服务器根据多个参考突发丢包数得到的，多个用户端包括用户端U。
在一个可行的实施例中，多个用户端为：
多个获取码流所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
通过对用户端进行分类，使得不同类型的用户端与服务器进行数据传输时，可以获取对应的T,B,N，从而可以更好的克服时延和丢包的问题。
第三方面，本发明实施例提供一种服务器，包括：
获取单元，用于获取待编码数据，并获取目标时延T和获取在该目标时延T内连续丢包数B和突发丢包数N，目标时延T为在数据传输过程中所需要的时延；
编码单元，用于根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流。
在一个可行的实施例中，编码单元具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为编码前的码字数，n为编码后的码字数；根据k和n对待编码数据进行编码，以得到码流。
在一个可行的实施例中，在根据目标时延T、连续丢包数B和突发丢包数N确定k和n的方面，编码单元具有用于：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定容量C，并根据容量C确定k和n。其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，在获取目标时延T的方面，获取单元具体用于：
获取待编码数据对应的业务类型，并根据待编码数据对应的业务类型确定目标时延T。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元具体用于：
获取在与用户端U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N，用户端U为接收待编码数据的用户端中的任一个；或者；
获取在与多个用户端进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N；多个用户端均为接收待编码数据的用户端。
进一步地，服务器还包括：
发送单元，用于在获取单元获取在目标时延T内连续丢包数B和突发丢包数N之后，将连续丢包数B和突发丢包数N通过单播发送至用户端U，或者；将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
在一个可行的实施例中，在获取目标时延T的方面，获取单元具体用于：
接收多个用户端发送的参考时延，用户端U的参考时延为用户端U所需要时延；该用户端U为多个用户端中的任一个；根据多个用户端发送的参考时延确定目标时延T。
在一个可行的实施例中，服务器还包括：
发送单元，用于在获取目标时延T后，将目标时延T通过广播发送至多个用户端，或者；将目标时延T通过单播至多个用户端。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元具体用于：
获取多个用户端发送的参考连续丢包数和参考突发丢包数；根据多个用户端发送的参考连续丢包数确定连续丢包数B，以及根据多个用户端发送的参考突发丢包数确定突发丢包数N；
其中，参考连续丢包数和参考突发丢包数分别为在上述参考时延内最大的连续丢包数和最大突发丢包数。
在一个可行的实施例中，服务器还包括：
发送单元，用于在获取在目标时延T内最大连续丢包数B和最大突发丢包数N之后，将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N均通过单播发送至多个用户端。
在一个可行的实施例中，多个用户端为：多个接收待编码数据所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
第四方面，本发明实施例提供一种用户端，包括：
获取单元，用于获取码流，并获取目标时延T，及获取在目标时延T内连续丢包数B和突发丢包数N；目标时延T为在数据传输过程中所需要的时延；
解码单元，用于根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据。
在一个可行的实施例中，解码单元具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为解码后的码字数，n为解码前的码字数；根据k和n待解码数据进行解码，以得到解码后的数据。
在一个可行的实施例中，在根据目标时延T、连续丢包数B和突发丢包数N确定k和n的方面，解码单元具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定为容量C，并根据容量C确定k和n，其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，在获取目标时延T的方面，获取单元具体用于：
将从服务器接收到的时延确定为目标时延T，或者；将用户端U所需要的时延确定为目标时延T。
在一个可行的实施例中，在获取目标时延T的方面，获取单元具体用于：
向服务器发送参考时延，参考时延为用户端所需要的时延；接收服务器发送的目标时延T，目标时延T为服务器根据多个用户端的参考时延得到的，多个用户端包括用户端。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元具体用于：
获取在与服务器进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N。
在一个可行的实施例中，用户端还包括：
发送单元，用于在根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N之后，向服务器发送连续丢包数B和突发丢包数N。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元具体用于：
向服务器发送参考连续丢包数和参考突发丢包数，参考连续丢包数为用户端根据多个历史连续丢包数得到，参考突发丢包数为用户端根据多个历史突发丢包数得到的；
接收服务器发送的连续丢包数B和突发丢包数N，连续丢包数B为服务器根据多个用户端的参考连续丢包数得到的，突发丢包数N为服务器根据多个用户端的参考突发丢包数得到的，多个用户端包括用户端。
在一个可行的实施例中，多个用户端为：
多个获取码流所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
第五方面，本发明实施例提供一种服务器，包括：
存储器和与该存储器耦合的处理器，该处理器执行存储器中存储的指令，以实现第一方面中全部或部分内容。
第六方面，本发明实施例提供一种用户端，包括：
存储器和与该存储器耦合的处理器，该处理器执行存储器中存储的指令，以实现第一方面中全部或部分内容。
本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为SRT算法的原理示意图；
图2为信道变化引起的丢包示意图；
图3为分组码示意图；
图4a为5G网络场景下的数据传输示意图；
图4b为WiFi场景下的数据传输示意图；
图5为本申请实施例提供一种数据编码方法的流程示意图；
图6a为本申请实施例提供独立信令交互示意图；
图6b为本申请实施例提供的随路信令交互示意图；
图7为本申请实施例提供传输的数据格式示意图；
图8为本申请实施例提供一种数据解码方法的流程示意图；
图9为发明实施例提供的一种数据编解码系统的架构示意图；
图10为本发明实施例提供的一种服务器的结构示意图；
图11为本发明实施例提供的一种用户端的结构示意图；
图12为本发明实施例提供的另一种服务器的结构示意图；
图13为本发明实施例提供的另一种用户端的结构示意图。
具体实施方式
下面结合附图对本申请的实施例进行描述。
现有的SRT的纠错算法，基于简单的“异或”操作运算，如图1所示，对每行或是每列的原始数据包进行“异或”运算得到校验包。在接收端，如果发现丢失一个包，可以根据校验包并通过“异或”操作恢复出这个丢失的包。
但是这种算法弊端很明显，鲁棒性不高，即只能纠正每行或每列中丢的一个包，无法应对复杂的场景。现有无线或有线的系统在传输不同大小的包时，在一定的时间间隔内，可以带来连续多个包的丢失或者时分散的多个包丢失。如图1所示，实际系统的丢包可能是第0，1，2或者第2，5包丢失。对于这样的丢包模式，SRT自带的FEC算法无法纠正丢失的数据包，而且，SRT自带的FEC算法无法自我调整FEC参数，应对海量应用和信道的多样性时，SRT自带的FEC算法无法应对，最后SRT自带的FEC算法不考虑实际应用的时延约束，对于某些对时延敏感的业务要求应用在5个包间隔内保证译码正确，如图1所示的编码方式就无法满足该要求。
在数据传输过程中对数据有稳定性要求，不仅要求数据能正确传输,对时延也有要求，如图2所示，对于每个接收数据窗口长度T，窗口的长度T根据实际应用得到或是服务器根据用户的体验的反馈得到,或是通过一定的统计方法获取的，其衡量的单位可以是毫秒(ms),也可为包长的持续时间。基于FEC的数据传输时，根据实际应用的需求，希望数据能在特定时间恢复。在应用层，系统的丢包的模式主要分为如下两种：
·每个接收时间窗口T内有连续最大B个丢包。
·每个时延间隔T内N个分离的丢包(也称为突发丢包)。
如上述场景要求，可以证明满足时延T及上述要求纠错能力的信道编码速率R满足以下条件：
Figure BDA0002388893050000081
上述速率R的上界定义为容量，表示为：C(T,B,N)。对于C(T,B,N),满足要求的码称为最优流码(optimal streaming code)，即
Figure BDA0002388893050000082
通过上述分析，在满足特定的时延T，而且能纠正连续最大B个丢包或者N个突发丢包的分组码(n,k,T)是存在的，现在通过设计这分组码来满足实际需求。分组码如图3所示。
如图3所示，假设输入信息为k个m比特(这里的m通用的值取比如8，16等)的码字，表示为[s(0),s(1),…,s(k)]T，编码后的n个码字表示为：[x(0),x(1),…,x(n-1)]T。定义分组码的规模为n×k的生成矩阵为
Figure BDA0002388893050000083
其中，Ik为一个规模为k×k的校验矩阵，P为一个规模为(n×k)×k的校验矩阵，编码后的信息于编码的信息可以表示为：
Figure BDA0002388893050000084
如何通过编码得到编码矩阵G，可采用如下两种方案:
方案一：
步骤1:通过获得的T,B,N的值,生成一个n×k的范德蒙矩阵G1如下所示:
Figure BDA0002388893050000085
步骤2:对G1进行列变换,将G1的上k×k矩阵变为单位矩阵即得到G。
Figure BDA0002388893050000091
方案二：
步骤1:通过获得的T,B,N的值,生成一个n×k的柯西矩阵G2如下所示：
Figure BDA0002388893050000092
其中,G2中第i行第j列的元素的值为
Figure BDA0002388893050000093
步骤2:对G2进行列变换,将G2的上k×k矩阵变为单位矩阵即得到G。
Figure BDA0002388893050000094
下面介绍本发明的应用场景。
图4a为在5G网络场景下的数据传输示意图。如图4a所示，服务器中的高清视频源经过FEC编码器的编码后，得到视频码流。比如，服务器获取时延T、在时延T内的连续丢包数B和突发丢包数N，根据时延T、连续丢包数B和突发丢包数N对高清视频源进行编码，以得到视频码流，并将该视频码流通过5G网络传输至用户端。5G网络包括核心网、基站和客户前置设备(Customer Premise Equipment，CPE)。用户端可以是支持与CPE连接的AR/VR头盔或者是智能手机或是掌上游戏设备，智能电视，智能盒子等。
类似地，图4b为在WiFi场景下的数据传输示意图。如图4b所示，服务器中的高清视频源经过FEC编码器的编码后，得到视频码流，该视频码流通过骨干网及WiFi设备传输至用户端。
用户端在获取视频码流后，用户端中的FEC解码器对视频码流进行解码，以得到高清视频源。具体地，获取时延T、在时延T内的连续丢包数B和突发丢包数N，根据时延T、连续丢包数B和突发丢包数N对视频流进行解码，以得到高清视频源。
参见图5，图5为本发明实施例提供的一种数据编码方法的流程示意图。如图5所示，该方法包括：
S501、服务器获取待编码数据，并获取目标时延T和获取在目标时延T内连续丢包数B和突发丢包数N。
其中，目标时延T为在数据传输过程中所需要的时延。待编码数据可以为对时延要求较高的数据，比如视频直播数据、VR/AR视频数据等。
优选地，目标时延T为在数据传输过程中所需要的最大时延，比如用户端的应用所需要的最大时延，连续丢包数B和突发丢包数N为在杉树目标时延T内的最大连续丢包数和最大突发丢包数。其中，突发丢包是由信道引起的，比如，突发丢包由信道带宽的波动或是其它用户的干扰等引起。
在一个可行的实施例中，服务器获取目标时延T包括：
服务器获取待编码数据对应的业务类型，并根据待编码数据的业务类型确定目标时延T。
具体地，在服务器端，不同类型的业务由不同的APP来处理，不同的APP要求的QOS不一样，因此可基于待编码数据对应的业务类型确定目标时延T。
可选地，目标时延T可以为6个帧长的持续时间或者10个帧长的持续时间。
通过根据待编码数据对应的业务类型确定目标时延T，可满足不同类型的业务的时延需求。
在一个可行的实施例中，服务器获取目标时延T，包括：
服务器接收多个用户端发送的参考时延，用户端U的参考时延为用户端U所需要的时延该用户端U为多个用户端中的任一个，根据多个用户端发送的参考时延确定目标时延。
其中，目标时延T为多个用户端的参考时延的最大值、最小值、平均值或者基于该多个用户端的参考时延进行预测得到的。
在此需要说明的是，用户端U的参考时延为在数据传输过程中，且用户端U的应用不卡顿或者花屏的前提下，业务传输时帧与帧之间最大的时间差。
进一步地，服务器在获取目标时延T后，将目标时延T通过广播发送至或者通过单播发送至上述多个用户端，以使服务器与用户端使用的时延是一致的。
在一个可行的实施例中，服务器获取在目标时延T内连续丢包数B和突发丢包数N，包括：
服务器获取在与用户端U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N，用户端U为接收待编码数据的用户端中的任一个；或者；
服务器获取在与多个用户端进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N；多个用户端均为接收待编码数据的用户端。
具体地，服务器在获取与用户端U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数后，根据多个历史连续丢包数确定连续丢包数B，根据多个历史突发丢包数确定突发丢包数N。其中，连续丢包数B为多个历史连续丢包数中的最大值、最小值、或者平均值，或者连续丢包数B是对多个历史连续丢包数进行预测得到的。突发丢包数N为多个历史突发丢包数中的最大值、最小值、或者平均值，或者突发丢包数N是对多个历史突发丢包数进行预测得到的。
再具体地，服务器获取在与多个用户端进行数据传输过程中的使用的多个历史连续丢包数和多个历史突发丢包数后，根据多个用户端的历史连续丢包数确定连续丢包数B，根据多个用户端的历史突发丢包数确定突发丢包数N。其中，连续丢包数B为多个用户端的历史连续丢包数中的最大值、最小值、或者平均值，或者连续丢包数B是对多个用户端的历史连续丢包数进行预测得到的。突发丢包数N为多个用户端的历史突发丢包数中的最大值、最小值、或者平均值，或者突发丢包数N是对多个用户端的历史突发丢包数进行预测得到的。
可选地，连续丢包数B是对多个历史连续丢包数进行平滑/平均处理得到的，同理，突发丢包数N是对多个历史突发丢包数进行平滑/平均处理得到的。平滑/平均处理包括：算术平均法，指数平均法，或是几何平均法，当然本发明不限于此。
以算术平均法进行举例说明，突发丢包数N可表示为：
Figure BDA0002388893050000111
可选地，连续丢包数B是基于多个历史连续丢包数进行预测得到的，同理，突发丢包数N是根据多个历史突发丢包数进行预测得到的。
比如突发丢包数N＝α1N1+α2N2+…+αMNM，其中，预测参数α1,α2,…,αM采用现有的线性预测方案中的参数估计算法得到。
N1,N2,…,NM为前M个历史突发丢包数。统计M次数据所需要的时长为预设时长，在预设时长内，最大的突发丢包数相对最小的突发丢包数变化不大于某一门限值，比如10％，门限值可以根据实际需求来调整。
在此需要说明的是，连续丢包数B同样可采用上述方法得到，在此不再叙述。
进一步地，服务器在获取连续丢包数B和突发丢包数N后，将连续丢包数B和突发丢包数N通过单播发送至用户端U，或者；将连续丢包数B和突发丢包数N通过广播发送至上述多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
在一个可行的实施例中，服务器获取在目标时延T内连续丢包数B和突发丢包数N，包括：
服务器获取多个用户端发送的参考连续丢包数和参考突发丢包数；根据多个用户端发送的参考连续丢包数确定连续丢包数B，以及根据多个用户端发送的参考突发丢包数确定突发丢包数N；
其中，参考连续丢包数和参考突发丢包数分别为在上述参考时延内最大的连续丢包数和突发丢包数。
在一个可行的实施例中，服务器获取在目标时延T内最大连续丢包数B和最大突发丢包数N之后，服务器将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
可选地，在通过广播方式或单播方式发送目标时延T、连续丢包数B和突发丢包数N时，可通过与用户端之间新建的信令通道发送，该信令通道不同于传输数据的数据信道；或者通过传输数据的数据信道发送。
具体地，服务器与用户端进行参数交互可通过独立信令通道交互模式或随路信令交互模式。
其中，独立信令通道交互模式，是对于服务器与用户端的重要的编码信息，如T,B,N信息,可以通过单独发起一路通信链路来传输T,B和N的信息。如图6a所示，传输的数据格式不限。基于此中方案的独立信令通道发送信令时，信令的发送要和当前的数据匹配，即数据与信令通过不同的信道发送，但时间上可以认为是同步的，可以通过对齐各自链路的时间戳或统一的帧号的方式来保证时间同步。
随路信令交互模式，是指服务器与用户端之间的信令和数据在同一条通信链路中传输，如图6b所示。传输的数据格式如图7所示，可以是格式I，也可以是格式II。
在一个可行的实施例中，多个用户端为：多个接收待编码数据所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需QoS等级相同或QoE相同的用户端。
具体地，对与服务器进行数据的用户端进行分类，可以基于传输方式分类，可以根据用户端处理的业务类型分类，或者用户端所需的QoS或QoE进行分类。其中，传输方式包括5G网络、WiFi和光纤；用户端处理的业务类型是基于用户端中的APP的类型来分类，比如音乐类、视频类和资讯类等。
S502、服务器根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流。
在一个可行的实施例中，服务器根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流，包括：
服务器根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为编码前的码字数，n为编码后的码字数，根据k和n对待编码数据进行编码，以得到码流。
进一步地，服务器根据目标时延T、连续丢包数B和突发丢包数确定k和n，包括：
服务器根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定容量C，根据容量C确定k和n。
其中，容量C为信道编码效率R的最大值，容量C大于或等于k/n。
在此需要说明的是，根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流的具体实现过程可参见图3所示实施例的相关描述，在此不再叙述。
可以看出，在本申请的方案中，通过根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流，有利于解决在数据传输中连续丢包和离散突发丢包的问题。并且在传输不同类型业务的数据时采用不同的时延，满足了不同类型业务对时延的需求。
参见图8，图8为本发明实施例提供的一种数据解码方法的流程示意图。如图8所示，该方法包括：
S801、用户端获取码流，并获取目标时延T，及获取在目标时延T内连续丢包数B和突发丢包数N。
其中，目标时延T为在数据传输过程中所需要的时延。
可选地，目标时延T为在数据传输过程中所需要的最大时延，比如应用需要使用解码后的数据，目标时延T为该应用所需要的最大时延。连续丢包数B为在目标时延T内最大连续丢包数，突发丢包数N为在目标时延T内最大的突发丢包数。
在一个可行的实施例中，用户端获取目标时延T，包括：
用户端将从服务器接收到的时延确定为目标时延T，或者；用户端将其所需要的时延确定为目标时延T。
在一个可行的实施例中，用户端获取目标时延T，包括：
用户端向服务器发送参考时延，参考时延为用户端所需要的时延。用户端接收服务器发送的目标时延T，目标时延T为服务器根据多个用户端发送的参考时延得到的。
在此需要说明的是，用户端所需要的时延可以理解为在数据传输过程中，用户端的应用不卡顿或花屏的情况下，业务传输时帧与帧之间的时间差。
在一个可行的实施例中，用户端获取在目标时延T内连续丢包数B和突发丢包数N，包括：
用户端获取在与服务器进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；用户端根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N。
其中，连续丢包数B是对多个历史连续丢包数进行平滑/平均处理得到的，同理，突发丢包数N是对多个历史突发丢包数进行平滑/平均处理得到的。平滑/平均处理包括：算术平均法，指数平均法，或是几何平均法，当然本发明不限于此。
以算术平均法进行举例说明，突发丢包数N可表示为：
Figure BDA0002388893050000131
可选地，连续丢包数B是基于多个历史连续丢包数进行预测得到的，同理，突发丢包数N是根据多个历史突发丢包数进行预测得到的。
比如突发丢包数N＝α1N1+α2N2+…+αMNM，其中，预测参数α1,α2,…,αM采用现有的线性预测方案中的参数估计算法得到。
N1,N2,…,NM为前M个历史突发丢包数。统计M次数据所需要的时长为预设时长，在预设时长内，最大的突发丢包数相对最小的突发丢包数变化不大于某一门限值，比如10％，门限值可以根据实际需求来调整。
在此需要说明的是，连续丢包数B同样可采用上述方法得到，在此不再叙述。
在一个可行的实施例中，用户端根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N之后，数据解码方法还包括：
用户端向服务器发送连续丢包数B和突发丢包数N。
在一个可行的实施例中，用户端获取在目标时延T内连续丢包数B和突发丢包数N，包括：
用户端向服务器发送参考连续丢包数和参考突发丢包数，参考连续丢包数为用户端U根据分别多个历史连续丢包数得到的，参考突发丢包数为用户端U根据多个历史突发丢包数得到的；
用户端接收服务器发送的连续丢包数B和突发丢包数N，连续丢包数B为服务器根据多个用户端的参考连续丢包数得到的，突发丢包数N为服务器根据多个用户端的参考突发丢包数得到的，多个用户端包括上述用户端。
在一个可行的实施例中，多个用户端为：
多个获取码流所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
在此需要说明的是，步骤S801的具体描述可参见上述步骤S501的相关描述，在此不再叙述。
S802、用户端根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据。
在一个可行的实施例中，用户端根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据，包括：
用户端根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为解码后的码字数，n为解码前的码字数；
用户端根据k和n待解码数据进行解码，以得到解码后的数据。
在一个可行的实施例中，用户端根据目标时延T、连续丢包数B和突发丢包数N确定k和n，包括：
用户端根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定为容量C，并根据容量C确定k和n，其中，k/n≤C，C为信道编码效率R的最大值。
在此需要说明的是，根据目标时延T、连续丢包数B和突发丢包数N对码流进行编码，以得到解码后的数据的具体实现过程可参见图3所示实施例的相关描述，在此不再叙述。
可以看出，在本发明实施例的方案中，通过根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据，有利于解决在数据传输中连续丢包和离散突发丢包的问题。并且在传输不同类型业务的数据时采用不同的时延，满足了不同类型业务对时延的需求。
参见图9，图9为本发明实施例提供的一种数据编解码系统的架构示意图。如图9所示，该数据编解码系统包括服务器和用户端。其中，服务器包括APP接口模块，FEC编码器、应用层与物理层接口、物理层和服务器参数预测管理模块；其中，服务器参数预测管理模块包括APP分类/解析器和参数预测模块。用户端包括APP接口模块，FEC解码器、应用层与物理层接口、物理层和用户端参数统计管理模块；其中，用户端参数统计管理模块包括APP分类/解析器和参数估计模块。
首先对服务器各功能模块的功能进行介绍。
APP接口模块用于处理各应用的数据以及将应用的数据转换为FEC编码器能处理的数据，即对APP的视频或原始的待编码的数据进行拆分或组合以便FEC编码其进行编码。
FEC编码器，用于对各应用的数据进行编码，以增强器对抗信道传输的鲁棒性，具体的编码过程可参见图3的相关描述。其中FEC编码器所需要的参数如，T，B，N通过服务器参数预测管理模块来获得。
应用层与物理层接口：由于经过FEC编码器编码后的数据还不能直接传给物理层进行传输，还要经过处理与转换，如果是应用的数据，需要加入相应的包头，如果是信令，需要做保护处理，具体保护处理可以参考通用的信令传输的方案。
物理层是对应实际的5G系统或是光纤网络或是WiFi网络，对APP数据进行传输。
服务器参数预测管理模块，用于获取目标时延T、连续丢包数B和突发丢包数N。其中，目标时延T与应用强相关，连续丢包数B和突发丢包数N与信道强相关。
目标时延T、连续丢包数B和突发丢包数N均可由服务器或用户端获取，然后共享给对方。
目标时延T根据实际应用的时延需求来设定，对于服务器，可根据服务器中的APP的QoS得到，具体实施时，可以先由服务器参数预测管理模块中的分类解析器对APP进行分类，再根据分类的结果给出不同的T值，T值的设定可以为6个帧长的时间或者10个帧长时间，或者对于用户端，可通过用户端参数统计管理模块来维护目标延时T，此时的T值可以由应用统计,基于如下方方式:如记录观看视频时在不发生花屏，卡顿或视频与音频不同步的情况下所需要的相邻数据包/数据帧之间的最大时延。
对于连续丢包数B和突发丢包数N，由于在实际应用中信道是时变的，其造成的丢包情况有时会恒定不变，有时可能差异较大，因此实时统计丢包长度与丢包次数，即连续丢包数B和突发丢包数N等需要根据实际需求来统计，统计的模块可以放在服务器中，也可以放在用户端。以下从服务器侧和用户端侧来分别叙述：
服务器侧，由服务器参数预测管理模获取连续丢包数B和突发丢包数N，具体可采用如下方法：
1)对每个用户端单独统计B和N：
对于服务器来说，认为每个用户端在传输数据时所使用的信是不一样的，因此每个用户端所使用的B、N和其它译码对应的参数单独统计。比如，针对播放视频的用户端，无论其是否采用同一APP进行播放，需要单独统计其传输数据时的B，N。这种统计方式的好处是，可对每个用户端进行最优的编解码参数的适配，最大限度保证每个用户的体验。由于实际系统的B，N值会随着时间变化，统计方案包括
统计方案1：连续丢包数B的值可以是对一段时间内的历史连续丢包数进行平滑/平均处理得到的值；同理，突发丢包数N的值可以是对一段时间内的历史连续丢包数进行平滑/平均处理得到的值。平滑/平均处理的方案包括但不限于算术平均法，指数平均法，或几何平均法。比如突发丢包数N可以表示为：
Figure BDA0002388893050000151
N1,N2,…,NM为统计的前M次历史连续丢包数，统计M次所需要的时长为预设时长，在预设时长内，最大的丢包相对最小的丢包变化不大于某一门限值，比如10％，门限值可以根据实际需求来调整。
统计方案2：连续丢包数B可以是基于统计一段时间内的历史连续丢包数进行预测得到的，同理，突发丢包数N可以是基于统计一段时间内的历史突发丢包数进行预测得到的，预测的方法可以基于线性预测模型或是自回归预测模型等。其中，线性预测方案如下:
N＝α1N1+α2N2+…+αMNM
α1,α2,…,αM为预测参数，是采用现有的线性预测方案中的参数估计算法得到。N1,N2,…,NM为统计的前M次历史连续丢包数，统计M次所需要的时长为预设时长，在预设时长内，最大的丢包相对最小的丢包变化不大于某一门限值，比如10％，门限值可以根据实际需求来调整。
统计方案3：对统计后的数据不做处理，生效的参数即是当前统计得到的值。换言之，连续丢包数B和突发丢包数N为服务器在与用户端进行数据传输过程中历史使用的连续丢包数和突发丢包数。
2)对用户端进行分类确定连续丢包数B和突发丢包数N
对用户端进行分类的方式包括：可基于当前APP的数据的传输方式进行分类；可以是基于用户端的APP进行分类；还可以根据用户端中应用所需的QoS或QoE等级进行分类。
比如，将通过5G进行数据传输的用户端分为一类，将通过WiFi进行数据传输的用户端分为一类，将通过光纤进行数据传输的用户端分为一类。确定连续丢包数B和突发丢包数N时根据传输方式(可以看成信道)来统计。这样做的好处是在保证降低APP的体验的前提下，优化获取B和N的效率，间接做到信道利用率的提升(因为B和N的传递均需要占用带宽)。
对用户端进行分类后，可通过取最大值的方式、取均值方式得到B和N。对采用最大值的方案举例如下：
N＝max(N1,N2,…,NM)
N1,N2,…,NM为统计一类中的某一用户端的前M次历史连续丢包数，统计M次所需要的时长为预设时长，在预设时长内，最大的丢包相对最小的丢包变化不大于某一门限值，比如10％，门限值可以根据实际需求来调整。
用户端侧，由用户端参数统计管理模获取连续丢包数B和突发丢包数N，具体可采用如下方法：
用户端获取连续丢包数B和突发丢包数N的具体方式与服务器连续丢包数B和突发丢包数N的具体方式相同，如同样可以根据历史的突发丢包数和连续丢包数进行平均或平滑，或是做预测处理。与服务器侧不同的是，对于B,N，用户端只能获取其自己的历史突发丢包数和历史连续丢包数，无法获取其他设备的，也不能根据信道类型来区分。与服务器一样的是其统计的B,N是可以让应用类型的来分类，如腾讯音乐和网易云音乐都归为同一类，音频类来统计，其统计的应用规模相对服务器小很多，计算复杂度低。
无论是服务器或是用户端，在得到相关的参数(比如T,,B,N)后，服务器根据生成所需的码流，用户端在解码时，根据最新的参数(比如T,,B,N)和接收到的数据以及编码信息恢复出原始数据。
在上述流程中，由于相应重要的参数如T，B，N是编码解码所必须的参数，需要服务器与用户端共享保持一致，因此重要参数需要进行服务器与用户端进行交互，进行参数交互方式可以如下两种：
交互方案1:以服务器为主的方案：
以服务器为主的方案，即服务器与用户端进行数据传输时使用的T，B，N以服务器获取的为准，服务器把相应的T，B，N对用户端进行广播或单播；
广播方案对应分类统计的场景,对用户端根据其APP的类别进行分类,归为同一类的用户,服务器对同一类的用户端进行参数广播,用户端在接收到广播的T，B，N后即更新。
单播主要针对每个用户单独统计参数的场景，服务器对每个用户端单播其T，B，N，用户端收到T，B，N后即更新。
交互方案2:以用户反馈为主的方案：
用户端将获取的参数(比如T，B，N)反馈至服务器后，服务器根据用户的反馈的参数获取其所需的参数并更新。
有两种场景，如果是每个用户端的参数是单独统计的，用户端的反馈参数只针对其与服务器之间的信道情况，此时服务器的编码器使用的参数为用户反馈的参数或是对用户端反馈的参数进行平均处理后得到参数；若服务器的编码器使用的参数为对用户端反馈的参数进行平均处理后得到参数，则服务器需要将该参数反馈至用户端，使得服务器与用户端使用的参数一致。
若是针对分类的场景，服务器需要根据多个用户端反馈的参数进行判断并更新编码器的参数，云端的参数处理方案可以采用前述的对多个用户端反馈的参数取平均，或是取最大值等，具体过程可参见前述相关描述。其更新后的参数需要告知用户，此时用户可以随路信令的方式获取，或者是通过广播信号获得其最新的参数。
服务器与用户端的参数信息交互可以是周期的和非周期，周期的方式，其更新的周期不超过当前信道的相干时间。优选的更新方式为周期更新方式，其鲁棒性更优。此方法可以保证服务器在某一次更新时，用户端不能正常接收参数信息时，可以根据后一周期的参数进行适当补救，避免长时间的服务器与用户端的数据不能同步的情况,而且能自适应信道的变化。
对于用户端新增加模块中的其它各子模块与云端的功能可以等同，如参数估计模块对应服务器的参数预测模块，实现的方式可以参考服务器的模块，APP分类解析器也与服务器的类似。在此不再赘述。
参数T，B,N主要是提供给FEC译码器相应的译码信息，此时译码器根据用户端的参数统计模块获取最新的T，B，N后，可以对接收的数据进行译码。译码方案有多种，可以基于矩阵求逆法，或是通用RS码译码方法，如：Berlekamp-Massey译码法,Peterson-Gorenstein-Zierler译码法，离散傅里叶变换法等。
以矩阵求逆译码进行举例说明：
首先根据T，B，N的信息以及辅助信息用户端可以生成和服务器端一致的编码生成矩阵G，具体生成方式可以参考前文的相关描述，在此不再叙述。得到生成矩阵后，可以根据接收的数据以及矩阵G，采用高斯消元法恢复出原始数据。如下公式：
Gs＝r
其中，G为生成矩阵，s为所需要恢复的数据，r为接收的数据。如果要得到s,相当于对齐求线性方程组，基于高斯消元法可以得到s。具体如何做高斯消元法可以参考现有的线性代数的教材，在此不再赘述。
参见图10，图10为本发明实施例提供的一种服务器的结构示意图。如图10所示，该服务器1000包括：
获取单元1001，用于获取待编码数据，并获取目标时延T和获取在该目标时延T内连续丢包数B和突发丢包数N，目标时延T为在数据传输过程中所需要的时延；
编码单元1002，用于根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流。
在一个可行的实施例中，编码单元1002具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为编码前的码字数，n为编码后的码字数；根据k和n对待编码数据进行编码，以得到码流。
在一个可行的实施例中，在根据目标时延T、连续丢包数B和突发丢包数N确定k和n的方面，编码单元1002具有用于：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定容量C，并根据容量C确定k和n。其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，在获取目标时延T的方面，获取单元1001具体用于：
获取待编码数据对应的业务类型，并根据待编码数据对应的业务类型确定目标时延T。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元1002具体用于：
获取在与用户端U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N，用户端U为接收待编码数据的用户端中的任一个；或者；
获取在与多个用户端进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N；多个用户端均为接收待编码数据的用户端。
进一步地，服务器1000还包括：
发送单元1003，用于在获取单元获取在目标时延T内连续丢包数B和突发丢包数N之后，将连续丢包数B和突发丢包数N通过单播发送至用户端U，或者；将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
在一个可行的实施例中，在获取目标时延T的方面，获取单元1001具体用于：
接收多个用户端发送的参考时延，用户端U的参考时延为用户端U所需要时延；该用户端U为多个用户端中的任一个；根据多个用户端发送的参考时延确定目标时延T。
在一个可行的实施例中，服务器1000还包括：
发送单元1003，用于在获取目标时延T后，将目标时延T通过广播发送至多个用户端，或者；将目标时延T通过单播发送至多个用户端。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元1001具体用于：
获取多个用户端发送的参考连续丢包数和参考突发丢包数；根据多个用户端发送的参考连续丢包数确定连续丢包数B，以及根据多个用户端发送的参考突发丢包数确定突发丢包数N；
其中，参考连续丢包数和参考突发丢包数分别为在上述参考时延内最大的连续丢包数和最大突发丢包数。
在一个可行的实施例中，服务器1000还包括：
发送单元1003，用于在获取单元1001获取在目标时延T内最大连续丢包数B和最大突发丢包数N之后，将连续丢包数B和突发丢包数N通过广播发送至多个用户端，或者；将连续丢包数B和突发丢包数N通过单播发送至多个用户端。
在一个可行的实施例中，多个用户端为：多个接收待编码数据所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
需要说明的是，上述各单元(获取单元1001、编码单元1002和发送单元1003)用于执行上述方法的相关步骤。比如获取单元1001和发送单元1003用于执行S501的相关内容，编码单元1002用于执行S502的相关内容。
在本实施例中，服务器1000是以单元的形式来呈现。这里的“单元”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。此外，以上获取单元1001和编码单元1002可通过图12所示的服务器的处理器1201来实现。
参见图11，图11为本发明实施例提供一种用户端的结构示意图。如图11所示，用户端1100包括：
获取单元1101，用于获取码流，并获取目标时延T，及获取在目标时延T内连续丢包数B和突发丢包数N；目标时延T为在数据传输过程中所需要的时延；
解码单元1102，用于根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据。
在一个可行的实施例中，解码单元1102具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定k和n，k为解码后的码字数，n为解码前的码字数；根据k和n待解码数据进行解码，以得到解码后的数据。
在一个可行的实施例中，在根据目标时延T、连续丢包数B和突发丢包数N确定k和n的方面，解码单元1102具体用于：
根据目标时延T、连续丢包数B和突发丢包数N确定信道编码效率R的取值范围；根据信道编码效率R确定为容量C，并根据容量C确定k和n，其中，k/n≤C，C为信道编码效率R的最大值。
在一个可行的实施例中，在获取目标时延T的方面，获取单元1101具体用于：
将从服务器接收到的时延确定为目标时延T，或者；将用户端U所需要的时延确定为目标时延T。
在一个可行的实施例中，在获取目标时延T的方面，获取单元1101具体用于：
向服务器发送参考时延，参考时延为用户端1100所需要的时延；接收服务器发送的目标时延T，目标时延T为服务器根据多个用户端的参考时延得到的，多个用户端包括用户端1100。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元1101具体用于：
获取在与服务器进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N。
在一个可行的实施例中，用户端1100还包括：
发送单元1103，用于在根据多个历史连续丢包数确定连续丢包数B，以及根据多个历史突发丢包数确定突发丢包数N之后，向服务器发送连续丢包数B和突发丢包数N。
在一个可行的实施例中，在获取在目标时延T内连续丢包数B和突发丢包数N的方面，获取单元1101具体用于：
向服务器发送参考连续丢包数和参考突发丢包数，参考连续丢包数为用户端1100根据分别多个历史连续丢包数得到的，参考突发丢包数为用户端1100根据多个历史突发丢包数得到的；
接收服务器发送的连续丢包数B和突发丢包数N，连续丢包数B为服务器根据多个用户端的参考连续丢包数得到的，突发丢包数N为服务器根据多个用户端的参考突发丢包数得到的，多个用户端包括用户端1100。
在一个可行的实施例中，多个用户端为：
多个获取码流所采用相同传输方式的用户端，或者；多个处理相同类型业务的用户端，或者；多个所需服务质量QoS等级相同或体验质量QoE相同的用户端。
需要说明的是，上述各单元(获取单元1101、解码单元1102和发送单元1103)用于执行上述方法的相关步骤。比如获取单元1101和发送单元1103用于执行S801的相关内容，解码单元1102用于执行S802的相关内容。
在本实施例中，用户端1100是以单元的形式来呈现。这里的“单元”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。此外，以上获取单元1101和解码单元1102可通过图13所示的用户端的处理器1301来实现。
如图12所示服务器1200可以以图12中的结构来实现，该服务器1200包括至少一个处理器1201，至少一个存储器1202以及至少一个通信接口1203。所述处理器1201、所述存储器1202和所述通信接口1203通过所述通信总线连接并完成相互间的通信。
处理器1201可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。
通信接口1203，用于与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。
存储器1202可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，所述存储器1202用于存储执行以上方案的应用程序代码，并由处理器1201来控制执行。所述处理器1201用于执行所述存储器1202中存储的应用程序代码。
存储器1202存储的代码可执行以上提供的任一种数据编码方法，比如：获取待编码数据，并获取目标时延T和获取在该目标时延T内连续丢包数B和突发丢包数N，目标时延T为在数据传输过程中所需要的时延；根据目标时延T、连续丢包数B和突发丢包数N对待编码数据进行编码，以得到码流。
如图13所示用户端1300可以以图13中的结构来实现，该用户端1300包括至少一个处理器1301，至少一个存储器1302以及至少一个通信接口1303。所述处理器1301、所述存储器1302和所述通信接口1303通过所述通信总线连接并完成相互间的通信。
处理器1301可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。
通信接口1303，用于与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。
存储器1302可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，所述存储器1302用于存储执行以上方案的应用程序代码，并由处理器1301来控制执行。所述处理器1301用于执行所述存储器1302中存储的应用程序代码。
存储器1302存储的代码可执行以上提供的任一种数据编码方法，比如：获取码流，并获取目标时延T，及获取在目标时延T内连续丢包数B和突发丢包数N；目标时延T为在数据传输过程中所需要的时延；根据目标时延T、连续丢包数B和突发丢包数N对码流进行解码，以得到解码后的数据。
在此需要说明的是，在实际应用中，上述服务器可以看成编码装置，相应地，用户端可以看成解码装置。
本发明实施例还提供一种计算机存储介质，其中，该计算机存储介质可存储有程序，该程序执行时包括上述方法实施例中记载的任何一种数据编解码方法的部分或全部步骤。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取器(英文：Random Access Memory，简称：RAM)、磁盘或光盘等。
以上对本发明实施例进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上上述，本说明书内容不应理解为对本发明的限制。

Claims (45)

1.一种数据编码方法，其特征在于，包括：
获取待编码数据，并获取目标时延T和获取在所述目标时延T内连续丢包数B和突发丢包数N；所述目标时延T为在数据传输过程中所需要的时延；
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N对所述待编码数据进行编码，以得到码流。
2.根据权利要求1所述的方法，其特征在于，所述根据所述目标时延T、所述连续丢包数B和所述突发丢包数N对所述待编码数据进行编码，以得到码流，包括：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，所述k为编码前的码字数，所述n为编码后的码字数；
根据所述k和n对所述待编码数据进行编码，以得到所述码流。
3.根据权利要求2所述的方法，其特征在于，所述根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，包括：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定信道编码效率R的取值范围；
根据所述信道编码效率R确定容量C，并根据所述容量C确定所述k和n。
4.根据权利要求1-3任一项所述的方法，其特征在于，所述获取目标时延T，包括：
获取所述待编码数据对应的业务类型，并根据所述待编码数据对应的业务类型确定所述目标延时T。
5.根据权利要求1-3任一项所述的方法，其特征在于，所述获取在所述目标时延T内连续丢包数B和突发丢包数N，包括：
获取在与解码装置U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N，所述解码装置U为接收所述待编码数据的解码装置中的任一个；或者；
获取在与多个解码装置进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N；所述多个解码装置均为接收待编码数据的解码装置。
6.根据权利要求1-3任一项所述的方法，其特征在于，所述获取目标时延T，包括：
接收多个解码装置发送的参考延时，解码装置U的参考延时为所述解码装置U所需要的延时；
根据所述多个解码装置发送的参考延时确定所述目标延时T；
其中，所述解码装置U为所述多个解码装置中的任一个。
7.根据权利要求6所述的方法，其特征在于，所述获取目标延时T后，所述方法还包括：
将所述目标延时T通过广播发送至所述多个解码装置，或者；
将所述目标时延T通过单播至所述多个解码装置。
8.根据权利要求1-3任一项所述的方法，其特征在于，所述获取在所述目标时延T内连续丢包数B和突发丢包数N，包括：
获取多个解码装置发送的参考连续丢包数和参考突发丢包数；
根据所述多个解码装置发送的参考连续丢包数确定所述连续丢包数B，以及根据多个解码装置发送的参考突发丢包数确定所述突发丢包数N。
9.根据权利要求8所述的方法，其特征在于，所述获取在所述目标时延T内连续丢包数B和突发丢包数N之后，所述方法还包括：
将所述连续丢包数B和所述突发丢包数N通过广播发送至所述多个解码装置，或者；
将所述连续丢包数B和所述突发丢包数N通过单播发送至所述多个解码装置。
10.根据权利要求5-9任一项所述的方法，其特征在于，所述多个解码装置为：
多个接收所述待编码数据所采用相同传输方式的解码装置，或者；
多个处理相同类型业务的解码装置，或者；
多个所需服务质量QoS等级相同或体验质量QoE相同的解码装置。
11.一种数据解码方法，其特征在于，包括：
获取码流，并获取目标时延T，及获取在所述目标时延T内连续丢包数B和突发丢包数N；所述目标时延T为在数据传输过程中所需要的时延；
根据所述目标时延T、所述连续丢包数B和突发丢包数N对所述码流进行解码，以得到解码后的数据。
12.根据权利要求11所述的方法，其特征在于，所述根据所述目标时延T、所述连续丢包数B和突发丢包数N对所述码流进行解码，以得到解码后的数据，包括：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，所述k为解码后的码字数，所述n为解码前的码字数；
根据所述k和n所述待解码数据进行解码，以得到所述解码后的数据。
13.根据权利要求12所述的方法，其特征在于，所述根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，包括：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定信道编码效率R的取值范围；
根据所述信道编码效率R确定为容量C，并根据所述容量C确定所述k和n。
14.根据权利要求11-13任一项所述的方法，其特征在于，所述获取目标时延T，包括：
将从编码装置接收到的时延确定为目标时延T。
15.根据权利要求11-13任一项所述的方法，其特征在于，所述获取目标时延T，包括：
将解码装置U所需要的时延确定为目标时延T。
16.根据权利要求15所述的方法，其特征在于，所述将解码装置U所需要的时延确定为目标时延T，之后，所述方法还包括：
向编码装置发送所述目标时延T。
17.根据权利要求11-13任一项所述的方法，其特征在于，所述获取目标时延T，包括：
向编码装置发送参考时延，所述参考时延为解码装置U所需要的时延；
接收所述编码装置发送的目标时延T，所述目标时延T为所述编码装置根据多个解码装置的参考时延得到的，所述多个解码装置包括所述解码装置U。
18.根据权利要求11-17任一项所述的方法，其特征在于，所述获取在所述目标时延T内连续丢包数B和突发丢包数N，包括：
获取在与编码装置进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；
根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N。
19.根据权利要求18所述的方法，其特征在于，所述根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N之后，所述方法还包括：
向所述编码装置发送所述连续丢包数B和所述突发丢包数N。
20.根据权利要求11-17任一项所述的方法，其特征在于，所述获取在所述目标时延T内连续丢包数B和突发丢包数N，包括：
向编码装置发送参考连续丢包数和参考突发丢包数，所述参考连续丢包数为所述解码装置U根据多个历史连续丢包数得到的，所述参考突发丢包数为所述解码装置U根据多个历史突发丢包数得到的；
接收所述编码装置发送的所述连续丢包数B和所述突发丢包数N，所述连续丢包数B为所述编码装置根据多个解码装置的参考连续丢包数得到，所述突发丢包数N分别为所述编码装置根据多个解码装置的参考突发丢包数得到的，所述多个解码装置包括所述解码装置U。
21.根据权利要求17-20任一项所述的方法，其特征在于，所述多个解码装置为：
多个获取所述码流所采用相同传输方式的解码装置，或者；
多个处理相同类型业务的解码装置，或者；
多个所需服务质量QoS等级相同或体验质量QoE相同的解码装置。
22.一种编码装置，其特征在于，包括：
获取单元，用于获取待编码数据，并获取目标时延T和获取在所述目标时延T内连续丢包数B和突发丢包数N；所述目标时延T为在数据传输过程中所需要的时延；
编码单元，用于根据所述目标时延T、所述连续丢包数B和所述突发丢包数N对所述待编码数据进行编码，以得到码流。
23.根据权利要求21所述的编码装置，其特征在于，所述编码单元具体用于：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，所述k为编码前的码字数，所述n为编码后的码字数；
根据所述k和n所述待编码数据进行编码，以得到所述码流。
24.根据权利要求23所述的编码装置，其特征在于，在所述根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n的方面，所述编码单元具体用于：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定信道编码效率R的取值范围；
根据所述信道编码效率R确定容量C，并根据所述容量C确定所述k和n。
25.根据权利要求22-24任一项所述的编码装置，其特征在于，在所述获取目标时延T的方面，所述获取单元具体用于：
获取所述待编码数据对应的业务类型，并根据所述待编码数据对应的业务类型确定所述目标延时T。
26.根据权利要求22-24任一项所述的编码装置，其特征在于，在所述获取在所述目标时延T内连续丢包数B和突发丢包数N的方面，所述获取单元具体用于：
获取在与解码装置U进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，并根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N，所述解码装置U为接收所述待编码数据的解码装置中的任一个；或者；
获取在与多个解码装置进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数，根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据多个历史突发丢包数确定所述突发丢包数N；所述多个解码装置均为接收待编码数据的解码装置。
27.根据权利要求22-24任一项所述的编码装置，其特征在于，在所述获取目标时延T的方面，所述获取单元具体用于：
接收多个解码装置发送的参考延时，解码装置U的参考延时为所述解码装置U所需要的延时；
根据所述多个解码装置发送的参考延时确定所述目标延时T；
其中，所述解码装置U为所述多个解码装置中的任一个。
28.根据权利要求27所述的编码装置，其特征在于，所述编码装置还包括：
发送单元，用于在所述获取单元获取目标时延T后，将所述目标延时T通过广播发送至所述多个解码装置，或者；将所述目标时延T通过单播发送至所述多个解码装置。
29.根据权利要求22-24任一项所述的编码装置，其特征在于，在所述获取在所述目标时延T内连续丢包数B和突发丢包数N的方面，所述获取单元具体用于：
获取多个解码装置发送的参考连续丢包数和参考突发丢包数；
根据所述多个解码装置发送的参考连续丢包数确定所述连续丢包数B，以及根据所述多个解码装置发送的参考突发丢包数确定所述突发丢包数N。
30.根据权利要求29所述的编码装置，其特征在于，所述编码装置还包括：
发送单元，用于在获取在所述目标时延T内连续丢包数B和突发丢包数N之后，将所述连续丢包数B和所述突发丢包数N通过广播发送至所述多个解码装置，或者；
用于将所述连续丢包数B和所述突发丢包数N通过单播发送至所述多个解码装置。
31.根据权利要求26-30任一项所述的编码装置，其特征在于，所述多个解码装置为：
多个接收所述待编码数据所采用相同传输方式的解码装置，或者；
多个处理相同类型业务的解码装置，或者；
多个所需服务质量QoS等级相同或体验质量QoE相同的解码装置。
32.一种解码装置，其特征在于，包括：
获取单元，用于获取码流，并获取目标时延T，及获取在所述目标时延T内的连续丢包数B和突发丢包数N；所述目标时延T为在数据传输过程中所需要的时延；
解码单元，用于根据所述目标时延T、所述连续丢包数B和突发丢包数N对所述码流进行解码，以得到解码后的数据。
33.根据权利要求32所述的解码装置，其特征在于，所述解码单元具体用于：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n，所述k为解码后的码字数，所述n为解码前的码字数；
根据所述k和n所述待解码数据进行解码，以得到所述解码后的数据。
34.根据权利要求33所述的解码装置，其特征在于，在所述根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定k和n的方面，所述解码单元具体用于：
根据所述目标时延T、所述连续丢包数B和所述突发丢包数N确定信道编码效率R的取值范围；
根据所述信道编码效率R确定为容量C，并根据所述容量C确定所述k和n。
35.根据权利要求32-34任一项所述的解码装置，其特征在于，在所述获取目标时延T的方面，所述获取单元具体用于：
将从编码装置接收到的时延确定为目标时延T。
36.根据权利要求32-34任一项所述的解码装置，其特征在于，在所述获取目标时延T的方面，所述获取单元具体用于：
将所述解码装置所需要的时延确定为目标时延T。
37.根据权利要求36所述的解码装置，其特征在于，所述解码装置还包括：
第一发送单元，用于在所述获取单元将所述解码装置所需要的时延确定为目标时延T之后，向编码装置发送所述目标时延T。
38.根据权利要求32-34任一项所述的解码装置，其特征在于，在所述获取目标时延T的方面，所述获取单元具体用于：
向编码装置发送参考时延，所述参考时延为所述解码装置所需要的时延；
接收所述编码装置发送的目标时延T，所述目标时延T为所述编码装置根据多个解码装置的参考时延得到的，所述多个解码装置包括所述解码装置。
39.根据权利要求32-38任一项所述的解码装置，其特征在于，在所述获取在所述目标时延T内连续丢包数B和突发丢包数N的方面，所述获取单元具体用于：
获取在与编码装置进行数据传输过程中使用的多个历史连续丢包数和多个历史突发丢包数；
根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N。
40.根据权利要求39所述的解码装置，其特征在于，所述解码装置还包括：
第二发送单元，用于在所述获取单元根据所述多个历史连续丢包数确定所述连续丢包数B，以及根据所述多个历史突发丢包数确定所述突发丢包数N之后，向所述编码装置发送所述连续丢包数B和所述突发丢包数N。
41.根据权利要求32-38任一项所述的解码装置，其特征在于，在所述获取在所述目标时延T内连续丢包数B和突发丢包数N的方面，所述获取单元具体用于：
向编码装置发送参考连续丢包数和参考突发丢包数，所述参考连续丢包数为所述解码装置根据多个历史连续丢包数得到，所述参考突发丢包数为所述解码装置根据多个历史突发丢包数得到的；
接收所述编码装置发送的所述连续丢包数B和所述突发丢包数N，所述连续丢包数B为所述编码装置根据多个解码装置的参考连续丢包数得到，所述突发丢包数N为所述编码装置根据多个解码装置的参考突发丢包数得到，所述多个解码装置包括所述解码装置。
42.根据权利要求39-41任一项所述的解码装置，其特征在于，所述多个解码装置为：
多个获取所述码流所采用相同传输方式的解码装置，或者；
多个处理相同类型业务的解码装置，或者；
多个所需服务质量QoS等级相同或体验质量QoE相同的解码装置。
43.一种编码装置，其特征在于，包括：
存储器；
与所述存储耦合的处理器，所述处理器执行存储器中存储的指令，以实现如权利要求1-10任一项所述的方法。
44.一种解码装置，其特征在于，包括：
存储器；
与所述存储耦合的处理器，所述处理器执行存储器中存储的指令，以实现如权利要求11-21任一项所述的方法。
45.一种数据编解码系统，所述数据编解码系统包括编码装置和多个解码装置，其特征在于，包括：
所述编码装置，用于执行如权利要求1-10任一项所述的方法；
所述多个解码装置中的任一个解码装置，用于执行如权利要求11-21任一项所述的方法。
CN202010107486.4A 2020-02-21 2020-02-21 数据编解码方法、相关设备及系统 Active CN113301387B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202010107486.4A CN113301387B (zh) 2020-02-21 2020-02-21 数据编解码方法、相关设备及系统
PCT/CN2020/137448 WO2021164405A1 (zh) 2020-02-21 2020-12-18 数据编解码方法、相关设备及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010107486.4A CN113301387B (zh) 2020-02-21 2020-02-21 数据编解码方法、相关设备及系统

Publications (2)

Publication Number Publication Date
CN113301387A true CN113301387A (zh) 2021-08-24
CN113301387B CN113301387B (zh) 2022-10-18

Family

ID=77317599

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010107486.4A Active CN113301387B (zh) 2020-02-21 2020-02-21 数据编解码方法、相关设备及系统

Country Status (2)

Country Link
CN (1) CN113301387B (zh)
WO (1) WO2021164405A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115189809B (zh) * 2022-07-07 2024-03-19 福州大学 基于qoe的异构网络实时视频传输arq与fec模式选择方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101394555A (zh) * 2008-10-24 2009-03-25 清华大学 适用于深空通信的高容错低延时的视频传输方法及装置
CN103684695A (zh) * 2013-12-24 2014-03-26 北京新讯世纪信息技术有限公司 一种数据传输方法和系统
WO2015113298A1 (zh) * 2014-01-29 2015-08-06 华为技术有限公司 资源的配置方法和装置
WO2016045332A1 (zh) * 2014-09-24 2016-03-31 中兴通讯股份有限公司 编码参数的调整、反馈信息的处理方法及装置
WO2017045528A1 (zh) * 2015-09-18 2017-03-23 中兴通讯股份有限公司 组播传输方法、装置及系统
CN108322286A (zh) * 2017-01-17 2018-07-24 华为技术有限公司 一种获得前向纠错fec参数的方法、装置
CN109474941A (zh) * 2017-09-08 2019-03-15 展讯通信（上海）有限公司 配置及获取中断时延的方法、基站、用户设备及可读介质
CN109687942A (zh) * 2017-10-18 2019-04-26 珠海市魅族科技有限公司 用于基站或者终端的无线网络配置反馈时延的方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8230316B2 (en) * 2008-01-25 2012-07-24 Nevion Usa, Inc. Forward error correction for burst and random packet loss for real-time multi-media communication
CN109981225B (zh) * 2019-04-12 2022-02-11 广州视源电子科技股份有限公司 一种码率预估方法、装置、设备及存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101394555A (zh) * 2008-10-24 2009-03-25 清华大学 适用于深空通信的高容错低延时的视频传输方法及装置
CN103684695A (zh) * 2013-12-24 2014-03-26 北京新讯世纪信息技术有限公司 一种数据传输方法和系统
WO2015113298A1 (zh) * 2014-01-29 2015-08-06 华为技术有限公司 资源的配置方法和装置
WO2016045332A1 (zh) * 2014-09-24 2016-03-31 中兴通讯股份有限公司 编码参数的调整、反馈信息的处理方法及装置
WO2017045528A1 (zh) * 2015-09-18 2017-03-23 中兴通讯股份有限公司 组播传输方法、装置及系统
CN108322286A (zh) * 2017-01-17 2018-07-24 华为技术有限公司 一种获得前向纠错fec参数的方法、装置
CN109474941A (zh) * 2017-09-08 2019-03-15 展讯通信（上海）有限公司 配置及获取中断时延的方法、基站、用户设备及可读介质
CN109687942A (zh) * 2017-10-18 2019-04-26 珠海市魅族科技有限公司 用于基站或者终端的无线网络配置反馈时延的方法及装置

Also Published As

Publication number Publication date
WO2021164405A1 (zh) 2021-08-26
CN113301387B (zh) 2022-10-18

Similar Documents

Publication Publication Date Title
KR100680671B1 (ko) 에러 정정용 데이터의 생성 방법 및 생성 장치와 생성 프로그램을 저장한 컴퓨터 판독가능한 기록 매체
CN101272495B (zh) 用于传输基于分组的图像帧的方法和装置
CN101061659B (zh) 自适应前向纠错的方法和设备
US9661053B2 (en) Generating a plurality of streams
US20220021612A1 (en) Data stream transmission method and device
US20130219240A1 (en) Data packet transmission/reception apparatus and method
US20060253763A1 (en) Method and system for correcting burst errors in communications networks, related network and computer-program product
US10084715B2 (en) Packet loss mitigation
CN108174234A (zh) 一种流媒体传输方法及系统
US8774220B2 (en) Method of packetizing encoded symbols and apparatus using the same
CN113055285A (zh) 基于mptcp与网络编码的自适应数据传输方法
KR20130086552A (ko) 점진 열화 순방향 오류 정정 방법 및 이를 수행하는 장치
KR102290779B1 (ko) 멀티미디어 데이터를 송수신하는 방법 및 장치
CN113301387B (zh) 数据编解码方法、相关设备及系统
US10833710B2 (en) Bandwidth efficient FEC scheme supporting uneven levels of protection
US20210050867A1 (en) Transmitting apparatus and method for controlling the transmitting apparatus
US20180192088A1 (en) Transmitting/receiving audio and/or video data over a wireless network
RU2711354C1 (ru) Способ передачи данных по асинхронным сетям связи с возможностью восстановления данных при их потере из-за наличия ошибок соединения в сетях связи
EP3300306B1 (en) Video delivery performance analysis for embms
US8707141B1 (en) Joint optimization of packetization and error correction for video communication
JP4878974B2 (ja) 送信装置及び通信システム
CN113489645B (zh) 一种基于卫星通信的数据链路聚合方法和路由器、服务器
Osunkunle Quality of Experience Enhancement Architecture For Video Delivery On WiFi.
CN117319684A (zh) 一种数据传输方法、发送装置、接收装置和系统
KR101999105B1 (ko) 실시간 비디오 스트리밍에서 비디오 지연시간을 최소로 하면서 안정적으로 비디오 데이터를 송수신하는 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant