建立live555海思编码推流服务

【建立live555海思编码推流服务】的更多相关文章

建立live555海思编码推流服务

因项目需要,这一周弄了一下live555.需求:海思编码——>RTSP server,使用VLC可以访问,类似于网络摄像机的需求.看了一下,live555的架构太复杂了,半桶水的C++水平还真的需要花点时间才可以明白.由于live555的例子server使用的是读取文件,打包成RTSP包然后发送.例子运行live555MediaServer,把对应的视频文件发到该服务的目录下面,在VLC使用rtsp://ip:8554/file.264即可播放file.264视频. 个人简单理解live555的…

live555 交叉编译移植到海思开发板

本文章参考了.http://blog.csdn.net/lawishere/article/details/8182952,写了hi3518的配置说明.特此感谢 https://blog.csdn.net/sunxiaopengsun/article/details/79175408 1.首先到它的主页下载一个源码包: http://www.live555.com/liveMedia/public/ 我下载的是latest的,具体什么版本还真不清楚 2.放到linux目录下解压: root@ku…

海思hi3518 移植live555 实现H264的RTSP播放

用海思的交叉编译工具交叉编译live555 ,结合海思例子venc中的H264部分,完成RTSP的视频数据发布. 用vlc可以播放,但是实时性比较差,慢了5秒…

在嵌入式、海思、ARM中进行统一的音频AAC编码的必要性

前言最近来到深圳,跟许多做硬件的小伙伴聊安防.聊互联网.聊技术,受益颇多,其中聊到一点,大家一直都在想,互联网发展如此迅猛,为啥大部分的摄像机还是采用的传统G.726/G.711的音频编码格式呢,如果能直接输出AAC格式的音频,再配合H.264+AAC,基本上编码数据就不用再做处理,就可以直接做协议转换的输出了,输出:RTSP.RTMP.HLS.MP4.FLV各种协议和封装格式,而如果还是传统安防的音频格式,不但音频数据要做转码,时间戳也要重新矫对,非常不便: 为什么呢? 目前市面上的大部分摄…

海思Hi3518A 海思Hi3518C 海思Hi3518E 这几个芯片都有什么区别么

在3518A.3518C的基础上深化完善,推出了Hi3518E.作为新一代IP民用摄像机SoC,Hi3518E集成新一代ISP,优化了编码前图像处理算法,采用新一代H.264编码器.同时采用业内领先的低功耗工艺和内部低功耗架构设计,使得Hi3518E在低码率,高图像质量,低功耗方面持续引领行业水平.Hi3518E集成DRAM,POR,RTC,AudioCodec,Sensor电平转换以及各种时钟输出等,将极大的降低IP摄像机的ebom成本.与海思DVR/NVR芯片相似的SDK设计,能够支撑客户快…

RTSPClient工具EasyRTSPClient支持H.265，支持海思等各种芯片平台

EasyRTSPClient是EasyDarwin开源流媒体团队开发.提供的一套非常稳定.易用.支持重连的RTSPClient工具,接口调用非常简单,再也不用像调用live555那样处理整个RTSP OPTIONS/DESCRIBE/SETUP/PLAY的复杂流程,担心内存释放的问题了,全平台支持(包括Windows/Linux 32&64,ARM各平台,Android,IOS),接口简单且成熟稳定! 调用示例 EasyRTSPClient:以RTSPClient的形式,从RTSP URL将音视…