基于linux嵌入式两个设备间视频通信

一根葱的无奈 2015-03-30 10:18:36
需求:基于arm9的设备,linux2.6的系统,基于OV的摄像头,采集上来就是RGB的数组,本地显示没有问题,现在主要针对向远端发送视频,这其中的远方也是个嵌入式的设备。
构想:是否采用rtsp或者h.264的编解码等方法来处理这个事情?
现行方案:现在的解决方案是单纯打包那个字节数组,效率低且显示效果比较差。

希望有人能提供个思路。
...全文
202 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
大海方舟 2015-04-03
  • 打赏
  • 举报
回复
两个嵌入式设备之间进行视频传输,采集端采集到视频数据后在本地进行压缩处理,现在一般是用h.264,压缩后进行网络传输,然后接收端设备对接收到的视频数据进行解压就可以了
一根葱的无奈 2015-03-31
  • 打赏
  • 举报
回复
引用 1 楼 lucifer886 的回复:
[quote=引用 楼主 eliachen 的回复:] 需求:基于arm9的设备,linux2.6的系统,基于OV的摄像头,采集上来就是RGB的数组,本地显示没有问题,现在主要针对向远端发送视频,这其中的远方也是个嵌入式的设备。 构想:是否采用rtsp或者h.264的编解码等方法来处理这个事情? 现行方案:现在的解决方案是单纯打包那个字节数组,效率低且显示效果比较差。 希望有人能提供个思路。
通讯层用RTP协议传输数据,编码H264,RGB你一个图像得多大啊,一帧640*480的RGBA图像就是4*640*480=1M,一秒平均25帧就是25MB,你确定网络受得了?…… 发送端:RGB编码成H264,然后通过RTP发送出去。 接收端:RTP接收数据,然后H264解码显示。 中间很多细节,如果你没有硬件编码264的话CPU可能会负荷不了,如果只是玩玩的话编码成JPEG也可以接受。[/quote] OV采上来的数据就是一个RGB的数组,现在的方案是拿一个压缩成bmp来处理的,应该就拿去用一个jpeg进行压缩就传走即可。RTP能具体说一下吗?(网络上信息也比较多且杂,在此只能先做一下伸手党了)
zhxianbin 2015-03-31
  • 打赏
  • 举报
回复
视频没做过,但既然是通信问题,必须考虑数据量、传输速率等
lucifer886 2015-03-31
  • 打赏
  • 举报
回复
如果你用的是JPEG,时间戳可以省了,获取到完整一帧图片后直接解码显示就行了。
lucifer886 2015-03-31
  • 打赏
  • 举报
回复
RTP也不是特别了解,网上有比较通用的jrtplib还是jrtlib。 RTP就是个传输层协议而已,在UDP基础上建立的,你拿UDP一样可以传视频数据。 简单点来讲,显示端其实只需要知道两件事: 1.解码的码流数据。 2.解码和显示时间戳,关于这个时间戳RTP里面也有,你可以就按90000/25=3600位一帧的增量来填充。 网络通畅情况下,采集端有一帧数据出来后你就编码后马上发送,基本到接收端解码到显示都是毫秒级的,只是个demo的话这么干就可以了。
lucifer886 2015-03-30
  • 打赏
  • 举报
回复
引用 楼主 eliachen 的回复:
需求:基于arm9的设备,linux2.6的系统,基于OV的摄像头,采集上来就是RGB的数组,本地显示没有问题,现在主要针对向远端发送视频,这其中的远方也是个嵌入式的设备。 构想:是否采用rtsp或者h.264的编解码等方法来处理这个事情? 现行方案:现在的解决方案是单纯打包那个字节数组,效率低且显示效果比较差。 希望有人能提供个思路。
通讯层用RTP协议传输数据,编码H264,RGB你一个图像得多大啊,一帧640*480的RGBA图像就是4*640*480=1M,一秒平均25帧就是25MB,你确定网络受得了?…… 发送端:RGB编码成H264,然后通过RTP发送出去。 接收端:RTP接收数据,然后H264解码显示。 中间很多细节,如果你没有硬件编码264的话CPU可能会负荷不了,如果只是玩玩的话编码成JPEG也可以接受。

23,110

社区成员

发帖
与我相关
我的任务
社区描述
Linux/Unix社区 应用程序开发区
社区管理员
  • 应用程序开发区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