ffmpeg-php如何在windows apache下进行配置

ffmpeg-php我之前也是一直没配置成功，后来干脆直接用ffmpeg，用php（我后来是用的go语言）执行它，这样就不用配置了，另外如果想找编程方面的视频教程可以去 v8视频 看看

公司主营业务：成都网站建设、网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联公司推出阜宁免费做网站回馈大家。

FFmpeg音视频的基础名词解释

是指视频文件在单位时间内使用的数据流量，也叫码率或码流率，通俗一点的理解就是取样率,是视频编码中画面质量控制中最重要的部分，一般我们用的单位是kb/s或者Mb/s。一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内取样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。

当然，码流越大，文件体积也越大，其计算公式是文件体积=时间X码率/8。例如，网络上常见的一部90分钟1Mbps码流的720P RMVB文件，其体积就=5400秒×1Mb/8=675MB。通常来说，一个视频文件包括了画面及声音，例如一个RMVB的视频文件，里面包含了视频信息和音频信息，音频及视频都有各自不同的采样方式和比特率，也就是说，同一个视频文件音频和视频的比特率并不是一样的。而我们所说的一个视频文件码流率大小，一般是指视频文件中音频及视频信息码流率的总和。以以国内最流行，大家最熟悉的RMVB视频文件为例，RMVB中的VB，指的是VBR，即Variable Bit Rate的缩写，中文含义是可变比特率，它表示RMVB采用的是动态编码的方式，把较高的采样率用于复杂的动态画面(歌舞、飞车、战争、动作等)，而把较低的采样率用于静态画面，合理利用资源，达到画质与体积可兼得的效果。

我的理解码流就是视频/音频文件的每秒的大小，码率越高文件越大，呈现出来的失帧也就越低

采样率（也称为采样速度或者采样频率）定义了每秒从连续信号中提取并组成离散信号的采样个数，它用 赫兹 （Hz）来表示。采样率是指将模拟信号转换成数字信号时的采样频率，也就是单位时间内采样多少点。一个采样点数据有多少个比特。比特率是指每秒传送的比特(bit)数。单位为 bps(Bit Per Second)，比特率越高，传送的数据越大，音质越好.比特率 =采样率 x 采用位数 x声道数.

采样率类似于动态影像的帧数，比如电影的采样率是24赫兹，PAL制式的采样率是25赫兹，NTSC制式的采样率是30赫兹。当我们把采样到的一个个静止画面再以采样率同样的速度回放时，看到的就是连续的画面。同样的道理，把以44.1kHZ采样率记录的CD以同样的速率播放时，就能听到连续的声音。显然，这个采样率越高，听到的声音和看到的图像就越连贯。当然，人的听觉和视觉器官能分辨的采样率是有限的，基本上高于44.1kHZ采样的声音，绝大部分人已经觉察不到其中的分别了。而声音的位数就相当于画面的颜色数，表示每个取样的数据量，当然数据量越大，回放的声音越准确，不至于把开水壶的叫声和火车的鸣笛混淆。同样的道理，对于画面来说就是更清晰和准确，不至于把血和西红柿酱混淆。不过受人的器官的机能限制，16位的声音和24位的画面基本已经是普通人类的极限了，更高位数就只能靠仪器才能分辨出来了。比如电话就是3kHZ取样的7位声音，而CD是44.1kHZ取样的16位声音，所以CD就比电话更清楚。

我的理解采样率就是每秒采集音视频的点，比如我们通常说的8k 16k与44100

比特率是指每秒传送的比特(bit)数。单位为bps(Bit Per Second)，比特率越高，传送的数据越大。在视频领域,比特率常翻译为码率 比特率是指每秒传送的比特(bit)数。单位为bps(Bit Per Second)，比特率越高，传送的数据越大。在视频领域,比特率常翻译为码率 !!!

比特率表示经过编码（压缩）后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；如果比特率越少则情况刚好相反。比特率是指将数字声音、视频由模拟格式转化成数字格式的采样率，采样率越高，还原后的音质、画质就越好。

我的理解是比特率与采样率概念相同，不过采样率是压缩前的比特率是压缩后的

VBR（Variable Bitrate）动态比特率 也就是没有固定的比特率，压缩软件在压缩时根据音频数据即时确定使用什么比特率，这是以质量为前提兼顾文件大小的方式，推荐编码模式；

ABR（Average Bitrate）平均比特率 是VBR的一种插值参数。LAME针对CBR不佳的文件体积比和VBR生成文件大小不定的特点独创了这种编码模式。ABR在指定的文件大小内，以每50帧（30帧约1秒）为一段，低频和不敏感频率使用相对低的流量，高频和大动态表现时使用高流量，可以做为VBR和CBR的一种折衷选择。

