1.RTMP 视频数据封装
2.FFmpeg学习(一)开篇
3.开源视频解决方案?
4.音视频流媒体开发系列(78)ffmpeg实战教程(一)Mp4,mkv等格式解码为h264和yuv数据
5.RTMP推流方案总结
6.流媒体客户端RTMP拉流保存h264(flv保存为h264)
RTMP 视频数据封装
RTMP协议,是一个基于TCP的实时消息传输协议,由Adobe Systems公司开发,用于Flash播放器和服务器之间的音频、视频和数据传输。传奇4区块链游戏源码大全在国内,RTMP广泛应用于直播领域,其默认端口为,与HTTP的默认端口不同。通过阅读Adobe的协议规范并建立与服务器的TCP通信,按照协议格式生成和解析数据,即可使用RTMP进行直播操作,或者使用实现了RTMP协议的开源库来实现这一过程。
RTMPDump是一个开源工具包,专门用于处理RTMP流媒体。它能独立运行进行RTMP通信,也可以通过FFmpeg接口集成到FFmpeg中使用。RTMPDump的源代码可以从rtmpdump.mplayerhq.hu/d...下载。为了在Android中直接调用RTMPDump进行RTMP通信,需要在JNI层进行交叉编译。RTMPDump的源代码结构包括Makefile和一系列.c源文件。编译过程需要通过CMakeLists.txt进行,将其放入AS中,复制librtmp到src/main/cpp/librtmp,并编写CMakeLists.txt,导入app/CMakeLists.txt。
RTMP视频流格式与FLV很相似,理解FLV的格式文档可以帮助我们构建RTMP视频数据。RTMP中的数据由FLV的TAG中的数据区组成。在FLV中,第一个字节表示数据类型,如0x表示视频,数据大小为字节,时间戳和流ID分别由后续的字节表示,最后的字节表示数据块的总大小。在AVCVIDEOPACKET中,数据结构与类型决定了后续数据的内容,包括版本、合成时间、SPS与PPS等关键信息。在构建AVC序列头和非AVC序列头时,需要注意数据的类型区分。
H.码流在网络中传输时以NALU(Network Abstract Layer Unit)的形式进行。NALU是NAL(Network Abstract Layer)单元,是H.编码标准中的一个概念。编码后的H.数据被分割为多个NAL单元,每个单元包含了视频帧的京东首页装修源码一部分信息。在将数据封装到RTMP包中时,需要去除分隔符,然后将NAL数据加入到RTMPPacket中。完整的封包代码需要将这些步骤结合在一起实现。
综上所述,理解RTMP协议、RTMPDump的使用以及如何在不同环境下构建RTMP视频数据和封装H.数据是进行实时流媒体传输的关键步骤。正确地使用这些工具和技术,能够有效地实现直播和视频流的传输。
FFmpeg学习(一)开篇
为什么要学习FFmpeg?本人希望深入研究音视频领域,音视频领域内容丰富,我计划从多个方面逐步学习:FFmpeg常用功能实践、FFmpeg源码研究、OpenGL、OpenGLES、Metal、AR、WebRTC、直播架构等。
当前音视频有哪些应用场景?从众多应用场景可以看出,音视频技术至关重要,尤其在5G时代,网络传输问题得到极大提升,音视频需求将爆发式增长。以下是一个简单播放器架构图:
音频解码和视频解码一般使用FFmpeg解码,iOS8之后提供了VideoToolBox框架支持硬解码。视频渲染通常使用OpenGL直接利用GPU渲染,还有GPUImage、SDL、VLC等第三方框架。
音视频播放中的音视频同步是一项复杂的技术。学习一项技术需要高效的方法,只有不断实践才能深刻理解。学习FFmpeg也需要好的文档,以下列举一些必备的学习文档地址:
以上都是英文文档,如果英文学习困难,可以参考以下中文资料:
此外,推荐两本非常好的书籍:
相关学习资料推荐,点击下方链接免费报名,先码住不迷路~
1. FFmpeg简介:FFmpeg是一套用于记录、转换数字音频、视频并将其转化为流的开源计算机程序。采用LGPL或GPL许可证。它提供了录制、转换以及流化音视频的完整解决方案。它包含了非常先进的音频/视频编解码库libavcodec,为了保证高可移植性和编解码质量,付费拆红包源码libavcodec里很多code都是从头开发的。FFmpeg在Linux平台下开发,但也可以在其他操作系统环境中编译运行,包括Windows、Mac OS X等。这个项目最早由Fabrice Bellard发起,年至年间由Michael Niedermayer主要负责维护。许多FFmpeg的开发人员都来自MPlayer项目,当前FFmpeg也是放在MPlayer项目组的服务器上。项目的名称来自MPEG视频编码标准,前面的"FF"代表"Fast Forward"。
2. FFmpeg能做什么
3. FFmpeg架构模块组成:我们先看一张FFmpeg的架构图:
下载好的源码,我们也可以看到大致的源码结构:
3.1 libavutil
3.2 libavformat
FFmpeg是否支持某种媒体封装格式,取决于编译时是否包含了该格式的封装库。根据实际需求,可进行媒体封装格式的扩展,增加自己定制的封装格式,即在AVFormat中增加自己的封装处理模块。
3.3 libavcodec
AVCodec中实现了目前多媒体绝大多数的编解码格式,既支持编码,也支持解码。AVCodec除了支持MPEG4、AAC、MJPEG等自带的媒体编解码格式之外,还支持第三方的编解码器,如H.(AVC)编码,需要使用x编码器;H.(HEVC)编码,需要使用x编码器;MP3(mp3lame)编码,需要使用libmp3lame编码器。如果希望增加自己的编码格式或硬件编解码,则需要在AVCodec中增加相应的编解码模块。
3.4 libavfilter
3.5 libavdevice
3.6 libswscale
3.7 libpostproc
3.8 libswrressample
3.9 ffmpeg
3. ffsever
3. ffplay
4. FFmpeg安装:下载源码后,我们可以查看一下目录结构:
输入./configure --help命令查看配置信息
内容太多需要分页,输入./configure --help | more
从上面的帮助,我们可以尝试输入:./configure --list-decoders查看所有解码器
接下来我们可以尝试输入:./configure --list-encoders查看所有编码器
接下来我们可以尝试输入:./configure --list-filters查看所有滤镜器
接下来我们可以尝试输入:./configure --list-muxers查看FFmpeg的封装,封装Muxing是指将压缩后的编码封装到一个容器格式中,我们输入./configure --list-muxers来查看FFmpeg支持哪些容器格式:
从上面打印信息来看,FFmpeg支持生成裸流文件,如H.、AAC、PCM,也支持一些常见的格式,如MP3、MP4、FLV、M3U8、WEBM等。我的王朝源码
从上面解封装又称为解复用格式的支持信息中可以看到,FFmpeg支持的demuxter非常多,包含image、MP3、FLV、MP4、MOV、AVI等。
从支持的协议列表中可以看到,FFmpeg支持的流媒体协议比较多,包括MMS、HTTP、HTTPS、HLS、RTMP、RTP,甚至支持TCP、UDP,它还支持使用file协议的本地文件操作和使用concat协议支持的多个文件串流操作。
接下来我们可以尝试输入:./configure --list-parsers查看FFmpeg支持的解析器
接下来我们可以尝试输入:./configure --list-bsfs查看FFmpeg支持的字节流过滤器
接下来我们可以尝试输入:./configure --list-indevs查看有效的输入设备
接下来我们可以尝试输入:./configure --list-outdevs查看有效的输出设备
开源视频解决方案?
探索开源视频解决方案:Yangwebrtc、Licode、Janus与Mediasoup的比较</ 在构建音视频系统时,开源技术无疑提供了快速而经济的途径,然而也伴随着技术债务的可能。让我们深入剖析 Yangwebrtc、Licode、Janus-gateway 和 Mediasoup 这四大开源解决方案,以帮助你做出明智的选择。Yangwebrtc
自主研发的结晶:</Yangwebrtc 以其自定义的Webrtc/Srt/Rtmp架构而闻名,适用于教育、医疗等多元化应用场景。它的优点在于编译简单,适合中国本土生态,但谷歌Lib的问题和复杂的编译过程可能成为挑战。Licode
全面的SFU/MCU平台:</Licode 不仅提供媒体通信和用户管理等基础功能,还支持分布式部署。其亮点在于无需二次开发,社区活跃。然而,Linux支持有限,代码结构复杂,Android/iOS SDK支持有限,性能方面略逊一筹。Janus-gateway
WebRTC服务器中的明星:</Janus以其C语言编写的WebRTC服务器而著名,尤其适合Linux环境。社区交流可能局限,但其源码清晰,app源码定制开发部署指南详细,链接如下:/meetecho/janus-gateway,部署步骤详尽。 Janus的优势在于其插件式架构,支持SIP、TextRoom和Streaming等多种插件,传输层兼容多种协议,性能卓越。然而,复杂性高和异步I/O处理机制的局限性也需留意。Mediasoup
Mediasoup,由Node.js和C++打造,专为WebRTC流媒体服务器设计。它关注底层数据传输,性能高效,WebRTC优化明显。与Janus相比,Mediasoup在实时性和效率上更胜一筹。其他选项
Medooze以其全面的功能而闻名,但C++开发的Mediasoup在性能上略优。Jitsi以其丰富的组件如Video-Bridge和活跃的社区吸引开发者,Kurento则凭借成熟的C++开发和详尽的文档吸引成熟项目。对于Go语言爱好者,pion/webrtc是个学习的好选择。决策建议
选择哪种方案,关键在于团队的技术熟悉度、项目需求、业务规模、分布式支持的考虑、二次开发的灵活性、时间限制以及社区的活跃度。务必在投入前进行彻底的测试和研究,确保选择最适合的开源视频解决方案。音视频流媒体开发系列()ffmpeg实战教程(一)Mp4,mkv等格式解码为h和yuv数据
在这个FFmpeg实战教程中,我们将探索如何将常见的视频格式如MP4和MKV解码为H和YUV数据。首先,让我们来看一个实例,通过运行解码过程,你将看到两个文件的生成,分别对应解码后的h和YUV数据,其中h由于采用了高效的压缩技术,文件大小明显小于YUV文件。 解码流程包括以下步骤:首先,将ws.mp4文件复制到项目目录,然后创建两个输出文件。接下来,初始化所需的组件,接着打开视频文件,获取视频信息并选择合适的解码器。在解码过程中,要注意av_read_frame()循环结束后可能遗留少量帧数据,这时需要调用flush_decoder函数,将这些帧数据完整输出。 下面是源代码示例,展示如何执行这些操作:拷贝ws.mp4并创建输出文件
初始化解码器和相关组件
打开和解码视频
使用flush_decoder确保所有帧数据都被处理
运行程序后,你将看到生成的h和YUV文件。如果你对音视频开发感兴趣,可以关注我们的免费学习资源,包括FFmpeg、WebRTC、RTMP、NDK和Android高级开发等内容。群文件中提供了详细的面试题、学习资料和教学视频,以及学习路线图,点击加群获取,希望能对你有所帮助。 对于Windows用户,需要配置FFmpeg环境。首先从ffmpeg.zeranoe.com下载相应版本的shared和dev版本,然后将include和lib文件夹分别复制到指定位置,最后在MinGW命令行中执行命令。而对于Linux或MacOS用户,可以在GCC命令行环境中进行操作。RTMP推流方案总结
RTMP协议简介,其全称为Real Time Messaging Protocol,是由Adobe Systems公司为Flash播放器与服务器之间音频、视频和数据传输开发的私有协议。RTMP协议像一个容器,用于装载AMF格式的数据或FLV中的视/音频数据,一个连接可通过不同的通道传输多路网络流,通道中的包遵循固定大小的传输规则。更多协议细节请参考《rtmp specification 1.0》。
RTMP服务器的选择有多种开源方案,如Nginx的rtmp插件,用于实时流推送,具体实现可参考另一篇博客。SRS(Simple RTMP Server)是一款国人开发的优秀开源流媒体服务器软件,使用C++开发,适用于直播、录播、视频客服等场景,提供丰富的接入方案和流变换功能,GitHub源码链接为:github.com/ossrs/srs。
crtmpserver是一款由C++语言编写的开源RTMP流媒体服务器,功能相对简单,与Flash Player的兼容性较差,但代码结构良好,适用于学习RTMP协议和服务器端编程。GitHub源码链接为:github.com/shiretu/crtm...。
livego是基于Go语言的RTMP直播服务器,Go语言为服务器性能而生,开发效率高于C/C++。GitHub源码链接为:github.com/gwuhaolin/liv...
基于Go的livego服务器解决了语言级别上的并发问题。node-rtsp-rtmp-server是使用Node.js实现的RTMP服务器,GitHub源码链接为:github.com/iizukanao/nod...
测试时,推荐使用大牛直播提供的推流工具,也可以使用FFmpeg进行推流。
RTMP推流器的选择同样多样,librtmp软件包含一个基本的客户端:rtmpdump,以及提供RTMP协议支持的库。FFmpeg也能实现RTMP推流,内部集成了librtmp,官方给出了muxing.c源代码示例。srs-librtmp是srs提供的一个RTMP库,可以推送H数据,但在Windows环境下存在兼容性问题。
音视频开发相关教程与资料可免费订阅QQ群:,领取学习资源。
流媒体客户端RTMP拉流保存h(flv保存为h)
librtmp是通过调用int RTMP_Read(RTMP *r, char *buf, int size); 来拉取流,直接得到的流是flv格式,保存后即可播放。
RTMP_Read内部调用Read_1_Packet,其功能是从网络上读取一个RTMPPacket的数据,RTMP_Read在此基础上增加了个字节的flv头。
在librtmp的源码中,可以看到flv头信息。
flv头实际只有9个字节,但为何是个字节?因为除了9个字节的flv头外,还有多个Tag,每个Tag的开头有4个字节表示上一个Tag的长度,即使是第一个Tag也需填充这4个字节,以匹配源码中的flvHeader。
srs_librtmp是通过srs v2.0-r6版本(v2.0-r7版本加入了ipv6功能,但连接rtmp服务器时总是失败,可能是个人使用不当)来拉流并保存为flv文件。
从srs导出的srs_librtmp客户端详情见github.com/ossrs/srs/wiki...,导出后,在research/librtmp下有作者编写的demo,其中srs_rtmp_dump.c用于从rtmp服务器拉流并保存为flv文件。
以下是简化版的demo源码,我注释了自己的理解,若有错误请指正。在vs下此代码能编译运行,但在linux下能正常播放。
主要讲述了flv头信息的结构,srs_librtmp源码中srs_flv_write_tag通过data封装成Tag并写入flv文件,srs_rtmp_read_packet读取的数据是flv文件中的tag data。
Tag data分为Audio、Video、Script三种,这里仅讲解Video Tag Data。
VideoTagHeader的第一个字节包含了视频帧类型及视频CodecID的基本信息。VideoTagHeader之后跟着的是VIDEODATA数据,即video payload,对于H.格式的视频,VideoTagHeader会额外包含4个字节的信息。
AVCPacketType和CompositionTime。AVCPacketType表示VIDEODATA的内容类型:若AVCPacketType为0,则为AVCDecoderConfigurationRecord(H.序列头);若为1,则为一个或多个NALU(完整帧是必需的)。
AVCDecoderConfigurationRecord包含H.解码相关的sps和pps信息,解码器在送数据流之前必须送出sps和pps信息,否则解码器不能正常解码。在解码器停止后再次开始之前,如seek、快进快退状态切换等,都需要重新送出sps和pps的信息。AVCDecoderConfigurationRecord在FLV文件中通常只出现一次,即第一个video tag,但有些视频流的sps和pps可能会发生变化,所以可能会出现多次。
Composition Time用于告知渲染器视频帧进入解码器后多长时间在设备上显示。在flv格式中,timestamp用于告知帧何时提供给解码器,单位为毫秒。Composition Time告诉渲染器视频帧显示的时间,因此compositionTime = (PTS - DTS) / .0。
总结如下:使用srs_librtmp拉流,拉取的数据为一个又一个的Tag Data,可通过type与宏值比较判断Tag Data是否为Video Tag Data。连接rtmp服务器拉流时收到的第一个Video Tag Data通常包含PPS和SPS信息。对于每个h编码的Video Tag Data,会多出4个字节的AVCPacketType和CompositionTime,其中CompositionTime用于B帧,这里暂时忽略它,我们仅支持P帧和I帧。Frame Type在h编码中只能是1或2,Frame Type == 1表示关键帧或包含PPS和SPS信息的Video Tag Data。CodecID在h编码中只能是7(AVC)。当AVCPacketType == 0时,Video Tag Data包含SPS和PPS信息;当AVCPacketType == 1时,为帧数据。
获取PPS和SPS信息非常关键,如果不告知解码器,根本无法播放视频。我写了一段代码,虽然技术有限,但希望能帮助到您。
AVCPacketType为1表示Video Tag Body的内容是NALU。Frame Type为1表示NALU内容是关键帧,Frame Type为2表示NALU内容是非关键帧。NALU的开头的4个字节表示NALU的长度(nalu_length),nalu_length之后是一个字节的nalu header。
nalu header中nal_ref_idc表示优先级,范围在~(2进制),值越大表示越重要。值指示NAL单元的内容不用于重建影响图像的帧间图像预测。对于nal_unit_type为6、9、、、的NAL单元,H.规范要求NRI的值应该为0。对于nal_unit_type等于7、8(指示顺序参数集或图像参数集)的NAL单元,H.编码器应设置NRI为(二进制格式)。nal_unit_type表示nalu类型,SPS开头是0x(nal_ref_idc为3,nal_unit_type为7),PPS开头是0x(nal_ref_idc为3,nal_unit_type为8),关键帧开头是0x(nal_ref_idc为3,nal_unit_type为5),非关键帧开头是0x(nal_ref_idc为2,nal_unit_type为1)。nal_unit_type为5表示idr帧,idr帧具有随机访问能力,所以每个idr帧前需要加上sps和pps。startcode起始码。
H.原始码流由一个一个的NALU组成,其结构包括起始码(0x或0x,取决于编码器实现)和数据。具体何时使用3个字节的起始码,何时使用4个字节的起始码,这个我没有完全弄明白,资料中提到具体哪种开头取决于编码器实现。0x是NAL起始前缀码,解码器检测每个起始码,作为NAL的起始标识,当检测到下一个起始码时,当前NAL结束。同时H.规定,当检测到0x时,也可以表示当前NAL的结束。对于NAL中数据出现0x或0x时,H.引入了防止竞争机制,如果编码器检测到NAL数据存在0x或0x时(非起始码,而是真正的音视频数据),编码器会在最后个字节前插入一个新的字节0x,这样当遇到0x或0x时就一定是起始码了。解码器检测到0x时,把抛弃,恢复原始数据。因此,组装H的步骤如下:读取tag data并判断是否是video tag data,判断frameType和AVCPacketType,区分video tag data是AVCDecoderConfigurationRecord还是NALU,如果是AVCDecoderConfigurationRecord则解析PPS和SPS保存在内存中并加上startcode(我这里加的是0x),如果是NALU,则判断nal_unit_type(有些NALU的流比较奇怪,依然包含PPS、SPS信息,甚至还有SEI信息)。switch case根据不同的nal_unit_type来解析,并加上startcode。如果nal_unit_type == 0x,则是idr帧,需要加上PPS和SPS信息(即一个idr通常包含3个startcode,SPS一个PPS一个idr帧数据一个)。
以下是完整代码:
rtmpTo.h
rtmpTo.cpp
main.cpp
原文链接:blog.csdn.net/qq_...