非常慢的 ffmpeg 编码命令

非常慢的 ffmpeg 编码命令

我正在使用以下 ffmpeg 命令拍摄 4K(3840x2160)视频(5 到 10 分钟之间),将其缩短至 21 秒,水平翻转(跨垂直轴)并切换红色和蓝色通道:

ffmpeg -i "input.webm" -ss {trim_start} -t 21 -y -vf "hflip,format=yuv420p,colorchannelmixer=0:0:1:0:0:1:0:0:1:0:0" -metadata:s:v rotate=0 -codec:v libx264 "output.mp4"

但是,我注意到它非常慢,即使在 3.9 GHz 的 Intel i7 5960x 8 核 16 线程 CPU 上也是如此。我注意到,大多数时候,ffmpeg 的 CPU 利用率都在 25% 左右,只有很少的时间 CPU 达到 100%,正如 Windows 任务管理器报告的那样。

我能做些什么来加快这个速度?是不是命令的结构方式导致它如此缓慢?还是这个操作(修剪、翻转和交换通道)太过繁琐?为什么 CPU 大部分时间都处于 25% 的状态?

我在 Windows 10 1607 上。这是编码视频时的 ffmpeg 输出:

ffmpeg version N-94150-g231d0c819f Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.1.1 (GCC) 20190621
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
  libavutil      56. 30.100 / 56. 30.100
  libavcodec     58. 53.101 / 58. 53.101
  libavformat    58. 28.101 / 58. 28.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter     7. 55.100 /  7. 55.100
  libswscale      5.  4.101 /  5.  4.101
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, matroska,webm, from 'C:\Users\John\Downloads\raw_videos\input.webm':
  Metadata:
    encoder         : google/video-file
  Duration: 00:04:10.30, start: 0.000000, bitrate: 16596 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)
Stream mapping:
  Stream #0:0 -> #0:0 (vp9 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 000001a42792fcc0] using SAR=1/1
[libx264 @ 000001a42792fcc0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 000001a42792fcc0] profile High 4:4:4 Predictive, level 5.2, 4:4:4, 8-bit
[libx264 @ 000001a42792fcc0] 264 - core 157 r2970 5493be8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2019 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=24 lookahead_threads=4 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'encoded/GB~BTj2lBc-84M.mp4':
  Metadata:
    encoder         : Lavf58.28.101
    Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv444p, 3840x2160 [SAR 1:1 DAR 16:9], q=-1--1, 60 fps, 15360 tbn, 60 tbc (default)
    Metadata:
      encoder         : Lavc58.53.101 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame=  954 fps=1.9 q=31.0 size=   48896kB time=00:00:14.71 bitrate=27217.8kbits/s speed=0.0297x

答案1

将参数放在-ss输入之后将导致 FFmpeg 通过从头解码文件直到到达指定点来搜索输入文件。这非常慢,搜索点距离文件开头越远,搜索所需的时间就越长。这很可能就是为什么您在一段时间内编码为 0 帧的原因。

-ss参数被放置时输入后,FFmpeg 将使用关键帧来定位,速度非常快。参见https://trac.ffmpeg.org/wiki/Seeking为什么。

如果 FFmpeg 成功定位到视频中的定义点后 CPU 使用率仍然很低,则可能是由于您使用的一个或多个过滤器。某些过滤器可能无法使用所有可用的 CPU 线程,而某些过滤器甚至不是多线程的。如果您很好奇并想知道哪个过滤器是瓶颈,请尝试一次删除一个过滤器,然后查看 CPU 使用率如何。

作为用户,对于过滤器瓶颈,您无能为力。如果您有多个文件等待处理,您可以启动多个 FFmpeg 实例来并行处理这些文件,从而避免“浪费”您的 CPU 核心。不过,启动多个实例确实会增加内存使用量,因此如果您决定这样做,请留意您的 RAM 使用情况。

相关内容