CN114124910A - 直播数据传输方法、系统及可读存储介质 - Google Patents

直播数据传输方法、系统及可读存储介质 Download PDF

Info

Publication number
CN114124910A
CN114124910A CN202111301499.6A CN202111301499A CN114124910A CN 114124910 A CN114124910 A CN 114124910A CN 202111301499 A CN202111301499 A CN 202111301499A CN 114124910 A CN114124910 A CN 114124910A
Authority
CN
China
Prior art keywords
data
data packets
packet
basic
live broadcast
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
CN202111301499.6A
Other languages
English (en)
Other versions
CN114124910B (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.)
Hubei Meihe Yisi Education Technology Co ltd
Original Assignee
Hubei Meihe Yisi Education Technology 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 Hubei Meihe Yisi Education Technology Co ltd filed Critical Hubei Meihe Yisi Education Technology Co ltd
Priority to CN202111301499.6A priority Critical patent/CN114124910B/zh
Publication of CN114124910A publication Critical patent/CN114124910A/zh
Application granted granted Critical
Publication of CN114124910B publication Critical patent/CN114124910B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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 or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本发明公开了一种直播数据传输方法、系统及可读存储介质，该方法包括：当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据。本发明通过冗余数据包对基础数据包的恢复机制，实现丢失数据包的找回，使数据发送端传输的数据与数据接收端接收的数据相同，实现直播数据的有效传输，确保了直播图像的高质量播放。

Description

