Đúc màn hình bằng ffmpeg (quá nhanh)

Tôi có thể sử dụng ffmpeg để tạo phôi màn hình:

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

Tuy nhiên, đầu ra đi ra là quá nhanh. Nó cũng xảy ra GTK RecordMyDesktopnếu tôi kích hoạt mã hóa khi đang bay. Vì vậy, các câu hỏi là làm thế nào để có được một tốc độ video bình thường. Ngoài ra để thu được âm thanh với ffmpeg nên sử dụng tùy chọn nào?

Đầu ra 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

— người chèo thuyền
nguồn

-f alsa -i pulsesẽ giúp bạn có được đầu vào âm thanh. Bạn có thể cung cấp cho chúng tôi đầu ra dòng lệnh hoàn chỉnh, không bị cắt không?

— slhck

Tôi thấy x11grabcó một -frameratelựa chọn . Nó mặc định là NTSC, vì vậy bạn có thể sử dụng -framerate 30và -r 30cho đầu ra kết hợp?

— slhck

@slhck, cảm ơn. bài viết được cập nhật theo đề nghị của bạn, tuy nhiên cùng một vấn đề. Máy tính của tôi cũng không nhanh như vậy.

— chèo thuyền

@slhck, tôi nghĩ tôi có manh mối gì đó xảy ra. Có vẻ như nó bỏ lỡ một số bức ảnh ở giữa trong khi thực hiện mã hóa cùng một lúc. Đó là lý do tại sao nó có vẻ nhanh hơn. Đặc biệt khi tải cao hơn, tốc độ mất khung hình cao hơn nhiều và video chỉ nhảy. Có một phương pháp để chỉ quay mà không mã hóa và mã hóa video khi quá trình quay được thực hiện, như được thực hiện bởi GTK RecordMyDesktop?

— chèo thuyền

Tôi tin rằng vấn đề là điều đầu tiên -r 30có nghĩa là "bỏ qua các dấu thời gian dữ liệu đến và xử lý nó như thể nó chính xác là 30 khung hình / giây" thử "

— rogerdpack

Hãy thử sử dụng bộ mã hóa lossless để chụp màn hình, sau đó mã hóa lại đầu ra khi bạn hoàn thành để tạo một tệp nhỏ hơn nếu muốn. Ưu điểm của phương pháp này thường là quá trình chụp ít chuyên sâu hơn có thể dẫn đến tốc độ khung hình "nhanh hơn". Tất nhiên kết quả có thể khác nhau.

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

Có thể CPU của bạn đơn giản là không có khả năng mã hóa ở tốc độ khung hình đã khai báo ở một kích thước chụp màn hình cụ thể. Trong trường hợp đó bạn có thể thử một -sgiá trị nhỏ hơn . Có thể đáng để thử nghiệm với các bộ mã hóa không mất dữ liệu khác như huffyuv, ffv1 hoặc utvideo nhưng cá nhân tôi chưa từng thử chúng cho các screencasts.

Thêm thông tin:

HOWTO: Ghi hình thích hợp trên Linux
Chụp âm thanh với FFmpeg và ALSA (thay thế cho xung)

— khẩu hiệu
nguồn

Có vẻ như các codec không mất dữ liệu khác mà bạn đề cập ít tốn tài nguyên hơn so với x264. Sẽ bình luận chính xác hơn về điều đó sau này.

— chèo thuyền

@rowman Hầu như bất kỳ bộ mã hóa nào đều sử dụng ít tài nguyên hơn x264 (hay nói chung là bộ mã hóa h.264), đây đơn giản là vấn đề chất lượng so với thời gian để mã hóa. Đây là lý do tại sao nhiều người dùng vẫn gắn bó với XviD hoặc tương tự khi nói đến mã hóa thời gian thực.

— slhck

| @slhck Điểm tốt. Liệu container cũng có ảnh hưởng gì đến tài nguyên không? và Có tài liệu nào để so sánh các codec video lossless khác nhau về tài nguyên không? Hầu như tất cả trong số họ tuyên bố là người nhanh nhất.

— chèo thuyền

@rowman Bạn đã thử ví dụ của tôi chưa? Sử dụng x264 để tạo đầu ra lossless sẽ cho hiệu năng tương tự so với các bộ mã hóa khác mà tôi đã liệt kê. Có lẽ chậm hơn một chút; có thể nhanh hơn một chút, nhưng tôi tưởng tượng sự khác biệt không đáng kể.

— llogan

@LordNeckbeard, vâng tôi đã làm. x264 trong ví dụ của bạn có quá tải 60-70% trên cpu của tôi trong khi huffyuv, utvideo, ffv1 có trung bình 25-35%. Tôi có một nguyên tử intel rắn;)

— chèo thuyền