CBR（Constant Bitrate），常数比特率 指文件从头到尾都是一种位速率。相对于VBR和ABR来讲，它压缩出来的文件体积很大，而且音质相对于VBR和ABR不会有明显的提高。

帧速率也称为FPS(Frames PerSecond)的缩写——帧/秒。是指每秒钟刷新的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次。越高的帧速率可以得到更流畅、更逼真的动画。每秒钟帧数(FPS)越多，所显示的动作就会越流畅。

就是俗称的每秒多少帧，例如我们众所周知的动画24帧/每秒

就是帧大小每一帧就是一副图像。

在手机上呈现的画面，第一帧与第二帧的图像中肯定有很多相同的画面，比如在一个固定的场所，背景不动，只有人物移动的情况，这时只需要重新绘制人物的移动就可以，背景不用重新绘制。IPB帧就是用于处理这种情况。

I帧:帧内编码帧 ，I帧表示关键帧，你可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成（因为包含完整画面）

P帧:前向预测编码帧。P帧表示的是这一帧跟之前的一个关键帧（或P帧）的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。（也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据）

P帧的预测与重构:P帧是以I帧为参考帧,在I帧中找出P帧“某点”的预测值和运动矢量,取预测差值和运动矢量一起传送。在接收端根据运动矢量从I帧中找出P帧“某点”的预测值并与差值相加以得到P帧“某点”样值,从而可得到完整的P帧。

B帧:双向预测内插编码帧。B帧是双向差别帧，也就是B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况，但我这样说简单些），换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时CPU会比较累。

B帧的预测与重构

B帧以前面的I或P帧和后面的P帧为参考帧,“找出”B帧“某点”的预测值和两个运动矢量,并取预测差值和运动矢量传送。接收端根据运动矢量在两个参考帧中“找出(算出)”预测值并与差值求和,得到B帧“某点”样值,从而可得到完整的B帧。

1）B帧是由前面的I或P帧和后面的P帧来进行预测的;

2）B帧传送的是它与前面的I或P帧和后面的P帧之间的预测误差及运动矢量;

3）B帧是双向预测编码帧;

4）B帧压缩比最高,因为它只反映丙参考帧间运动主体的变化情况,预测比较准确;

5）B帧不是参考帧,不会造成解码错误的扩散。

我找了篇文章，可以更好的理解H264

H264基础简介

在视频编码序列中，GOP即Group of picture（图像组），指两个I帧之间的距离，Reference（参考周期）指两个P帧之间的距离（如下图3.1）。一个I帧所占用的字节数大于一个P帧，一个P帧所占用的字节数大于一个B帧（如下图3.1所示）。

所以在码率不变的前提下，GOP值越大，P、B帧的数量会越多，平均每个I、P、B帧所占用的字节数就越多，也就更容易获取较好的图像质量；Reference越大，B帧的数量越多，同理也更容易获得较好的图像质量。需要说明的是，通过提高GOP值来提高图像质量是有限度的，在遇到场景切换的情况时，H.264编码器会自动强制插入一个I帧，此时实际的GOP值被缩短了。另一方面，在一个GOP中，P、B帧是由I帧预测得到的，当I帧的图像质量比较差时，会影响到一个GOP中后续P、B帧的图像质量，直到下一个GOP开始才有可能得以恢复，所以GOP值也不宜设置过大。同时，由于P、B帧的复杂度大于I帧，所以过多的P、B帧会影响编码效率，使编码效率降低。另外，过长的GOP还会影响Seek操作的响应速度，由于P、B帧是由前面的I或P帧预测得到的，所以Seek操作需要直接定位，解码某一个P或B帧时，需要先解码得到本GOP内的I帧及之前的N个预测帧才可以，GOP值越长，需要解码的预测帧就越多，seek响应的时间也越长。

DTS（Decoding Time Stamp）：即解码时间戳，这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。

PTS（Presentation Time Stamp）：即显示时间戳，这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

这2个概念经常出现在音频视频编码和播放中，其实际意义是，PTS是真正录制和播放的时间戳，而DTS是解码的时间戳。

对于普通的无B桢视频(H264 Baseline或者VP8)，PTS/DTS应该是相等的，因为没有延迟编码。

对于有B桢的视频，I桢的PTS依然等于DTS, P桢的PTSDTS, B桢的PTSDTS。

可以简单地这样理解：

若视频没有B帧，则I和P都是解码后即刻显示。

若视频含有B帧，则I是解码后即刻显示，P是先解码后显示，B是后解码先显示。（B 和P的先、后是相对的）。

上面说了视频帧、DTS、PTS 相关的概念。我们都知道在一个媒体流中，除了视频以外，通常还包括音频。音频的播放，也有 DTS、PTS 的概念，但是音频没有类似视频中 B 帧，不需要双向预测，所以音频帧的 DTS、PTS 顺序是一致的。

