近段时间涉及到一个Windows上录屏软件的需求。第一反应借用了FFMPEG开源库的方案，本想按正常思路调用ffmpeg接口开发一个优雅的方案，由于时间仓促，只得直接调用ffmpeg工具来做屏幕录制。评估了一下，由于是客户端软件，没有高并发需要，也没有苛刻的内存需求，直接调用FFmpeg工具做录屏确实一种高效敏捷的办法。
图形界面：可以使用QT，C#winform 或者MFC，支持start stop pause resume四个按钮。
API：该层提供start stop pause resume 四个接口。
关键在于怎么调用ffmpeg实现API层的四个接口。
由于是直接调用FFmpeg工具，相当于重新启动一个进程来录制，但如何控制这个进程变得非常重要，否则无法完成stop，pause 和resume的接口
关于FFmpeg工具录屏也有两个方案：
1.基于GDI录屏，FFmpeg直接从Windows的GDI中拷贝图形，然后再合成视频。
优点：省事，不需要依赖其他库
缺点：内存拷贝性能不是很好，没有硬件加速
命令如下：ffmpeg -y -f gdigrab -t 30 -r 25 -i desktop -vcodec libx264 -s 1280x720 test720.mp4
-t 表示录屏时间:缺省没有录屏时间限制
-r 表示帧率
-y 表示覆盖同名文件
- s 表示分辨率
-vcodec 表示编码器的库为x264
然后 test720.mp4为输出文件名
2.基于directshow方案，FFmpeg从directshow驱动接口中读取。
优点：性能较好，directshow可以控制采样帧率，硬件加速。
缺点：需要安装directshow驱动，不过directshow驱动网上很容易可以找到并下载。
命令如下：
ffmpeg -y --framerate 25 -f dshow -i video="screen-capture-recorder" -s 1280x720 -r 25 -t 30 yo.mp4
注意：这里默认是x264 编码，当然也可以指定其他编码器。
start接口的实现：直接开启一个执行ffmpeg 命令的进程，刚开始想用 system("ffmpeg -y -f gdigrab -t 30 -r 25 -i desktop -vcodec libx264 -s 1280x720 test720.mp4")，后来发现这种方法执行起来的进程无法控制，获取不到进程相关信息。后来我们选择就CreateProcess可以获取进程相关参数，便于后面其他接口实现使用。在Linux下也有类似的fork接口可以实现。
stop接口实现：直接将这个进程杀掉即可实现stop，但要注意进程不能强杀，否则进程退出资源没有回收造成录制的文件无法完整写入磁盘。如果是MP4文件就更加不幸了，MP4文件索引在文件尾，造成MP4文件无法播放。所以这里要优雅杀进程，让进程回收资源，文件刷进磁盘，同时FFmpeg截获到信号，完成MP4索引容器的写入，保证MP4完整写入磁盘。在Windows上可以采用GenerateConsoleCtrlEvent给进程发CTRL_BREAK_EVENT信号。Linux使用kill函数更容易了。
pause接口实现：如果暂停录屏，这个需求直接在FFmpeg工具层面不好处理。FFmpeg启动后根本无法控制它去暂停和恢复。所以我们从系统进程角度去控制，将FFmpeg该进程进入睡眠，自然录屏暂停了。在Windows上可以用SuspendThread实现，Linux也有类似接口
stop接口实现：同理FFmpeg工具层面不好处理，只能该进程唤醒即可完成录屏的恢复。
基本思路实现如上。笔者只是实现Windows上录屏，当然如果在Linux或者Android端可以采用类似方法实现，只是操作系统接口不同而已，录屏驱动不一样。当然本例子只是屏幕录制到本地，如果需要推流到RTMP服务器或者RTSP服务器，只是FFmpeg命令不一样，实现思路一致。
更多更详细请关注公众号：AV_Chat
(版权所有，仅限链接分享，盗版必究）
网友评论