Кастинг экрана с использованием 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

— Rowman
источник

-f alsa -i pulseдолжен получить аудио вход. Можете ли вы дать нам полный, неразрезанный вывод командной строки?

— Slhck

Я вижу, x11grabесть -framerateвариант . По умолчанию NTSC, так что вы можете использовать -framerate 30и -r 30для вывода в комбинации?

— Slhck

@ спасибо, спасибо. пост обновляется по вашему предложению, однако та же проблема. Мой компьютер тоже не такой быстрый.

— гребец

@slhck, я думаю, что знаю, что происходит. Кажется, что он пропускает несколько кадров между ними при одновременном кодировании. Вот почему это кажется быстрее. Особенно, когда нагрузка выше, скорость потери кадров намного выше, а видео просто скачет. Есть ли способ просто захватывать без кодирования и кодировать видео после завершения захвата, как это делает GTK RecordMyDesktop?

— гребец

Я полагаю, что проблема в первую очередь, -r 30это означает, что «игнорируйте временные метки входящих данных и обрабатывайте их так, как если бы это были ровно 30 кадров в секунду вместо« try »-framerate 30»

— rogerdpack

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

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

Вполне возможно, что ваш процессор просто не имеет возможности кодировать с вашей заявленной частотой кадров при определенном размере снимка экрана. В этом случае вы можете попробовать меньшее -sзначение. Возможно, стоит поэкспериментировать с другими кодерами без потерь, такими как huffyuv, ffv1 или utvideo, но я лично не пробовал их для скринкастов.

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

HOWTO: правильная трансляция в Linux
Захват аудио с помощью FFmpeg и ALSA (в качестве альтернативы импульсу)

— llogan
источник

Кажется, что другие упомянутые вами кодеки без потерь менее ресурсоемки по сравнению с x264. Более точно прокомментируем это позже.

— гребец

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

— Slhck

| @slhck Хороший вопрос. Контейнер также влияет на ресурсы? и есть ли литература по сравнению различных видеокодеков без потерь с точки зрения ресурсов? Почти все они утверждают, что они самые быстрые.

— гребец

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

— Llogan

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

— гребец