- 综合排序
- 最热优先
- 最新优先
- 来自专栏音视频技术
FFmpeg代码导读——HEVC在RTMP中的扩展
对于直播而言，大部分推拉流协议是基于RTMP的，因此本文将主要介绍如何在RTMP协议中增加对HEVC视频编码格式的支持。 HEVC在RTMP中的扩展 为推进HEVC视频编码格式在直播方案中的落地，经过CDN联盟讨论，并和主流云服务厂商达成一致，规范了HEVC在RTMP/FLV中的扩展，具体修改内容见下。 4.1 FLV规范扩展 HEVC为视频编码格式，因此对FLV规范的扩展，只集中在Video Tag，其它部分，无任何改动。 扩展后的VideoTagBody如下图所示(红色字体为HEVC新增内容)： 图10. 结束语 本文简单介绍了如何在FFmpeg中扩展rtmp协议对HEVC编码格式的支持，而要将HEVC应用于直播整体方案，除推流端和播放端要提供相应能力外，源站、CDN、转码服务同样都需要提供这种能力。
2.4K20发布于 2021-09-02 - 来自专栏国标视频云平台
SkeyeRTMPPusher推送RTMP扩展支持HEVC(H265)
不久前刚实现SkeyeRTMPPusher扩展支持h265推送，当时在网上也查找了很多资料，发现都不尽详细，而官方也没有更新对HEVC(H265，后文统称HEVC)tag的支持，反正是走了不少弯路，当然 首先， RTMP头部信息封装并没有定义HEVC，我们采用CDN联盟的HEVC扩展标准，将HEVC的VideoTagHeader定义为12，详见下图： 图片 然后，我们在H264封装的基础上进行改进，以支持
54730编辑于 2023-04-23 - 来自专栏国标视频云平台
RTMP推送扩展支持HEVC(H265)之Metadata结构填写详解
鉴于广大码友对上一篇文章RTMP推送扩展支持HEVC(H265)的Metadata数据结构还存在不清楚的地方，这里对RTMP推送Metadata的结构进行详解。 pps data memcpy(&body[i],lpMetaData->Pps,lpMetaData->nPpsLen); i= i+lpMetaData->nPpsLen; 从上一篇文章RTMP 推送扩展支持HEVC(H265)我们了解了HEVCDecoderConfigurationRecord结构： typedef struct HEVCDecoderConfigurationRecord
1.1K10编辑于 2023-04-13 - 来自专栏RTSP/RTMP直播相关
双模式 RTMP H.265 播放器解析：从国内扩展到 Enhanced RTMP 标准的演进
这种设计导致 RTMP 长期以来只能绑定 H.264，难以扩展到 HEVC 等新一代编码标准。Enhanced RTMP 规范 在不破坏现有结构的前提下，引入了以下关键机制：1. 从协议角度来看，Enhanced RTMP 是一种 增量扩展，它没有推倒重建，而是在 RTMP 的原有生态上，补齐了新一代编码器的适配能力。 国内 CDN 厂商联盟的 RTMP-H.265 扩展模式。 双模式支持的背景在 Enhanced RTMP HEVC 出台之前，国内主要 CDN 厂商为了降低带宽成本，已经推出过 RTMP-H.265 扩展方案。 大牛直播SDK的实现方式为了让开发者无需关心不同扩展模式的差异，大牛直播SDK 的 RTMP 播放器实现了 双模式自动识别与解码： 国内联盟扩展模式 识别 CodecID = 12/13（厂商自定义
62100编辑于 2025-08-20 - 来自专栏国标视频云平台
SkeyeRTMPClient拉取RTMP流扩展支持HEVC(H.265)解决方案
不久前我们已经在RTMP推送端扩展支持了HEVC(H.265 后文统称H265)编码格式，但是，由于RTMP官方指定的协议格式已经不再更新，官方的播放器的Flash播放器并不支持H265格式的编码数据进行解码播放 ；现在，我们需要在播放器端解析RTMP流时对H265编码格式进行扩展支持。 首先，我们可以通过扩展ffmpeg，让其支持拉H265封装的RTMP流进行解码播放，我们可以通过金山云对FFmepg的扩展支持H265来解决。 拉流)播放，如下图所示： 图片 我们发现通过网页播放我们推送的基于H265编码的RTMP是播放不了的，而通过SkeyePlayer则成功播放了出来，说明我们通过SkeyeRTMPClient拉取RTMP 流扩展支持H265的方案已经完美解决。
92950编辑于 2023-04-21 - 来自专栏用户1692782的专栏
手撕rtmp协议细节（2）——rtmp Header
rtmp的协议的数据包，总的来讲分为两大部分，一部分是Rtmp Header，另一部分为Rtmp Body，这一篇我们来主要讲解一下Rtmp Header的组织形式。 RTMP header的长度不固定，可能的长度为12字节，8字节，4字节，1字节。具体长度为多少个字节，由RTMP header数据包的第一个字节的高2位决定。 ? 抓包看下，RTMP HEADER的长度。 图中，RTMP Header的第一个字节为0x03，高两位的值为00，所以，整个RTMP Header的长度就是4个字节了。 知道了RTMP header的第一个字节的作用以后，接下来我们看下几种不同长度的RTMP Header。 12字节的RTMP Header ?
4.5K40发布于 2020-05-20 - 来自专栏用户1692782的专栏
手撕Rtmp协议细节（3）——Rtmp Body
上一篇讲了RTMP数据包中关于Header的数据组织格式，不过一个完整的RTMP数据包除了Header之外，紧跟着的是RTMP Body，这一篇就继续来说一下RTMP Body的数据组织结构了。 说到RTMP Body的数据包组织格式，就不得不提到AMF。 那么AMF和RTMP Body又有什么关系呢，不才，RTMP数据包的序列化就是按照AMF的格式进行的。 说完AMF，再回到我们的RTMP Body，RTMP Body就是按照AMF0规范，将数据包进行组织，然后再通过网络发送的。 好了，接下来就结合wireshark实际抓到的RTMP数据包，一起熟悉AMF0，同时也熟悉RTMP Body的数据包组织方式。 先看一下_result的数据包。 ?
3.3K40发布于 2020-05-20 - 来自专栏RTSP/RTMP直播相关
多路RTSP-RTMP转RTMP定制版
大牛直播SDK(Github)多路RTMP/RTSP转RTMP转发软件，系原有转发SDK基础上，官方推出的Windows平台定制版。 如监控类摄像机、NVR等，通过厂商说明或Onvif工具，获取拉流的RTSP地址，图形化配置，完成拉流转发等操作，轻松实现标准RTMP服务器（或CDN）对接。 视频转发支持H.264、H.265（需要RTMP服务器或CDN支持扩展H.265），音频支持配置PCMA/PCMU转AAC后转发，并支持只转发/录制视频或音频，RTSP拉流端支持鉴权和TCP/UDP模式设置和 添加转发项配置信息 [image] 配置说明： 添加配置项：点击页面“添加”按钮： ² 序号：无需关注，系统自动生成； ² 名称：该路转发配置项的描述信息； ² 拉流地址（必须填）：需要转发的RTSP或RTMP 地址； ² 推流RTMP地址：需要转推的RTMP地址； ² 推流播放地址：需要预览的播放地址； ² 音视频转发选项：可选择之转发音频或视频，亦或同时转发音视频； ² 录像参数配置：可选择录制音频或视频，
3.2K30发布于 2019-09-11 - 来自专栏全栈程序员必看
rtmp协议详解_rtmp服务器
前言 最近在学习rtmp协议，在看官方文档的时候总是懵懵懂懂，硬生生看了两天，现在基本上了解rtmp协议了，想用自己觉得比较清晰的方式来讲解rtmp协议，希望能够对向我一样的初学者有所帮助。 1、消息 2、块 3、rtmp的消息类型 4、实例分析rtmp传输过程 一、消息 消息是rtmp的基本数据单元，服务端和客户端通过在网络上发送RTMP消息进行通讯。 basic header 1byte或2byte或3byte 块基本头 chunk msg header 11byte或2byte或3byte 块消息头 extended timestamp 4byte 扩展时间戳 c、扩展时间戳(extended timestamp) 扩展时间戳总共4个字节，只有当块消息头中的普通时间戳设置为0x00ffffff时，本字段才被传送。 示意图如下： 实例分析： 客户端向服务端发送命令消息的”connect命令”： 03：bit[7:8]表示fmt为0，bit[0:6]表示块流ID为3（如果是0，则表示有一个扩展字节；如果是1，则表示有两个扩展字节
3.6K12编辑于 2022-11-01 - 来自专栏linux驱动个人学习
RTMP协议
RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对 多向视频点播服务器直接广播到交互式会议应用程序。 RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。 在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接。 2. 3. rtmp协议握手过程 要建立一个有效的rtmp连接，首先经过”握手”阶段，规则如下： 客户端被指定依次向服务器发送C0,C1,C2三个chunk，服务器向客户端发送S0,S1,S2三个chunk ，大小1字节 版本：8比特，C0:客户端需求的rtmp版本，S0:服务器选择的rtmp版本,如图： 4.2 握手第二阶段： 客户端发送C1包，C1包大小1536字节，格式如下图： time:包含了一个时间戳
1.6K20编辑于 2022-05-10 - 来自专栏性能优化
RTMP协议
变量 file(GLOB rtmp_source *.c) # 编译静态库 add_library(rtmp STATIC ${rtmp_source} ) 在 中导入这个 CMakeLists.txt #XXX需要链接rtmp库 target_link_libraries(XXX rtmp ...) RTMP 视频数据 RTMP 视频流格式与 FLV 很相似，通过查看 FLV 的格式文档，就能够知道 RTMP 视频数据应该怎么拼接。 时戳扩展 1 如果时戳大于 0xFFFFFF，将会存在字节。 ID 3 总是 0 数据区 n 音、视频包 如上图，第一个字节 0x09 表示此段数据为视频，数据大小为 0x00,0x00,0x2F 即 47，时间戳为 0x00,0x00,0x00,时间戳扩展也为
2.2K02发布于 2020-11-24 - 来自专栏媒矿工厂
RTMP：快速深入
本文来自SF Video Tech，来自Mux的工程师Nick Chadwick带来了一场演讲，帮助我们快速深入的了解RTMP协议。 若干年前，RTMP的延迟很低，已接近成为事实上的标准。 由于RTMP还没有消失，我们仍需花一些时间来了解它是如何工作的。 首先是RTMP的简史。 RTMP可以在一个TCP连接上，多路传输更大的消息，比如视频、消息以及非常短的数据请求如RPC。包级的多路复用允许RTMP在发送长消息的同时向另一端询问问题。 因为RTMP有一个硬编码的支持的编解码器列表，这在扩展到新的编解码器时产生了困难。 虽然关于RTMP本身的一切仍然会是正确的，但是当下SRT、RIST和Zixi已经取代了很多RTMP工作流程。
1.1K30发布于 2020-11-02 - 来自专栏FreeSWITCH中文社区
mod_rtmp
基于Flash的实时多媒体通信是基于Adobe的RTMP协议进行的。FreeSWITCH中通过“mod_rtmp”实现了一个基于RTMP协议的Endpoint，可以支持用Flash实现的软电话。 在FreeSWITCH源代码目录中使用如下命令即可安装该模块： # make mod_rtmp-install 在FreeSWITCH控制台上使用“load mod_rtmp”命令加载该模块后， 它将监听RTMP协议默认的1935端口，并等待客户端连接，使用如下命令将可以显示它的该模块的有关状态： freeswitch> rtmp status default tcp:0.0.0.0 :1935 profile 上面的命令显示了有一个RTMP的Profile运行在1935端口上，它也是RTMP服务默认的端口。 在实际使用时，通过在浏览器中访问特定的网页，网页中嵌入Flash软件电话，软电话就可以通过RTMP协议与FreeSWITCH进行连接，即实现了在浏览器中打电话。
2.3K20发布于 2020-12-21 - 来自专栏职场亮哥
rtmp规范1.0
扩展时间戳（0或4字节）：此字段在某些情况下是存在的，取决于消息块消息头中的编码时间戳或时间戳增量字段。 消息块块数据（可变大小）：该块的有效负载，直至配置的最大块大小。 如果时间戳大于或等于16777215（十六进制0xFFFFFF），则该字段必须是16777215，表示存在扩展时间戳字段以编码完整的32位时间戳。 否则，这个字段应该是整个时间戳。 如果增量大于或等于16777215（十六进制0xFFFFFF），则该字段必须是16777215，表示扩展时间戳字段以编码完整的32位增量的形式存在。 否则，这个字段应该是实际的增量。 扩展时间戳 Extended Timestamp字段用于编码大于16777215（0xFFFFFF）的时间戳或时间戳增量; 也就是说，对于时间戳或时间戳增量，它们不适合类型0,1或2块的24位字段。 当相同块流ID的最新类型0,1或2的块指示存在扩展时间戳字段时，该字段出现在类型3的块中。 示例 共有2个示例 示例1 本例给出了一个简单的音频消息流，这个例子示范了信息的冗余。 ?
2K23发布于 2020-10-10 - 来自专栏SRS开源服务器
RTMP协议优化
RTMP协议是基于TCP的协议，将应用层的消息分割成chunk用tcp发送，除了增大chunk到很大的数避免分片譬如60000，还可以优化发包方式，将很多小包组合到一起了一次发送给客户端，避免每个小包分开发送 先看一个没有优化的例子，一个知名的cdn的rtmp的序列，一共花了39个TCP包才开始传输数据包，前面都是磨磨唧唧的rtmp握手和交互： SRS对于RTMP已经做了优化，组合了一些小包，可以减少大约10
91920编辑于 2022-03-18 - 来自专栏SRS开源服务器
复活RTMP：和OBS支持RTMP HEVC新标准
How to Push HEVC via RTMP by OBS Written by Winlin, chundonglinlin OBS 29.1支持RTMP的HEVC，所以你现在可以用OBS和SRS 现在，RTMP支持HEVC出新标准了，详见Enhanced RTMP。这个标准定义了一个新的codec ID，用于HEVC，即fourCC hvc1， OBS和SRS都支持这个标准。 你可以给FFmpeg打补丁，支持RTMP的HEVC，参考FFmpeg HEVC SRS支持HEVC WebRTC，支持的是Safari浏览器，但SRS不支持RTMP转WebRTC，我们正在开发中了。 One More Thing 往事如烟，6年前给FFmpeg提过FFmpeg RTMP HEVC，但是当时FFmpeg社区说RTMP标准没有支持，所以FFmpeg也不支持。 其实后来给Adobe写过邮件，问过是否RTMP会更新的问题。Adobe回复说正在考虑更新RTMP标准。这一考虑就是6年过去了，不过终于也支持了。
2.8K20编辑于 2023-04-16 - 来自专栏RTSP/RTMP直播相关
如何在RTMP推送端和RTMP播放端支持Enhanced RTMP H.265(HEVC)
RTMP要支持H.265，大家约定俗成的做法是扩展flv协议，CDN厂商携手给出的解决方案是给flv的videotag CodecID增加一个新类型(12)来表示h265(hevc)，和h264不同的地方是要解析 技术实现本文以大牛直播SDK的Windows平台RTMP直播推送和RTMP直播播放模块为例，考虑到老的扩展CodecID 12的场景依然使用，我们添加了个设置接口：RTMP推送端，对应文件为SmartPublisherSDK 1，那就是扩展头，Enhanced-Rtmp格式。 推流URL，实现Enhanced RTMP推送，播放端拉流播放，整体延迟如下：可以看到，尽管开启了Enhanced RTMP，整体延迟还在毫秒级。 技术总结鉴于目前RTMP扩展265这块，大多还是用的老的CodecID设置为12的模式，如果需要支持新的Enhanced RTMP，除了推送端和播放端外，RTMP服务端也需要做响应的调整，来适配这种情况
1.1K10编辑于 2024-03-05 - 来自专栏测试工程师成长之道
实时视频RTMP
实时视频rtmp 背景: 由于经常接触实时视频, 对实时视频略有了解. 实时视频是将视频流实时上传到服务器端进行解析, 由RTMP服务器处理. 安装RTMP 服务器 自己动手搭建一个rtmp, 本文在 Linux环境中搭建 去git上clone 一个下来https://github.com/arut/nginx-rtmp-module 解压后安装即可 /nginx-rtmp-module/test下配置文件nginx.conf, GitHub上就是这个结构, 我们这里不做改动. ? 作用是指定端口号和文件目录 ? 配置文件修改完成后推荐重启server nginx:nginx -s reload 检查RTMP是否生效 浏览器中输入:http://+服务器ip+端口+stat 浏览器中出现下图，则表示rtmp服务生效了 将地址放在VLC network中rtmp://10.10.10.10:8001/live/test 即可查看推流视频 ?
3.5K52发布于 2019-07-30 - 来自专栏RTSP/RTMP直播相关
如何实现Android端获取RTSP或RTMP流转推RTMP
技术背景 最近不少开发者找到我们，他们在做智能家居等传统行业时，希望实现在Android板件拉取本地的RTSP或RTMP流，然后对外推送RTMP出去，亦或内部启个轻量级RTSP服务，提供个对外对接的媒介 拉流：通过RTSP|RTMP直播播放SDK的数据回调接口，拿到音视频数据； 2. 转推：通过RTMP直播推送SDK的编码后数据输入接口，把回调上来的数据，传给RTMP直播推送模块，实现RTSP|RTMP数据流到RTMP服务器的转发； 3. 整体网络状态反馈：考虑到有些摄像头可能会临时或异常关闭，RTMP服务器亦是，可以通过推拉流的event回调状态，查看那整体网络情况，如此界定：是拉不到流，还是推不到RTMP服务器； 10. 设置RTMP、RTSP拉流的URL； 2. 设置转推RTMP的URL； 3. 实时播放|录像过程中，实时静音、实施快照； 4. 实时播放； 5. 实时录像； 6.
3.6K10发布于 2021-04-06 - 来自专栏全栈程序员必看
rtsp、rtmp测试地址
有时需要rtsp、rtmp测试地址时，网上搜出来的都是千篇一律的已停用的测试地址，因此在这里维护一个播放列表，随缘更新（发现新的地址可以在评论区留言） 【last update】2022 已停用) rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4 (可用) 可自行使用live555搭建rtsp服务器 [rtmp ] 1、湖南卫视 rtmp://58.200.131.2:1935/livetv/hunantv (已停用) 2、广西卫视 rtmp://58.200.131.2:1935/livetv/gxtv (已停用) 3、广东卫视 rtmp://58.200.131.2:1935/livetv/gdtv (已停用) 4、东方卫视 rtmp://58.200.131.2:1935/livetv/dftv
8.4K10编辑于 2022-11-01
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号