直播数据传输方法、系统及可读存储介质
技术领域
本发明涉及互联网技术领域，尤其涉及一种直播数据传输方法、系统及可读存储介质。
背景技术
随着互联网技术的发展和人民生活水平的提高，互联网直播层出不穷，受到越来越多人的喜爱追捧。当前，直播主要包括将直播内容传输到手机、平板电脑等移动设备播放的普通直播，还包括将直播内容投射到电视机或屏幕播放的投屏直播。
但无论是普通直播还是投屏直播，均可能在直播过程中产生直播数据包丢包问题。其情形主要有：(1)当路由器和网关发生拥塞时，由于网络中传输的数据包大于网络信道的承载能力，导致某些数据包可能被丢弃；(2)对于分组数据在传送时为避免路由中死循环而设置的生存时间限制，在网络状况恶劣时，分组数据可能超时丢失；(3)接收端工作超载运行时可能因调度困难而不能及时处理网口数据而丢包。
当前为了解决直播过程中的丢包问题，通常采用较小的GOP(即较小的I帧间隔)，以期在出现丢包花屏后能尽快的用I帧码流刷新画面。但因I帧压缩效率远不如P帧、B帧，I帧往往比P帧、B帧大很多，频繁的I帧将给传输信道带来持续的波动压力，造成更严重的直播数据丢包和乱序。同时，因I帧占用的码流较多，使P帧、B帧不得不采用较大的QP量化参数以保证码率的局部可控，但较大的QP量化参数会使得图像质量较差，从而使直播图像随着I帧间隔周期性的发虚、马赛克。因此，如何有效解决直播过程中的丢包问题，实现直播数据的有效传输是当前亟待解决的技术问题。
发明内容
本发明的主要目的在于提供一种直播数据传输方法、系统及可读存储介质，旨在有效解决直播过程中的丢包问题，实现直播数据的有效传输。
为实现上述目的，本发明提供一种直播数据传输方法，应用于数据接收端，所述直播数据传输方法包括：
当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据。
可选地，所述若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
若处于丢包状态，则根据所述直播数据包中携带的数量标识和所述基础数据包的数量，确定丢包数量，并根据所述丢包数量，判断丢失的数据包是否支持成功恢复；
若支持成功恢复，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
若不支持成功恢复，则向所述数据发送端反馈重新发送请求，以供所述数据发送端基于所述重新发送请求，再次发送所述直播数据包。
可选地，所述基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
根据多个所述基础数据包与多个所述冗余数据包之间的编码对应关系，确定多个所述基础数据包中与丢失的数据包所对应的目标基础数据包，以及多个所述冗余数据包中与丢失的数据包所对应的目标冗余数据包；
获取与所述冗余数据包对应的解码算法，并基于所述解码算法，对所述目标基础数据包和所述目标冗余数据包进行解码运算，获得丢失的数据包。
可选地，所述对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据的步骤包括：
识别恢复的数据包携带的第一顺序标识，以及多个所述基础数据包分别携带的第二顺序标识；
根据所述第一顺序标识和所述第二顺序标识，对恢复的数据包和多个所述基础数据包进行排序，获得数据包序列；
对所述数据包序列依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
可选地，所述判断多个所述基础数据包是否处于丢包状态的步骤之后包括：
若不处于丢包状态，则获取多个所述基础数据包分别携带的第三顺序标识，并根据所述第三顺序标识，对多个所述基础数据包进行排序；
对排序后的多个所述基础数据包依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
可选地，所述判断多个所述基础数据包是否处于丢包状态的步骤包括：
获取所述直播数据包中携带的数量标识，并根据所述数量标识和所述基础数据包的数量，判断多个所述基础数据包是否处于丢包状态；
或者，读取多个所述基础数据包携带的编码标识，并根据各所述编码标识判断多个所述基础数据包是否处于丢包状态。
进一步地，为实现上述目的，本发明还提供一种直播数据传输方法，应用于数据发送端，所述直播数据传输方法包括：
当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
进一步地，为实现上述目的，本发明还提供一种直播数据传输系统，所述直播数据传输系统包括数据接收端和数据发送端；其中，
所述数据接收端包括：
拆分模块，用于当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断模块，用于判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
解码模块，用于对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据；
所述数据发送端包括：
第一编码模块，用于当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
第二编码模块，用于基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
传输模块，用于将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
进一步地，为实现上述目的，本发明还提供一种直播数据传输系统，所述直播数据传输系统包括送直播数据的数据发送端，以及接收直播数据的数据接收端，还包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的控制程序，所述控制程序被所述处理器执行时实现如上所述的直播数据传输方法的步骤。
进一步地，为实现上述目的，本发明还提供一种可读存储介质，所述可读存储介质上存储有控制程序，所述控制程序被处理器执行时实现如上所述的直播数据传输方法的步骤。
本发明的直播数据传输方法、系统及可读存储介质，应用于数据接收端，当接收到与该数据接收端通信连接的数据发送端传输的直播数据包时，先从直播数据包中拆分出多个基础数据包和多个冗余数据包；再判断多个基础数据包是否处于丢包状态，若处于丢包装置，则通过多个基础数据包和多个冗余数据包之间的运算，对多个基础数据包中丢失的数据包进行恢复；进而对恢复的数据包和多个基础数据包一并进行解码操作，获得数据发送端发送的初始直播数据。如此一来，通过冗余数据包对基础数据包的恢复机制，实现丢失数据包的找回，使数据发送端传输的数据与数据接收端接收的数据相同，实现直播数据的有效传输，同时，避免了更为严重的丢包，并确保了直播图像的高质量播放。
附图说明
图1为本发明直播数据传输系统实施例方案涉及的硬件运行环境的结构示意图；
图2为本发明直播数据传输方法第一实施例的流程示意图；
图3为本发明直播数据传输方法另一实施例的流程示意图；
图4为本发明直播数据传输系统一实施例的功能模块示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
本发明提供一种直播数据传输系统。
请参照图1，图1为本发明直播数据传输系统实施例方案涉及的硬件运行环境的结构示意图。
如图1所示，该直播数据传输系统可以包括处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储设备。
本领域技术人员可以理解，图1中示出的直播数据传输系统硬件结构并不构成对直播数据传输系统的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图1所示，作为一种可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及控制程序。其中，操作系统是管理和控制直播数据传输系统与软件资源的程序，支持网络通信模块、用户接口模块、控制程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1004；用户接口模块用于管理和控制用户接口1003。
在图1所示的直播数据传输系统硬件结构中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；处理器1001可以调用存储器1005中存储的控制程序，并执行以下操作：
当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据。
进一步地，所述若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
若处于丢包状态，则根据所述直播数据包中携带的数量标识和所述基础数据包的数量，确定丢包数量，并根据所述丢包数量，判断丢失的数据包是否支持成功恢复；
若支持成功恢复，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
若不支持成功恢复，则向所述数据发送端反馈重新发送请求，以供所述数据发送端基于所述重新发送请求，再次发送所述直播数据包。
进一步地，所述基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
根据多个所述基础数据包与多个所述冗余数据包之间的编码对应关系，确定多个所述基础数据包中与丢失的数据包所对应的目标基础数据包，以及多个所述冗余数据包中与丢失的数据包所对应的目标冗余数据包；
获取与所述冗余数据包对应的解码算法，并基于所述解码算法，对所述目标基础数据包和所述目标冗余数据包进行解码运算，获得丢失的数据包。
进一步地，所述对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据的步骤包括：
识别恢复的数据包携带的第一顺序标识，以及多个所述基础数据包分别携带的第二顺序标识；
根据所述第一顺序标识和所述第二顺序标识，对恢复的数据包和多个所述基础数据包进行排序，获得数据包序列；
对所述数据包序列依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，所述判断多个所述基础数据包是否处于丢包状态的步骤之后，处理器1001可以调用存储器1005中存储的控制程序，并执行以下操作：
若不处于丢包状态，则获取多个所述基础数据包分别携带的第三顺序标识，并根据所述第三顺序标识，对多个所述基础数据包进行排序；
对排序后的多个所述基础数据包依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，所述判断多个所述基础数据包是否处于丢包状态的步骤包括：
获取所述直播数据包中携带的数量标识，并根据所述数量标识和所述基础数据包的数量，判断多个所述基础数据包是否处于丢包状态；
或者，读取多个所述基础数据包携带的编码标识，并根据各所述编码标识判断多个所述基础数据包是否处于丢包状态。
进一步地，处理器1001可以调用存储器1005中存储的控制程序，并执行以下操作：
当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
本发明直播数据传输系统的实施方式与下述直播数据传输方法各实施例基本相同，在此不再赘述。
本发明提供一种直播数据传输方法，参照图2，图2为本发明直播数据传输方法第一实施例的流程示意图。
本发明实施例提供了直播数据传输方法的实施例，需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。具体地，本实施例直播数据传输方法应用于服务器，包括：
步骤S10，当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
本实施例直播数据传输方法应用于数据接收端，主播直播过程中使用的直播终端设备为数据发送端，接入到主播直播间，对主播直播进行收看的用户终端设备则构成该数据接收端。数据发送端与数据接收端为一对多的关系，且两者之间优选以UDP(UserDatagram Protocol，用户数据报协议)网络协议实现直播数据的传输，其相对于TCIP/IP网络的传输速度更快。
进一步地，数据发送端将主播使用其进行直播采集到的数据编码生成为直播数据包，通过UDP网络传输到数据接收端。数据接收端对该直播数据包进行接收，并从其中拆分出多个基础数据包和多个冗余数据包。多个冗余数据包依据多个基础数据生成，如通过不同基础数据包之间的异或运算生成，且冗余数据包的数量至少为基础数据包的一半，如直播数据经编码生成了8个基础数据包，则可对8个基础数据包两两异或运算，生成4个冗余数据包，如此，便于在某一基础数据包丢失时，通过冗余数据包和运算的另一基础数据包对丢失的基础数据包进行恢复。
步骤S20，判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
更进一步地，数据接收端对拆分出的多个基础数据包进行检测，确定传输过程中是否丢失了数据包，由检测结果判断多个基础数据包整体上是否处于丢包状态。若经检测确定传输过程中丢失了数据包，则判定基础数据包整体处于丢包状态；反之若检测确定传输过程中未丢失数据包，则判定基础数据包整体非处于丢包状态。并且，检测可以依据所传输基础数据包的数量实现，也可以依据所传输数据包携带的编码实现。具体地，所述判断多个所述基础数据包是否处于丢包状态的步骤包括：
步骤S21，获取所述直播数据包中携带的数量标识，并根据所述数量标识和所述基础数据包的数量，判断多个所述基础数据包是否处于丢包状态；
或者，步骤S22，读取多个所述基础数据包携带的编码标识，并根据各所述编码标识判断多个所述基础数据包是否处于丢包状态。
进一步地，数据发送端在编码得到多个基础数据包的同时，将基础数据包的数量生成为数据标识添加到直播数据包中一并发送到数据接收端。故数据接收端在判断多个基础数据包整体上是否处于丢包状态时，先从直播数据包中读取出数量标识，由数量标识确定数据发送端所发送基础数据包的发送数量。同时，统计拆分得到的基础数据包的数量，进而将发送数量和统计的数量进行比对，若两者相等则说明传输过程中未丢失基础数据包，多个基础数据包整体上处于未丢包状态。若发送的数量大于统计的数量，则说明传输的过程中丢失了基础数据包，多个基础数据包整体上处于丢包状态。
此外，本实施例还可通过对基础数据包的编码实现丢包状态的判断。具体地，数据发送端在编码得到多个基础数据包的同时，还对各个基础数据包以一定规则进行编码，如以等差数列的规则进行编码，第一个基础数据包编码为1，第二个基础数据包编码为2等，并且将编码作为编码标识添加到基础数据包中，与基础数据包一并传输到数据接收端。数据接收端在判断多个基础数据包整体上是否处于丢包状态时，先读取各个基础数据包携带的编码标识，进而依据编码标识的连续性判断传输过程中是否丢失基础数据包。并且，对于第一个编码标识和最后一个编码标识，还添加有开始标识和结束标识，若经判断开始标识和结束标识之间的编码标识为连续标识，则说明传输过程中未丢失基础数据包，多个基础数据包整体上处于未丢包状态。若开始标识和结束标识之间的编码标识非连续标识，则说明传输的过程中丢失了基础数据包，多个基础数据包整体上处于丢包状态。
进一步地，若经判定多个基础数据包整体上处于丢包状态，则依据生成冗余数据包时，多个基础数据包之间的运算规则，对多个基础数据包和多个冗余数据包进行该运算规则的逆运算，通过逆运算对丢失的数据包进行恢复。
步骤S30，对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据。
更进一步地，在恢复丢失的数据包之后，数据接收端则对拆分的多个基础数据包和恢复的数据包一并进行解码操作，获得数据发送端传输的初始直播数据，实现直播音视频的流畅高质量播放。
可理解地，多个基础数据包在网络传输过程中可能存在乱序的现象，即数据发送端发送各个基础数据包的顺序，与数据接收端接收各个基础数据包的顺序不一致。故为了解码得到初始直播数据的准确性，需先确定各个基础数据包和所恢复数据包的排列顺序后再进行解码操作。具体地，所述对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据的步骤包括：
步骤S31，识别恢复的数据包携带的第一顺序标识，以及多个所述基础数据包分别携带的第二顺序标识；
步骤S32，根据所述第一顺序标识和所述第二顺序标识，对恢复的数据包和多个所述基础数据包进行排序，获得数据包序列；
步骤S33，对所述数据包序列依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，将恢复的数据包携带的表征其在数据发送端所传输直播数据中排列顺序的标识作为第一顺序标识，以及将各个基础数据包携带的表征各自在数据发送端所传输直播数据中排列顺序的标识作为第二顺序标识。数据接收端对该第一顺序标识和第二顺序标识进行识别，并根据识别的第一顺序标识和第二顺序标识，对恢复的数据包和多个基础数据包进行排序，得到数据包序列。该数据包序列中的各个数据包为数据发送端对直播数据编码依次生成的数据包，进而对数据包序列进行FEC解码，FEC解码为FEC编码的逆操作，通过FEC解码确保了数据包序列中包含的数据包均为数据发送端编码生成的基础数据包，不掺杂有由基础数据包生成的冗余数据包。此后，对经FEC解码后数据包序列中的数据包进行音视频解码，得到数据发送端传输的初始直播数据，即直播过程中的音视频数据进行播放，实现数据接收端用户对直播的流畅和高质量观看。
需要说明的是，若经判断基础数据库包整体上处于非丢包状态，数据发送端编码的基础数据包均完整的传输到数据接收端，则数据包接收端不需要进行数据包的恢复操作，可直接解码得到初始直播数据。具体地，所述判断多个所述基础数据包是否处于丢包状态的步骤之后包括：
步骤a1，若不处于丢包状态，则获取多个所述基础数据包分别携带的第三顺序标识，并根据所述第三顺序标识，对多个所述基础数据包进行排序；
步骤a2，对排序后的多个所述基础数据包依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，若经判定多个数据包整体上不处于丢包状态，则将多个基础数据包携带表征各自在数据发送端所传输直播数据中排列顺序的标识读取为第三顺序标识，并依据各个第三顺序标识，对各个基础数据包进行排序，进而对排序后的各个基础数据包先进行FEC解码再进行音视频解码，获得数据发送端传输的初始直播数据进行播放，实现数据接收端用户对直播的流畅和高质量观看。
本发明的直播数据传输方法，应用于数据接收端，当接收到与该数据接收端通信连接的数据发送端传输的直播数据包时，先从直播数据包中拆分出多个基础数据包和多个冗余数据包；再判断多个基础数据包是否处于丢包状态，若处于丢包装置，则通过多个基础数据包和多个冗余数据包之间的运算，对多个基础数据包中丢失的数据包进行恢复；进而对恢复的数据包和多个基础数据包一并进行解码操作，获得数据发送端发送的初始直播数据。如此一来，通过冗余数据包对基础数据包的恢复机制，实现丢失数据包的找回，使数据发送端传输的数据与数据接收端接收的数据相同，实现直播数据的有效传输，同时，避免了更为严重的丢包，并确保了直播图像的高质量播放。
进一步地，基于本发明直播数据传输方法的第一实施例，提出本发明直播数据传输方法第二实施例。
所述直播数据传输方法第二实施例与所述直播数据传输方法第一实施例的区别在于，所若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
步骤S23，若处于丢包状态，则根据所述直播数据包中携带的数量标识和所述基础数据包的数量，确定丢包数量，并根据所述丢包数量，判断丢失的数据包是否支持成功恢复；
步骤S24，若支持成功恢复，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
步骤S25，若不支持成功恢复，则向所述数据发送端反馈重新发送请求，以供所述数据发送端基于所述重新发送请求，再次发送所述直播数据包。
进一步地，冗余数据包依据基础数据包运算生成，在某些基础数据包丢失时，可依据冗余数据包和未丢失基础数据包之间的逆运算，对丢失的基础数据包进行恢复。但若丢失的基础数据过多，剩余的未丢失基础数据包过少，则难以依据该剩余未丢失的基础数据包和冗余数据包，对丢失的数据包进行恢复。故，本实施例对丢失的数据包是否支持恢复进行限定。
具体地，预先设定表征支持丢失数据包恢复的预设丢包数量，如对于8个基础数据包，4各冗余数据包，则可设定预设丢包数量为4，即最多丢失4个数据包，可对丢失的数据包进行恢复，若丢失数据包的数量超过4个，则不可对丢失的数据包进行恢复。
进一步地，若经判定多个基础数据包整体上处于丢包状态，则读取直播数据包中携带的数量标识，由该数量标识确定经数据发送端编码并发送的基础数据包的总数量。进而统计当前具有的基础数据包数量，并由数量标识表征的总数量和统计的基础数据包的数量，计算丢包数量。
更进一步地，将丢包数量和预设丢包数量对比，判断丢包数量是否少于或等于预设丢包数量，若少于或等于预设丢包数量，则说明对丢失数据支持成功恢复；反之，若丢包数量大于预设丢包数量，则说明对丢失数据包不支持成功恢复。
进一步地，对于支持成功恢复的情形，则依据多个基础数据包和剩余未丢失的多个冗余数据包，对多个基础数据包中丢失的数据包进行恢复。而对于不支持成功恢复的情形，则向数据发送端反馈重新发送请求。数据发送端在接收到重新发送请求后，再次将由基础数据包及其对应的冗余数据包生成的直播数据包发送到数据接收端，以便数据接收端从其中拆分出基础数据包和冗余数据包进行丢包判断。
其中，所述基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
步骤S26，根据多个所述基础数据包与多个所述冗余数据包之间的编码对应关系，确定多个所述基础数据包中与丢失的数据包所对应的目标基础数据包，以及多个所述冗余数据包中与丢失的数据包所对应的目标冗余数据包；
步骤S27，获取与所述冗余数据包对应的解码算法，并基于所述解码算法，对所述目标基础数据包和所述目标冗余数据包进行解码运算，获得丢失的数据包。
可理解地，不同的冗余数据包由不同的基础数据包编码生成，故对于不同基础数据包的丢失，也需依据不同的冗余数据包进行恢复。具体地，数据发送端中针对每一冗余数据包，将用于生成该冗余数据包的基础数据包，以及该冗余数据包本身，形成为编码对应关系。例如，初始直播数据经编码得到8个基础数据包(P1，P2，…P8)，并分别生成4个冗余数据包(FEC1，…FEC4)，其中，FEC1＝P1^P5，FEC2＝P2^P6，FEC3＝P3^P7，FEC4＝P4^P8，则该4个冗余数据包与各自基础数据包的运算关系即为各自的编码对应关系。
进一步地，数据接收端对该编码对应关系进行获取，并查找所丢失数据包所在的编码对应关系，作为目标编码对应关系。进而将目标编码对应关系中的冗余数据包作为多个冗余数据包中与丢失数据包对应的目标冗余数据包，以及将目标编码对应关系中未丢失的基础数据包作为多个基础数据包中与丢失数据包对应的目标基础数据包。例如，若查找的目标编码对应关系为FEC2＝P2^P6，丢失的数据包为P2，则目标冗余数据包为FEC2，目标基础数据包为P6。
更进一步地，根据生成冗余数据包的编码算法，获取与该编码算法对应的解码算法作为与冗余数据包对应的解码算法。并且，对目标基础数据包和目标冗余数据包以解码算法进行解码运算，获得丢失的数据包。如对于上述FEC2和P6，则以异或运算的逆运算进行运算，获得的运算结果即为丢失的数据包P2。
本实施例通过限定丢失数据包支持恢复的丢失数量，在丢失数据包数量过多的情况下，直接请求数据发送端再次发送数据，避免过长时间的恢复。并且，对于需要恢复的数据包，通过其生成的冗余数据包进行逆运算即可恢复，有利于丢失数据包的快速恢复。
进一步地，请参照图3，图3为本发明直播数据传输方法的另一实施例的流程示意图。该直播数据传输方法另一实施例应用于与数据发送端，包括：
步骤S40，当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
步骤S50，基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
步骤S60，将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
本实施例的直播数据传输方法应用于主播进行直播的数据发送端，适用于数据发送端将初始直播数据生成为包含基础数据包和冗余数据包的直播数据包传输到数据接收端。具体地，先基于数据发送端上的摄像装置采集主播直播过程中的初始直播数据，再通过数据发送端内的音视频编码器将采集的初始直播数据进行编码，获得多个基础数据包。其中，音视频编码器可以是硬件装置，也可以是软件模块，对此不作限制。
进一步地，通过数据发送端内的FEC编码器，对多个基础数据包进行再次编码，得到与多个基础数据包对应的冗余数据包。并且，再次编码的编码规则可依据需求设定，可以是上述实施例中的异或规则，也可以是其他规则。
更进一步地，将多个基础数据包和再次编码得到的冗余数据包共同生成为直播数据包，如上述实施例中8个基础数据包(P1，P2，…P8)和4个冗余数据包(FEC1，…FEC4)则共同形成为直播数据包。此后，将直播数据包通过UDP网络及其对应的UDP传输协议传输到进入主播直播间，与数据发送端通信连接以对直播进行观看的数据接收端。数据接收端从直播数据包中拆分出基础数据包和冗余数据包，并判断基础数据包传输过程中是否丢包；若丢包则依据拆分的基础数据包和冗余数据包，对丢失的数据包进行恢复，并对恢复后的数据包和基础数据包进行解码，获得初始直播数据供数据接收端用户观看。
本实施例通过数据发送端对直播过程中采集的初始直播数据进行处理，得到包含基础数据包和冗余数据包的直播数据包传输到用于观看直播的数据接收端，一旦数据接收端接收的基础数据包存在丢包情形，通过接收的基础数据包和冗余数据包即可对丢失的数据包进行恢复，确保数据接收端所接收直播数据的完整性，有利于数据接收端用户对直播的流畅和高质量观看。
请参照图4，本发明实施例还提出一种直播数据传输系统。在本发明直播数据传输系统一实施例中，所述直播数据传输系统包括数据接收端10和数据发送端20；其中，
所述数据接收端10包括：
拆分模块11，用于当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断模块12，用于判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
解码模块13，用于对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据；
所述数据发送端20包括：
第一编码模块21，用于当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
第二编码模块22，用于基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
传输模块23，用于将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
进一步地，所述判断模块还包括：
判断单元，用于若处于丢包状态，则根据所述直播数据包中携带的数量标识和所述基础数据包的数量，确定丢包数量，并根据所述丢包数量，判断丢失的数据包是否支持成功恢复；
恢复单元，用于若支持成功恢复，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
反馈单元，用于若不支持成功恢复，则向所述数据发送端反馈重新发送请求，以供所述数据发送端基于所述重新发送请求，再次发送所述直播数据包。
进一步地，所述判断模块还包括：
确定单元，用于根据多个所述基础数据包与多个所述冗余数据包之间的编码对应关系，确定多个所述基础数据包中与丢失的数据包所对应的目标基础数据包，以及多个所述冗余数据包中与丢失的数据包所对应的目标冗余数据包；
获取单元，用于获取与所述冗余数据包对应的解码算法，并基于所述解码算法，对所述目标基础数据包和所述目标冗余数据包进行解码运算，获得丢失的数据包。
进一步地，所述解码模块还包括：
识别单元，用于识别恢复的数据包携带的第一顺序标识，以及多个所述基础数据包分别携带的第二顺序标识；
排序单元，用于根据所述第一顺序标识和所述第二顺序标识，对恢复的数据包和多个所述基础数据包进行排序，获得数据包序列；
解码单元，用于对所述数据包序列依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，所述判断模块还包括：
排序单元，用于若不处于丢包状态，则获取多个所述基础数据包分别携带的第三顺序标识，并根据所述第三顺序标识，对多个所述基础数据包进行排序；
生成单元，用于对排序后的多个所述基础数据包依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
进一步地，所述判断模块还用于：
统计单元，用于获取所述直播数据包中携带的数量标识，并根据所述数量标识和所述基础数据包的数量，判断多个所述基础数据包是否处于丢包状态；
或者，读取多个所述基础数据包携带的编码标识，并根据各所述编码标识判断多个所述基础数据包是否处于丢包状态。
本发明直播数据传输系统的具体实施方式与上述直播数据传输方法各实施例基本相同，在此不再赘述。
本发明实施例还提出一种可读存储介质。所述可读存储介质上存储有控制程序，所述控制程序被所述处理器执行时实现如上所述直播数据传输方法的步骤。
本发明可读存储介质可以为计算机可读存储介质，其具体实施方式与上述直播数据传输方法各实施例基本相同，在此不再赘述。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，这些均属于本发明的保护之内。

Claims (10)

1.一种直播数据传输方法，其特征在于，应用于数据接收端，所述直播数据传输方法包括：
当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据。
2.根据权利要求1所述的直播数据传输方法，其特征在于，所述若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
若处于丢包状态，则根据所述直播数据包中携带的数量标识和所述基础数据包的数量，确定丢包数量，并根据所述丢包数量，判断丢失的数据包是否支持成功恢复；
若支持成功恢复，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
若不支持成功恢复，则向所述数据发送端反馈重新发送请求，以供所述数据发送端基于所述重新发送请求，再次发送所述直播数据包。
3.根据权利要求1所述的直播数据传输方法，其特征在于，所述基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复的步骤包括：
根据多个所述基础数据包与多个所述冗余数据包之间的编码对应关系，确定多个所述基础数据包中与丢失的数据包所对应的目标基础数据包，以及多个所述冗余数据包中与丢失的数据包所对应的目标冗余数据包；
获取与所述冗余数据包对应的解码算法，并基于所述解码算法，对所述目标基础数据包和所述目标冗余数据包进行解码运算，获得丢失的数据包。
4.根据权利要求1所述的直播数据传输方法，其特征在于，所述对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据的步骤包括：
识别恢复的数据包携带的第一顺序标识，以及多个所述基础数据包分别携带的第二顺序标识；
根据所述第一顺序标识和所述第二顺序标识，对恢复的数据包和多个所述基础数据包进行排序，获得数据包序列；
对所述数据包序列依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
5.根据权利要求1-4任一项所述的直播数据传输方法，其特征在于，所述判断多个所述基础数据包是否处于丢包状态的步骤之后包括：
若不处于丢包状态，则获取多个所述基础数据包分别携带的第三顺序标识，并根据所述第三顺序标识，对多个所述基础数据包进行排序；
对排序后的多个所述基础数据包依次进行FEC解码和音视频解码，生成所述数据发送端传输的初始直播数据。
6.根据权利要求1-4任一项所述的直播数据传输方法，其特征在于，所述判断多个所述基础数据包是否处于丢包状态的步骤包括：
获取所述直播数据包中携带的数量标识，并根据所述数量标识和所述基础数据包的数量，判断多个所述基础数据包是否处于丢包状态；
或者，读取多个所述基础数据包携带的编码标识，并根据各所述编码标识判断多个所述基础数据包是否处于丢包状态。
7.一种直播数据传输方法，其特征在于，应用于数据发送端，所述直播数据传输方法包括：
当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
8.一种直播数据传输系统，其特征在于，所述直播数据传输系统包括数据接收端和数据发送端；其中，
所述数据接收端包括：
拆分模块，用于当接收到与所述数据接收端通信连接的数据发送端传输的直播数据包时，将所述直播数据包拆分为多个基础数据包和多个冗余数据包；
判断模块，用于判断多个所述基础数据包是否处于丢包状态，若处于丢包状态，则基于多个所述基础数据包和多个所述冗余数据包，对多个所述基础数据包中丢失的数据包进行恢复；
解码模块，用于对恢复的数据包和多个所述基础数据包进行解码，生成所述数据发送端传输的初始直播数据；
所述数据发送端包括：
第一编码模块，用于当采集到初始直播数据时，基于音视频编码器将所述初始直播数据编码为多个基础数据包；
第二编码模块，用于基于FEC编码器对多个所述基础数据包进行再次编码，生成与多个所述基础数据包对应的冗余数据包；
传输模块，用于将多个所述基础数据包和所述冗余数据包生成为直播数据包，并将所述直播数据包基于UDP传输协议传输到与所述数据发送端通信连接的数据接收端，以供所述数据接收端基于所述基础数据包和所述冗余数据包，获得所述初始直播数据。
9.一种直播数据传输系统，其特征在于，所述直播数据传输系统包括送直播数据的数据发送端，以及接收直播数据的数据接收端，还包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的控制程序，所述控制程序被所述处理器执行时实现如权利要求1-7中任一项所述的直播数据传输方法的步骤。
10.一种可读存储介质，其特征在于，所述可读存储介质上存储有控制程序，所述控制程序被处理器执行时实现如权利要求1-7中任一项所述的直播数据传输方法的步骤。
CN202111301499.6A 2021-11-04 2021-11-04 直播数据传输方法、系统及可读存储介质 Active CN114124910B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111301499.6A CN114124910B (zh) 2021-11-04 2021-11-04 直播数据传输方法、系统及可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111301499.6A CN114124910B (zh) 2021-11-04 2021-11-04 直播数据传输方法、系统及可读存储介质

Publications (2)

Publication Number Publication Date
CN114124910A true CN114124910A (zh) 2022-03-01
CN114124910B CN114124910B (zh) 2024-08-09

Family

ID=80380579

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111301499.6A Active CN114124910B (zh) 2021-11-04 2021-11-04 直播数据传输方法、系统及可读存储介质

Country Status (1)

Country Link
CN (1) CN114124910B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017157303A1 (zh) * 2016-03-15 2017-09-21 中兴通讯股份有限公司 实时通信中的抗丢包方法、装置和系统
CN107276722A (zh) * 2017-06-21 2017-10-20 北京奇艺世纪科技有限公司 一种基于udp的数据传输方法和系统
WO2018058803A1 (zh) * 2016-09-30 2018-04-05 瞬已网络科技（上海）有限公司 一种网络实时视频传输方法及装置
CN111464262A (zh) * 2020-03-18 2020-07-28 腾讯科技（深圳）有限公司 数据处理方法、装置、介质及电子设备
CN111787413A (zh) * 2020-07-09 2020-10-16 郑州信大捷安信息技术股份有限公司 流媒体数据传输方法、系统、发送装置及接收装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017157303A1 (zh) * 2016-03-15 2017-09-21 中兴通讯股份有限公司 实时通信中的抗丢包方法、装置和系统
WO2018058803A1 (zh) * 2016-09-30 2018-04-05 瞬已网络科技（上海）有限公司 一种网络实时视频传输方法及装置
CN107276722A (zh) * 2017-06-21 2017-10-20 北京奇艺世纪科技有限公司 一种基于udp的数据传输方法和系统
CN111464262A (zh) * 2020-03-18 2020-07-28 腾讯科技（深圳）有限公司 数据处理方法、装置、介质及电子设备
CN111787413A (zh) * 2020-07-09 2020-10-16 郑州信大捷安信息技术股份有限公司 流媒体数据传输方法、系统、发送装置及接收装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
周仕飞;贾维嘉;张历卓;: "基于二项式概率的冗余传输策略", 计算机工程, no. 01 *

