栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 系统运维 > 运维 > Linux

关于linux下librtmp推流开发的几点思考

Linux 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

关于linux下librtmp推流开发的几点思考

关于linux下librtmp推流开发的几点思考
  • 1阻塞和非阻塞的问题
  • 2发送音频G711A的问题
  • 3视频帧推流抓包的问题
  • 4librtmp库writeN源码的问题

1阻塞和非阻塞的问题

库架构是阻塞的,目前如果将socket全改为非阻塞出现一堆问题,因为我主要使用推流的功能,所以考虑只把send用非阻塞,增加发送失败的errno判断,如果全部改为非阻塞,好像代码改动量挺大?connect的错误处理、send、recv的处理都要添加东西。

2发送音频G711A的问题

我单纯发送G711A的数据,可能是我的服务器兼容性有问题,无法解析出有音频的存在,所以客户端完全没有声音,AAC的音频就正常,直到我在G711A数据的第一个包,也发送一个AAC的audio tag(4个字节),神奇的事情发生了,居然能听到声音了,用ffmpeg拉流,居然显示有AAC和PCMA两个通道,奇葩。所以,有没有好的兼容性强的服务器和客户端推荐。

3视频帧推流抓包的问题

我推流的是从IPC出的H264、H265和音频帧,发现用wireshark抓包的时候会出现许多unknow的包,都很小,非常奇怪。如果用雷神的代码和他那个h264推流就全是正常的video包,只要我换成其他的H264视频文件,或者IPC出流的实时帧就会有乱七八槽的数据包,这个包的包头也不符合RTMP的协议,我就很纳闷,现在还没找出原因来。。。

4librtmp库writeN源码的问题

很奇怪,librtmp中那个writeN函数虽然底层调用的send是阻塞的第四个参数是0且全局socket不是非阻塞的,但是他的逻辑又是非阻塞的逻辑,while循环中判断已发送的字节是否达到预期发送的数量,没有的话是continue继续执行while循环的,这不是典型非阻塞的逻辑吗。。。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/345627.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号