CN110278195B - 一种基于视联网的数据传输方法和装置 - Google Patents

一种基于视联网的数据传输方法和装置 Download PDF

Info

Publication number
CN110278195B
CN110278195B CN201910434866.6A CN201910434866A CN110278195B CN 110278195 B CN110278195 B CN 110278195B CN 201910434866 A CN201910434866 A CN 201910434866A CN 110278195 B CN110278195 B CN 110278195B
Authority
CN
China
Prior art keywords
data
video
rtp
video networking
sending
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.)
Active
Application number
CN201910434866.6A
Other languages
English (en)
Other versions
CN110278195A (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.)
Hainan Qiantang Shilian Information Technology Co.,Ltd.
Original Assignee
Visionvera Information 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 Visionvera Information Technology Co Ltd filed Critical Visionvera Information Technology Co Ltd
Priority to CN201910434866.6A priority Critical patent/CN110278195B/zh
Publication of CN110278195A publication Critical patent/CN110278195A/zh
Application granted granted Critical
Publication of CN110278195B publication Critical patent/CN110278195B/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/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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • 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
    • 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/233—Processing of audio elementary streams
    • H04N21/2335—Processing of audio elementary streams involving reformatting operations of audio signals, e.g. by converting from one coding standard to another
    • 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/439—Processing of audio elementary streams
    • H04N21/4398—Processing of audio elementary streams involving reformatting operations of audio signals
    • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种基于视联网的数据传输方法，所述视联网包括视联网服务器、数据发送端及数据接收端；所述数据发送端配置有与所述数据发送端的内存相匹配的RTP协议层；所述方法包括：数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；将各所述RTP数据包传输至所述视联网协议层，以将各所述RTP数据包封装为符合视联网协议的视联网数据包；根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；基于所述发送时长，将各所述视联网数据包经由所述视联网服务器发送至数据接收端。本申请实现了降低数据发送端的硬件成本的目的。

Description

