Кастинг екрану за допомогою ffmpeg (занадто швидко)

Я можу використовувати ffmpeg для створення екранів:

ffmpeg -f x11grab -s 1280x800 -i :0.0 -c:v libx264 -framerate 30 -r 30 -crf 18 out.mkv

Однак вихід виходить занадто швидким темпом. Це трапляється і з тим, GTK RecordMyDesktopякщо я ввімкну кодування під час польоту. Отже, питання полягає в тому, як отримати нормальний темп відео. Також для того, щоб захопити звук за допомогою ffmpeg, яку опцію слід використовувати?

Вихід FFmpeg:

    ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -c:v libx264 -framerate 30 -r 30 -crf 18 out.mkv
ffmpeg version N-35162-g87244c8 Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct  7 2012 15:56:19 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --enable-gpl --enable-libfaac --enable-libfdk-aac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp --enable-libtheora --enable-libvorbis --enable-libvpx --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3
  libavutil      51. 73.102 / 51. 73.102
  libavcodec     54. 64.100 / 54. 64.100
  libavformat    54. 29.105 / 54. 29.105
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 19.102 /  3. 19.102
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
[x11grab @ 0xab896a0] device: :0.0 -> display: :0.0 x: 0 y: 0 width: 1280 height: 800
[x11grab @ 0xab896a0] shared memory extension found
[x11grab @ 0xab896a0] Estimating duration from bitrate, this may be inaccurate
Input #0, x11grab, from ':0.0':
  Duration: N/A, start: 1350136942.608988, bitrate: 983040 kb/s
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1280x800, 983040 kb/s, 30 tbr, 1000k tbn, 30 tbc
[libx264 @ 0xab87320] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
[libx264 @ 0xab87320] profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit
[libx264 @ 0xab87320] 264 - core 128 r2 198a7ea - H.264/MPEG-4 AVC codec - Copyleft 2003-2012 - 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=6 lookahead_threads=1 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=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'out.mkv':
  Metadata:
    encoder         : Lavf54.29.105
    Stream #0:0: Video: h264, yuv444p, 1280x800, q=-1--1, 1k tbn, 30 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> libx264)
Press [q] to stop, [?] for help
frame=   10 fps=0.0 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   19 fps= 17 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   28 fps= 17 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   37 fps= 17 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   45 fps= 16 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   47 fps= 14 q=0.0 size=       1kB time=00:00:00.00 bitrate=   0.0kbits/sframe=   52 fps= 13 q=24.0 size=     257kB time=00:00:00.00 bitrate=2101632.0kbiframe=   55 fps= 12 q=24.0 size=     257kB time=00:00:00.10 bitrate=20808.2kbitsframe=   59 fps= 11 q=24.0 size=     289kB time=00:00:00.23 bitrate=10145.0kbitsframe=   64 fps= 11 q=24.0 size=     289kB time=00:00:00.40 bitrate=5894.7kbits/frame=   70 fps= 11 q=24.0 size=     289kB time=00:00:00.60 bitrate=3933.1kbits/frame=   72 fps= 10 q=24.0 size=     289kB time=00:00:00.66 bitrate=3549.2kbits/frame=   77 fps=9.8 q=24.0 size=     289kB time=00:00:00.83 bitrate=2837.7kbits/frame=   80 fps=9.6 q=24.0 size=     289kB time=00:00:00.93 bitrate=2533.5kbits/frame=   85 fps=9.3 q=24.0 size=     289kB time=00:00:01.10 bitrate=2146.9kbits/frame=   89 fps=9.3 q=24.0 size=     289kB time=00:00:01.23 bitrate=1917.1kbits/frame=   92 fps=9.1 q=24.0 size=     289kB time=00:00:01.33 bitrate=1773.3kbits/frame=   96 fps=9.0 q=24.0 size=     289kB time=00:00:01.46 bitrate=1612.4kbits/frame=   99 fps=8.8 q=24.0 size=     321kB time=00:00:01.56 bitrate=1676.8kbits/frame=  104 fps=8.7 q=24.0 size=     321kB time=00:00:01.73 bitrate=1515.2kbits/frame=  109 fps=5.3 q=24.0 Lsize=    1093kB time=00:00:03.56 bitrate=2511.5kbits/s    
video:1092kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.120198%
[libx264 @ 0xab87320] frame I:3     Avg QP:18.93  size:142610
[libx264 @ 0xab87320] frame P:43    Avg QP:20.79  size: 15751
[libx264 @ 0xab87320] frame B:63    Avg QP:23.75  size:   195
[libx264 @ 0xab87320] consecutive B-frames: 21.1%  1.8% 11.0% 66.1%
[libx264 @ 0xab87320] mb I  I16..4: 50.0% 21.1% 28.9%
[libx264 @ 0xab87320] mb P  I16..4:  6.1%  0.9%  3.2%  P16..4:  5.5%  1.2%  0.6%  0.0%  0.0%    skip:82.5%
[libx264 @ 0xab87320] mb B  I16..4:  0.4%  0.1%  0.0%  B16..8:  2.9%  0.1%  0.0%  direct: 0.0%  skip:96.5%  L0:40.7% L1:57.0% BI: 2.3%
[libx264 @ 0xab87320] 8x8 transform intra:14.5% inter:46.1%
[libx264 @ 0xab87320] coded y,u,v intra: 33.5% 24.1% 25.4% inter: 0.9% 0.4% 0.4%
[libx264 @ 0xab87320] i16 v,h,dc,p: 70% 26%  1%  3%
[libx264 @ 0xab87320] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 21% 30%  5%  7%  5%  7%  4% 10%
[libx264 @ 0xab87320] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 32% 35% 12%  2%  4%  3%  4%  3%  5%
[libx264 @ 0xab87320] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0xab87320] ref P L0: 57.0%  5.6% 26.8% 10.6%
[libx264 @ 0xab87320] ref B L0: 69.4% 22.6%  8.0%
[libx264 @ 0xab87320] ref B L1: 93.7%  6.3%
[libx264 @ 0xab87320] kb/s:2460.40

