Casting d'écran avec ffmpeg (trop rapide)

Je peux utiliser ffmpeg pour faire des captures d'écran:

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

Cependant, la sortie se révèle être trop rapide. Cela se produit également GTK RecordMyDesktopsi j'active l'encodage à la volée. Donc, la question est de savoir comment obtenir un rythme vidéo normal. Aussi pour capturer le son avec ffmpeg, quelle option doit-on utiliser?

Sortie 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
source

-f alsa -i pulsedevrait vous obtenir une entrée audio. Pouvez-vous également nous fournir la sortie de ligne de commande complète et non coupée?

— slhck

Je vois x11graba une -framerateoption . Il est par défaut NTSC, donc vous pourriez peut-être utiliser -framerate 30et -r 30pour la sortie en combinaison?

— slhck

@slhck, merci. le message est mis à jour selon votre suggestion, cependant le même problème. Mon ordinateur n'est pas très rapide non plus.

— Rowman

@slhck, je pense avoir une idée de ce qui se passe. Il semble qu'il manque quelques clichés entre les deux en faisant l'encodage en même temps. C'est pourquoi cela semble plus rapide. Surtout lorsque la charge est plus élevée, le taux de perte d'image est beaucoup plus élevé et la vidéo saute. Existe-t-il une méthode pour capturer simplement sans encoder et encoder la vidéo lorsque la capture est terminée, comme le fait GTK RecordMyDesktop?

— Rowman

Je crois que le problème est le premier, -r 30cela signifie "ignorer les horodatages des données entrantes et les traiter comme s'il s'agissait exactement de 30 ips" - essayez plutôt de cadrer à 30 "

— rogerdpack

Essayez d'utiliser un encodeur sans perte pour capturer l'écran, puis réencodez la sortie lorsque vous avez terminé pour créer un fichier plus petit si vous le souhaitez. L'avantage de cette méthode est souvent un processus de capture moins intensif qui peut entraîner une cadence de capture "plus rapide". Bien sûr, les résultats peuvent varier.

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

Il est possible que votre CPU n'ait tout simplement pas la capacité de coder à votre fréquence d'images déclarée à une taille de capture d'écran particulière. Dans ce cas, vous pouvez essayer une -svaleur plus petite . Cela pourrait valoir la peine d'expérimenter avec d'autres encodeurs sans perte tels que huffyuv, ffv1 ou utvideo, mais je ne les ai personnellement pas essayés pour les screencasts.

Plus d'informations:

HOWTO: Screencasting approprié sous Linux
Capture audio avec FFmpeg et ALSA (comme alternative à pulse)

— llogan
source

Il semble que les autres codecs sans perte que vous avez mentionnés utilisent moins de ressources que le x264. Je commenterai plus précisément cela plus tard.

— Rowman

@rowman Presque tous les encodeurs sont moins gourmands en ressources que les encodeurs x264 (ou généralement les encodeurs h.264), ce qui est simplement une question de qualité par rapport au temps nécessaire pour encoder. C'est pourquoi de nombreux utilisateurs s'en tiennent toujours à XviD ou similaire en ce qui concerne l'encodage en temps réel.

— slhck

| @slhck Bon point. Le conteneur a-t-il également un effet sur les ressources? et Existe-t-il une documentation sur la comparaison des différents codecs vidéo sans perte en termes de ressources? Presque tous prétendent être les plus rapides.

— Rowman

@rowman Avez-vous essayé mon exemple? L'utilisation de x264 pour créer une sortie sans perte devrait donner des performances quelque peu similaires par rapport aux autres encodeurs que j'ai énumérés. Peut-être un peu plus lentement; peut-être un peu plus vite, mais j'imagine que les différences ne devraient pas être considérables.

— llogan

@ LordNeckbeard, oui je l'ai fait. x264 dans votre exemple a une surcharge de 60 à 70% sur mon processeur tandis que huffyuv, utvideo, ffv1 ont une moyenne de 25 à 35%. J'ai un atome d'Intel solide;)

— Rowman