一种基于视联网的数据传输方法和装置
技术领域
本申请涉及数据处理技术领域，特别是涉及一种基于视联网的数据传输方法以及装置。
背景技术
视联网是网络发展的重要里程碑，是一个实时网络，能够实现高清视频实时传输，将众多互联网应用推向高清视频化，高清面对面。
视联网采用实时高清视频交换技术，可以在一个网络平台上将所需的服务，如高清视频会议、视频监控、智能化监控分析、应急指挥、数字广播电视、延时电视、网络教学、现场直播、VOD点播、电视邮件、个性录制(PVR)、内网(自办)频道、智能化视频播控、信息发布等数十种视频、语音、图片、文字、通讯、数据等服务全部整合在一个系统平台，通过电视或电脑实现高清品质视频播放。
目前，采用现有的RTP(Real-time Transport Protocol，实时传输协议)协议传输音视频数据时，往往需要操作性能好的操作系统的支持，对软件和硬件的要求高，这样提高了视联网中设备的成本。
申请内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于视联网的数据传输方法，以及一种基于视联网的数据传输装置。
为了解决上述问题，本申请实施例公开了一种基于视联网的数据传输方法，所述视联网包括视联网服务器，与所述视联网服务器分别通信连接的数据发送端及数据接收端；所述数据发送端配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的实时传输协议RTP协议层，所述RTP协议层与所述数据发送端的内存相匹配；所述方法包括：
所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；
所述数据发送端将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包；
所述数据发送端根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；
所述数据发送端基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器；
所述数据接收端接收所述视联网服务器转发的各所述视联网数据包，将各所述视联网数据包还原为所述RTP数据包。
可选地，所述预置的协议栈接口为轻型LWIP协议栈接口或UIP协议栈接口。
可选地，所述数据发送端根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长，包括：
所述数据发送端计算所述视联网数据包的大小与所述音视频数据的码率的比值，将所述比值确定为所述发送时长。
可选地，所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包的步骤，包括：
所述数据发送端根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期；所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
可选地，所述数据接收端配置有所述RTP协议层；所述将各所述视联网数据包还原为所述RTP数据包，包括：
所述数据接收端采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，并采用所述RTP协议层从所述RTP数据包中解析出音视频数据；
所述数据接收端对所述音视频数据进行解码，并播放解码后的音视频数据。
为了解决上述问题，本申请实施例还公开了一种基于视联网的数据传输装置，所述视联网包括视联网服务器，与所述视联网服务器连接的数据发送端及数据接收端；所述装置包括位于所述数据发送端的发送模块，所述发送模块配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的RTP协议层，所述预设的RTP协议层与所述数据发送端的内存相匹配；所述发送模块包括：
RTP封装单元，用于将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；
视联网数据包封装单元，用于将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包；
发送时长确定单元，用于根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；
发送单元，用于基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器；所述视联网服务器用于将各所述视联网数据包发送至所述数据接收端，所述数据接收端用于将各所述视联网数据包还原为所述RTP数据包。
可选地，所述预置的协议栈接口为轻型LWIP协议栈接口或UIP协议栈接口。
可选地，所述RTP封装单元，包括：
打包周期确定子单元，用于根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期；所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
可选地，所述发送时长确定单元具体用于计算所述视联网数据包的大小与所述音视频数据的码率的比值，将所述比值确定为所述发送时长。
可选地，所述装置还包括位于所述数据接收端的接收模块，所述接收模块配置有所述RTP协议层；
所述接收模块包括：
第一解析单元，用于采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，
第二解析单元，用于采用所述RTP协议层从所述RTP数据包中解析出音视频数据；
播放单元，用于对所述音视频数据进行解码，并播放解码后的音视频数据。
本申请实施例包括以下优点：
在本申请实施例中，数据发送端中预设的RTP协议层与自身的内存相匹配，数据发送端在将采集到的音视频数据发送至RTP协议层进行封装时，RTP协议层可以仅调用预置的协议栈接口去完成多个RTP数据包的封包，在封装RTP数据包的的过程中，可以不用调用过多的协议栈接口，这样，降低了RTP协议层的内存空间占用，进而降低了对数据发送端的内存要求和系统要求，降低了数据发送端的硬件成本。进一步地，数据发送端根据音视频数据的码率和视联网数据包的大小，确定发送视联网数据包的发送时长，使得发送各个视联网数据包的时长动态变化，这样，可以使得数据发送端在一毫秒内发送的数据量稳定，网络带宽的占用也稳定，提高了视联网数据包的发送稳定性。
进一步，数据发送端在动态调整各个视联网数据包的发送时长时，数据接收端也不用耗费大量内存去缓存来不及解码的视联网数据包，因此可以降低数据接收端的内存占用率，保证数据接收端的解码性能。
进一步，数据接收端配置与数据发送端一致的RTP协议层，可以进一步降低对数据接收端的内存要求，进而从整体上降低在视联网内进行音视频数据传输时的设备成本。
附图说明
图1是本申请的一种视联网的组网示意图；
图2是本申请的一种节点服务器的硬件结构示意图；
图3是本申请的一种接入交换机的硬件结构示意图；
图4是本申请的一种以太网协转网关的硬件结构示意图；
图5是本申请实施例的一种基于视联网的数据传输方法实施例一的步骤流程图；
图6是本申请实施例的一种基于视联网的数据传输方法实施例一的具体实例的步骤流程图；
图7是本申请实施例的一种视联网的数据传输装置实施例二的结构示意图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
视联网是网络发展的重要里程碑，是一个实时网络，能够实现高清视频实时传输，将众多互联网应用推向高清视频化，高清面对面。
视联网采用实时高清视频交换技术，可以在一个网络平台上将所需的服务，如高清视频会议、视频监控、智能化监控分析、应急指挥、数字广播电视、延时电视、网络教学、现场直播、VOD点播、电视邮件、个性录制(PVR)、内网(自办)频道、智能化视频播控、信息发布等数十种视频、语音、图片、文字、通讯、数据等服务全部整合在一个系统平台，通过电视或电脑实现高清品质视频播放。
为使本领域技术人员更好地理解本申请实施例，以下对视联网进行介绍：
视联网所应用的部分技术如下所述：
网络技术(NetworkTechnology)
视联网的网络技术创新改良了传统以太网(Ethernet)，以面对网络上潜在的巨大第一视频流量。不同于单纯的网络分组包交换(Packet Switching)或网络电路交换(Circuit Switching)，视联网技术采用Packet Switching满足Streaming需求。视联网技术具备分组交换的灵活、简单和低价，同时具备电路交换的品质和安全保证，实现了全网交换式虚拟电路，以及数据格式的无缝连接。
交换技术(Switching Technology)
视联网采用以太网的异步和包交换两个优点，在全兼容的前提下消除了以太网缺陷，具备全网端到端无缝连接，直通用户终端，直接承载IP数据包。用户数据在全网范围内不需任何格式转换。视联网是以太网的更高级形态，是一个实时交换平台，能够实现目前互联网无法实现的全网大规模高清视频实时传输，将众多网络视频应用推向高清化、统一化。
服务器技术(ServerTechnology)
视联网和统一视频平台上的服务器技术不同于传统意义上的服务器，它的流媒体传输是建立在面向连接的基础上，其数据处理能力与流量、通讯时间无关，单个网络层就能够包含信令及数据传输。对于语音和视频业务来说，视联网和统一视频平台流媒体处理的复杂度比数据处理简单许多，效率比传统服务器大大提高了百倍以上。
储存器技术(Storage Technology)
统一视频平台的超高速储存器技术为了适应超大容量和超大流量的媒体内容而采用了最先进的实时操作系统，将服务器指令中的节目信息映射到具体的硬盘空间，媒体内容不再经过服务器，瞬间直接送达到用户终端，用户等待一般时间小于0.2秒。最优化的扇区分布大大减少了硬盘磁头寻道的机械运动，资源消耗仅占同等级IP互联网的20％，但产生大于传统硬盘阵列3倍的并发流量，综合效率提升10倍以上。
网络安全技术(Network Security Technology)
视联网的结构性设计通过每次服务单独许可制、设备与用户数据完全隔离等方式从结构上彻底根除了困扰互联网的网络安全问题，一般不需要杀毒程序、防火墙，杜绝了黑客与病毒的攻击，为用户提供结构性的无忧安全网络。
服务创新技术(Service Innovation Technology)
统一视频平台将业务与传输融合在一起，不论是单个用户、私网用户还是一个网络的总合，都不过是一次自动连接。用户终端、机顶盒或PC直接连到统一视频平台，获得丰富多彩的各种形态的多媒体视频服务。统一视频平台采用“菜谱式”配表模式来替代传统的复杂应用编程，可以使用非常少的代码即可实现复杂的应用，实现“无限量”的新业务创新。
视联网的组网如下所述：
视联网是一种集中控制的网络结构，该网络可以是树型网、星型网、环状网等等类型，但在此基础上网络中需要有集中控制节点来控制整个网络。
如图1所示，视联网分为接入网和城域网两部分。
接入网部分的设备主要可以分为3类：节点服务器，接入交换机，终端(包括各种机顶盒、编码板、存储器等)。节点服务器与接入交换机相连，接入交换机可以与多个终端相连，并可以连接以太网。
其中，节点服务器是接入网中起集中控制功能的节点，可控制接入交换机和终端。节点服务器可直接与接入交换机相连，也可以直接与终端相连。
类似的，城域网部分的设备也可以分为3类：城域服务器，节点交换机，节点服务器。城域服务器与节点交换机相连，节点交换机可以与多个节点服务器相连。
其中，节点服务器即为接入网部分的节点服务器，即节点服务器既属于接入网部分，又属于城域网部分。
城域服务器是城域网中起集中控制功能的节点，可控制节点交换机和节点服务器。城域服务器可直接连接节点交换机，也可直接连接节点服务器。
由此可见，整个视联网络是一种分层集中控制的网络结构，而节点服务器和城域服务器下控制的网络可以是树型、星型、环状等各种结构。
形象地称，接入网部分可以组成统一视频平台(虚线圈中部分)，多个统一视频平台可以组成视联网；每个统一视频平台可以通过城域以及广域视联网互联互通。
视联网设备分类
1.1本申请实施例的视联网中的设备主要可以分为3类：服务器，交换机(包括以太网协转网关)，终端(包括各种机顶盒，编码板，存储器等)。视联网整体上可以分为城域网(或者国家网、全球网等)和接入网。
1.2其中接入网部分的设备主要可以分为3类：节点服务器，接入交换机(包括以太网协转网关)，终端(包括各种机顶盒，编码板，存储器等)。
各接入网设备的具体硬件结构为：
节点服务器：
如图2所示，主要包括网络接口模块201、交换引擎模块202、CPU模块203、磁盘阵列模块204；
其中，网络接口模块201，CPU模块203、磁盘阵列模块204进来的包均进入交换引擎模块202；交换引擎模块202对进来的包进行查地址表205的操作，从而获得包的导向信息；并根据包的导向信息把该包存入对应的包缓存器206的队列；如果包缓存器206的队列接近满，则丢弃；交换引擎模块202轮询所有包缓存器队列，如果满足以下条件进行转发：1)该端口发送缓存未满；2)该队列包计数器大于零。磁盘阵列模块204主要实现对硬盘的控制，包括对硬盘的初始化、读写等操作；CPU模块203主要负责与接入交换机、终端(图中未示出)之间的协议处理，对地址表205(包括下行协议包地址表、上行协议包地址表、数据包地址表)的配置，以及，对磁盘阵列模块204的配置。
接入交换机：
如图3所示，主要包括网络接口模块(下行网络接口模块301、上行网络接口模块302)、交换引擎模块303和CPU模块304；
其中，下行网络接口模块301进来的包(上行数据)进入包检测模块305；包检测模块305检测包的目地地址(DA)、源地址(SA)、数据包类型及包长度是否符合要求，如果符合，则分配相应的流标识符(stream-id)，并进入交换引擎模块303，否则丢弃；上行网络接口模块302进来的包(下行数据)进入交换引擎模块303；CPU模块304进来的数据包进入交换引擎模块303；交换引擎模块303对进来的包进行查地址表306的操作，从而获得包的导向信息；如果进入交换引擎模块303的包是下行网络接口往上行网络接口去的，则结合流标识符(stream-id)把该包存入对应的包缓存器307的队列；如果该包缓存器307的队列接近满，则丢弃；如果进入交换引擎模块303的包不是下行网络接口往上行网络接口去的，则根据包的导向信息，把该数据包存入对应的包缓存器307的队列；如果该包缓存器307的队列接近满，则丢弃。
交换引擎模块303轮询所有包缓存器队列，可以包括两种情形：
如果该队列是下行网络接口往上行网络接口去的，则满足以下条件进行转发：1)该端口发送缓存未满；2)该队列包计数器大于零；3)获得码率控制模块产生的令牌；
如果该队列不是下行网络接口往上行网络接口去的，则满足以下条件进行转发：1)该端口发送缓存未满；2)该队列包计数器大于零。
码率控制模块308是由CPU模块304来配置的，在可编程的间隔内对所有下行网络接口往上行网络接口去的包缓存器队列产生令牌，用以控制上行转发的码率。
CPU模块304主要负责与节点服务器之间的协议处理，对地址表306的配置，以及，对码率控制模块308的配置。
以太网协转网关：
如图4所示，主要包括网络接口模块(下行网络接口模块401、上行网络接口模块402)、交换引擎模块403、CPU模块404、包检测模块405、码率控制模块408、地址表406、包缓存器407和MAC添加模块409、MAC删除模块410。
其中，下行网络接口模块401进来的数据包进入包检测模块405；包检测模块405检测数据包的以太网MAC DA、以太网MAC SA、以太网length or frame type、视联网目地地址DA、视联网源地址SA、视联网数据包类型及包长度是否符合要求，如果符合则分配相应的流标识符(stream-id)；然后，由MAC删除模块410减去MAC DA、MAC SA、length or frame type(2byte)，并进入相应的接收缓存，否则丢弃；
下行网络接口模块401检测该端口的发送缓存，如果有包则根据包的视联网目地地址DA获知对应的终端的以太网MAC DA，添加终端的以太网MAC DA、以太网协转网关的MACSA、以太网length or frame type，并发送。
以太网协转网关中其他模块的功能与接入交换机类似。
终端：
主要包括网络接口模块、业务处理模块和CPU模块；例如，机顶盒主要包括网络接口模块、视音频编解码引擎模块、CPU模块；编码板主要包括网络接口模块、视音频编码引擎模块、CPU模块；存储器主要包括网络接口模块、CPU模块和磁盘阵列模块。
1.3城域网部分的设备主要可以分为2类：节点服务器，节点交换机，城域服务器。其中，节点交换机主要包括网络接口模块、交换引擎模块和CPU模块；城域服务器主要包括网络接口模块、交换引擎模块和CPU模块构成。
2、视联网数据包定义
2.1接入网数据包定义
接入网的数据包主要包括以下几部分：目的地址(DA)、源地址(SA)、保留字节、payload(PDU)、CRC。
如下表所示，接入网的数据包主要包括以下几部分：
DA SA Reserved Payload CRC
其中：
目的地址(DA)由8个字节(byte)组成，第一个字节表示数据包的类型(例如各种协议包、组播数据包、单播数据包等)，最多有256种可能，第二字节到第六字节为城域网地址，第七、第八字节为接入网地址；
源地址(SA)也是由8个字节(byte)组成，定义与目的地址(DA)相同；
保留字节由2个字节组成；
payload部分根据不同的数据报的类型有不同的长度，如果是各种协议包的话是64个字节，如果是单组播数据包话是32+1024＝1056个字节，当然并不仅仅限于以上2种；
CRC有4个字节组成，其计算方法遵循标准的以太网CRC算法。
2.2城域网数据包定义
城域网的拓扑是图型，两个设备之间可能有2种、甚至2种以上的连接，即节点交换机和节点服务器、节点交换机和节点交换机、节点交换机和节点服务器之间都可能超过2种连接。但是，城域网设备的城域网地址却是唯一的，为了精确描述城域网设备之间的连接关系，在本申请实施例中引入参数：标签，来唯一描述一个城域网设备。
本说明书中标签的定义和MPLS(Multi-Protocol Label Switch，多协议标签交换)的标签的定义类似，假设设备A和设备B之间有两个连接，那么数据包从设备A到设备B就有2个标签，数据包从设备B到设备A也有2个标签。标签分入标签、出标签，假设数据包进入设备A的标签(入标签)是0x0000，这个数据包离开设备A时的标签(出标签)可能就变成了0x0001。城域网的入网流程是集中控制下的入网过程，也就意味着城域网的地址分配、标签分配都是由城域服务器主导的，节点交换机、节点服务器都是被动的执行而已，这一点与MPLS的标签分配是不同的，MPLS的标签分配是交换机、服务器互相协商的结果。
如下表所示，城域网的数据包主要包括以下几部分：
DA SA Reserved 标签 Payload CRC
即目的地址(DA)、源地址(SA)、保留字节(Reserved)、标签、payload(PDU)、CRC。其中，标签的格式可以参考如下定义：标签是32bit，其中高16bit保留，只用低16bit，它的位置是在数据包的保留字节和payload之间。
基于视联网的上述特性，提出了本申请实施例的核心构思之一，在数据发送端配置与数据发送端自身内存相匹配的RTP协议层，数据发送端将采集到的音视频数据发送至RTP协议层，将音视频数据封装为多个RTP数据包，之后将RTP数据包封装为视联网数据包后，发送至数据接收端。使得数据发送端可以采用与自身内存相适配的RTP协议层封装RTP数据包，而不用采用现有的RTP协议去封装RTP协议层，避免采用现有的RTP协议去封装RTP数据包时，需要内存和系统配置高的设备，从而可以降低在视联网中传输音视频数据时的设备成本。
实施例一
参考图5，示出了本申请实施例一的一种基于视联网的数据传输方法的实施例一的步骤流程图，所述视联网可以包括视联网服务器，与所述视联网服务器分别通信连接的数据发送端及数据接收端；所述数据发送端配置有视联网协议栈，所述视联网协议栈可以包括视联网协议层及预设的实时传输协议RTP协议层，所述RTP协议层与所述数据发送端的内存相匹配。
本申请实施例中，视联网协议栈是视联网中用于进行数据传输的通信协议，可以包括视联网协议层和RTP协议层。其中，视联网协议层是基于链路层传输的协议层，通过视联网协议层，可以使得数据在二层网络中传输，而不用在IP网络中传输，因此，在视联网中传输时，可以不用IP地址寻址。又基于视联网的特性，其视联网服务器采用了如上所述的服务器技术和存储器技术，因此，在视联网中传输数据时，特别是音视频数据时，可以极大提高音视频数据的传输速度。
其中，RTP协议层与数据发送端的内存相匹配，实际中，可以与数据发送端的ROM或RAM的存储空间相匹配，数据发送端的内存很小，则预设的RTP协议层的库文件较小，因此，RTP协议层占用的内存空间也较小。具体而言，在配置时，可以通过取消预设的RTP协议层中的多个接口调用以减小库文件的大小，如，可以取消随机生成函数rand的接口调用、套接字监听函数select的接口调用；即在RTP协议层中可以不包含上述rand的接口调用及select的接口调用的文件，因此，可以减少RTP协议层所占用的内存空间，进而可以降低对数据发送端的内存占用，使得数据发送端可以不用配置较高的内存来满足现有的RTP协议层，因此，可以降低数据发送端的设备成本。
本申请实施例中，数据发送端可以是但不限于智能盒子、台式电脑、笔记本、平板电脑、手机、摄像机、智能手环等等。数据接收端也可以是但不限于智能盒子、台式电脑、笔记本、平板电脑、手机、摄像机、智能手环等等。
本申请实施例所述的方法，具体可以包括如下步骤：
步骤501，所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包。
本申请实施例中，数据发送端可以采集音视频数据，并可以将采集的音视频数据编码后发送至视联网协议栈，进而视联网协议栈可以将编码后的音视频数据交予RTP协议层，由RTP协议层将音视频数据封装为RTP协议的音视频数据。实际中，RTP协议层可以在将与音视频数据封装为多个RTP数据包的过程中，可以通过调用预置的协议栈接口完成对音视频数据的RTP协议封装。实际中，多个RTP数据包均包括音视频数据的帧率信息和码率信息。
其中，预置的协议栈接口可以是轻型LWIP协议栈接口或UIP协议栈接口，调用LWIP协议栈接口时，可以在保持RTP协议主要功能的基础上减少对RAM的占用，LWIP协议栈接口只需十几KB的RAM和40K左右的ROM就可以运行。本申请实施例中，RTP协议层在调用LWIP协议栈接口或UIP协议栈接口时，并不包括LWIP协议栈接口或UIP协议栈中IP协议的接口调用部分，使得通过LWIP协议栈接口或UIP协议栈接口封装RTP数据包时，可以进一步降低对数据发送端的内存占用。
步骤502，所述数据发送端将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包。
本申请实施例中，数据发送端可以将各个RTP数据包传输至视联网协议层，视联网协议层可以为各个RTP数据包添加视联网协议包头，进而得到视联网数据包，添加的视联网协议包头中可以包括数据发送端的设备号码和MAC地址，以及，数据接收端的设备号码和MAC地址。
步骤503，所述数据发送端根据所述音视频数据的码率和各视联网数据包的大小，确定发送各所述视联网数据包的发送时长。
本申请实施例中，码率可以理解为音视频数据的取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件。实际中，数据发送端可以根据音视频数据的码率，确定各个视联网数据包的发送时长。因各个RTP数据包的码率都一致，因此，各个视联网数据包的码率一致，实际中，数据发送端可以将视联网数据包的大小与码率的比值作为发送时长，如，码率为2400kbps，即一秒内发送2400kb的音视频数据，各个视联网数据包的大小分别为600kb、800kb，400kb，600kb，则各视联网数据包的发送时长分别是0.25s，0.33s，0.16s，0.25s。
本申请实施例中，数据发送端根据音视频数据的码率和视联网数据包的大小，确定了发送时长后，使得发送每个视联网数据包的时间可以不一样。
步骤504，所述数据发送端基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器。
本申请实施例中，数据发送端按照各个视联网数据包各自的发送时长，将各个视联网数据包发送至视联网服务器。如，以码率为2400kbps，各个视联网数据包的大小分别为600kb、800kb，400kb，600kb，各视联网数据包的发送时长分别是0.25s，0.33s，0.16s，0.25s为例，数据发送端在发送600kb的视联网数据包时，发送的时长为0.25s，即用0.25s的时间完成该600kb视联网数据包的发送，同理，发送800kb的视联网数据包时，发送的时长为0.33s，以此类推其他视联网数据包。这样，视联网数据包越大，发送完该视联网数据包的时间越长。而若采用等时长发送各个视联网数据包，以上述例子为例，则各视联网数据包的发送时长均为0.25s，使得较大的视联网数据包每一毫秒传输的数据量大，进而使得发送过程中，占用的网络带宽随时发生变化，会产生数据发送的稳定性很低的问题。
因此，相比于等时长地发送各视联网数据包，本申请实施例可以在保证码率不变的情况下，动态调整各个视联网数据包的发送时长，使得数据发送端每一毫秒内发送的数据量保持不变，提高视联网数据包的发送稳定性。并且，也可以避免数据发送端仍然保持均等时长发送各个视联网数据包时，数据接收端对接收到的较大的视联网数据音视频数据解码时间较长，而必须耗费大量内存对来不及解码的音视频数据进行缓存的问题。因此，动态调整各个视联网数据包的发送时长，也可以进一步降低数据接收端的内存占用率。
步骤505，所述数据接收端接收所述视联网服务器转发的各所述视联网数据包，将各所述视联网数据包还原为所述RTP数据包。
本申请实施例中，视联网服务器为视联网中进行音视频数据转发的服务器，在视联网服务器接收到视联网数据包时，可以根据视联网数据包的视联网协议包头中的数据接收端的设备号码和MAC地址，将视联网数据包发送至数据接收端。数据接收端接收到视联网服务器转发的视联网数据包时，可以通过视联网协议解析出其中的RTP数据包，具体地，可以采用视联网协议去掉视联网数据包的视联网协议包头，然后得到其中的RTP数据包，之后，便可以对RTP数据包依次进行解码后播放。
实际中，因预置的RTP协议中去掉了一些非必须的接口调用，这样，数据接收端在采用现有的RTP协议去解析数据发送端发送过来的RTP数据包时，因封装RTP数据包时，并没有用到一些系统调用接口，如，套接字监听函数select的接口，则数据接收端在采用现有的RTP协议解析RTP数据包时，也不会调用套接字监听函数select的接口，这样，在解析RTP数据包时，可以降低对数据接收端的系统的要求。
本申请实施例中，通过预设的RTP协议层减小了库文件大小以适应数据发送端的内存，因此在数据发送端发送音视频数据时，可以采用该预设的RTP协议层完成RTP数据包的封装，从而可以使得在数据发送端配置不高的情况下，也能完成音视频数据的发送，避免采用现有的RTP协议时，必须在数据发送端具有较高内存和高系统配置的情况下，才能发送音视频数据的问题，因此，降低了数据发送端的成本。
进一步，数据发送端将视联网数据包的大小与音视频数据的码率的比值作为发送各所述视联网数据包的发送时长，使得数据发送端发送各视联网数据包的时长是动态变化的，使得视联网数据包越大，发送时长越长，这样，数据发送端一毫秒内发送的数据量稳定，网络带宽的占用也稳定，提高了视联网数据包的发送稳定性，因端一毫秒内发送的数据量稳定，因此，也可以保证数据发送端的设备性能。并且，数据接收端也不用耗费大量内存去缓存来不及解码的视联网数据包，因此可以降低数据接收端的内存占用率，保证数据接收端的解码性能。
本申请实施例还提供了一种基于视联网的数据传输方法，所述视联网包括视联网服务器，与所述视联网服务器分别通信连接的数据发送端及数据接收端；所述数据发送端配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的实时传输协议RTP协议层，所述RTP协议层与所述数据发送端的内存相匹配。
本申请实施例中，根据数据发送端的内存配置预设的RTP协议层时，可以根据数据发送端的内存条型号和大小配置，例如，数据发送端采用的是单片机，在单片机上运行的是μCOS(Micro-Controller Operating System，实时多任务操作系统)操作系统，则配置到该数据发送端的RTP协议层可以是基于LWIP协议栈编写的协议层，因LWIP协议栈占用的内存很小，因此可以在该数据发送端上运行，该RTP协议层还可以去掉一些不必要的接口调用，例如，可以去掉现有RTP协议中套接字监听函数select的接口调用，和/或随机生成函数rand的接口调用，这样，可以进一步降低RTP协议层的库文件大小，使得RTP协议层可以在运行μCOS操作系统的单片机上运行。
所述方法可以包括以下步骤：
步骤601，所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包。
本申请实施例中，因数据发送端位于视联网内，需要将RTP数据包在视联网内传输，因此，基于LWIP协议栈编写的RTP协议层并不包括LWIP协议栈中的IP协议部分，得到的多个RTP数据包需要进一步发送至视联网协议层进行视联网协议封装。
作为本申请实施例的一种可选示例，步骤601具体可以是以下步骤601’。
步骤601’，所述数据发送端根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期，所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
本申请实施例中，数据发送端在对音视频数据进行封装得到多个RTP数据包时，还可以根据音视频数据的码率，确定打包周期。具体而言，可以根据预置的打包周期对照表确定，该打包周期确定表中包括码率范围与打包周期的对应关系，实际中，可以设置该打包周期对照表的码率越大，对应的打包周期越短，即打包周期的长短与码率的大小成正比。则RTP协议层可以按照打包周期将音视频数据封装为多个RTP数据包，因码率越大，打包周期越短，则封装后形成的RTP数据包的个数越多，因对于同一个音视频数据，码率保持不变，这样，按照打包周期封装得到的各个RTP数据包的大小可以保持一致。此种情况下，使得数据发送端中待发送的各个RTP数据包便具有相同的大小。
如，音视频数据的码率是2400kbps，通过打包周期对照表，确定2400kbps所述的码率范围为2000kbps-3000kbps，2000kbps-3000kbps对应的打包周期为40ms，则每间隔40ms封装一个RTP数据包，因码率一致，则1秒内封装的RTP数据包个数为25个，每个RTP数据包的大小均为96kb(2400kbps/25)。
再如，音视频数据的码率是4500kbps，通过打包周期对照表，确定4500kbps所述的码率范围为4000kbps-5000kbps，4000kbps-5000kbps对应的打包周期为20ms，则每间隔20ms封装一个RTP数据包，因码率一致，则1秒内封装的RTP数据包个数为45个，每个RTP数据包的大小均为100kb(4500kbps/45)。
由上述例子可知，码率越大，打包周期越短，RTP数据包的个数越多，而RTP数据包的大小可以动态保持平衡。
步骤602，所述数据发送端将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包。
本步骤602与步骤502类似，在此不再赘述。
步骤603，所述数据发送端根据所述音视频数据的码率和各视联网数据包的大小，确定发送各所述视联网数据包的发送时长。
本申请实施例中，因数据发送端得到的各个RTP数据包大小可以一致，因此，在数据发送端中的各视联网数据包的大小也一致，则确定出的各个视联网数据包的发送时长也可以均等，使得数据发送端中各个视联网数据包不仅大小一致，发送各视联网数据包的时长也一致，这样，更加保证了数据发送端发送视联网数据包的发送稳定性。
如，以音视频数据的码率是2400kbps，打包周期为40ms，1秒内封装了25个RTP数据包为例，每个RTP数据包的大小均为96kb，封装后的各个视联网数据包为100kb，则发送每一个视联网数据包的时长为1/24s，实现了等时间间隔发送各个相同大小的视联网数据包。
步骤604，所述数据发送端基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器。
本步骤604与步骤504类似，在此不再赘述。
步骤605，所述数据接收端接收所述视联网服务器转发的各所述视联网数据包，将各所述视联网数据包还原为所述RTP数据包。
本申请实施例中，因数据发送端发送的各个视联网数据包的大小一致，发送时长也均等，则数据接收端接收到的视联网数据包的大小也一致，并且，码率越大，打包周期越短，得到的视联网数据包越多，使得每个视联网数据包也就相对越小，这样，在解码时，数据接收端对各个RTP数据包的解码时长波动也不大，可以提高解码的匀速性，使得播放后的音视频更为流畅，而不发生卡顿，同时，数据接收端也不必为来不及解码的视联网数据包分配较大的缓存空间，因此，可以进一步降低数据接收端的内存占用率。
作为本申请实施例的一种可选示例，所述数据接收端配置有所述RTP协议层；步骤605具体可以是以下子步骤：
子步骤6051，所述数据接收端采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，并采用所述RTP协议层从所述RTP数据包中解析出音视频数据。
本申请实施例中，数据接收端中也可以配置与数据发送端一致的RTP协议层，因预设的RTP协议层的库文件较小，则占用的数据接收端的内存空间较小，因此，可以进一步降低数据接收端的硬件成本，从整体上又进一步降低了在视联网中传输音视频数据时的设备成本。
实际中，数据接收端可以采用所述RTP协议层解析出RTP数据包中净载的原始音视频数据。
子步骤6052，所述数据接收端对所述音视频数据进行解码，并播放解码后的音视频数据。
本申请实施例中，数据接收端可以对解析出的该原始音视频数据进行解码后播放，具体而言，数据接收端可以采用预置的编解码器对该音视频数据进行解码后播放。
本申请实施例中，数据发送端在封装RTP数据包时，根据音视频数据的码率确定打包周期，使得码率越大，打包周期越短，进而得到的RTP数据包个数越多，使得码率变化时，各个RTP数据包的大小仍然可以保持动态平衡，这样，可以提高数据发送端发送各个RTP数据包的稳定性，并且，在数据接收端对各个RTP数据的解码时间也保持了均等，使得播放后的音视频数据更加流畅，提高了用户体验。
进一步，在数据接收端配置与数据发送端一致的RTP协议层时，可以进一步降低对数据接收端的内存要求，进而可以降低数据接收端的设备成本。
参照图6所示，示出了本发明的一种基于视联网的数据传输方法的步骤流程图，该实施例为一具体的应用实例，其中，所述视联网包括视联网服务器，与所述视联网服务器分别通信连接的数据发送端及数据接收端；所述数据发送端为智能手表，数据接收端为智能手环。
其中，智能手表上安装有微型录像机，其安装的单片机型号为8051系列单片机，单片机上安装的系统为μCOS；在智能手表上配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的实时传输协议RTP协议层，所述RTP协议层与所述数据发送端的内存相匹配；所述预设的RTP协议层调用的协议栈接口为LWIP协议栈接口，并不包括随机生成函数rand的接口调用的文件、套接字监听函数select的接口调用的文件。因此，预设的RTP协议层的库文件占用的内存很小，只需30Kb左右的内存便能运行，因此，适合在8051系列单片上使用，进而可以在智能手表上进行音视频数据的RTP协议的传输。智能手环上也配置有上述的RTP协议层。
本实例中，智能手环和智能手表均先到视联网服务器中注册，注册成功后，获取到自身在视联网中的设备号码，该设备号码可以是11位数字编码，如，10221251232。
所述方法包括以下步骤：
步骤701，所述智能手表将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包。
智能手表的录像机将采集到的音视频数据传输至视联网协议栈，视联网协议栈中的RTP协议层调用LWIP协议栈接口将音视频数据封装为多个RTP数据包。
步骤702，所述智能手表将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包。
智能手表采用视联网协议层为各所述RTP数据包添加视联网协议包头，该视联网协议包头包括了智能手环的MAC地址和设备号码，以及自身的MAC地址和设备号码。
步骤703，所述智能手表根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长。
智能手表计算各视联网数据包的大小与音视频数据的码率的比值，将所述比值确定为发送时长。
步骤704，所述智能手表基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器。
智能手表按照确定好的各视联网数据包的发送时长，依次将各视联网数据包发送到视联网服务器。视联网服务器可以根据视联网数据包中智能手环的MAC地址和设备号码，将视联网数据包转发至智能手环。
步骤705，所述智能手环接收所述视联网服务器转发的各所述视联网数据包，将各所述视联网数据包还原为所述RTP数据包。
智能手环在接收到视联网数据包时，可以采用视联网协议将视联网数据包的视联网协议包头去掉，获取到RTP数据包，再采用所述的RTP协议层对各个RTP数据包进行解析得到原始的音视频数据，进而可以对原始的音视频数据进行播放。具体地，智能手环可以采用配置的MP4播放器播放音视频数据。
通过本申请实例的方法，使得视联网内的智能手表能通过配置的简单的单片机实现对音视频数据的RTP协议的封装，进而可以实现智能手表在视联网内传输音视频数据，而避免了以往在视联网内传输RTP协议的音视频数据时，要求设备必须具备较高的内存的问题，进而实现了在视联网内可以进行低端配置设备之间的音视频数据的实时传输，增加了实时音视频数据传输的适应性。并且，利用视联网的特性，可以使得智能手表的音视频数据能得到较快传输。
进一步，智能手表根据视联网数据包的大小和码率确定每个视联网数据包的发送时长，使得发送时长与视联网数据包的大小成正比，使得智能手表在发送每个视联网数据时，其发送的速率保持不变，网络带宽的占用率维持稳定，因此提高了音视频数据的发送稳定性。此外，在智能手环端，接收每一个视联网数据包的速率也维持不变，这样，可以更加平稳的解码，相对于等时间间隔地接受各个大小不一的视联网数据包，智能手环不用分配较大的存储空间缓存音视频数据，这样也能保证智能手环的性能。并且，智能手环也采用预设的RTP协议层，也使得RTP协议层的内存占用小，从而降低了智能手环的成本。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
实施例二
参考图7，示出了本申请实施例的一种基于视联网的数据传输装置，所述视联网包括视联网服务器，与所述视联网服务器连接的数据发送端及数据接收端；所述装置包括位于所述数据发送端的发送模块801，所述发送模块801配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的RTP协议层，所述预设的RTP协议层与所述数据发送端的内存相匹配；所述发送模块801包括：
RTP封装单元8011，用于将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；
视联网数据包封装单元8012，用于将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包；
发送时长确定单元8013，用于根据所述音视频数据的码率和各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；
发送单元8014，用于基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器；所述视联网服务器用于将各所述视联网数据包发送至所述数据接收端，所述数据接收端用于将各所述视联网数据包还原为所述RTP数据包。
作为本申请实施例的一种可选示例，所述预置的协议栈接口为轻型LWIP协议栈接口或UIP协议栈接口。
作为本申请实施例的一种可选示例，所述RTP封装单元，包括：
打包周期确定子单元8015，用于根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期；所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
作为本申请实施例的一种可选示例，所述发送时长确定单元具体用于计算所述视联网数据包的大小与所述音视频数据的码率的比值，将所述比值确定为所述发送时长。
作为本申请实施例的一种可选示例，所述装置还包括位于所述数据接收端的接收模块802，所述接收模块802配置有所述RTP协议层；
所述接收模块802包括：
第一解析单元8021，用于采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，
第二解析单元8022，用于采用所述RTP协议层从所述RTP数据包中解析出音视频数据；
播放单元8023，用于对所述音视频数据进行解码，并播放解码后的音视频数据。
对于一种基于视联网的数据传输装置实施例而言，由于其与基于视联网的数据传输方法实施例一基本相似，所以描述的比较简单，相关之处参见一种基于视联网的数据传输方法实施例一的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种基于视联网的数据传输方法方法和一种基于视联网的数据传输装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种基于视联网的数据传输方法，其特征在于，所述视联网包括视联网服务器，与所述视联网服务器分别通信连接的数据发送端及数据接收端；所述数据发送端配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的实时传输协议RTP协议层，所述RTP协议层与所述数据发送端的内存相匹配；所述方法包括：
所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；
所述数据发送端将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包；
所述数据发送端根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；
所述数据发送端基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器；
所述数据接收端接收所述视联网服务器转发的各所述视联网数据包，将各所述视联网数据包还原为所述RTP数据包。
2.根据权利要求1所述的方法，其特征在于，所述预置的协议栈接口为轻型LWIP协议栈接口或UIP协议栈接口。
3.根据权利要求1所述的方法，其特征在于，所述数据发送端根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长，包括：
所述数据发送端计算所述视联网数据包的大小与所述音视频数据的码率的比值，将所述比值确定为所述发送时长。
4.根据权利要求1或3所述的方法，其特征在于，所述数据发送端将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包的步骤，包括：
所述数据发送端根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期；所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
5.根据权利要求1所述的方法，其特征在于，所述数据接收端配置有所述RTP协议层；所述将各所述视联网数据包还原为所述RTP数据包，包括：
所述数据接收端采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，并采用所述RTP协议层从所述RTP数据包中解析出音视频数据；
所述数据接收端对所述音视频数据进行解码，并播放解码后的音视频数据。
6.一种基于视联网的数据传输装置，其特征在于，所述视联网包括视联网服务器，与所述视联网服务器连接的数据发送端及数据接收端；所述装置包括位于所述数据发送端的发送模块，所述发送模块配置有视联网协议栈，所述视联网协议栈包括视联网协议层及预设的RTP协议层，所述预设的RTP协议层与所述数据发送端的内存相匹配；所述发送模块包括：
RTP封装单元，用于将采集到的音视频数据传输至所述RTP协议层，所述RTP协议层用于调用预置的协议栈接口，将所述音视频数据封装为多个RTP数据包；
视联网数据包封装单元，用于将各所述RTP数据包传输至所述视联网协议层，并采用所述视联网协议层将各所述RTP数据包封装为符合视联网协议的视联网数据包；
发送时长确定单元，用于根据所述音视频数据的码率及各视联网数据包的大小，确定发送各所述视联网数据包的发送时长；
发送单元，用于基于所述发送时长，将各所述视联网数据包发送至所述视联网服务器；所述视联网服务器用于将各所述视联网数据包发送至所述数据接收端，所述数据接收端用于将各所述视联网数据包还原为所述RTP数据包。
7.根据权利要求6所述的装置，其特征在于，所述预置的协议栈接口为轻型LWIP协议栈接口或UIP协议栈接口。
8.根据权利要求6所述的装置，其特征在于，所述RTP封装单元，包括：
打包周期确定子单元，用于根据所述音视频数据的码率，确定所述RTP协议层封装各个RTP数据包的打包周期；所述RTP协议层具体用于调用预置的协议栈接口，并按照所述打包周期，将所述音视频数据封装为多个RTP数据包。
9.根据权利要求6所述的装置，其特征在于，所述发送时长确定单元具体用于计算所述视联网数据包的大小与所述音视频数据的码率的比值，将所述比值确定为所述发送时长。
10.根据权利要求6所述的装置，其特征在于，所述装置还包括位于所述数据接收端的接收模块，所述接收模块配置有所述RTP协议层；
所述接收模块包括：
第一解析单元，用于采用视联网协议从各所述视联网数据包中解析出所述RTP数据包，
第二解析单元，用于采用所述RTP协议层从所述RTP数据包中解析出音视频数据；
播放单元，用于对所述音视频数据进行解码，并播放解码后的音视频数据。
CN201910434866.6A 2019-05-23 2019-05-23 一种基于视联网的数据传输方法和装置 Active CN110278195B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910434866.6A CN110278195B (zh) 2019-05-23 2019-05-23 一种基于视联网的数据传输方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910434866.6A CN110278195B (zh) 2019-05-23 2019-05-23 一种基于视联网的数据传输方法和装置

