CN114584538A - 移动流媒体数据传输方法、装置及存储介质 - Google Patents
移动流媒体数据传输方法、装置及存储介质 Download PDFInfo
- Publication number
- CN114584538A CN114584538A CN202210195942.4A CN202210195942A CN114584538A CN 114584538 A CN114584538 A CN 114584538A CN 202210195942 A CN202210195942 A CN 202210195942A CN 114584538 A CN114584538 A CN 114584538A
- Authority
- CN
- China
- Prior art keywords
- data
- streaming media
- data packet
- media data
- packet
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 57
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000003860 storage Methods 0.000 title claims abstract description 28
- 238000004806 packaging method and process Methods 0.000 claims abstract description 12
- 239000000872 buffer Substances 0.000 claims description 39
- 230000002457 bidirectional effect Effects 0.000 claims description 26
- 238000004590 computer program Methods 0.000 claims description 4
- 230000002829 reductive effect Effects 0.000 abstract description 3
- 230000006870 function Effects 0.000 description 26
- 230000008569 process Effects 0.000 description 12
- 230000010354 integration Effects 0.000 description 7
- 238000005538 encapsulation Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000004927 fusion Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000009432 framing Methods 0.000 description 2
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请涉及一种移动流媒体数据传输方法、装置及存储介质，移动流媒体数据传输方法包括采集流媒体数据，对流媒体数据在采集端进行本地缓存，将缓存的流媒体数据封装成多个数据包，将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据。本申请可以实现移动流媒体数据本地化存储，解决数据传输安全性问题，并且可以减少使用第三方云平台存储成本，便于流媒体数据与其他业务数据进行集成或融合。
Description
技术领域
本申请属于计算机技术领域，具体涉及一种移动流媒体数据传输方法、装置及存储介质。
背景技术
移动流媒体数据依靠互联网企业提供的云平台支撑移动流媒体的采集、传输、存储、播放等功能。移动流媒体数据包括视频直播数据和音视频通信RTC(Real-TimeCommunication，实时音视频交互)数据。视频直播数据是主播通过采集设备采集直播内容后，通过推流SDK工具推送直播流，视频直播服务通过边缘推流的方式将直播流推送至云平台直播中心，视频流推送至云平台直播中心后，可按需对视频流进行转码、时移、录制、截图等处理，处理好的视频流通过内容分发网络下发至客户端设备中进行播放。音视频通信RTC数据依托核心音视频编解码、信道传输、网络调度技术，提供高可用、高品质、超低延时的音视频通信服务，让用户快速搭建多端实时应用，适用于在线教育、视频会议、互动娱乐、音视频社交等场景。在视频直播产品的基础上实现双向语音、视频等功能。
现有移动流媒体数据传输技术中，直播数据录制端将直播视频数据和音频数据发送至云平台，由云平台封装为流媒体数据后，基于传输控制协议将流媒体数据再实时传输至流媒体服务器，后续由流媒体服务器分发至观众终端。这种传输方式需要将移动流媒体数据先上传至云平台，导致这些数据在本地无法二次使用。同时随着客户业务不断的增加和扩展，对存储空间的需求也不断提高。由于云平台属于第三方需用户购买，因此在不断扩容时，也会增加用户企业成本支出，另外，上传至云平台的数据与其他业务产品相互独立，无法进行数据集成与融合，导致无法支撑客户业务的扩展，并且，由于云平台需要通过互联网访问，随着用户对网络安全要求的不断提升，通过互联网进行数据传输也是不能满足用户需求。
发明内容
为至少在一定程度上克服现有的移动流媒体数据传输过程中需要将移动流媒体数据先上传至云平台，导致这些数据在本地无法二次使用、不便于与其他业务数据集成以及依靠互联网传输存在安全隐患的问题，本申请提供一种移动流媒体数据传输方法、装置及存储介质。
第一方面，本申请提供一种移动流媒体数据传输方法，包括：
采集流媒体数据；
对所述流媒体数据在采集端进行本地缓存；
将缓存的流媒体数据封装成多个数据包；
将所述多个数据包传输至接收端，以使所述接收端对所述数据包进行解析以获取所述流媒体数据。
进一步的，所述采集流媒体数据，包括：
分别创建音频采集线程和视频采集线程；
在所述音频采集线程中使用Android操作系统的MediaRecorder类进行音频采集；
在所述视频采集线程中使用Android操作系统的MediaRecorder类进行视频采集。
进一步的，所述采集端包括采集服务器和采集客户端，所述对所述流媒体数据在采集端进行本地缓存，包括：
在所述采集服务器的Android操作系统中定义第一采集类，在所述采集客户端的Android操作系统定义第二采集类；
在所述第一采集类中使用第一存储空间对采集到的流媒体数据进行缓存；
所述采集服务器将缓存后的流媒体数据发送至所述采集客户端；
在所述第二采集类中使用第二存储空间对所述流媒体数据进行缓存。
进一步的，所述将缓存的流媒体数据封装成多个数据包，包括：
从所述流媒体数据中剥离出每个网络抽象层单元；
在每个网络抽象层单元前添加对应的RTP包头；
将所述网络抽象层单元及其对应RTP包头封装成数据包。
进一步的，所述将所述多个数据包传输至接收端包括：
定义数据传输类数据结构，所述数据传输类数据结构包括数据包结构、数据包发送结构和缓冲区，所述缓冲区用于存储所述数据包；
所述数据包结构用于根据所述网络抽象层单元的大小设置数据包的大小；
所述数据包发送结构用于通过音频发送端口和视频发送端口发送数据包。
进一步的，所述接收端包括视频缓冲区和音频缓冲区，还包括：
所述接收端在接收到数据包后，将所述数据包缓存至所述视频缓冲区或音频缓冲区中的双向循环队列中；
双向循环队列在接收到一个数据包传入时，判断队列中是否有数据包；
若否，则直接将数据包插入双向循环队列；
若是，则将接收到的数据包的序列号与双向循环队列尾部的数据包序列号进行比较，根据比较结果确定是否将所述数据包插入双向循环队列。
进一步的，所述根据比较结果确定是否将所述数据包插入双向循环队列，包括：
若队列尾部的数据包序列号小于接收到的数据包的序列号，将所述数据包插入双向循环队列；
若队列尾部的数据包序列号大于接收到的数据包的序列号，则顺序查找队列尾部之前的数据包，直到查找到序列号小于接收到的数据包的序列号，将接收到的数据包的序列号插入到序列号小于接收到的数据包的序列号对应的数据包后；
若查找到序列号与接收到的数据包的序列号相同的数据包，将接收到的数据包直接舍弃。
进一步的，所述所述接收端对所述数据包进行解析，包括：
将所述双向循环队列中属于同一帧的数据包进行封装封装成FFMPEG的帧格式；
从每帧数据包的包头中获取流媒体数据信息解码时所需要的参数，已根据所述参数对数据包进行解码。
第二方面，本申请提供一种移动流媒体数据传输装置，包括：
采集模块，用于采集流媒体数据；
缓存模块，用于对所述流媒体数据在采集端进行本地缓存；
封装模块，用于将缓存的流媒体数据封装成多个数据包；
传输模块，用于将所述多个数据包传输至接收端，以使所述接收端对所述数据包进行解析以获取所述流媒体数据。
第三方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的方法步骤。
本申请的实施例提供的技术方案可以包括以下有益效果：
本发明实施例提供的移动流媒体数据传输方法、装置及存储介质，通过采集流媒体数据，对流媒体数据在采集端进行本地缓存，将缓存的流媒体数据封装成多个数据包，将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据，实现移动流媒体数据本地化存储，解决数据传输安全性问题，并且可以减少使用第三方云平台存储成本，便于流媒体数据与其他业务数据进行集成或融合。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请一个实施例提供的一种移动流媒体数据传输方法的流程图。
图2为本申请一个实施例提供的一种现有视频直播产品的架构图。
图3为本申请另一个实施例提供的一种移动流媒体数据传输方法的流程图。
图4为本申请一个实施例提供的一种采集端采集过程的流程图。
图5为本申请一个实施例提供的一种采集端采集视频过程的流程图。
图6为本申请一个实施例提供的一种采集端采集音频过程的流程图。
图7为本申请一个实施例提供的一种移动流媒体数据传输方法中接收端接收过程的流程图。
图8为本申请一个实施例提供的一种移动流媒体数据传输方法中接收端解析过程的流程图。
图9为本申请一个实施例提供的一种移动流媒体数据传输方法中接收端解码过程的流程图。
图10为本申请一个实施例提供的一种移动流媒体数据传输装置的功能结构图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将对本申请的技术方案进行详细的描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本申请所保护的范围。
图1为本申请一个实施例提供的移动流媒体数据传输方法的流程图，如图1所示，该移动流媒体数据传输方法包括：
S11：采集流媒体数据；
S12：对流媒体数据在采集端进行本地缓存；
S13：将缓存的流媒体数据封装成多个数据包；
S14：将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据。
现有移动流媒体数据传输技术中，直播数据录制端将直播视频数据和音频数据发送至云平台，由云平台封装为流媒体数据后，基于传输控制协议将流媒体数据再实时传输至流媒体服务器，后续由流媒体服务器分发至观众终端。
如图2所示，主播通过采集设备采集直播内容后，通过推流SDK推送直播流，视频直播服务通过边缘推流的方式将直播流推送至阿里云直播中心，视频流推送至阿里云直播中心后，可按需对视频流进行转码、时移、录制、截图等处理。处理好的视频流通过CDN内容分发网络，下发至观众的设备中进行播放。移动端的播放设备可以集成阿里云提供的播放器SDK进行开发。直播视频除了可以进行转码截图等操作外，还可以进行直播转点播的操作，将录制下来的视频转至点播系统中再进行点播播放和短视频云剪辑。方便直播与短视频内容生产和传播的联动。
上述传输方式需要将移动流媒体数据先上传至云平台，导致这些数据在本地无法二次使用。同时随着客户业务不断的增加和扩展，对存储空间的需求也不断提高。由于云平台属于第三方需用户购买，因此在不断扩容时，也会增加用户企业成本支出，另外，上传至云平台的数据与其他业务产品相互独立，无法进行数据集成与融合，导致无法支撑客户业务的扩展，并且，由于云平台需要通过互联网访问，随着用户对网络安全要求的不断提升，通过互联网进行数据传输也是不能满足用户需求。
本实施例中，通过采集流媒体数据，对流媒体数据在采集端进行本地缓存，将缓存的流媒体数据封装成多个数据包，将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据，实现移动流媒体数据本地化存储，解决数据传输安全性问题，并且可以减少使用第三方云平台存储成本，便于流媒体数据与其他业务数据进行集成或融合。
本发明实施例提供另一种移动流媒体数据传输方法，如图3所示的流程图，该移动流媒体数据传输方法包括：
S31：分别创建音频采集线程和视频采集线程；
在采集前，首先检查采集设备(例如智能手机)是否支持H.264编码，如果采集设备不支持H.264编码，重新选择采集设备。如果采集设备支持H.264编码，在采集设备内部创建2个MediaRecorder类，分别进行视频和音视频的录制，同时设置2个MediaRecorder类的编码与输出位置。
一些实施例中，判断手机是否支持H.264硬件编码，可设置MediaRecorder类使用H.264编码录制一段视频，从该段视频文件中如果能够提取出序列参数集和图像参数集，则说明该采集设备支持H.264硬件编码，否则不支持，如果该采集设备不支持H.264硬件编码，可使用H.264软件编码。
通过将音频数据与视频数据分开采集，可以提升采集速度。
S32：在音频采集线程中使用Android操作系统的MediaRecorder类进行音频采集；
音频采集，定义录制声音的MediaRecorder类的MediaStreamer，制定录制的声音源、录音输出方式以及录音编码等，录音方式采用AMR及AMR_NB编码。
S33：在视频采集线程中使用Android操作系统的MediaRecorder类进行视频采集。
采集端包括采集服务器和采集客户端。
S34：在采集服务器的Android操作系统中定义第一采集类，在采集客户端的Android操作系统定义第二采集类；
S35：在第一采集类中使用第一存储空间对采集到的流媒体数据进行缓存；
S36：采集服务器将缓存后的流媒体数据发送至采集客户端；
S37：在第二采集类中使用第二存储空间对流媒体数据进行缓存。
使用Android操作系统的LocalSocket和LocalServerSocket对音频数据进行缓存。采集服务器端定义LocalServersocket和Socket，采集客户端定义LocalSocket和Socket，采集服务器将采集设备的摄像头输出指定为LocalSocket使用100000大小的缓存，采集服务器端将摄像头的数据缓存后发送给采集客户端的LocalSocket，客户端Socket同样用大小为100000的缓存，将采集客户端Socket流中的数据作为RTP封装数据的来源，采集端的缓存大小为2*100000。
视频采集需要指定录制的视频源、制定输出方式、视频编码，还需要指定视频的采集帧频率和视频像素大小，设置视频采集频率在设置像素大小参数之前。本实施例中使用的视频源移动终端的摄像头进行采集，视频输出格式为THREE_GPP,视频采集图像频率为15bps，像素大小为320*240，视频编码采用H.264编码方式。
通过对音频数据和视频数据在采集端进行缓存，可以不依靠云平台，减少网络传输风险，有利于流媒体数据在本地的二次使用。
S38：将缓存的流媒体数据封装成多个数据包；
一些实施例中，将缓存的流媒体数据封装成多个数据包，包括：
S381：从流媒体数据中剥离出每个网络抽象层单元；
S382：在每个网络抽象层单元前添加对应的RTP包头；
S383：将网络抽象层单元及其对应RTP包头封装成数据包。
音频、视频数据采集完成后，使用本地套接字技术进行本地缓存，RTP封装过程是把本地缓存数据封装成RTP包。音频和视频分别使用两个线程进行封装。
根据以太网络中最大传输单元的大小和系统的实际需要，可设置RTP包的最大为20+1400，即1420字节(最大传输单元的大小为1500字节)，其中，20字节为RTP的首部大小，1400字节为网络抽象层单元大小。
自定义一个RTPSocket类数据结构，该类包含一个RPTPacket类型、一个UDPSocket DatagramSocket类型的引用和一个缓冲区，缓冲区存储打包完成的数据。音频和视频的发送使用不同的端口，音频使用5001端口，视频使用5002端口。发送数据时，首先更新RTPPacket的序号，根据封装的网络抽象层单元大小，设置RTPPacket的大小，最后执行DatagramSocket实现发送功能。
一些实施例中，在采集端还包括播放器，播放器支持多个播放协议，播放系统例如为FFMPEG，FFMPEG基于Linux系统开发，用C语言实现，因此可以将FFMPEG移植到Android操作系统环境上进行编解码使用。
FFMPEG包括三个函数库，分别是lbavutil函数库,iibavcodec函数库和libavformat函数库。Hibavutil函数库是最基础的函数库，libavcodec函数库依赖于ibavutil函数库，而lbavformat函数库又依赖于前两者，因此使用NDK编译FFMPEG时，须按照Libavutil->libavcode->libavformat函数的编译顺序进行。
FFMPEG在经过configure命令之后会产生一个configh文件和一个config.mak文件，这两个文件用来描述编译后代码的各个方面参数设置，其中有关于体系架构、编译器、链接库、头文件、版本、编解码器等相关的宏定义。
编译Hibavutil.a文件时，在ibavutil文件夹下建立一个Android.mk的文件，Hibavutil里的makefile文件需要调用subdir.mak，是真正的编译书写在Android.mk下，make文件可以不要，但需要直接把对应的源文件引入，标准的makefile是指定.0目标文件，但在Android.mk中需要直接指定.C源文件。
编译ibavcodec.a时，avcode中包含了所有的DECODER和ENCODER，用于实现FFMPEG的编解码工作，在生成configh文件时可以通过配置configure工具指定需要的DECODER和ENCODER，如果包含所有的编解码的话会使ibavcodec.a包过大，所以指定了h.263、mp2、amr等解码和大部分手机播放器需要支持的音视频解码格式。该模块的Android.mk文件和avutil的mk文件与avcodec目录下的makefile文件一致。avutil的添加方法为在Android.mk最后一行添加LOCAL_STATIC_LIBRARIES:＝avutilo。
编译libvformat.a与编译ibavcodec.a相同，avformat模块放的都是muxers和dernuxers,只需要avi、3gp、mov的muxer和所有的demuxer。该包也同样需要解决一些类似的头文件问题，对产生错误的源文件进行改正后，生成libavformat.a静态包。
对FFMPEG进行应用测试时，在上层定义一个native方法enavi，与一个button相关联，并设置chick点击事件，该事件处理函数内调用enavi函数，目的是把sdcard里的原始音频1.wav文件和原始视频文件1.yuv封装成avi媒体格式文件。在NDK里写enavi方法的实现，方法体中调用之前的avi编码的入口函数。编译成功即可生成ibenavi.so文件。把apk文件重新安装到Android中，运行测试程序后，通过eclipse的adt插件的FileList中可以看到sdcard文件列表中生成了1.avi文件，或者通过adb命令进入sdcard查看文件列表信息。若1.avi文件可以播放，则说明FFMPEG应用测试成功。
S39：将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据。
一些实施例中，将多个数据包传输至接收端包括：
定义数据传输类数据结构，数据传输类数据结构包括数据包结构、数据包发送结构和缓冲区，所述缓冲区用于存储所述数据包；
数据包结构用于根据所述网络抽象层单元的大小设置数据包的大小；
数据包发送结构用于通过音频发送端口和视频发送端口发送数据包。
一些实施例中，接收端包括视频缓冲区和音频缓冲区，还包括：
接收端在接收到数据包后，将所述数据包缓存至所述视频缓冲区或音频缓冲区中的双向循环队列中；
双向循环队列在接收到一个数据包传入时，判断队列中是否有数据包；
若否，则直接将数据包插入双向循环队列；
若是，则将接收到的数据包的序列号与双向循环队列尾部的数据包序列号进行比较，根据比较结果确定是否将所述数据包插入双向循环队列。
本实施例中，根据比较结果确定是否将数据包插入双向循环队列，包括：
若队列尾部的数据包序列号小于接收到的数据包的序列号，将所述数据包插入双向循环队列；
若队列尾部的数据包序列号大于接收到的数据包的序列号，则顺序查找队列尾部之前的数据包，直到查找到序列号小于接收到的数据包的序列号，将接收到的数据包的序列号插入到序列号小于接收到的数据包的序列号对应的数据包后；
若查找到序列号与接收到的数据包的序列号相同的数据包，将接收到的数据包直接舍弃。
接收端需要从采集端获取流媒体文件，流媒体文件获取过程包括前期会话协商部分、数据发送部分和数据缓冲部分。其中媒体信息协商部分需要使用RTSP协议协商媒体流常规信息，如媒体类型(音频和视频)、传输协议(RTP/UDP)和媒体格式(H.264、mpeg)和媒体传输端口等信息。在网络中通过RTP协议传送流媒体数据时，由于网络的情况经常发生变化，因此到达接收端的数据包经常会产生时延或抖动。为避免这一现象发生，本实施例中，在接收方应用缓冲机制，为流媒体播放器分配两个缓冲区，分别为视频缓冲区和音频缓冲区。当网络中的RTP包到达接收端后，并非马上转发给上一层进行处理而是全部放入缓冲区中，根据一定的缓冲策略将数据包发送出去。这时虽然缓冲区接收的还是从网络中得到的带有抖动和时延的数据包，由于缓冲区中已经有一定的数量的数据包，数据包有序排列，因此对上层来说接收到的已经是平稳且按序的数据包，这样该层就成功的屏蔽了下层网络的不稳定性。
如图7所示，按序将RTP数据包传出的前提条件是缓冲区里面的所有RTP数据包是按照RTP的序列号递增的方式存储的。采用双向循环队列的数据结构存储数据包，当一个RTP数据包传入时，首先判断队列中是否有RTP包，若队列为空则直接将RTP包插入队列，若队列不为空，则将现有包的序列号与队列尾部的数据包序列号进行比较，若队列尾部的数据包序列号小于现有包的序列号，说明现有包为队列尾部的后续包，将现有包插入队列即可,若队列尾部的数据包序列号大于现有包的序列号，则顺序查找队列尾部之前的数据包，直到序列号小于现有包，将现有包插入队列。若在查找期间找到序列号相同的RTP包，则说明当前的RTP为重复数据包，直接舍弃。
一些实施例中，接收端对所述数据包进行解析，包括：
将所述双向循环队列中属于同一帧的数据包进行封装封装成FFMPEG的帧格式；
从每帧数据包的包头中获取流媒体数据信息解码时所需要的参数，已根据所述参数对数据包进行解码。
解码过程包括在解析完成后创建解码线程，通过所述解码线程对解析后数据进行解码播放，所述解码线程包括音频解码线程和视频解码线程。
如图8所示，RTP数据包解析模块负责在接收到顺序的RTP数据包后，为提供给上层统一提取数据帧接口，需要通过调用函数库解析RTP包，将音视频数据按帧封装成统一的数据格式，即FFMPEG的帧格式，并从RTP包头得出数据信息解码时所需要的参数。对于H.264编码的视频信息，必须先对其进行网络抽象层重新合并。
如图9所示，一个RTP包中的音视频数据不一定是完整的一帧信息，而判断队列中两个相邻的RTP包是否是同一帧中的数据，不但需要判断时间戳是否一致(同一帧是数据的时间戳是相同的)，还要判断队列中相邻两个数据包的序列号是否也是相邻的，若不相邻则说明在网络传输过程中有丢包现象。所以当前包所在的帧是不完整的，必须舍弃。顺序的将队列的属于同一帧的包连接到一起直到某个RTP包的M位为1(M位为1表示该包是当前要组合帧的最后一个数据包)，表示一帧的数据信息已经完整，封装并记录该帧的时间戳，放入缓冲队列等待上层解码播放。
获得RTP解析后的帧数据后，因为采集端使用的是H.264编码的视频数据，因此需要将帧数据解码进行显示，调用FFMEPG解码接口进行解码后，将解码后的数据放入缓冲区，供播放器进行播放。
解码器使用的是FFMPEG开源代码中的解码部分，但FFMPEG中该解码部分只是针对于本地文件，并且解码流程是需要同时处理音视频数据组帧或拆分成帧，同时对完整帧解码。流媒体文件经过RTP解析模块处理后，音视频数据都按帧存入解码前的缓冲区只需要调用FFMPEG的解码接口从缓冲区中读取一帧解码即可，将解码后的数据放入播放缓冲区，供显示播放。
分别创建两个线程独立的待解码数据缓冲区和已解码数据帧的缓冲区，上层从已解码数据帧的缓冲区获取到已经经过同步的数据信息就可以将数据显示给用户。
一些实施例中，还包括播放视频流和发布视频流，为了让互联网上的其他客户端可以进行访问播放。播放媒体流和发布媒体流都是基于会话描述协议(SDP，SessionDescription Protocol)协议完成。
接收端接受SDP指定端口的多媒体实时数据流，使用VCL流媒体播放器打开SDP文件即可实现实时播放。
该会话的视频信息流使用5002端口并且使用RTP/AVP协议，视频的编码为H.264；b＝RR:0,3GPP的PSS规范中对于SDP中的会话层和媒体层都定义了带宽信息参数的两个扩展字段：b＝RS：该字段指明了发送者即流媒体服务器端分配的RTCP的带宽，b＝RR,指明接受端即采集客户端分配的RTCP带宽，由于系统暂时没有考虑RTCP功能，因此RTCP的带宽设置为0；a＝rtpmap:96H.264/90000描述了该会话使用的时RTP协议，视频使用H.264压缩编码，90KHZ频率的采集时钟；a＝framerate:15摄像头的采集频率为15帧/秒；该SDP描述文件另外几个重要的信息是a＝fmtp:96packetization-mode＝l；profile-level-id＝42000a；sprop-parameter-sets＝ZOIACpZUBQHogA＝＝,aM44gA＝＝,其中packetization-mode＝1表示使用非交错的封装模式进行RTP打包，即可用使用NAL unit、FU-A或者STAP-A方式打包，本实施例中使用了NALU unit和FU-A两种方式进行打包。profile-level-id＝42000a,这个参数用于指示H.264流的profile类型和级别。由Base 16(十六进制)表示的3个字节。第一个字节表示H.264的Profile类型，第三个字节表示H.264的Profile级别，这个值根据采集到的视频文件参数产生。
sprop-parameter-sets＝Z0IACpZUBQHogA＝＝,aM44gA＝＝,即序列参数集和图像参数集,这个字段是实时传输H.264最关键的一个字段，它描述了传输的H.264视频流的序列参数集和图像参数网络抽象层单元，视频进行采集产生序列参数集和图像参数集的值，服务器端根据这两个参数进行图像解析，通常进行实时视频传输时分为发送序列参数集和图像参数集和不发送两种方式。本实施例中根据实际需要使用不发送序列参数集和图像参数集的方式。
m＝audio 5001RTP/AVP 96该行字段以及以下字段都是描述音频字段信息，音频使用5001号端口，RTP/AVP协议与视频传输协议一样，96表示使用是payload类型为ACC音频编码；b＝AS:128表示音频的bitrate比特率为128kbps；其他字段和视频类似。使用以上sdp文件，将sdp文件交给vic打开，即可播放端的实时视频。如果将sdp文件交给流媒体服务器，则可实现发布实时流完成直播的功能。
接收端可实现对远端音视频流采集后的直播功能。接收端利用流媒体服务器Wowza Media Server的强大功能，建立基于RTP/RTSP的直播系统。
本实施例提供的移动流媒体数据传输方法，不需要依靠第三方网络云平台，可实现流媒体数据本地化存储、播放以及与其他业务数据融合。
图10为本申请一个实施例提供的移动流媒体数据传输装置的功能结构图，如图10所示，该移动流媒体数据传输装置包括：
采集模块101，用于采集流媒体数据；
缓存模块102，用于对流媒体数据在采集端进行本地缓存；
封装模块103，用于将缓存的流媒体数据封装成多个数据包；
传输模块104，用于将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据。
本实施例中，通过采集模块采集流媒体数据，缓存模块对流媒体数据在采集端进行本地缓存，封装模块将缓存的流媒体数据封装成多个数据包，传输模块将多个数据包传输至接收端，以使接收端对数据包进行解析以获取流媒体数据，实现移动流媒体数据本地化存储，解决数据传输安全性问题，并且可以减少使用第三方云平台存储成本，便于流媒体数据与其他业务数据进行集成或融合。
本发明实施例提供一种计算机可读存储介质，计算机可读存储介质内存储有计算机程序，计算机程序被处理器执行时实现上述实施例所述的方法步骤。
可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。
需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。
应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。
需要说明的是，本发明不局限于上述最佳实施方式，本领域技术人员在本发明的启示下都可得出其他各种形式的产品，但不论在其形状或结构上作任何变化，凡是具有与本申请相同或相近似的技术方案，均落在本发明的保护范围之内。
Claims (10)
1.一种移动流媒体数据传输方法，其特征在于，包括：
采集流媒体数据；
对所述流媒体数据在采集端进行本地缓存；
将缓存的流媒体数据封装成多个数据包；
将所述多个数据包传输至接收端，以使所述接收端对所述数据包进行解析以获取所述流媒体数据。
2.根据权利要求1所述的移动流媒体数据传输方法，其特征在于，所述采集流媒体数据，包括：
分别创建音频采集线程和视频采集线程；
在所述音频采集线程中使用Android操作系统的MediaRecorder类进行音频采集；
在所述视频采集线程中使用Android操作系统的MediaRecorder类进行视频采集。
3.根据权利要求1所述的移动流媒体数据传输方法，其特征在于，所述采集端包括采集服务器和采集客户端，所述对所述流媒体数据在采集端进行本地缓存，包括：
在所述采集服务器的Android操作系统中定义第一采集类，在所述采集客户端的Android操作系统定义第二采集类；
在所述第一采集类中使用第一存储空间对采集到的流媒体数据进行缓存；
所述采集服务器将缓存后的流媒体数据发送至所述采集客户端；
在所述第二采集类中使用第二存储空间对所述流媒体数据进行缓存。
4.根据权利要求1所述的移动流媒体数据传输方法，其特征在于，所述将缓存的流媒体数据封装成多个数据包，包括：
从所述流媒体数据中剥离出每个网络抽象层单元；
在每个网络抽象层单元前添加对应的RTP包头；
将所述网络抽象层单元及其对应RTP包头封装成数据包。
5.根据权利要求4所述的移动流媒体数据传输方法，其特征在于，所述将所述多个数据包传输至接收端包括：
定义数据传输类数据结构，所述数据传输类数据结构包括数据包结构、数据包发送结构和缓冲区，所述缓冲区用于存储所述数据包；
所述数据包结构用于根据所述网络抽象层单元的大小设置数据包的大小；
所述数据包发送结构用于通过音频发送端口和视频发送端口发送数据包。
6.根据权利要求5所述的移动流媒体数据传输方法，其特征在于，所述接收端包括视频缓冲区和音频缓冲区，还包括：
所述接收端在接收到数据包后，将所述数据包缓存至所述视频缓冲区或音频缓冲区中的双向循环队列中；
双向循环队列在接收到一个数据包传入时，判断队列中是否有数据包；
若否，则直接将数据包插入双向循环队列；
若是，则将接收到的数据包的序列号与双向循环队列尾部的数据包序列号进行比较，根据比较结果确定是否将所述数据包插入双向循环队列。
7.根据权利要求6所述的移动流媒体数据传输方法，其特征在于，所述根据比较结果确定是否将所述数据包插入双向循环队列，包括：
若队列尾部的数据包序列号小于接收到的数据包的序列号，将所述数据包插入双向循环队列；
若队列尾部的数据包序列号大于接收到的数据包的序列号，则顺序查找队列尾部之前的数据包，直到查找到序列号小于接收到的数据包的序列号，将接收到的数据包的序列号插入到序列号小于接收到的数据包的序列号对应的数据包后；
若查找到序列号与接收到的数据包的序列号相同的数据包，将接收到的数据包直接舍弃。
8.根据权利要求6所述的移动流媒体数据传输方法，其特征在于，所述所述接收端对所述数据包进行解析，包括：
将所述双向循环队列中属于同一帧的数据包进行封装封装成FFMPEG的帧格式；
从每帧数据包的包头中获取流媒体数据信息解码时所需要的参数，已根据所述参数对数据包进行解码。
9.一种移动流媒体数据传输装置，其特征在于，包括：
采集模块，用于采集流媒体数据；
缓存模块，用于对所述流媒体数据在采集端进行本地缓存；
封装模块，用于将缓存的流媒体数据封装成多个数据包；
传输模块，用于将所述多个数据包传输至接收端，以使所述接收端对所述数据包进行解析以获取所述流媒体数据。
10.一种计算机可读存储介质，其特征在于，
所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1～8任一所述的方法步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210195942.4A CN114584538B (zh) | 2022-03-01 | 2022-03-01 | 移动流媒体数据传输方法、装置及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210195942.4A CN114584538B (zh) | 2022-03-01 | 2022-03-01 | 移动流媒体数据传输方法、装置及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114584538A true CN114584538A (zh) | 2022-06-03 |
| CN114584538B CN114584538B (zh) | 2024-03-22 |
Family
ID=81772217
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210195942.4A Active CN114584538B (zh) | 2022-03-01 | 2022-03-01 | 移动流媒体数据传输方法、装置及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114584538B (zh) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104093088A (zh) * | 2013-12-26 | 2014-10-08 | 赛特斯信息科技股份有限公司 | 实现自适应流媒体播放控制的系统及方法 |
| CN105681817A (zh) * | 2016-01-05 | 2016-06-15 | 王成 | 一种智能终端视音频采集传输播放系统和方法 |
| CN105933343A (zh) * | 2016-06-29 | 2016-09-07 | 深圳市优象计算技术有限公司 | 一种用于720度全景视频网络播放的码流缓存机制 |
| CN108366292A (zh) * | 2017-12-27 | 2018-08-03 | 武汉烽火众智数字技术有限责任公司 | 一种基于流媒体的跨网络视频直播方法及系统 |
| CN108616722A (zh) * | 2018-04-18 | 2018-10-02 | 中南大学 | 一种嵌入式高清视频采集与数据流传输系统 |
| WO2018213401A1 (en) * | 2017-05-16 | 2018-11-22 | Apple Inc. | Methods and interfaces for home media control |
| CN109168031A (zh) * | 2018-11-06 | 2019-01-08 | 杭州云英网络科技有限公司 | 流媒体推送方法及装置、流媒体平台 |
| CN113905026A (zh) * | 2021-10-22 | 2022-01-07 | 广西中科曙光云计算有限公司 | 一种流媒体视频数据处理方法、装置及存储介质 |
-
2022
- 2022-03-01 CN CN202210195942.4A patent/CN114584538B/zh active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104093088A (zh) * | 2013-12-26 | 2014-10-08 | 赛特斯信息科技股份有限公司 | 实现自适应流媒体播放控制的系统及方法 |
| CN105681817A (zh) * | 2016-01-05 | 2016-06-15 | 王成 | 一种智能终端视音频采集传输播放系统和方法 |
| CN105933343A (zh) * | 2016-06-29 | 2016-09-07 | 深圳市优象计算技术有限公司 | 一种用于720度全景视频网络播放的码流缓存机制 |
| WO2018213401A1 (en) * | 2017-05-16 | 2018-11-22 | Apple Inc. | Methods and interfaces for home media control |
| CN108366292A (zh) * | 2017-12-27 | 2018-08-03 | 武汉烽火众智数字技术有限责任公司 | 一种基于流媒体的跨网络视频直播方法及系统 |
| CN108616722A (zh) * | 2018-04-18 | 2018-10-02 | 中南大学 | 一种嵌入式高清视频采集与数据流传输系统 |
| CN109168031A (zh) * | 2018-11-06 | 2019-01-08 | 杭州云英网络科技有限公司 | 流媒体推送方法及装置、流媒体平台 |
| CN113905026A (zh) * | 2021-10-22 | 2022-01-07 | 广西中科曙光云计算有限公司 | 一种流媒体视频数据处理方法、装置及存储介质 |
Non-Patent Citations (1)
| Title |
|---|
| 王勇;周金和;: "基于私有云的远程视频监控系统设计", 电视技术, no. 2, 30 September 2013 (2013-09-30) * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114584538B (zh) | 2024-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106134146B (zh) | 处理连续的多周期内容 | |
| KR100928998B1 (ko) | 사용자 단말기에 멀티미디어 컨텐츠와 코덱을 제공하는적응적 멀티미디어 시스템 및 그 방법 | |
| CN112752115B (zh) | 直播数据传输方法、装置、设备及介质 | |
| US20150181003A1 (en) | Method and apparatus for transmitting and receiving packets in hybrid transmission service of mmt | |
| US10887645B2 (en) | Processing media data using file tracks for web content | |
| CN107846633A (zh) | 一种直播方法及系统 | |
| CN107634930B (zh) | 一种媒体数据的获取方法和装置 | |
| KR20130126538A (ko) | Mmt 패킷 포맷 확장을 통한 하이브리드 전송 방법 | |
| US11750864B2 (en) | Methods and apparatuses for ingesting one or more media assets across a video platform | |
| CN115243074A (zh) | 视频流的处理方法及装置、存储介质、电子设备 | |
| Dong et al. | Ultra-low latency, stable, and scalable video transmission for free-viewpoint video services | |
| JP4391231B2 (ja) | 複数のターミナルへのマルチメディア信号のブロードキャスト方法 | |
| CN115643426B (zh) | 一种面向空间应用领域的通用视频播放方法和系统 | |
| CN114584538B (zh) | 移动流媒体数据传输方法、装置及存储介质 | |
| CN114885198B (zh) | 面向混合网络的伴音与视频协同呈现系统 | |
| KR101538114B1 (ko) | 모바일 스마트 기기 내에서 다중 코덱 기반으로 끊김 없이 동영상을 재생할 수 있도록 하는 동영상 처리 장치 및 방법 | |
| KR102705364B1 (ko) | 콘텐츠 전달을 위한 레이턴시 관리 | |
| US10547878B2 (en) | Hybrid transmission protocol | |
| CN112073727B (zh) | 转码方法、装置、电子设备及存储介质 | |
| CN113409801A (zh) | 用于实时音频流播放的噪音处理方法、系统、介质和装置 | |
| Lohan et al. | Integrated system for multimedia delivery over broadband ip networks | |
| KR102600762B1 (ko) | Atsc 3.0 기반의 방송 콘텐츠 전송 장치 및 방법과, 방송 콘텐츠 수신 장치 및 방법 | |
| CN115278288B (zh) | 一种显示处理方法、装置、计算机设备及可读存储介质 | |
| JP2009134747A (ja) | 送信装置およびメディアデータ送信方法 | |
| KR20220068636A (ko) | 초저지연 ott 서비스를 제공하는 시스템 및 동작 방법 |
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 | ||
| CB02 | Change of applicant information |
Address after: 100086 10th Floor, Building A, Office, No. 19 Zhongguancun Street, Haidian District, Beijing Applicant after: Beijing Smart Starlight Information Technology Co.,Ltd. Address before: 100089 area a, 22 / F, block a, No. 8, Haidian Street, Haidian District, Beijing Applicant before: BEIJING SMART STARLIGHT INFORMATION TECHNOLOGY CO.,LTD. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |