【大多为搜集的文章,都归类为,转载。所以没有标明,来处。】
1. windows下ffmpeg的编译:
如:./configure --disable-yasm --enable-static --enable-indev=dshow
如果装了yasm,x264,就:./configure --enable-static --enable-indev=dshow --enable-gpl --enable-libx264
2. windows下用ffmpeg采集视频:
命令如:ffmpeg.exe -r 5 -f vfwcap -i 0 -s 176x144
3. 如果要想深入下ffmpeg中vfwcap:
4.记录一下遇到的问题
Aconnect设备失败
Win7系统下使用capDriverConnect()连接失败的解决办法
5. 前面提到的是VFW(video for windows)设备,现在摄像头都会支持vfw/wdm,但各系统并非有对应驱动程序。
【电脑插上USB摄像头时,会为其安装通用驱动,测试其是VFW还是WDM,在设备管理查看驱动程序详细信息应该能辨别,或者直接上程序,编译测试。】
【根据使用的驱动程序的不同来分类,目前市场上大致有两种捕捉卡:VFW (Video for Windows)卡和WDM (Windows Driver Model)卡。VFW是DirectShow的前身,摄像头驱动未必支持。新的程序应该使用DirectShow。参考DirectShow SDK中的amcap示例。】
【视频捕捉卡的接口,可以是以PCI或AGP的方式插入PC机箱,也可以直接以USB接口的方式外挂;还有就是通过1394接口与PC机相连的数码摄像机等等。】
6.windows下用ffmpeg采集音频:
7.windows下使用ffmpeg中的dshow
如:ffmpeg -f dshow -i video="6RoomsCam" -y out.flv //用的六间房的虚拟摄像头
ffmpeg-f dshow -i audio="Realtek HD Audio Input" -y out.flv
上面是分开采集的,同时采集,合并就行了,两个输入文件是ffmpeg -f dshow -i video="6RoomsCam" -f dshow -i audio="Realtek HD Audio Input" -y out.flv。若要查看本机有哪些设备,可以参考10.
8.null.
9.在linux下,如:
ffmpeg -f video4linux2 -s 320*240 -r 10 -i /dev/video0 test.asf
ffmpeg -f oss -i /dev/dsp /tmp/out.mpg
10. 最后可以参考这里:
记录一些命令,直接研究也可:
ffmpeg -list_devices true -f dshow -i dummy //可查看摄像头和声卡设备名称
ffmpeg -y -f vfwcap -i list
ffmpeg -y -f vfwcap -r 25 -i 0 out.mp4
ffmpeg -f video4linux2 -r 25 -s 640x480 -i /dev/video0 out.avi
ffmpeg -f v4l2 -r 25 -s 640x480 -i /dev/video0 out.avi
ffmpeg -f dshow -i video="Integrated Camera" out.mp4ffmpeg -f dshow -s 1280x720 -r 15 -vcodec mjpeg -i video="Integrated Camera" out.avi
dshow编译方面参考:如何编译包含dshow设备的版本【编译遇到问题,就自己解决吧,不是很麻烦。】
ffplay -f dshow video="USB video capture 0"
【交代后期遇到的问题,以及提示】
『用ffmpeg推音视频流(音视频皆用dshow为输入,视频编码用X264,以flv格式输出)的延迟问题,据我所看,有两点如下:』
1. 音频采样的带来的延迟,这个延迟很小。它是如何影响到延迟大小的呢?这样的:dshow中,音视频源filter的capture pin,数据包buffer大小是可设置的,假设它默认为1秒的数据,也就是每一秒才回调并向外投递出一包数据,此时(假设视频fps=15)编码器得到了15帧,在format的interleave(音视频包交错存放)处理里ff_interleave_packet_per_dts时,就缓存了接近1秒,即造成等量延迟。
如何修改capture pin呢?参考代码如下:
- dshow_cycle_formats()
- {
- ......
- IAMBufferNegotiation *negotiate = NULL;
- ALLOCATOR_PROPERTIES prop = {0};
- if (devtype == AudioDevice)
- if (IPin_QueryInterface(pin, &, (void **) &negotiate) != S_OK)
- return;//IID_IAMBufferNegotiation
- ......
- if (devtype == AudioDevice)
- {
- {
- prop.cbAlign = 1;
- prop.cBuffers = 2;
- prop.cbBuffer = ??;
- }
- if (IAMBufferNegotiation_SuggestAllocatorProperties(negotiate, &prop) != S_OK)
- goto next;
- }
- ......
- if (devtype == AudioDevice)
- IAMBufferNegotiation_Release(negotiate);
- ......
- }
至于该buffer设置多大,可以结合,音频编码的frame_size、interleave是单帧视频对应多少音频包,来考虑
2. X264编码带来的延迟,在配置参数的时候,先参考下这篇文章:如何计算x264编码延迟(转载如下)
01 | delay = 0 |
02 |
03 | if b-adapt=2 and not (nopass or pass2): |
04 | delay = MAX(bframes,3)*4 |
05 | else : |
06 | delay = bframes |
07 |
08 | if mb-tree or vbv: |
09 | delay = MAX(delay,rc_lookahead) |
10 |
11 | if not sliced-threads: |
12 | delay = delay + threads - 1 |
13 |
14 | delay = delay + sync-lookahead |
15 |
16 | if vbv and (vfr-input or abr or pass1: |
17 | delay = delay + 1 |
计算出来是x264要buffer掉的frame数。当然在这之外还要算上编码计算的时间,但是这个buffer掉的时间是不可逾越的延迟的极限了。
“B帧给客户端带来的延迟,并不能简单的说,是B帧数目的两倍关系,请画出时序图去衡量。” “编码速度带来的延迟?编码帧缓冲与策略带来延迟?网路延迟?流媒体服务器带来延迟?解码带来延迟?。。。”