ffmpeg screen-capture video-capture

— грабінець
джерело

-f alsa -i pulseмає отримати аудіовведення. Чи можете ви дати нам також повний, необрізаний вихід командного рядка?

— slhck

Я бачу x11grab, є -framerateваріант . Це значення за замовчуванням для NTSC, так що ви можете, можливо, використовувати -framerate 30і -r 30для виводу в поєднанні?

— slhck

@slhck, дякую. публікація оновлюється за вашою пропозицією, однак та сама проблема. Мій комп'ютер теж не такий швидкий.

— грабіжник

@slhck, я думаю, у мене є поняття, що відбувається. Здається, що він пропускає кілька кадрів між ними, одночасно роблячи кодування. Ось чому це здається швидше. Особливо, коли навантаження вище, швидкість втрати кадру набагато вище, а відео просто скаче. Чи існує метод просто захоплення без кодування та кодування відео, коли зроблено захоплення, як це робиться GTK RecordMyDesktop?

— грабіжник

Я вважаю, що проблема полягає в першому, -r 30це означає "ігноруйте часові позначки даних, що надходять, і ставитесь до них так, як якщо б це було рівно 30 кадрів в секунду" спробуйте "-фрамерат 30" там вище

— rogerdpack

Спробуйте використовувати кодер без втрат для зйомки екрана, а потім повторно кодуйте вихід, коли закінчите, щоб створити менший файл, якщо потрібно. Перевагою цього методу часто є менш інтенсивний процес захоплення, який може призвести до «швидшого» частоти зйомки кадрів. Звичайно, результати можуть відрізнятися.

ffmpeg -f x11grab -s 1280x800 -i :0.0 -c:v libx264 -preset ultrafast -crf 0 out.mkv

Цілком можливо, що ваш процесор просто не має можливості кодувати за заявленою частотою кадрів під певний розмір екрану. У такому випадку ви можете спробувати менше -sзначення. Можливо, варто експериментувати з іншими кодерами без втрат, такими як huffyuv, ffv1 або utvideo, але я особисто не пробував їх для екранізацій.

Більше інформації:

ЯК: Правильна трансляція екрана на Linux
Захоплення аудіо за допомогою FFmpeg та ALSA (як альтернатива імпульсу)

— льоган
джерело

Здається, що інші кодеки без втрат, про які ви згадали, є менш ресурсомісткими порівняно з x264. Прокоментую точніше це згодом.

— грабеж

@rowman Практично будь-який кодер є менш ресурсоємним, ніж x264 (або загалом, кодери h.264), що просто питання якості та часу, необхідного для кодування. Ось чому багато користувачів все ще дотримуються XviD або подібного, якщо мова йде про кодування в режимі реального часу.

— slhck

| @slhck Добре. Чи контейнер також впливає на ресурси? і чи є література про порівняння різних відеокодеків без втрат за ресурсами? Майже всі вони претендують на найшвидший.

— грабіжник

@rowman Ти спробував мій приклад? Використання x264 для створення виходу без втрат повинно дати дещо схожі показники порівняно з іншими переліченими кодерами. Може, трохи повільніше; можливо трохи швидше, але я думаю, що відмінності не повинні бути значними.

— логіан

@LordNeckbeard, так, я зробив. x264 у вашому прикладі має 60-70% перевантаження на моєму процесорі, а huffyuv, utvideo, ffv1 мають в середньому 25-35%. У мене є солідний атом Intel;)

— веслувач