Publications (2)

Publication Number Publication Date
CN110278195A CN110278195A (zh) 2019-09-24
CN110278195B true CN110278195B (zh) 2020-12-11

Family

ID=67959113

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910434866.6A Active CN110278195B (zh) 2019-05-23 2019-05-23 一种基于视联网的数据传输方法和装置

Country Status (1)

Country Link
CN (1) CN110278195B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100676064B1 (ko) * 2005-03-10 2007-01-29 엘지전자 주식회사 와이어리스 텔레비전 시스템에서 디인터레이싱 방식 선택방법
CN101833296A (zh) * 2010-05-14 2010-09-15 山东大学 一种单片机的远程通讯装置及其方法
CN106060901A (zh) * 2016-05-17 2016-10-26 深圳芯智汇科技有限公司 嵌入式无线网络系统及其接入无线网络的方法
CN107465679A (zh) * 2017-08-07 2017-12-12 郑州仁峰软件开发有限公司 一种流媒体传输控制方法
CN107682417A (zh) * 2017-09-19 2018-02-09 深圳市盛路物联通讯技术有限公司 一种数据节点的任务分配方法和装置
CN108632679A (zh) * 2017-09-07 2018-10-09 北京视联动力国际信息技术有限公司 一种多媒体数据传输的方法和一种视联网终端

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007028640A1 (de) * 2007-06-21 2008-12-24 Siemens Enterprise Communications Gmbh & Co. Kg Verfahren, Endgerät und Sprachspeicher zum Speichern von Sprachnachrichten in einem Kommunikationsnetz
CN106332155B (zh) * 2015-06-30 2020-02-11 华为技术有限公司 无线接入网设备、数据处理方法和ip报文处理方法
CN109587511A (zh) * 2018-12-24 2019-04-05 网易（杭州）网络有限公司 多设备视频直播方法、设备、系统及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100676064B1 (ko) * 2005-03-10 2007-01-29 엘지전자 주식회사 와이어리스 텔레비전 시스템에서 디인터레이싱 방식 선택방법
CN101833296A (zh) * 2010-05-14 2010-09-15 山东大学 一种单片机的远程通讯装置及其方法
CN106060901A (zh) * 2016-05-17 2016-10-26 深圳芯智汇科技有限公司 嵌入式无线网络系统及其接入无线网络的方法
CN107465679A (zh) * 2017-08-07 2017-12-12 郑州仁峰软件开发有限公司 一种流媒体传输控制方法
CN108632679A (zh) * 2017-09-07 2018-10-09 北京视联动力国际信息技术有限公司 一种多媒体数据传输的方法和一种视联网终端
CN107682417A (zh) * 2017-09-19 2018-02-09 深圳市盛路物联通讯技术有限公司 一种数据节点的任务分配方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
杨诚诚."局域网环境下TCP/IP协议栈实时性改进".《中国优秀硕士学位论文全文数据库 信息科技辑》.2014,(第3期), *

Also Published As

Publication number Publication date
CN110278195A (zh) 2019-09-24

Similar Documents

Publication Publication Date Title
CN109194982B (zh) 一种传输大文件流的方法和装置
CN110572433B (zh) 一种视频调度方法、系统及装置
CN108877820B (zh) 一种音频数据混合方法和装置
CN109547163B (zh) 一种数据传输速率的控制方法和装置
CN110460804B (zh) 会议数据发送方法、系统、设备和计算机可读存储介质
CN110166433B (zh) 一种视频数据获取的方法和系统
CN109450982B (zh) 一种网络通讯方法和系统
CN110022295B (zh) 一种数据传输的方法和视联网系统
CN108809921B (zh) 一种音频处理方法、视联网服务器和视联网终端
CN110049341B (zh) 视频处理方法和装置
CN111147859A (zh) 一种视频处理方法和装置
CN108881958B (zh) 一种多媒体数据流封装方法和装置
CN110768910A (zh) 数据传输方法和装置
CN110650147A (zh) 数据获取方法和系统
CN110830826A (zh) 视频转码设备调度方法及系统
CN110611639A (zh) 流媒体会议的音频数据处理方法和装置
CN110769297A (zh) 一种音视频数据的处理方法和系统
CN110519331B (zh) 一种视联网资源处理方法及装置
CN110336710B (zh) 一种终端的测试方法、系统及装置和存储介质
CN109842630B (zh) 视频处理方法和装置
CN110830762B (zh) 一种音视频数据的处理方法和系统
CN108965914B (zh) 一种基于视联网的视频数据处理方法及装置
CN111245733A (zh) 一种数据传输的方法和装置
CN111478880A (zh) 一种数据处理的方法和装置
CN110278195B (zh) 一种基于视联网的数据传输方法和装置

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
TR01 Transfer of patent right

Effective date of registration: 20201230

Address after: 570105 room 1201, Central International Plaza, 77 Binhai street, Longhua District, Haikou City, Hainan Province

Patentee after: Hainan Qiantang Shilian Information Technology Co.,Ltd.

Address before: 100000 Beijing Dongcheng District Qinglong Hutong 1 Song Hua Building A1103-1113

Patentee before: VISIONVERA INFORMATION TECHNOLOGY Co.,Ltd.

TR01 Transfer of patent right