RT5350 H264 RTSP 直播成功

调试了一阵子的RTSP server终于可以看到直播了,测试环境为

①RT5350 运行于AP 模式

②客户端为PC+VLC ,wifi是用的是tp-link的54Mbps usb 网卡

BusyBox v1.12.1 (2014-09-08 22:09:57 CST) built-in shell (ash)

Enter ‘help‘ for a list of built-in commands.

# free

total         used         free       shared      buffers

Mem:        28116        18524         9592            0          836

Swap:            0            0            0

Total:        28116        18524         9592

# top

Mem: 18520K used, 9596K free, 0K shrd, 836K buff, 2840K cached

CPU:   9% usr   9% sys   0% nice  81% idle   0% io   0% irq   0% softirq

Load average: 0.15 0.13 0.09

PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND

1632  1631 admin    S    10704  38%   9% /opt/FMServer

1639  1631 admin    S    10704  38%   5% /opt/FMServer

1910  1904 admin    R     1760   6%   5% top

1638  1631 admin    S    10704  38%   0% /opt/FMServer

1629   715 admin    S    10704  38%   0% /opt/FMServer

1633  1631 admin    S    10704  38%   0% /opt/FMServer

1631  1629 admin    S    10704  38%   0% /opt/FMServer

710     1 admin    S     1852   7%   0% goahead

1904   713 admin    S     1764   6%   0% -sh

715     1 admin    S     1764   6%   0% /bin/sh

1595     1 admin    S     1760   6%   0% syslogd -C8

1     0 admin    S     1756   6%   0% init

713     1 admin    S     1756   6%   0% telnetd

1278     1 admin    S     1756   6%   0% udhcpd /etc/udhcpd.conf

1598     1 admin    S     1752   6%   0% klogd

1454     1 admin    S     1752   6%   0% udhcpc -i eth2.2 -s /sbin/udhcpc.sh -

709     1 admin    S     1364   5%   0% nvram_daemon

665     1 admin    SW       0   0%   0% [mtdblockd]

4     1 admin    SW<      0   0%   0% [khelper]

#  35     5 admin    SW<      0   0%   0% [khubd]

#

从中可以看出在720P的H264下,rt5350的cpu使用率并不高。

时间: 2024-10-22 16:05:02

RT5350 H264 RTSP 直播成功的相关文章

如何设计一款跨平台低延迟的RTMP/RTSP直播播放器

开发背景 2015年,当我们试图在市面上找一款专供直播播放使用的低延迟播放器,来配合测试我们的RTMP推送模块使用时,居然发现没有一款好用的,市面上的,如VLC或Vitamio,说白了都是基于FFMPEG,在点播这块支持格式很多,也非常优异,但是直播这块,特别是RTMP,延迟要几秒钟,对如纯音频.纯视频播放,快速启播.网络异常状态处理.集成复杂度等各方面,支持非常差,而且因为功能强大,bug很多,除了行业内资深的开发者能驾驭,好多开发者甚至连编译整体环境,都要耗费很大的精力. 我们的直播播放器,

Windows平台RTMP/RTSP直播推送模块设计和使用说明

开发背景 好多开发者一直反馈,Windows平台,做个推屏或者推摄像头,推RTMP或者RTSP出去,不知道哪些功能是必须的,哪些设计是可有可无的,还有就是,不知道如何选技术方案,以下是基于我们设计的Windows平台RTSP.RTMP直播推送模块,设计和使用说明,供大家参考. 整体方案架构 Windows平台RTMP或RTSP推送,系采集端模块,主要完成,屏幕或者摄像头数据.麦克风或扬声器数据的采集,编码,然后按照特定格式打包,通过RTMP或者RTSP传输出去,实现直播目的. 对应设计架构图的“

调用Live555接收RTSP直播流,转换为Http Live Streaming(iOS直播)协议

Live555接收RTSP直播流,转换Http Live Streaming(iOS直播)协议 RTSP协议也是广泛使用的直播/点播流媒体协议,之前实现过一个通过live555接收RTSP协议,然后转换为HLS(Http Live Streaming)直播协议文件的程序,为的是可以接收远端设备或服务器的多路RTSP直播数据,实时转换为HLS协议文件,以实现iPhone或iPad等设备观看RTSP直播源的需求.现在把实现的思路分享如下. 要点分析 首先,程序的主要目的,是从多路RTSP输入源中提取

rt5350接入HD720P 直播效果

今天有空使用rt5350播放HD720摄像头,看看效果.看上去效果还行,不至于很差!录制了一段视频,不知道怎么上到csdn rt5350接入HD720P 直播效果

多媒体开发之---H264 RTSP交互过程

OPTIONS rtsp://192.168.1.154:8557/h264 RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2010.05.28)  RTSP/1.0 200 OK CSeq: 1 Date: Sat, Jan 01 2000 00:05:11 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE  DESCRIBE

rt5350 两路 sonix sn9c291 同时直播成功

今天抽空把,另外一路的usb camera也挂载上去了.效果如下图 两个均为720p,20fps 并查看了下free,剩余内存不多了,需要做些优化. top查看到的cpu使用率也不高.

网络摄像机IPCamera RTSP直播播放网络/权限/音视频数据/花屏问题检测与分析助手EasyRTSPClient

前言 最近在项目中遇到一个奇怪的问题,同样的SDK调用,访问海康摄像机的RTSP流,发保活OPTIONS命令保活,一个正常,而另一个一发就会被IPC断开,先看现场截图: 图1:发OPTIONS,摄像机立马断流 图2:但在另一个程序中发OPTIONS保活包又不断流 在大部分的摄像机上,都没什么问题,单单在海康的这一款摄像机中出现了这种问题,不仔细对比命令行中的输出,根本无法确定问题点,图2中的OPTIONS报文中携带了Authorization的头字段,将认证信息都带入了进来,而图1中只是简单将用

APICloud如何对接大牛直播SDK

随着apicloud的普及,越来越多的用户苦于apicloud下没有一款真正靠谱低延迟的rtmp/rtsp直播播放器苦恼. 鉴于此,大牛直播SDK携手apicloud资深版主,推出apicloud对接方案: apicloud官方链接:https://www.apicloud.com/mod_detail/49069 apicloud对接版本说明:https://docs.apicloud.com/Client-API/Open-SDK/daniuPlayer 相关接口如下: 视沃科技-大牛直播S

视频直播的发展趋势分析

视频直播的分析与发展 在讲视频直播之前,先讲一讲直播.直播是怎么来的呢?从传播消息的角度上来说,视频和文字.图片.音乐一样都是传播消息的手段,古时以文字传播消息,之后出现了图片和音乐,再之后视频开始流行.出现这种演变的原因是什么呢?我想主要是由于读者的需求日益提高和传播技术的不断发展.读者不满足于当前的文字阅读,由此出现了图片与音乐,到后来图片与音乐也无法满足日益增长的需求,则出现了视频.视频具有文字.图片.音乐不具有的优势:传递的信息多,更让人有代入感,给观众更综合的体验.虽然视频有着无可比拟