Screen Casting mit ffmpeg (zu schnell)

Ich kann ffmpeg verwenden, um Screencasts zu erstellen:

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

Die Ausgabe ist jedoch zu schnell. Es passiert auch, GTK RecordMyDesktopwenn ich die Codierung im laufenden Betrieb aktiviere. Die Frage ist also, wie man ein normales Videotempo erreicht. Welche Option sollte auch verwendet werden, um den Sound mit ffmpeg aufzunehmen?

FFmpeg-Ausgabe:

    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
quelle

-f alsa -i pulsesollte Ihnen Audioeingang bekommen. Können Sie uns auch die vollständige, ungeschnittene Befehlszeilenausgabe geben?

— Slhck

Ich sehe x11grabhat eine -framerateOption . Der Standardwert ist NTSC, sodass Sie möglicherweise -framerate 30und -r 30für die Ausgabe in Kombination verwenden können.

— Slhck

@slhck, danke. Der Beitrag wird gemäß Ihrem Vorschlag aktualisiert, jedoch das gleiche Problem. Mein Computer ist auch nicht so schnell.

— Rowman

@slhck, ich glaube ich habe eine Ahnung was passiert. Es scheint, dass einige Aufnahmen dazwischen fehlen, während gleichzeitig die Codierung durchgeführt wird. Deshalb scheint es schneller. Insbesondere wenn die Last höher ist, ist die Bildverlustrate viel höher und das Video springt einfach. Gibt es eine Methode, um das Video nach der Aufnahme einfach ohne Codierung aufzunehmen und zu codieren, wie dies von GTK RecordMyDesktop durchgeführt wird?

— Rowman

Ich glaube , das Problem ist die erste -r 30diese Mittel „ignorieren den eingehenden Daten Zeitstempel und es zu behandeln , als wäre es genau waren 30 fps“ versuchen „-framerate 30“ dort statt

— rogerdpack

Versuchen Sie, den Bildschirm mit einem verlustfreien Encoder zu erfassen, und codieren Sie die Ausgabe neu, wenn Sie fertig sind, um bei Bedarf eine kleinere Datei zu erstellen. Der Vorteil dieser Methode ist häufig ein weniger intensiver Erfassungsprozess, der zu einer "schnelleren" Erfassungsbildrate führen kann. Natürlich können die Ergebnisse variieren.

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

Es ist möglich, dass Ihre CPU einfach nicht in der Lage ist, mit Ihrer angegebenen Bildrate bei einer bestimmten Bildschirmaufnahmegröße zu codieren. In diesem Fall können Sie einen kleineren -sWert ausprobieren . Es könnte sich lohnen, mit anderen verlustfreien Encodern wie huffyuv, ffv1 oder utvideo zu experimentieren, aber ich persönlich habe diese nicht für Screencasts ausprobiert.

Mehr Info:

HOWTO: Richtiges Screencasting unter Linux
Audioaufnahme mit FFmpeg und ALSA (als Alternative zum Puls)

— llogan
quelle

Es scheint, dass die anderen verlustfreien Codecs, die Sie erwähnt haben, im Vergleich zu x264 weniger ressourcenintensiv sind. Ich werde das später genauer kommentieren.

— Rowman

@rowman Fast jeder Encoder ist weniger ressourcenintensiv als x264 (oder allgemein h.264-Encoder), was einfach eine Frage der Qualität im Verhältnis zur Zeit ist, die für die Codierung benötigt wird. Aus diesem Grund halten sich viele Benutzer bei der Echtzeitcodierung immer noch an XviD oder ähnliches.

— Slhck

| @slhck Guter Punkt. Hat der Container auch Auswirkungen auf die Ressourcen? und Gibt es Literatur zum Vergleich verschiedener verlustfreier Videocodecs in Bezug auf Ressourcen? Fast alle behaupten, der Schnellste zu sein.

— Rowman

@rowman Hast du mein Beispiel ausprobiert? Die Verwendung von x264 zum Erstellen einer verlustfreien Ausgabe sollte im Vergleich zu den anderen von mir aufgelisteten Encodern eine ähnliche Leistung bieten. Vielleicht etwas langsamer; vielleicht etwas schneller, aber ich stelle mir vor, dass die Unterschiede nicht wesentlich sein sollten.

— Llogan

@ LordNeckbeard, ja, ich habe es getan. x264 in Ihrem Beispiel hat 60-70% Überlastung auf meiner CPU, während huffyuv, utvideo, ffv1 durchschnittlich 25-35% haben. Ich habe ein festes Intel-Atom;)

— Rowman