Log in

View Full Version : Maximize encoding speed on multi-core CPU


spookybathtub
22nd October 2013, 07:10
When I encode ProRes files with ffmpeg using libx264, my CPU never goes higher than about 650% (out of 1600% in Activity Monitor). Is there any way to improve this and get faster encode speed? How can I tell where the bottleneck is? I highly doubt it's disk speed, because the source is on a 500MBps RAID. I'm running OS X 10.8.5 with an octo-core 2.4GHz CPU and 32GB RAM.
$ ffmpeg -threads 10 -loglevel verbose -i A001_C004_1016KB.mov -pix_fmt yuv420p -vf scale=hd720 -an -vcodec libx264 -preset veryfast -crf 18 -level 31 -g 8 test.mp4
ffmpeg version N-57248-g12e66f2 Copyright (c) 2000-2013 the FFmpeg developers
built on Oct 19 2013 01:10:23 with llvm-gcc 4.2.1
configuration: --arch=x86_64 --enable-gpl --enable-version3 --enable-postproc --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libass --enable-libopenjpeg --enable-openssl --enable-libopus --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-yasm --enable-swscale --enable-avfilter --enable-libmodplug --enable-libbluray --enable-gnutls --enable-shared --enable-pthreads --enable-nonfree --enable-opencl --enable-avresample
libavutil 52. 47.100 / 52. 47.100
libavcodec 55. 37.101 / 55. 37.101
libavformat 55. 19.102 / 55. 19.102
libavdevice 55. 4.100 / 55. 4.100
libavfilter 3. 88.101 / 3. 88.101
libavresample 1. 1. 0 / 1. 1. 0
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'A001_C004_1016KB.mov':
Metadata:
creation_time : 2013-10-16 19:42:28
Duration: 00:00:35.87, start: 0.000000, bitrate: 179909 kb/s
Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le, 1920x1080, 176448 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
Metadata:
creation_time : 2013-10-16 19:42:28
handler_name : Apple Alias Data Handler
timecode : 09:49:47:02
Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 3.0, s32, 3456 kb/s (default)
Metadata:
creation_time : 2013-10-16 19:42:28
handler_name : Apple Alias Data Handler
Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
Metadata:
creation_time : 2013-10-16 19:43:08
handler_name : Apple Alias Data Handler
timecode : 09:49:47:02
File 'test.mp4' already exists. Overwrite ? [y/N] y
[Parsed_scale_0 @ 0x7ffd29c28c80] w:1280 h:720 flags:'0x4' interl:0
[graph 0 input from stream 0:0 @ 0x7ffd29c2b760] w:1920 h:1080 pixfmt:yuv422p10le tb:1/24000 fr:24000/1001 sar:1/1 sws_param:flags=2
[Parsed_scale_0 @ 0x7ffd29c28c80] w:1920 h:1080 fmt:yuv422p10le sar:1/1 -> w:1280 h:720 fmt:yuv420p sar:1/1 flags:0x4
[libx264 @ 0x7ffd2a037000] using SAR=1/1
[libx264 @ 0x7ffd2a037000] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 0x7ffd2a037000] profile High, level 3.1
[libx264 @ 0x7ffd2a037000] 264 - core 138 r2358 9e941d1 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=24 lookahead_threads=5 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=1 keyint=8 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=8 rc=crf mbtree=1 crf=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'test.mp4':
Metadata:
encoder : Lavf55.19.102
Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 24k tbn, 23.98 tbc (default)
Metadata:
creation_time : 2013-10-16 19:42:28
handler_name : Apple Alias Data Handler
timecode : 09:49:47:02
Stream mapping:
Stream #0:0 -> #0:0 (prores -> libx264)
Press [q] to stop, [?] for help
No more output streams to write to, finishing.e=00:00:33.95 bitrate=2930.7kbits/s
frame= 860 fps= 62 q=-1.0 Lsize= 12795kB time=00:00:35.78 bitrate=2929.0kbits/s
video:12785kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.075992%
[libx264 @ 0x7ffd2a037000] frame I:108 Avg QP:14.86 size: 79387
[libx264 @ 0x7ffd2a037000] frame P:470 Avg QP:17.74 size: 8400
[libx264 @ 0x7ffd2a037000] frame B:282 Avg QP:17.81 size: 2020
[libx264 @ 0x7ffd2a037000] consecutive B-frames: 37.2% 56.3% 2.8% 3.7%
[libx264 @ 0x7ffd2a037000] mb I I16..4: 9.9% 54.9% 35.3%
[libx264 @ 0x7ffd2a037000] mb P I16..4: 3.5% 13.4% 0.2% P16..4: 20.5% 6.4% 3.9% 0.0% 0.0% skip:52.0%
[libx264 @ 0x7ffd2a037000] mb B I16..4: 0.6% 1.1% 0.0% B16..8: 10.9% 2.1% 0.2% direct: 6.2% skip:78.9% L0:36.0% L1:51.6% BI:12.4%
[libx264 @ 0x7ffd2a037000] 8x8 transform intra:64.8% inter:53.1%
[libx264 @ 0x7ffd2a037000] coded y,uvDC,uvAC intra: 65.0% 41.2% 25.2% inter: 7.0% 9.1% 0.4%
[libx264 @ 0x7ffd2a037000] i16 v,h,dc,p: 57% 18% 17% 8%
[libx264 @ 0x7ffd2a037000] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 36% 14% 38% 2% 2% 2% 2% 2% 2%
[libx264 @ 0x7ffd2a037000] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 19% 9% 6% 8% 8% 8% 8% 8%
[libx264 @ 0x7ffd2a037000] i8c dc,h,v,p: 63% 13% 22% 3%
[libx264 @ 0x7ffd2a037000] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x7ffd2a037000] kb/s:2919.84

nevcairiel
22nd October 2013, 07:15
It might be limited by decoding speed. I'm not sure how fast the ProRes decoder really is, but if it can't produce enough frames, the encoder can't work full time.

Dark Shikari
22nd October 2013, 14:44
Resizing/colorspace conversion is single-threaded and may be a bottleneck too.

Blue_MiSfit
23rd October 2013, 08:29
62 fps for transcoding HD ProRes is pretty damned good. I haven't tried the open source decoder in a long time but this is way faster than I remember it being...

benwaggoner
23rd October 2013, 23:12
Resizing/colorspace conversion is single-threaded and may be a bottleneck too.
Could piping be used to parallelize this some? Resize in one stage and pipe the resized frames to another ffmpeg instance for color space conversion?

The overhead of moving all those frames in memory could be way worse, though. What we really need is frame-level parallelism for operations without any interframe dependencies, like scaling and color space conversions.

smok3
23rd October 2013, 23:19
bottleneck is almost certainly prores decoder, try to input some other format to the same equation.

benwaggoner
23rd October 2013, 23:24
bottleneck is almost certainly prores decoder, try to input some other format to the same equation.
Yeah, ProRes is commonly a dog. Each frame is a whole lot of data. But it's also an intraframe-only codec, so frame-level parallelism in decode should be feasible. That's a technique sadly missing from lots of digital media pipelines.

Still, even if bound by a single thread, doing stuff like switching to a 64-bit build or using a more advanced compiler can often improve throughput at least some.