最近整理了一篇脱敏后的实验记录：把 WebRTC 音频从 Pion `OnTrack` 收到后，解码 Opus RTP 为 PCM ，再通过 FFmpeg `arnndn` 做 RNN 降噪，先输出文件做对比验证。 文章地址： https://www.lodan.me/zh-cn/posts/server-side-webrtc-noise-reduction-pion-ffmpeg-rnn/ 我现在的判断是： - 这条链路适合先做离线验证，不适合一上来就做实时转发。 - `int16` PCM 要对应 FFmpeg `s16le`，格式边界不能含糊。 - 真正难的是延迟、CPU 、缓冲、FFmpeg 进程生命周期、丢包和音视频同步。 - 如果设备侧硬件和 WebRTC 3A 表现不可控，服务端降噪可以作为补充方向，但不能当成免费能力。 想讨论一下：大家在 WebRTC 或实时音频场景里，有没有把降噪、增益、混音这类处理放到服务端做过？最后卡住的是延迟、效果，还是资源成本？
想提取视频的中英双语字幕，ffmpeg 好像提取不了硬字幕。试了开源的 video-subtitle-extractor 总是提取不了大文件(300mb)字幕。 视频格式：mp4 提取字幕：txt / srt 各位有什么推荐吗？
想提取视频的中英双语字幕，ffmpeg 好像提取不了硬字幕。试了开源的 video-subtitle-extractor 总是提取不了大文件(300mb)字幕。 视频格式：mp4 提取字幕：txt / srt 各位有什么推荐吗？
想提取视频的中英双语字幕，ffmpeg 好像提取不了硬字幕。试了开源的 video-subtitle-extractor 总是提取不了大文件(300mb)字幕。 视频格式：mp4 提取字幕：txt / srt 各位有什么推荐吗？
当前ffmpeg效果图 1 个帖子 - 1 位参与者 阅读完整话题
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
公司内网不让装录屏软件，于是我用 ffmpeg 自己封装了一个 CLI 工具 起因很简单：公司内网管控比较严，录屏软件装不上，OBS 装不了，Win+G 又没有权限开，但 ffmpeg 不知道为什么没有被拦——它就静静地躺在某个服务器目录里，能用。 于是就想着，ffmpeg 本身支持录屏，能不能把那一长串命令参数封装一下，做成一个随时能跑的小工具，录完就走，不依赖任何需要安装权限的软件。 就这样写了这个东西，叫 ScreenRecorder-cli 。 项目地址： https://github.com/gdjdkid/ScreenRecorder-cli 痛点在哪 ffmpeg 本身当然能录屏，但命令太难记了，每次临时录东西都要现查参数： ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audio="virtual-audio-capturer" \ -f dshow -i audio="麦克风 (Conexant ISST Audio)" \ -filter_complex "[1:a][2:a]amerge=inputs=2[a]" \ -map 0:v -map "[a]" \ -c:v libx264 -crf 23 -preset veryfast \ -c:a aac -b:a 128k \ recording_2025-05-17_10-30-00.mp4 音频设备名拼错一个字符就报错，时间戳要手动写，输出路径每次都要重新指定。在工作中临时录个演示或者操作步骤，效率反而比直接截图还低。 所以我想做的事情就一件：把这些参数固化下来，音频设备名保存一次，之后一条命令搞定。 目前实现了什么 跨平台：Windows 用 gdigrab + dshow ，macOS 用 avfoundation ，Linux 用 x11grab + pulseaudio 音频设备名保存到本地配置文件，下次启动直接复用 默认输出目录可配置，也可以每次用 -o 临时覆盖 安装时自动检测 ffmpeg 是否在 PATH 里，没有的话给出安装提示 按 Ctrl+C 优雅退出（向 ffmpeg stdin 写 q ，不产生损坏文件） 输出文件名自动带时间戳： recording_YYYY-MM-DD_HH-MM-SS.mp4 无需安装权限，只要 ffmpeg 在 PATH 里， npm install -g 之后就能用 基本用法 # 安装 npm install -g screenrecorder-cli # 第一次用，先查一下有哪些音频设备 screenrec devices # 把设备名保存到配置，之后不用再输 screenrec set-device --mic "麦克风 (Conexant ISST Audio)" --system "virtual-audio-capturer" # 开始录制，Ctrl+C 停止，文件自动保存 screenrec start # 临时指定输出路径和帧率 screenrec start -o D:\Videos -r 60 # 不录音频 screenrec start --no-audio # 查看当前配置 screenrec show-config 有几个地方没想清楚，想听听意见 1. Windows 系统音频需要额外装一个驱动 录系统声音需要装 screen-capture-recorder （开源的 DirectShow 驱动），不装只能录麦克风。在内网受限环境下这个驱动不一定能装，目前没找到绕过的方式，只是在文档里说明了。 2. Linux 部分是按文档写的，没有实机测过 我自己用 Windows ，Linux 下 x11grab + pulseaudio 的逻辑是照着 ffmpeg 文档写的，不同发行版差异可能不小。有 Linux 用户的话能帮忙验证一下吗。 3. 只能录全屏 目前没有窗口选择或区域选择。ffmpeg 的 gdigrab 支持 -i title=窗口标题 ，但窗口标题需要手动输入，不太实用。有没有更好的思路？ 4. 输出格式写死了 mp4 编码用 libx264 ，没有其他格式的选项。有没有人有别的格式需求？ 技术栈 Node.js ，CJS ，无额外框架 commander 做参数解析 底层是 child_process.spawn 调 ffmpeg ，没用任何 ffmpeg npm wrapper 最开始只是为了解决自己工作里的问题，后来整理了一下结构，加了跨平台支持，就顺手放出来了。如果有人在类似受限的内网环境下办公，或者单纯想要一个轻量的命令行录屏方案，可以试一下。 macOS 和 Linux 用户帮忙验证一下跨平台逻辑有没有问题就更好了，Issues 和 PR 都欢迎。
我把自己日常要用的一个视频处理需求做成了在线工具： videosnap.cc 本来目标很朴素： 不用装软件 尽量浏览器本地处理 少上传原视频，降低隐私顾虑 结果最近被一个问题狠狠干懵了： 处理进度卡在 99% 很久，没挂但就是不结束。 复现现象（真实可复现） 在部分机器 + 中大视频文件下： 前面进度推进正常 到 99% 后长时间不动 CPU 看着还在跑 页面不报错 用户体感就是： “卡死了” 我目前的判断 大概率是尾段组合问题，不是单点 bug： ffmpeg.wasm 处理结束后，JS 侧 Uint8Array/Blob 搬运开销太大 Worker <-> Main thread 消息传递产生了额外 copy MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞； OPFS 还没来得及完整验证，准备继续试 已尝试（但还没彻底解决） 调 ffmpeg 参数，减少中间产物 主流程尽量放到 Worker 尝试 WORKERFS 尝试 OPFS 控制并发，压低内存峰值 修正进度条策略（避免“假 100%”） 想请教各位的关键问题 你们做 Web 端 ffmpeg 时，有没有遇到这种“99% 假完成”？ 大文件场景下，最终导出阶段你们是怎么设计的？ OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS ？ 有无推荐的排查维度：内存曲线、拷贝次数、阶段耗时埋点等？ 项目地址： https://videosnap.cc 先谢过各位 🙏
我把自己日常要用的一个视频处理需求做成了在线工具： videosnap.cc 本来目标很朴素： 不用装软件 尽量浏览器本地处理 少上传原视频，降低隐私顾虑 结果最近被一个问题狠狠干懵了： 处理进度卡在 99% 很久，没挂但就是不结束。 复现现象（真实可复现） 在部分机器 + 中大视频文件下： 前面进度推进正常 到 99% 后长时间不动 CPU 看着还在跑 页面不报错 用户体感就是： “卡死了” 我目前的判断 大概率是尾段组合问题，不是单点 bug： ffmpeg.wasm 处理结束后，JS 侧 Uint8Array/Blob 搬运开销太大 Worker <-> Main thread 消息传递产生了额外 copy MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞； OPFS 还没来得及完整验证，准备继续试 已尝试（但还没彻底解决） 调 ffmpeg 参数，减少中间产物 主流程尽量放到 Worker 尝试 WORKERFS 尝试 OPFS 控制并发，压低内存峰值 修正进度条策略（避免“假 100%”） 想请教各位的关键问题 你们做 Web 端 ffmpeg 时，有没有遇到这种“99% 假完成”？ 大文件场景下，最终导出阶段你们是怎么设计的？ OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS ？ 有无推荐的排查维度：内存曲线、拷贝次数、阶段耗时埋点等？ 项目地址： https://videosnap.cc 先谢过各位 🙏
我把自己日常要用的一个视频处理需求做成了在线工具： videosnap.cc 本来目标很朴素： 不用装软件 尽量浏览器本地处理 少上传原视频，降低隐私顾虑 结果最近被一个问题狠狠干懵了： 处理进度卡在 99% 很久，没挂但就是不结束。 复现现象（真实可复现） 在部分机器 + 中大视频文件下： 前面进度推进正常 到 99% 后长时间不动 CPU 看着还在跑 页面不报错 用户体感就是： “卡死了” 我目前的判断 大概率是尾段组合问题，不是单点 bug： ffmpeg.wasm 处理结束后，JS 侧 Uint8Array/Blob 搬运开销太大 Worker <-> Main thread 消息传递产生了额外 copy MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞； OPFS 还没来得及完整验证，准备继续试 已尝试（但还没彻底解决） 调 ffmpeg 参数，减少中间产物 主流程尽量放到 Worker 尝试 WORKERFS 尝试 OPFS 控制并发，压低内存峰值 修正进度条策略（避免“假 100%”） 想请教各位的关键问题 你们做 Web 端 ffmpeg 时，有没有遇到这种“99% 假完成”？ 大文件场景下，最终导出阶段你们是怎么设计的？ OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS ？ 有无推荐的排查维度：内存曲线、拷贝次数、阶段耗时埋点等？ 项目地址： https://videosnap.cc 先谢过各位 🙏
我把自己日常要用的一个视频处理需求做成了在线工具： videosnap.cc 本来目标很朴素： 不用装软件 尽量浏览器本地处理 少上传原视频，降低隐私顾虑 结果最近被一个问题狠狠干懵了： 处理进度卡在 99% 很久，没挂但就是不结束。 复现现象（真实可复现） 在部分机器 + 中大视频文件下： 前面进度推进正常 到 99% 后长时间不动 CPU 看着还在跑 页面不报错 用户体感就是： “卡死了” 我目前的判断 大概率是尾段组合问题，不是单点 bug： ffmpeg.wasm 处理结束后，JS 侧 Uint8Array/Blob 搬运开销太大 Worker <-> Main thread 消息传递产生了额外 copy MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞； OPFS 还没来得及完整验证，准备继续试 已尝试（但还没彻底解决） 调 ffmpeg 参数，减少中间产物 主流程尽量放到 Worker 尝试 WORKERFS 尝试 OPFS 控制并发，压低内存峰值 修正进度条策略（避免“假 100%”） 想请教各位的关键问题 你们做 Web 端 ffmpeg 时，有没有遇到这种“99% 假完成”？ 大文件场景下，最终导出阶段你们是怎么设计的？ OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS ？ 有无推荐的排查维度：内存曲线、拷贝次数、阶段耗时埋点等？ 项目地址： https://videosnap.cc 先谢过各位 🙏
我把自己日常要用的一个视频处理需求做成了在线工具： videosnap.cc 本来目标很朴素： 不用装软件 尽量浏览器本地处理 少上传原视频，降低隐私顾虑 结果最近被一个问题狠狠干懵了： 处理进度卡在 99% 很久，没挂但就是不结束。 复现现象（真实可复现） 在部分机器 + 中大视频文件下： 前面进度推进正常 到 99% 后长时间不动 CPU 看着还在跑 页面不报错 用户体感就是： “卡死了” 我目前的判断 大概率是尾段组合问题，不是单点 bug： ffmpeg.wasm 处理结束后，JS 侧 Uint8Array/Blob 搬运开销太大 Worker <-> Main thread 消息传递产生了额外 copy MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞； OPFS 还没来得及完整验证，准备继续试 已尝试（但还没彻底解决） 调 ffmpeg 参数，减少中间产物 主流程尽量放到 Worker 尝试 WORKERFS 尝试 OPFS 控制并发，压低内存峰值 修正进度条策略（避免“假 100%”） 想请教各位的关键问题 你们做 Web 端 ffmpeg 时，有没有遇到这种“99% 假完成”？ 大文件场景下，最终导出阶段你们是怎么设计的？ OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS ？ 有无推荐的排查维度：内存曲线、拷贝次数、阶段耗时埋点等？ 项目地址： https://videosnap.cc 先谢过各位 🙏
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI 生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出 github.com GitHub - worldwonderer/video-recap: 视频自动解说 skill。输入视频，输出带中文旁白的解说视频。适配 Claude Code。 视频自动解说 skill。输入视频，输出带中文旁白的解说视频。适配 Claude Code。 项目里放了 demo 视频。 使用焚决： claude code 用 glm-5.1 就行 画面识别 Doubao-Seed-2.0-pro，有中转站可以薅 ASR 用 Qwen3-ASR 0.6B 或者 1.7B均可，macos apple 芯片本地部署 TTS 我用了 edge-TTS 的 yunxi 整体四舍五入完全没成本 3 个帖子 - 3 位参与者 阅读完整话题