Also Published As

Publication number Publication date
CN114124910B (zh) 2024-08-09

Similar Documents

Publication Publication Date Title
US8971415B2 (en) Video communication system, device and method based on feedback reference frames
US8005028B2 (en) Data communication system, data transmitting device, data transmitting method, data receiving device, and data receiving method
CN1242623C (zh) 视频编码方法、解码方法以及相关的编码器和解码器
US20140359679A1 (en) Content streaming with client device trick play index
US10944973B2 (en) Estimation of video quality of experience on media servers
CN110392284B (zh) 视频编码、视频数据处理方法、装置、计算机设备和存储介质
CN1643875A (zh) 数据流式传输系统和方法
CN111093083B (zh) 数据传输方法及装置
CN112073543B (zh) 一种云视频录制方法、系统和可读存储介质
JP2020184805A (ja) ビデオサービス品質の評価方法及び装置
KR20100106383A (ko) 가변 대역폭 채널을 통한 동시송출을 위한 장치 및 방법
US20140280754A1 (en) Resilience in the presence of missing media segments in dynamic adaptive streaming over http
KR100612691B1 (ko) 동영상 화질 평가시스템 및 방법
CN106303661B (zh) 一种直播客户端实现自适应屏幕旋转的方法及系统
CN105979284B (zh) 移动终端视频共享方法
CN111093082A (zh) 一种流媒体直播的方法及系统
JP4406816B2 (ja) 受信装置および受信方法、記録媒体、並びにプログラム
US7627184B2 (en) Content distribution/reception device, content transmission/reception method, and content distribution/reception program
CN103918258A (zh) 减少视频编码中的数据量
CN101296166B (zh) 基于索引的多媒体数据的测量方法
CN114124910B (zh) 直播数据传输方法、系统及可读存储介质
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
Belda et al. Hybrid FLUTE/DASH video delivery over mobile wireless networks
CN107995502B (zh) 实现自适应流媒体的方法和设备以及系统
KR101931653B1 (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
CB02 Change of applicant information

Country or region after: China

Address after: Room 01, 2 / F, building A14, phase 1.1, Wuhan National Geospatial Information Industrialization Base (New Area), no.6, Beidou Road, Donghu New Technology Development Zone, Wuhan City, Hubei Province, 430000

Applicant after: Wuhan Meihe Yisi Digital Technology Co.,Ltd.

Address before: Room 01, 2 / F, building A14, phase 1.1, Wuhan National Geospatial Information Industrialization Base (New Area), no.6, Beidou Road, Donghu New Technology Development Zone, Wuhan City, Hubei Province, 430000

Applicant before: HUBEI MEIHE YISI EDUCATION TECHNOLOGY Co.,Ltd.

Country or region before: China

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant