CN109617891A - 码流传输方法及装置 - Google Patents

码流传输方法及装置 Download PDF

Info

Publication number
CN109617891A
CN109617891A CN201811598954.1A CN201811598954A CN109617891A CN 109617891 A CN109617891 A CN 109617891A CN 201811598954 A CN201811598954 A CN 201811598954A CN 109617891 A CN109617891 A CN 109617891A
Authority
CN
China
Prior art keywords
data
level message
code stream
message
frame data
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.)
Pending
Application number
CN201811598954.1A
Other languages
English (en)
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.)
Sumavision Technologies Co Ltd
Original Assignee
Sumavision 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 Sumavision Technologies Co Ltd filed Critical Sumavision Technologies Co Ltd
Priority to CN201811598954.1A priority Critical patent/CN109617891A/zh
Publication of CN109617891A publication Critical patent/CN109617891A/zh
Pending legal-status Critical Current

Links

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/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供一种码流传输方法及装置，码流传输方法包括：首先从码流数据源中获得待传输的原始流，原始流包括多个帧数据以及每个帧数据的数据信息。然后根据信道带宽，对原始流进行分组，得到包含多个帧数据组，将帧数据组作为二级报文负载，将分组后帧数据作为一级报文负载，并得到各个一级报文。最后根据各个二级报文负载得到各个二级报文，并将二级报文发送到码流接收终端。由此，根据通信通道的信道带宽灵活调整二级报文的负载长度，有效地利用了通信信道的信道带宽，降低了信道带宽的使用率，提高了数据传输的传输效率，同时避免了在生成报文时向报文中填充无效信息，进一步提高了数据传输的传输效率。

Description

码流传输方法及装置
技术领域
本申请涉及数据传输领域，具体而言，涉及一种码流传输方法及装置。
背景技术
码流传输，即将本地视频和/或音频数据流通过某种信道传输到远端的方法，目前在各行各业广泛应用，例如视频会议、远程监控、直播课程等。伴随着码流传输技术的广泛应用，现有的码流传输方法的传输效率已经无法满足使用者的需求，基于此，如何提升数据传输的效率是本领域技术人员亟待解决的技术问题。
申请内容
有鉴于此，本申请的目的在于提供一种码流传输方法及装置，以解决或者改善上述问题。
为了实现上述目的，本申请实施例采用的技术方案如下：
第一方面本申请提供一种码流传输方法，应用于码流发送终端，所述方法包括：
从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳。
根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端。
可选地，所述根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组的步骤包括：
根据所述原始流的帧数据码率以及所述信道带宽得到最大负载长度，并根据所述最大负载长度得到分组长度。
按照所述时间戳的顺序，根据所述分组长度以及每个帧数据的数据长度，依次对所述多个帧数据进行分组，得到包含至少一个分组后帧数据的多个帧数据组，其中，每个帧数据组内的各个分组后帧数据的数据长度之和等于所述分组长度。
可选地，所述按照所述时间戳的顺序，根据所述分组长度以及每个帧数据的数据长度，依次对所述多个帧数据进行分组，得到包含至少一个分组后帧数据的多个帧数据组的步骤包括：
对于各个帧数据，在按照时间戳的顺序，将该帧数据填充到当前数据组的预留位置时，判断当前该帧数据的数据长度是否大于当前数据组的剩余分组长度，其中，所述剩余分组长度为该帧数据组的分组长度与已填充帧数据的数据长度之差。
若是，则根据所述剩余分组长度将当前待填充的帧数据分割为第一分组单元以及第二分组单元，并将所述第一分组单元填充到当前帧数据组中，再将所述第二分组单元填充到下一帧数据组中。
可选地，所述将所述二级报文发送到所述码流接收终端的步骤，包括：
采用开放式***互联协议UDP对所述二级报文进行处理得到对应的UDP报文。
将所述UDP报文发送到所述码流接收终端。
可选地，所述采用开放式***互联协议UDP对所述二级报文进行处理得到对应的UDP报文的步骤包括：
根据所述二级报文中各个一级报文的数据类型，对所述二级报文进行分组，得到数据类型不同的多个二级报文组。
将所述多个二级报文组中的二级报文聚合，得到聚合负载，其中，所述聚合负载包括各个数据类型的二级报文。
对于每个聚合负载，采用UDP对该聚合负载进行处理，得到对应的UDP报文。
可选地，所述将所述多个二级报文组中的二级报文聚合，得到聚合负载的步骤包括：
根据各个数据类型的二级报文对应的帧数据帧率，得到各个数据类型的二级报文的聚合比例。
根据所述聚合比例从所述多个二级报文组中将不同数据类型对应的二级报文聚合，得到聚合负载。
可选地，所述将所述UDP报文发送到所述码流接收终端的步骤之后，所述方法还包括：
将所述UDP报文存储在缓存池中，并检测是否接收到所述码流接收终端发送的重传指令。
在接收到所述重传指令时，判断所述缓存池中是否包括所述重传指令中的二级报文ID对应的UDP报文。
若是，则将所述缓存池中对应的UDP报文发送到所述码流接收终端。
可选地，所述将所述二级报文发送到所述码流接收终端的步骤包括：
采用传输控制协议TCP对各个二级报文的二级报文报头前添加同步字。
将添加所述同步字后的各个二级报文依次发送到所述码流接收终端。
第二方面，本申请实施例还提供一种码流传输装置，应用于码流发送终端，所述装置包括：
码流获取模块，用于从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳。
码流分组模块，用于根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
以及报文传输模块，用于根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端。
第三方面，本申请实施例还提供一种码流传输方法，应用于通过通信信道通信连接的码流发送终端以及码流接收终端，所述方法包括：
所述码流发送终端从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳。
根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端。
所述码流接收终端接收所述二级报文，并根据所述二级报文报头对所述一级报文解析，得到所述原始流。
相比现有技术，本申请提供的有益效果是：
本申请实施例提供的码流传输方法及装置，根据通信通道的信道带宽灵活调整二级报文的负载长度，有效地利用了通信信道的信道带宽，降低了信道带宽的使用率，提高了数据传输的传输效率，同时避免了在生成报文时向报文中填充无效信息，进一步提高了数据传输的传输效率。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍。应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定。对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的用于执行码流传输方法码流传输***的交互示意框图；
图2为本申请实施例提供的一种码流传输方法的流程示意图；
图3A～3D为本申请实施例提供的不同情况下一级报文报头的结构示意表；
图4A～4D为本申请实施例提供的不同情况下二级报文报头的结构示意表；
图5为本申请实施例提供的不同情况下LTP包中可变报头的长度示意表；
图6为本申请实施例提供的多种传输协议的打包方式比较表；
图7为本申请实施例提供的多种传输协议的理论传输效率结果比较表；
图8为本申请实施例提供的多种传输协议的实际传输效率结果比较表；
图9为本申请实施例提供的用于实现码流传输方法的码流发送终端的结构示意框图；
图10为本申请实施例提供的码流传输装置的功能模块图；
图11为本申请实施例提供的另一种码流传输方法的流程示意图。
图标：10-码流传输***；100-码流发送终端；110-总线；120-处理器；130-存储介质；140-总线接口；150-网络适配器；160-用户接口；200-码流接收终端；300-码流传输装置；310-码流获取模块；320-码流分组模块；330-报文传输模块。
具体实施方式
如前述背景技术分析所获知的技术问题，在码流传输的过程中，码流发送终端需要对原始流进行分组打包得到数据报文，并在数据报文中搭载原始流的数据信息，以使码流接收终端根据数据信息对数据报文进行解析得到原始流。
具体地，对于视音频数据流一般采用UDP(User Datagram Protocol,用户数据报协议)进行传输，对原始流进行打包生成UDP报文，码流发送终端将UDP报文发送到码流接收终端，由于UDP报文报头仅包含源端口号信息、目标端口号信息、数据报长度信息以及校验值信息，对于多个数据单元无法仅根据UDP报文得到原始流，因此需要对UDP报文负载进行打包生成报文，即对原始流打包生成负载报文，并用负载报文填充UDP报文负载，并在负载报文报头输入。
UDP报文的负载报文一般可以为RTP报文(Real-time Transport Protocol，实时传输协议)或TS报文(Transport Stream,传输流)，但RTP报文和TS报文都存在一定的缺陷。
具体地，RTP是基于Internet传输的协议，对于其他信道的支持不足。在工作时，RTP一般采用FU-A和FU-B格式对原始流进行分片封装，生成RTP报文，但RTP不支持一个分片包含两帧图像的数据，例如，当原始流的帧数据较大时，在对一个帧数据分片到最后只剩一点数据时，不能与下一帧数据的分片结果一同打包，只能将剩余数据打包为一个较短的RTP报文。这使得RTP的包长度参差不齐，对于信道传输的稳定不利，码率节约上也不占优势。
对于TS报文，由于TS协议本身的定义，TS报文负载固定为188字节，用于网络传输时一般是7个TS包合并成一个UDP包进行传输，但对于存在MTU(Maximum TransmissionUnit,最大传输单元)限制的网络，以整数倍188字节为单位的包在长度调整方面不够灵活，会造成带宽的浪费，降低传输速度。
此外，TS协议无法实现多帧数据的聚合传输，以188字节为单位封包，剩余的不满188字节的部分会被无效数据填充。尤其是在传输每帧数据都比较小的音频流时，对带宽的浪费极为严重。同时，TS协议的开销很大，TS协议为适应数字电视传输的实际情况，包含较多的冗余。这些冗余在传输较为简单的数据流时是不必要的，例如，一路视音频。
基于上述问题，本申请发明人提供了一种码流传输方法及装置，本申请提供的码流传输方法能够根据通信通道的信道带宽灵活调整第一报文的长度，有效地利用了通信信道的带宽，提高了数据传输的传输速度，同时避免了在生成报文时向报文中填充无效信息，提高了数据传输的传输效率。
以上现有技术中的方案所存在的缺陷，均是申请人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本申请实施例针对上述问题所提出的解决方案，都应该是申请人在本申请过程中对本申请做出的贡献。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。
因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的关键可以相互组合。
请参阅图1，为本申请实施例提供的用于实现下述码流传输方法的码流传输***10的交互示意框图。
如图1所示，码流传输***10包括通信连接的码流发送终端100以及码流接收终端200。
在工作时，码流发送终端100将原始流打包生成报文发送到码流接收终端200。码流接收终端200接收报文，并根据报文报头对报文解析得到原始流。
需要说明的是，本申请提供的码流传输方法在未说明具体传输协议时，对码流发送终端100与码流接收终端200的通讯连接方法不做限制。在数据传输领域，由于码流数据的特性，对码流传输时一般采用上述的UDP报文，但码流发送终端100以及码流接收终端200还可以通过TCP(Transmiss ion Control Protocol,传输控制协议)连接进行数据传输，此外码流发送终端100以及码流接收终端200还可以直接通过总线连接或进行端对端的传输。
进一步地，请参阅图2，为本申请实施例提供的码流传输方法的一种流程示意图，本实施例中，码流传输方法由图1中所示的码流发送终端100执行，下面结合图2对图1中所示的码流发送终端100进行详细阐述。所应说明的是，本申请实施例提供的码流传输方法不以图2及以下的具体顺序为限制。方法的具体流程如下：
步骤S110，从码流数据源中获得待传输的原始流，原始流包括多个帧数据以及每个帧数据的数据信息，其中，数据信息包括帧数据的数据源ID、数据类型、数据长度以及时间戳。
具体地，步骤S110中的码流数据源可以包括实时生成数据流的实时数据源或存储有数据流的预存数据源一种或多种组合，原始流可以为视频帧数据流、音频帧数据流以及普通帧数据流中的一种或多种组合。
作为一种实施方式，数据源可以为与码流发送终端100通信连接的前端设备。在码流发送终端100接收到原始流时，可以根据前端设备获得数据源ID以及数据类型，并根据前端设备获得原始流中各个帧数据的时间得到各个帧数据的时间戳，再根据数据源的帧率与码流得到各个帧数据的数据长度。
其中，可以理解，码流发送终端100可以通过总线接口与前端设备连接，例如，前段设备可以为通过USB端口与码流发送终端100连接的摄像头，或者前段设备可以为码流发送终端100的一部分，例如，前段设备可以为码流发送终端100的存储介质。
可选地，在码流发送终端100可以从前端设备获取码流数据源之后，码流发送终端100可以根据码流接收终端200需要的码流对原始流进行时间采样、图像缩放等操作，例如，码流接收终端200需要30FPS，720P的视频流数据，前端设备可以生成50FPS，1080P的视频流数据，则码流发送终端100在接收到原始流是可以对原理流进行时间下采样与图片缩小，以得到30FPS，720P的原始流。
作为一种实施方式，前端设备可以包括获取视频数据流的摄像机以及获取音频数据流的录音机，则视频帧数据流的数据源ID可以为摄像机的ID信息，音频帧数据流的数据源ID可以为录音机的ID信息。
作为另一种实施方式，前端设备可以包括同时获得视频数据流以及音频数据流的集成设备，则视频帧数据流和音频帧数据流的数据源ID均为该集成设备的ID信息。
需要说明的是，数据源为预存数据源，码流发送终端100获得各个帧数据以及对应的数据信息的方式与实时数据源类似，但对于原始流中各个帧数据的时间戳以及数据源ID存在一定区别，
具体地，数据源ID可以为产生预存数据流的数据源的ID，也可以为在码流发送终端100储存预存数据流后，由码流发送终端100对各个预存数据流编码分配的ID信息。原始流中各个帧数据的时间戳信息可以由该帧数据到起始帧数据的时间得到。
步骤S120，根据码流发送终端100与码流接收终端200之间的通信信道的信道带宽，对原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将帧数据组作为二级报文负载，将分组后帧数据作为一级报文负载，并根据分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
在工作时，码流发送终端100根据原始流的帧数据码率以及所述信道带宽得到最大负载长度，并根据所述最大负载长度得到分组长度。再按照时间戳的顺序，根据分组长度以及每个帧数据的数据长度，依次对多个帧数据进行分组，得到包含至少一个分组后帧数据的多个帧数据组。
其中，每个帧数据组内的各个分组后帧数据的数据长度之和等于分组长度。
作为一种实施方式，最大负载长度减去预留长度可以得到有效负载长度，有效负载长度乘以长度比例可以得到分组长度，例如，采用UDP传输原始流时，原始流可以为G711格式音频数据流，码率为64Kbps，帧长20ms，基于此，原始流每秒产生50个160字节长的音频帧，根据信道带宽以及码率可以得到最大负载长度，例如，当通信信道的信道带宽128Kbps时，最大负载长度可以为1400字节。当一次发送一个二级报文时，长度比例为1，分组长度与有效负载长度相等。对应的，二级报文报头可以为4个字节，每个二级报文的第一个一级报文报头6个字节，其他一级报文报头4个字节，其他预留长度共42个字节，因为帧数据的长度为160字节，设一级报文数量为x，则可以得到一级报文数量的计算公式：
1400-42-4-(6+4*(x-1))≥x*160
其中，经计算可得，x＝8。则二级报文中可以包括8个一级报文，则分组长度可以为160*8＝1280个字节。
即在分组时，分组长度为1280字节，将8个帧数据作为一个帧数据组。
需要说明的是，在传输时可能将多个二级报文打包发送，长度比例为该二级报文的长度与该传送包内所有二级报文的长度之和的比，例如，一个打包两个长度一致的二级报文时，每个二级报文的长度比例为0.5。
基于上述设计，在分组时可以根据通信信道的信道带宽调整报文数量，有效地利用了通信信道的信道带宽，传输相同数据量的数据时，降低了信道带宽的占用率，提高了数据传输的效率。
应注意的是，上述例子中分组长度为1280字节，即有效数据为1280字节，则传输时UDP报文总长度为1360个字节，为充分利用通信信道，在分组时可以根据通信信道的信道带宽对帧数据进行分割，以提高通信信道的利用率，从而提高数据传输的效率。
可选地，对于各个帧数据，在按照时间戳的顺序，将该帧数据填充到当前数据组的预留位置时，判断当前该帧数据的数据长度是否大于当前数据组的剩余分组长度。如果当前该帧数据的数据长度大于当前数据组的剩余分组长度，则根据剩余分组长度将当前待填充的帧数据分割为第一分组单元以及第二分组单元，并将第一分组单元填充到当前帧数据组中，再将第二分组单元填充到下一帧数据组中。
其中，剩余分组长度为该二级报文负载的分组长度与已填充帧数据的数据长度之差；
基于上述设计，上述例子中，可以设一级报文数量为x，负载中包含的帧数据数量为y，其中x＝[y]+1，则可以得到一级报文数量的计算公式：
1400-42-4-(6+4*(x-1))＝y*160
则经计算可知y＝8.225，x＝9，即传输时每个二级报文包括9个一级报文，一个UDP报文的长度为1400字节，有效数据为1316字节。
即在分组时，分组长度为1316字节，平均将8.225个帧数据作为一个帧数据组。对于长度溢出的帧数据，根据该组的剩余长度将帧数据拆分。
再例如，采用UDP传输原始流时，原始流可以为码率为100Kbps，帧率25FPS的视频数据流，每帧图像数据为500字节时，基于上述拆分帧数据的分包方式，最大负载长度可以为1400字节，包含一个二级报文，一个二级报文包括三个一级报文，有效数据为1340字节。当不拆分时，一个UDP报文的长度为1056字节，包含一个二级报文，一个二级报文包括二个一级报文，有效数据为1000字节。
基于上述设计，在分组时可以对帧数据进行拆分，拆分后的帧数据不需要填充无效数据，从而提高通信信道的带宽利用率，降低了通信信道的占用率，提高了数据传输的效率。
可选地，在根据分组后帧数据得到对应的一级报文报头，以得到各个一级报文的步骤中，码流发送终端100根据分组后帧数据以及其对应的数据信息生成一级报文报头。
其中，一级报文报头包括帧起始标记(ES_start)、帧结尾标记(ES_end)、特征帧标记(ES_anchor)、加密标记(ES_encryption)、一级报文长度(ES_len gth)、时间戳信息(timestamp)、时间偏移判定标记(long_offset)以及时间偏移信息(timestamp_offset)中的多种组合。
具体地，帧起始标记用于标记该一级报文负载是否为帧数据的开始。帧结尾标记用于标记该一级报文负载是否为帧数据的结束。例如，当帧数据不被拆分时，该帧数据对应的一级报文报头中帧起始标记以及帧结尾标记均为有效，例如，数值为1。当帧数据被拆分时，拆分后的数据单元中起始部分对应的数据单元的帧起始标记为有效，终止部分对应的数据单元的帧结尾标记为有效，该帧数据的其他数据单元的帧起始标记以及帧结尾标记均为无效。
特征帧标记用于标记该一级报文负载是否为特征帧，若是，则有效。其中，特征帧一般为用于同步数据的帧数据，例如，音视频数据流中每秒的第一个帧音频数据以及第一帧图像数据。则对应的每秒第一个帧数据对应的所有一级报文报头中特征帧标记为有效。
加密标记用于标记该一级报文负载是否为加密后的帧数据，若是，则有效。一级报文长度用于标记该一级报文的长度信息。时间戳信息用于标记该一级报文的时间戳信息。时间偏移判定标记用于标记该一级报文的时间偏移信息的类型。时间偏移信息用于标记该一级报文相对特定时间戳信息的时间偏移量。
基于上述设计，当一个二级报文仅包括一个一级报文，该一级报文的报头可以包括1位的帧起始标记、1位的帧结尾标记、1位的特征帧标记、1位的加密标记、1位的时间偏移判定标记、3位的站位标记(reserved)以及32位的时间戳信息，共40位，5个字节，其报头的具体结构如图3A所示。
其中，码流接收终端200解析时，可以根据各个二级报文报头分割各个一级报文，因此，打包时，不需要在一级报文报头添加该一级报文的长度信息，此外，该一级报文报头的时间偏移判定标记和站位标记可以根据情况作为扩展标记使用。
当一个二级报文仅包括多个一级报文，对于各个二级报文中第一个一级报文，该一级报文的报头可以包括1位的帧起始标记、1位的帧结尾标记、1位的特征帧标记、1位的加密标记、1位的时间偏移判定标记、8位的长度信息以及32位的时间戳信息，共48位，6个字节，其报头的具体结构如图3B所示。
本申请发明人发现对于第一个一级报文之外的一级报文，在码流接收终端200对该一级报文进行解析时，可以根据第一个一级报文的时间戳信息以及时间偏移信息来生成该一级报文的时间戳信息，进而减少一级报文报头的长度。由此，对于第一个一级报文之外的一级报文，该一级报文的报头可以包括1位的帧起始标记、1位的帧结尾标记、1位的特征帧标记、1位的加密标记、1位的时间偏移判定标记、8位的长度信息以及时间偏移信息。
进一步地，本申请发明人发现不同类型的原始流中帧数据的间隔时间可能不一致，例如，视频数据流的间隔时间可能小于音频数据流的间隔时间，基于此，本申请发明人发现可以设置两种时间偏移信息，并通过时间偏移判定标记确定时间偏移信息的类型。
作为一种实施方式，时间偏移信息可以包括16位长度以及24位长度两种，时间偏移信息为16位时间偏移信息时，该一级报文共32位，即4字节，具体结构如图3C所示。时间偏移信息为24位时间偏移信息时，该一级报文共40位，即5字节，具体结构如图3D所示。
作为另一种实施方式，时间偏移信息可以为固定长度，例如16位长度，码流接收终端200在解析报文时根据时间偏移判定标记确定时间偏移信息为正还是为负。
步骤S130，根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将二级报文发送到码流接收终端200。
可选地，在根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文的步骤中，码流发送终端100根据各个二级报文负载中的一级报文以及其对应的数据信息生成二级报文报头。
其中，二级报文报头包括长度忽略标记(omit_length)、重传标记(retrans fer_flg)、协议类型(identify_code)、扩展标记(extension)、负载聚合标记(agg regation_flag)、传输包长度(transport_packet_length)、数据源ID(stream_ID)、数据类型(stream_type)以及包序号(sequence_number)中的多种组合。
具体地，长度忽略标记用于标记是否忽略该二级报文的传输包长度，其中，当码流发送终端100一次发送一个二级报文时，长度忽略标记可有效，在二级报文报头中不记录传输包长度以减少二级报文报头长度，当码流发送终端100一次发送一个二级报文时，长度忽略标记无效在二级报文报头中记录传输包长度。
重传标记用于标记该二级报文是否为重传报文，若是，重传标记有效。协议类型用于标记本传输方法的类型。扩展标记用于根据用户设计表示是否对报头进行扩展，若是，则扩展标记有效，并在报头后添加一个字节的扩展位(extension_contant)，其中扩展位可以根据用户设置存放额外信息，例如，加密秘钥等。负载聚合标记用于标记该二级报文是否包括多个一级报文，若是，则负载聚合标记有效。传输包长度用于标记该二级报文的报文长度。数据源ID用于标记该二级报文的数据源ID信息。数据类型用于标记该二级报文的数据类型，其中，一个二级报文只能传输一个类型的数据。包序号用于标记二级报文的顺序。
基于上述设计，当码流发送终端100一次发送一个二级报文，且该二级报文报头无扩展时，该一级报文的报头可以包括1位的有效的长度忽略标记、1位的重传标记、1位的无效的扩展标记、1位的负载聚合标记、4位的特协议类型、4位的数据源ID、4位的数据类型以及16位的包序号，共32位，4个字节，其报头的具体结构如图4A所示。
当码流发送终端100一次发送一个二级报文，且该二级报文报头有扩展时，该一级报文的报头可以包括1位的有效的长度忽略标记、1位的重传标记、1位的有效的扩展标记、1位的负载聚合标记、4位的特协议类型、4位的数据源ID、4位的数据类型、16位的包序号以及8位的扩展位，共40位，5个字节，其报头的具体结构如图4B所示。
当码流发送终端100一次发送多个二级报文，且该二级报文报头无扩展时，该一级报文的报头可以包括1位的无效的长度忽略标记、1位的重传标记、1位的无效的扩展标记、1位的负载聚合标记、1位的特协议类型、11位的传输包长度、1位的数据源ID、4位的数据类型以及16位的包序号，共40位，5个字节，其报头的具体结构如图4C所示。
当码流发送终端100一次发送多个二级报文，且该二级报文报头有扩展时，该一级报文的报头可以包括1位的无效的长度忽略标记、1位的重传标记、1位的有效的扩展标记、1位的负载聚合标记、1位的特协议类型、11位的传输包长度、1位的数据源ID、4位的数据类型、16位的包序号以及8位的扩展位，共48位，6个字节，其报头的具体结构如图4D所示。
可选地，当码流发送终端100采用UDP与码流接收终端200通讯连接时，将二级报文发送到码流接收终端200的步骤可以先根据UDP对二级报文进行处理得到对应的UDP报文。在将UDP报文发送到码流接收终端200。
其中，一个UDP报文包括一个8个字节的UDP报头，在发送时，需要在UDP报头前添加一个34个字节的IP包头以及以太包头，以生成一个传输包。
基于上述设计，采用UDP传输二级报文不需要码流发送终端100与码流接收终端200实时通讯连接，有资源消耗小，处理速度快。
在研究过程中，本申请发明人还发现，在传输音频数据流时，由于一帧音频帧数据较小，填充满一个二级报文时，需要较多帧的音频帧数据，码流接收终端200接受到二级报文的频率较低，容易造成较为严重的延迟，尤其在网络环境较差，容易丢包的情况下。现有技术在传输时一般通过分组长度减小二级报文内帧数据的数据量提升同步效果。但是在传输视音频复合数据流时，如果减小分组长度，则会造成二级报文的长度参差不齐，波动性较大，影响数据传输的稳定性，为解决该技术问题，本领域技术人员一般将音频数据流与视频数据流进行聚合。
在数据聚合方面，上述RTP报文没有对视音频数据流聚合的解决方案，无法聚合传输同源的视频、音频数据，也无法聚合传输不同来源的原始流，在传输时只能分开传输，浪费了码率，降低的传输效率。
虽然基于RTP报文报头存在扩展位，可自定义协议实现聚合，但该方法利占用扩展位后，一些其他信息无法写入RTP报文报头，例如，秘钥信息，降低了RTP报文的泛用性。
基于上述问题，可选地，本申请提供的码流传输方法在根据UDP对二级报文进行处理得到对应的UDP报文的步骤中，码流发送终端100可以先根据二级报文中各个一级报文的数据类型，对二级报文进行分组，得到数据类型不同的多个二级报文组。然后，将多个二级报文组中的二级报文聚合，得到聚合负载，其中，聚合负载包括各个数据类型的二级报文。最后，对于每个聚合负载，采用UDP对该聚合负载进行处理，得到对应的UDP报文。
作为一种实施方式，码流发送终端100可以先根据各个数据类型的二级报文对应的帧数据帧率，得到各个数据类型的二级报文的聚合比例。然后根据聚合比例从多个二级报文组中将不同数据类型对应的二级报文聚合，得到聚合负载。
需要说明的是，在进行分组时，码流发送终端100也需要根据聚合比例作为长度比例，调整不同类型数据的分组长度。
具体地，对于包括码率为100Kbps，帧率25fps的视频流，G729格式的音频流的复合流。则每帧图像平均为500字节，共25帧/s，每帧音频平均为30字节，约34帧/s。根据视频流与音频流的帧率，得到视频流与音频流的聚合比例为25:34，即平均来说要每打包25帧图像帧数据，需要聚合34帧音频帧数据。如果最大负载长度为1400字节，并设图像帧数据对应的二级报文包括x个一级报文，负载中包含的帧数据数量为y，其中x＝[y]+1，设音频帧数据对应的二级报文包括a个一级报文，负载中包含的帧数据数量为b，其中a＝[b]+1，y:b＝25:34。则可以得到一级报文数量的计算公式：
1400-42*2-5*2-(6*2+4*(x+a-2))＝y*500+b*30
则可得：
4[b]+4[y]+500y+30b＝1294
假设[y]:[b]＝25:34，则9.44[y]+540.8y＝1294，x＝3，y＝2.34，则4[b]+30b＝112，a＝4，b＝3.2。
则视频数据流对应的分组长度为1170，对应的一个二级报文包括3个一级报文，平均一个二级报文包含2.34帧视频帧数据。音频数据流对应的分组长度为96，对应的一个二级报文包括4个一级报文，平均一个二级报文包含3.2帧音频帧数据。一个聚合负载包括一个音频数据流二级报文以及一个视频数据流二级报文。
作为另一种实施方式，为保证数据的完整性，可以在部分二级报文中包含三个完整的音频帧数据，剩余部分二级报文中包含两个完整的音频帧数据，其中，部分二级报文以及剩余部分二级报文的比例可以根据聚合比例得到。
基于上述设计，将音频数据流与视频数据流聚合发送，避免了音频数据较短从而产生的延迟现象，提高了用户体验，此外，还避免了UDP报文长短参差不齐的情况，提高了数据传输的稳定性。
可选地，码流发送终端100将处理得到的UDP报文发送到码流接收终端200之后，还可以将UDP报文存储在缓存池中，同时检测是否接收到码流接收终端200发送的重传指令；并在接收到重传指令时，判断缓存池中是否包括重传指令中的二级报文ID对应的UDP报文。若缓存池中包括对应的UDP报文，将缓存池中对应的UDP报文发送到码流接收终端200。
其中，码流发送终端100重新发送对应的UDP报文时，需要将二级报文报头的重传标记置为有效。
可选地，当码流接收终端200超过60ms都没有接收到重传的UDP报文时，可以根据插值算法估算缺失的UDP报文内容。
作为一种实施方式，码流发送终端100可以通过传输控制协议TCP与码流接收终端200通信连接。
在码流发送终端100将二级报文发送到码流接收终端200时，码流发送终端100可以先根据TCP对各个二级报文的二级报文报头前添加同步字，然后将添加同步字后的各个二级报文依次发送到码流接收终端200。
在工作时，码流接收终端200依靠同步字和其后长度字段分割二级报文，从而对二级报文进行解析。
可以理解，当码流发送终端100通过总线接口与码流接收终端200通信连接时或两个端对端连接时，也可以采用上述添加同步字的方法进行传输。
基于上述设计，增加了本申请提供的码流传输方法的泛用性。
为进一步说明本申请提供的码流传输方法的技术效果，本申请发明人对本申请提供的码流传输方法与现有技术的码流传输方法的传输效率进行了理论打包效率的计算。
对于本申请提供的码流传输方法，本申请发明人将其命名为LTP(Low-bitrateTransport Protocol,低比特率传输协议)。将二级报文命名为transport报文，将一级报文命名为ES报文，将向UDP报文前添加IP包头以及以太包头得到的传输包作为LTP包。
在进行计算前，需要说明的是，理论打包效率(理论传输效率)＝有效数据量/打包总长度＝原始流码率/(原始流码率+打包速率*包头长度)。其中，当采用UDP进行数据传输时，包头长度＝UDP报文负载的报头长度之和+以太包头(14字节)+IP包头(20字节)+UDP报文报头(8字节)。
对于RTP，RTP包头长度计算：对于RTP打包方式，包头长度固定为54字节(包括以太包头14字节、IP头20字节、UDP头报头字节和RTP报头12字节)。
音频打包个数计算：一般一个音频帧的长度小于RTP最大负载长度，也就是一个音频帧打到一个RTP包里。用1000/音频帧长度来计算一秒钟有多少个音频RTP包。例如，G711格式音频帧长20ms，那么一秒钟产生50个RTP包，G729格式音频典型帧长为30ms，那么打包速率为1000/30每秒，其中，RTP包是指通过RTP生成的UDP报文添加以太包头与IP包头后的传输包。
视频打包个数计算：以码率1Mbps，帧率25fps为例，平均每帧图像的大小为5000字节，如果最大负载长度为1400字节，那么平均每帧图像的打包个数为4，打包速率为100/s。如果最大负载长度为500字节，那么平均每帧图像的打包个数为10，打包速率为250/s。
需要说明的是，由于视频实际上是分为I帧和P帧，而不是每帧都是均匀大小，对于结果有一定影响，但基本结论不会有很大变化。
对于TS流，如果只包含音频帧数据，由于G711音频每帧160字节，G729音频每帧30字节，封装为TS包时，都是每一个188字节的TS包里包含1帧音频，于是总的音频码率固定是188字节*包个数。TS流的打包速度为1000/音频帧长度。
如果只包含视频帧数据，TS打包方式的总码率按照以下公式计算：
总码率＝(原始流码率+3.8Kbps+36.6Kbps)×188/184+188*3*8
对于视音频复合流，则需要按以上方法对视频和音频分别计算，然后合并计入总码率。
对于本申请提供的码流传输方法LTP，包头长度计算：对于LTP打包方式，传输包的包头长度是变化的，固定的部分是以太包头+IP包头+UDP包头共42字节。
基于上述的设计，LTP包的可变报头的长度，如图5所示，需要说明的是本申请提供的LTP报文不需要扩展位进行扩展即可达到上述协议相同的传输效果。
音频打包个数计算：G711格式音频，码率为64Kbps，帧长20ms，每秒产生50个160字节长的音频帧，如果最大负载长度最大为1400字节，那么可以将原始流打包成每个UDP报文含有1个transport报文，每个transport报文含有9个ES报文的结构，每秒产生6个LTP包，即打包速率为6/s，每个包的包头长度为42+[4+(6+4*8)]，共84字节。如果最大负载长度最大为500字节，打包速率为13/s，包头长度是42+[4+(6+4*3)]，共64字节。
视频打包个数计算：对于码率100Kbps，帧率25fps的视频，每帧图像平均为500字节，如果最大负载长度最大为1400，那么每秒产生9个传输包，每个LTP包包括一个transport报文，每个transport报文里有3个ES报文。包头长度是42+4+6+4*2，共60字节。如果最大负载长度最大为500字节，那么每秒产生25个传输包，包头长度是42+4+5，共51字节。对于码率为1Mbps，帧率25fps的视频，计算方式类似。
视音频合并打包时的包个数计算：对于码率为100Kbps，帧率为25fps的视频，G729格式的音频的复合流。每帧图像平均为500字节，共25帧/s，每帧音频平均为30字节，约34帧/s。对于最大负载长度为1400字节的情况，平均来说要将3帧图像和4帧音频打包到一个传输包里。总共大约产生9个LTP包。每个LTP包的包头长度平均为42+(5+6+4+4)+(5+6+4+4+4)，共84字节。对于最大负载长度为500字节，总负载为500*25+1000＝13500字节，要产生27个LTP包，总共有34个音频LTP包，其中20个LTP包有1帧音频帧数据，7个LTP包中有2帧音频帧数据。对于视频，假设每个LTP包都具有2个不完整的分片，那么总包头长度为(5+(6+4)+(6+4))*20+(5+(6+4)+(6+4+4))*7，共703字节。
对于码率1Mbps，帧率25fps的视频，G729格式音频的复合流。每帧图像平均为5000字节，共25帧/s，每帧音频为30字节，约34帧/s。总负载量为126KB，对于最大负载长度为1400字节的情况，要产生90个LTP包。90个LTP包里34个LTP包含有音频transport报文，56个LTP包只含视频transport报文。总transport报文报头长度是(4+5)*56+(5+5+5+5)*34，共1184字节。对于最大负载长度为500字节的情况，要产生252个传输包，里面有34个含有音频，218个只含有视频片。总transport报文报头长度是(4+5)*218+(5+5+5+5)*34，共2642字节。
根据上述内容，可以得到打包方式比较表，如图6所示，对图6中的表格进行数据整理，可以得到理论结果比较表，如图7所示。
基于计算结果可知，本申请提供的码流传输方法LTP具有以下优点：
1、理论效率较高，比RTP打包效率高0.49％到48.75％。与TS打包相比，绝大多数情况下效率比TS高，一般提高0.31％到68.50％。
2、在低码率场景封包效率较高。
本申请发明人还对本申请提供的码流传输方法LTP与RTP以及TS进行了实际测试，其中，音频采用G729编码格式，视频采用H264编码格式，实际结果比较表如图8所示：
基于计算结果可知，本申请提供的码流传输方法LTP对信道带宽有更好的利用率，从而有更高的传输效率，具体地，与TS相比，本申请提供的码流传输方法LTP节省9～34％的带宽；与RTP非聚合相比，本申请提供的码流传输方法LTP能够节省2～7％的带宽，与RTP聚合相比，本申请提供的码流传输方法LTP可以节省0.5～4.5％的带宽。
本申请实施例还提供一种用于执行码流传输方法的码流发送终端100，请参阅图9，图9提供了用于实现码流传输方法的码流发送终端100的结构示意框图。
如图9所示，码流发送终端100可以由总线110作一般性的总线体系结构来实现。总线110将各种电路连接在一起，这些电路包括处理器120、存储介质130和总线接口140。可选地，电子设备100可以使用总线接口140将网络适配器150等经由总线110连接。网络适配器150可用于实现电子设备100中物理层的信号处理功能。用户接口160可以连接外部设备。
处理器120可执行下述实施例，具体地，存储介质130中可以存储***流传输装置300，处理器120可以用于执行码流传输装置300。
在一种实施方式中，请参阅图10，为本申请实施例提供的上述码流传输装置300的功能模块图，码流传输装置300可包括
码流获取模块310，用于从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳。
码流分组模块320，用于根据所述码流发送终端100与码流接收终端200之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
报文传输模块330，用于根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端200。
基于上述设计，根据通信通道的信道带宽灵活调整二级报文的负载长度，有效地利用了通信信道的信道带宽，降低了信道带宽的使用率，提高了数据传输的传输效率，同时避免了在生成报文时向报文中填充无效信息，进一步提高了数据传输的传输效率。
请参阅图11，本申请实施例还提供一个应用于通讯连接的码流发送终端100以及码流接收终端200的码流传输方法。
如图11所示，码流传输方法包括以下步骤：
步骤S210，所述码流发送终端100从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳。
步骤S220，根据所述码流发送终端100与码流接收终端200之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文。
步骤S230，根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端200。
步骤S240，所述码流接收终端200接收所述二级报文，并根据所述二级报文报头对所述一级报文解析，得到所述原始流。
本申请实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序被执行时可以实现上述任意实施例中的码流传输方法。
对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本关键的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及权利要求。

Claims (10)

1.一种码流传输方法，其特征在于，应用于码流发送终端，所述方法包括：
从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳；
根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文；
根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端。
2.根据权利要求1所述的码流传输方法，其特征在于，所述根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组的步骤包括：
根据所述原始流的帧数据码率以及所述信道带宽得到最大负载长度，并根据所述最大负载长度得到分组长度；
按照所述时间戳的顺序，根据所述分组长度以及每个帧数据的数据长度，依次对所述多个帧数据进行分组，得到包含至少一个分组后帧数据的多个帧数据组，其中，每个帧数据组内的各个分组后帧数据的数据长度之和等于所述分组长度。
3.根据权利要求2所述的码流传输方法，其特征在于，所述按照所述时间戳的顺序，根据所述分组长度以及每个帧数据的数据长度，依次对所述多个帧数据进行分组，得到包含至少一个分组后帧数据的多个帧数据组的步骤包括：
对于各个帧数据，在按照时间戳的顺序，将该帧数据填充到当前数据组的预留位置时，判断当前该帧数据的数据长度是否大于当前数据组的剩余分组长度，其中，所述剩余分组长度为该帧数据组的分组长度与已填充帧数据的数据长度之差；
若是，则根据所述剩余分组长度将当前待填充的帧数据分割为第一分组单元以及第二分组单元，并将所述第一分组单元填充到当前帧数据组中，再将所述第二分组单元填充到下一帧数据组中。
4.根据权利要求1所述的码流传输方法，其特征在于，所述将所述二级报文发送到所述码流接收终端的步骤，包括：
采用开放式***互联协议UDP对所述二级报文进行处理得到对应的UDP报文；
将所述UDP报文发送到所述码流接收终端。
5.根据权利要求4所述的码流传输方法，其特征在于，所述采用开放式***互联协议UDP对所述二级报文进行处理得到对应的UDP报文的步骤包括：
根据所述二级报文中各个一级报文的数据类型，对所述二级报文进行分组，得到数据类型不同的多个二级报文组；
将所述多个二级报文组中的二级报文聚合，得到聚合负载，其中，所述聚合负载包括各个数据类型的二级报文；
对于每个聚合负载，采用UDP对该聚合负载进行处理，得到对应的UDP报文。
6.根据权利要求5所述的码流传输方法，其特征在于，所述将所述多个二级报文组中的二级报文聚合，得到聚合负载的步骤包括：
根据各个数据类型的二级报文对应的帧数据帧率，得到各个数据类型的二级报文的聚合比例；
根据所述聚合比例从所述多个二级报文组中将不同数据类型对应的二级报文聚合，得到聚合负载。
7.根据权利要求4所述的码流传输方法，其特征在于，所述将所述UDP报文发送到所述码流接收终端的步骤之后，所述方法还包括：
将所述UDP报文存储在缓存池中，并检测是否接收到所述码流接收终端发送的重传指令；
在接收到所述重传指令时，判断所述缓存池中是否包括所述重传指令中的二级报文ID对应的UDP报文；
若是，则将所述缓存池中对应的UDP报文发送到所述码流接收终端。
8.根据权利要求1所述的码流传输方法，其特征在于，所述将所述二级报文发送到所述码流接收终端的步骤包括：
采用传输控制协议TCP对各个二级报文的二级报文报头前添加同步字；
将添加所述同步字后的各个二级报文依次发送到所述码流接收终端。
9.一种码流传输装置，其特征在于，应用于码流发送终端，所述装置包括：
码流获取模块，用于从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳；
码流分组模块，用于根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文；以及
报文传输模块，用于根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端。
10.一种码流传输方法，其特征在于，应用于通过通信信道通信连接的码流发送终端以及码流接收终端，所述方法包括：
所述码流发送终端从码流数据源中获得待传输的原始流，所述原始流包括多个帧数据以及每个帧数据的数据信息，其中，所述数据信息包括所述帧数据的数据源ID、数据类型、数据长度以及时间戳；
根据所述码流发送终端与码流接收终端之间的通信信道的信道带宽，对所述原始流进行分组，得到包含至少一个分组后帧数据的多个帧数据组，将所述帧数据组作为二级报文负载，将所述分组后帧数据作为一级报文负载，并根据所述分组后帧数据得到对应的一级报文报头，以得到各个一级报文；
根据各个二级报文负载中的一级报文得到各个二级报文负载的二级报文报头，以得到各个二级报文，并将所述二级报文发送到所述码流接收终端；
所述码流接收终端接收所述二级报文，并根据所述二级报文报头对所述一级报文解析，得到所述原始流。
CN201811598954.1A 2018-12-26 2018-12-26 码流传输方法及装置 Pending CN109617891A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811598954.1A CN109617891A (zh) 2018-12-26 2018-12-26 码流传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811598954.1A CN109617891A (zh) 2018-12-26 2018-12-26 码流传输方法及装置

Publications (1)

Publication Number Publication Date
CN109617891A true CN109617891A (zh) 2019-04-12

Family

ID=66011202

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811598954.1A Pending CN109617891A (zh) 2018-12-26 2018-12-26 码流传输方法及装置

Country Status (1)

Country Link
CN (1) CN109617891A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110768864A (zh) * 2019-10-16 2020-02-07 北京科技大学 一种网络流量批量生成图像的方法及装置
CN112104589A (zh) * 2019-06-18 2020-12-18 成都鼎桥通信技术有限公司 一种宽窄融合的端到端加密方法
CN112468887A (zh) * 2019-09-06 2021-03-09 杭州海康微影传感科技有限公司 热成像数据的传输方法、装置及热成像设备
WO2021179307A1 (zh) * 2020-03-13 2021-09-16 华为技术有限公司 传输流ts的处理方法、装置和***

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050068914A1 (en) * 2003-08-13 2005-03-31 Kang-Bok Lee Broadcasting and communication combining system based on Ethernet and method thereof
CN1791057A (zh) * 2004-12-15 2006-06-21 华为技术有限公司 在光传送网中传输数据业务的方法及其装置
CN1972454A (zh) * 2006-11-30 2007-05-30 中兴通讯股份有限公司 一种移动多媒体广播实时流的封装方法
CN1976495A (zh) * 2006-11-30 2007-06-06 中兴通讯股份有限公司 一种移动多媒体广播控制信息与媒体信息区分传送的方法
CN101102506A (zh) * 2007-08-01 2008-01-09 北京创毅视讯科技有限公司 一种多媒体广播数据传输方法、装置及***
CN101146041A (zh) * 2006-09-13 2008-03-19 美国博通公司 最小化分组网络上通话的端到端延迟的方法、***和电路
CN101202920A (zh) * 2007-12-19 2008-06-18 北京创毅视讯科技有限公司 一种广播***中的数据发送、传输方法、发射***和终端
CN101420369A (zh) * 2007-10-24 2009-04-29 华为技术有限公司 通用分组无线业务隧道协议报文传输方法、***及设备
CN100550799C (zh) * 2004-02-17 2009-10-14 夏普株式会社 传输装置
US20110249660A1 (en) * 2010-04-08 2011-10-13 Lg Electronics Inc. Method for transmitting ppdu in wireless local area network and apparatus for the same
CN108353035A (zh) * 2015-10-28 2018-07-31 微软技术许可有限责任公司 多路复用数据

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050068914A1 (en) * 2003-08-13 2005-03-31 Kang-Bok Lee Broadcasting and communication combining system based on Ethernet and method thereof
CN100550799C (zh) * 2004-02-17 2009-10-14 夏普株式会社 传输装置
CN1791057A (zh) * 2004-12-15 2006-06-21 华为技术有限公司 在光传送网中传输数据业务的方法及其装置
CN101146041A (zh) * 2006-09-13 2008-03-19 美国博通公司 最小化分组网络上通话的端到端延迟的方法、***和电路
CN1972454A (zh) * 2006-11-30 2007-05-30 中兴通讯股份有限公司 一种移动多媒体广播实时流的封装方法
CN1976495A (zh) * 2006-11-30 2007-06-06 中兴通讯股份有限公司 一种移动多媒体广播控制信息与媒体信息区分传送的方法
CN101102506A (zh) * 2007-08-01 2008-01-09 北京创毅视讯科技有限公司 一种多媒体广播数据传输方法、装置及***
CN101420369A (zh) * 2007-10-24 2009-04-29 华为技术有限公司 通用分组无线业务隧道协议报文传输方法、***及设备
CN101202920A (zh) * 2007-12-19 2008-06-18 北京创毅视讯科技有限公司 一种广播***中的数据发送、传输方法、发射***和终端
US20110249660A1 (en) * 2010-04-08 2011-10-13 Lg Electronics Inc. Method for transmitting ppdu in wireless local area network and apparatus for the same
CN108353035A (zh) * 2015-10-28 2018-07-31 微软技术许可有限责任公司 多路复用数据

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112104589A (zh) * 2019-06-18 2020-12-18 成都鼎桥通信技术有限公司 一种宽窄融合的端到端加密方法
CN112104589B (zh) * 2019-06-18 2022-06-21 成都鼎桥通信技术有限公司 一种宽窄融合的端到端加密方法
CN112468887A (zh) * 2019-09-06 2021-03-09 杭州海康微影传感科技有限公司 热成像数据的传输方法、装置及热成像设备
CN110768864A (zh) * 2019-10-16 2020-02-07 北京科技大学 一种网络流量批量生成图像的方法及装置
WO2021179307A1 (zh) * 2020-03-13 2021-09-16 华为技术有限公司 传输流ts的处理方法、装置和***
CN115211127A (zh) * 2020-03-13 2022-10-18 华为技术有限公司 传输流ts的处理方法、装置和***

Similar Documents

Publication Publication Date Title
CN109617891A (zh) 码流传输方法及装置
CN1859579B (zh) 传输多媒体数据流的设备和方法
CN102546081B (zh) 丢包检测方法、***和媒体客户端
US9100180B2 (en) Method, device and communication system for retransmission based on forward error correction
TWI401918B (zh) 傳送指示接收器緩衝架構之緩衝參數信號的通訊方法
CN108809893B (zh) 一种视频质量评估方法和设备
CN103650431B (zh) 视频数据传输方法及装置
KR20190045117A (ko) 오버헤드를 최소화한 헤더를 가지는 패킷 기반의 미디어 데이터 전송 방법
RU2009134145A (ru) Снижение влияния от потерь пакетов в передачах видео
CN106341738A (zh) 流媒体网络传输的带宽计算方法、服务器端和***
CN108183774A (zh) 一种流媒体传输的前向纠错方法和***
US10498788B2 (en) Method and apparatus for transceiving data packet for transmitting and receiving multimedia data
JP2004343698A (ja) マルチメディア・ストリーミング環境におけるサーバベースのレート制御
CN104967502A (zh) 数据发送方法和装置、数据接收方法和装置
US20120110403A1 (en) Error Correction Scheme for Facsimile Over a Packet Switched Network
CN106549916A (zh) 组播传输方法、装置及***
CN104270594B (zh) 数据包发送与接收的方法及设备
CN106603192A (zh) 一种基于媒体内容的自适应fec机制
US20120151537A1 (en) Method and system for asynchronous and isochronous data transmission in a high speed video network
EP2099193A1 (en) Data transport container for transferring data in a high speed internet protocol network
CN101521813A (zh) 一种处理媒体流的方法和装置
CN105635802A (zh) 一种数字媒体数据的传输方法及装置
CN103339930A (zh) 合作媒体***中管理多个终端设备上内容分配的方法和装置
US8270312B2 (en) Communication system, communication method, communication device, and program
EP1802120A2 (en) Information presentation device and method

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20190412

RJ01 Rejection of invention patent application after publication