解决方案 »
- 关于ffmpeg移植到android遇到的问题
- socket通讯,服务器和客户端不能接收到对方的消息
- 密码管理器,源码已经上传
- 你运行的程序意外停止 logcat显示如下 是什么问题?
- Android中怎样由图片的id号R.drawable.XX得到图片文件XX的绝对路径
- 如何下载google code?用GIT
- android 看api 里面的button
- android app开发 列表背景色
- android系统设置里的触摸提示音功能怎样实现开启和关闭?
- eclipse今天突然变回最原始的状态了
- android 手机有没有视频录制的应用?
- 请教关于Android中setMargins不可用的问题。
视频是确实是彩色数据的,我觉得花屏的现象应该是出现在这个丢包上,也就是说在传输过程中出现的问题,udp的传输本身就不保证可靠,我再发送端和接收端log查看了一下,当发送端数据大时,对方收到的数据与发送的不相符,也就导致了花屏。我的疑问是市面上的做的实时视频传输都是用的什么协议进行传送的呢?他们如何做到流程而且不花屏的?
发送和采集不是在同一个线程里的,要说性能的话,这是完全可以应付视频传输的,没有任何问题。所以我觉得问题的关键可能是udp的原因。
但是若采用tcp的话,又不能保证实时性了。
常见的实现是编码成流媒体视频,用rtsp之类的协议传输的。
如果是通过Camera.onPreviewCallback获取Preview直接发送,必然很卡了
差不多吧,我就是获取的实时视频数据,而非rtsp流,然后将数据转发给服务器,服务器再转码播放。为什么您说这个直接发送会很卡?为什么?
难道封装成rtsp流就可以了吗?
差不多吧,我就是获取的实时视频数据,而非rtsp流,然后将数据转发给服务器,服务器再转码播放。为什么您说这个直接发送会很卡?为什么?
难道封装成rtsp流就可以了吗?
再描述一下我的应用场景,将设备的网口与一个dvr连接,然后设备取到dvr传输过来的视频数据转发到服务器。我也考虑过直接转发dvr的rtsp流,但问题是我用什么方式去获取这个rtsp流呢?如果转发的话,要怎么转呢,这都是问题
也不是一定要包装成流媒体/rtsp,只要用视频格式编码一下就会小很多(比如H.264等)。流媒体/rtsp只不过是为了接收方播放方便。
至于怎么编码成rtsp,网上有很多人研究过,百度一下就知道了。你的需求应该不是很难实现。
确实是有点不尽如意,不过市面上有些号称3G可以做到720P实时传输的,这个可能吗两种方法达到所谓的720p实时传输。1,降低帧率,2,低分辨率强行在接收端拉大到720p。这都是所谓的720p实时传输。
确实是有点不尽如意,不过市面上有些号称3G可以做到720P实时传输的,这个可能吗两种方法达到所谓的720p实时传输。1,降低帧率,2,低分辨率强行在接收端拉大到720p。这都是所谓的720p实时传输。 对方说可以做到720p。帧率为16帧/s。。 不过你说的第二种方式倒是有可能的。
您是说把实时视频流转换为ts文件,然后就可以播放吗?敢问这个ffmpeg的指令是什么
您是说把实时视频流转换为ts文件,然后就可以播放吗?敢问这个ffmpeg的指令是什么
抱歉了哥们,这指令我找了蛮久没找到,忘了放哪儿了,其实原理就是把整个视频切割成一个个小片段播放的,播放起来就会比较流畅
您是说把实时视频流转换为ts文件,然后就可以播放吗?敢问这个ffmpeg的指令是什么
抱歉了哥们,这指令我找了蛮久没找到,忘了放哪儿了,其实原理就是把整个视频切割成一个个小片段播放的,播放起来就会比较流畅
http://blog.raphaelzhang.com/2013/04/video-streaming-and-ffmpeg-transcoding/ 都在这了
确实是有点不尽如意,不过市面上有些号称3G可以做到720P实时传输的,这个可能吗两种方法达到所谓的720p实时传输。1,降低帧率,2,低分辨率强行在接收端拉大到720p。这都是所谓的720p实时传输。
世面上的都是 理论上 的 , 大家要想想我们不是 学者不是做理论的, 做的东西是要用的,还必须客户体验度好才行,
还有一点就是 流量现在这么贵 ,这个是国内必须考虑的。