音频视频混合在一起播放，就呈现了我们常常看到的广义的视频。在音视频一起播放的时候，我们通常需要面临一个问题：怎么去同步它们，以免出现画不对声的情况。

要实现音视频同步，通常需要选择一个参考时钟，参考时钟上的时间是线性递增的，编码音视频流时依据参考时钟上的时间给每帧数据打上时间戳。在播放时，读取数据帧上的时间戳，同时参考当前参考时钟上的时间来安排播放。这里的说的时间戳就是我们前面说的 PTS。实践中，我们可以选择：同步视频到音频、同步音频到视频、同步音频和视频到外部时钟。

rtsp流浏览器播放方案

rtsp流在主流浏览器并不支持直接播放。比如大华的视频流：rtsp://admin:123456@

192.168.10.129/cam/realmonitor?channel=1subtype=0，用vlc可以直接播放。但在浏览器会报ERR_UNKNOWN_URL_SCHEME。那如何在浏览器中播放呢。

以下列出几种方案。

1、安装插件（chrome最新版基本都不支持）

类如：kurento，vlc插件（谷歌浏览器版本41以下),vgx插件(不支持高版本，chrome72.0版本可用)等。

2、安装软件（中间件，基本都付费）

类如：Appemit（调用vlc插件播放rtsp），可以免安装的，目前只能windows,免费版会有提示。

猿大师中间件（底层调用VLC的ActiveX控件，实现在主流浏览器网页中内嵌播放多路RTSP的实时视频流），中间件收费的。

PluginOK(牛插)中间件。底层调用ActiveX控件VlcOcx.dll。（商业用途需付费使用）

3、服务器拉流转发及协议转换

示意图如下所示：

推流--------------服务器转发--------------拉流

方法一览：

a,vlc软件串流到http协议 ，网页显示几个视频需启动几个vlc,只适合应急场景。

b,html5 + websocket_rtsp_proxy 实现视频流直播 ，基于MSE（Media Source Extensions,W3C），扩展H5的功能。

步骤：服务器安装streamedian服务器，客户端通过video标签播放。

原型图：

价格：

c.基于nginx的rsmp转发

基于nginx实现rtmp转化，用flash实现播放。由于flash目前大多浏览器默认禁用，不推荐此方式。

步骤：安装ffmpeg工具,安装nginx。

另外nginx-rtmp-module也支持HLS协议,可以搭建基于hls的直播服务器。

d.rtsp转hls播放,通过ffmpeg转码

步骤：安装ffmpeg工具，ffmpeg转码。

形如：

ffmpeg -i "rtsp://admin:123456@192.168.10.129/cam/realmonitor?channel=1subtype=0" -c copy -f hls -hls_time 2.0 -hls_list_size 0 -hls_wrap 15 "D:/hls/test.m3u8"

缺点是直播流延时很大，对实时要求比较高的不满足要求。

案例：基于EasyDarwin拾建转码服务器。参考地址:

通过存储的m3u8去读取。

e.websocket代理推送，FFMPEG转码

此方法与a，b类似。但更实用。

以下提供两种方案：

（1）Gin+WebSocket+FFMPEG实现rtsp转码,参考：

通过FFMPEG把rstp转成http，ginrtsp作为转发服务器，但需要自己写相应接口，需要了解go语言。

（2）node + ffmpeg + websocket + flv.js，参考：

步骤：在node服务中建立websocket；通过fluent-ffmpeg转码，将RTSP 流转为flv格式；通过flv.js连接websocket，并对获取的flv格式视频数据进行渲染播放。

import WebSocket from 'ws'import webSocketStream from 'websocket-stream/stream'import ffmpeg from 'fluent-ffmpeg'// 建立WebSocket服务const wss = new WebSocket.Server({ port: 8888, perMessageDeflate: false })// 监听连接wss.on('connection', handleConnection)// 连接时触发事件function handleConnection (ws, req) {  // 获取前端请求的流地址（前端websocket连接时后面带上流地址）  const url = req.url.slice(1)  // 传入连接的ws客户端 实例化一个流  const stream = webSocketStream(ws, { binary: true })  // 通过ffmpeg命令 对实时流进行格式转换 输出flv格式  const ffmpegCommand = ffmpeg(url)    .addInputOption('-analyzeduration', '100000', '-max_delay', '1000000')    .on('start', function () { console.log('Stream started.') })    .on('codecData', function () { console.log('Stream codecData.') })    .on('error', function (err) {      console.log('An error occured: ', err.message)      stream.end()    })    .on('end', function () {      console.log('Stream end!')      stream.end()    })    .outputFormat('flv').videoCodec('copy').noAudio()  stream.on('close', function () {    ffmpegCommand.kill('SIGKILL')  })  try {    // 执行命令 传输到实例流中返回给客户端    ffmpegCommand.pipe(stream)  } catch (error) {    console.log(error)  }}

优点全部基于js。前端即可搞定。

参考: