基于Live555,ffmpeg的RTSP播放器直播与点播

  • 时间:
  • 浏览:0
  • 来源:uu快3计划_uu快3官方_单双

   4.4 WEB浏览器调用

(2) SourceSdK的管理功能由SourceEngine引擎来完成,主要对input以及demux模块进行封装管理。SourceEngine从数据源(直播、点播、文件)获取数据,并解析数据将数据源分离成音频ES流和视频ES流,并将解析的数据以私有格式进行封装,通过回调函数的机制传递给应用层;

(3) 数据再各模块之间传递时使用数据缓冲池,处置了额外的内存分配操作,一起也减少了因内存分配操作而带来的内存碎片;

(4)音视频码流的同步存储,文件存储时以当前系统的时间戳作为音视频 播放时的索引,方便在文件播放时以时间戳作为检索条件来点播文件;

(2) 在数据解码中使用了ffmpeg的directbuffer机制,进一步的处置了数据的拷贝动作;

(3) PlaySdk的管理功能由PlayEngine引擎来完成,主要对decode以及output模块进行封装管理。PlayEngine提供了数据输入接口,通过该接口可不都可以 将从SourceEngine得到的数据传入该接口,放满去PlayEngine缓存。PlayEngine从缓存中提取数据,并对数据按协议格式进行解析,将解溶解的音视频数据分别回调;

 ======================================================================

(2)网络数据流的断线重连;

基于Live555,ffmpeg的RTSP播放器直播与点播

多路RTSP高清视频播放器下载地址:http://download.csdn.net/detail/u011352914/61504437

1.综述

(5)视频播放格式上支持 h.264、mpeg4、mpeg2 等,音频播放格式上支 持 AAC、AMR、G711 等;

3.应用守护进程框架

(1)RTSP 标准码流(包括音视频)的实时预览播放;

2.采集

为支持多路媒体数据并行解码输出,对于每路媒体数据分别设计了相应的engine引擎机制来进行管理,具体实现方案如下:

   4.3 音视频同步

RTSP协议定义了一对多应用应用守护进程如何有效地通过IP网络传送多媒体数据,在体系底部形态上存在RTP和RTCP之上,它使用TCP或RTP完成数据传输。目前在流媒体传输技术中使用最多的只是基于RTSP/RTP的流媒体传输,在智能网络摄像机上也时需实现基于RTSP/RTP的H.264实时流的传输。

本文研究的流媒体播放器主要用来对遵循RTSP标准协议的码流以及AVI文件进行实时播放以及码流录制。播放器核心为四个 多 DLL,分别为网络 DLL 以及播放 DLL。网络库 基于 Live555 开发,主要对码流的获取以及链路的管理进行控制;播放库基于基于 Live555以及DirectX 开发,主要对实时码流以及本地的音视频的文件进行解码播放和控制。

   QQ:1589385592 讨论群: 2645715049 (群共享可直接下载)

   QQ:1589385592 讨论群: 2645715049

(1) 为实现多种输入办法的扩展性,将input、demux、decode、output四个 过程划分为四个 多库来实现,分别为数据源解析库SourceSdk、播放库PlaySdk;

该RTSP播放器实现了主流RTSP播放器的基本功能,并有所拓展:

(6)视频抓拍;

播放器在功能和性能上具有较高的要求,具体的实现上,时需主要处置的关键技术点主要包括有:多路高清解码、兼顾低下行速率 单位与流畅性、音视频同步以及浏览器扩展。针对以上问提图片,实现上采用的相应处置办法如下:

RTSP协议基于TCP完成RTSP请求报文和响应报文的传输,RTP协议基于UDP协议完成流媒体数据的实时传输,RTCP协议基于UDP协议提供客户端和服务器有关当前网络拥塞和以及实时流传输质量等信息。

通过比较音频和视频的时间戳(pts)来对视频的显示下行速率 单位进行调整,如当前的视频的pts比音频pts大于最小偏差值(目前设置为150MS),说明视频快了,就更快是视频的显示下行速率 单位;反之就加快视频的显示下行速率 单位;否则,将会差距很多 (目前设置为11150MS), 大于最大偏差值时,加快视频的显示下行速率 单位的效果不明显就采用丢帧办法,这人一般突然出先再刚开启的是事先。

(5) 在相互作用的模块之间,如decode与output之间采用高效的数据缓冲池机制来保证高效的内存分配,并通过队列机制将数据进行有效的传递;

播放器整体设计参考VLC,MPLAYER等知名播放器,将整个数据的处置流程分为:input、demux、decode、output四个 过程。其中input用来处置网络数据流的输入以及文件数据的读取;demux用来做数据流的解复用,将音频以及视频数据分离成ES流;decode用来解码视频以及音频ES流,并输出解码后的数据(视频为YUV数据,音频为PCM格式);output用来处置YUV视频数据的显示以及PCM音频数据的输出。

   4.1 多路高清解码

在低下行速率 单位与流畅的平衡性上,通过设置最大缓冲帧数和最小缓冲帧数来实现控制,具体实现策略为:

多路RTSP高清视频播放器下载地址:http://download.csdn.net/detail/u011352914/61504437

(8)画面填充控制显示比例。

通过比较待解码缓冲区和解码后还未来得及显示的缓冲区里数据包的个数的和值,将会该值大于最大缓冲帧数,说明有只是数据在缓存里,延迟大了,这时就要加快显示下行速率 单位(减小output模块的休眠时间),最大缓冲帧数只是影响延迟的;反之一样, 最小缓冲帧数只是流畅的保证,该值越大就越流畅;通过改变这人最大值最小值就可不都可以 平衡延迟与流畅。

RTSP直播与点播:多路视频并发实时预览,窗口布局可动态调整;可动态的设置视频输出的显示比例,调整音量的输出大小;支持对视频内容的时间点检索等操作。

(1) 在PlaySdk中设计了回环数据缓冲机制,对应用层输入的数据进行高效的缓存,在传输decode模块时,处置了数据拷贝;

(1) 通过SourceSdk、PlaySdk的实现,将繁琐的数据处置流程统一成了标准的数据接口,控制管理底下便有效;

(3)对存储文件的解码播放以及控制;

(2) 在SourceSdk、PlaySdk内部实现上通过engine机制,对单路数据以及播放的管理提供了统一接口,对于多路播放实际上只时需管理多个engine即可;

(4) 为方便Engine对各模块的管理以及数据通讯,在内部设计了消息机制,可不都可以 通过Engine给模块发送消息控制各模块的正常运行;

   4.2 低下行速率 单位与流畅

对于媒体数据大体处置流程图如下:

(7)视频显示厚度旋转;

4.主要技术