Screen Casting menggunakan ffmpeg (terlalu cepat)

Saya bisa menggunakan ffmpeg untuk membuat gips layar:

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

Namun hasilnya terlalu cepat. Ini juga terjadi GTK RecordMyDesktopjika saya mengaktifkan encode on the fly. Jadi, pertanyaannya adalah bagaimana cara mendapatkan kecepatan video yang normal. Juga untuk menangkap suara dengan ffmpeg opsi apa yang harus digunakan?

Output 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

— pekerja baris
sumber

-f alsa -i pulseAnda harus mendapatkan input audio. Bisakah Anda memberi kami output baris perintah yang lengkap dan belum dipotong juga?

— slhck

Saya melihat x11grabmemiliki -framerateopsi . Ini default ke NTSC, jadi Anda mungkin dapat menggunakan -framerate 30dan -r 30untuk output dalam kombinasi?

— slhck

Sslhck, terima kasih. posting diperbarui sesuai dengan saran Anda, namun masalah yang sama. Komputer saya juga tidak secepat itu.

— rowman

Sslhck, saya pikir saya tahu apa yang terjadi. Tampaknya ia melewatkan beberapa bidikan di antaranya saat melakukan pengkodean pada saat yang sama. Itu sebabnya sepertinya lebih cepat. Khususnya ketika beban lebih tinggi tingkat kehilangan bingkai jauh lebih tinggi dan video hanya melompat. Apakah ada metode untuk hanya menangkap tanpa penyandian dan penyandian video saat pengambilan dilakukan, seperti yang dilakukan oleh GTK RecordMyDesktop?

— rowman

Saya percaya masalahnya adalah yang pertama -r 30ini berarti "mengabaikan cap waktu data yang masuk dan memperlakukannya seolah-olah itu tepat 30 fps" coba "-framerate 30" di sana sebagai gantinya

— rogerdpack

Coba gunakan enkode lossless untuk menangkap layar, dan kemudian menyalin kembali output ketika Anda selesai membuat file yang lebih kecil jika diinginkan. Keuntungan dari metode ini adalah proses penangkapan yang kurang intensif yang dapat menghasilkan laju bingkai tangkapan yang lebih cepat. Tentu saja hasilnya bisa bervariasi.

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

Ada kemungkinan bahwa CPU Anda tidak memiliki kemampuan untuk menyandikan pada frame rate Anda yang dinyatakan pada ukuran tangkapan layar tertentu. Dalam hal ini Anda dapat mencoba -snilai yang lebih kecil . Mungkin ada baiknya bereksperimen dengan encoders lossless lain seperti huffyuv, ffv1, atau utvideo tapi saya pribadi belum mencoba ini untuk screencasts.

Info lebih lanjut:

HOWTO: Screencasting yang Tepat di Linux
Mengambil audio dengan FFmpeg dan ALSA (sebagai alternatif untuk pulsa)

— llogan
sumber

Tampaknya codec lossless lain yang Anda sebutkan kurang intensif sumber daya dibandingkan dengan x264. Akan berkomentar lebih akurat tentang itu nanti.

— rowman

@rowman Hampir semua encoder kurang intensif sumber daya daripada x264 (atau umumnya, h.264 encoders), yang hanya masalah kualitas vs waktu yang diperlukan untuk menyandikan. Inilah sebabnya mengapa banyak pengguna masih tetap menggunakan XviD atau serupa ketika datang ke pengkodean real-time.

— slhck

| @slhck Poin bagus. Apakah wadah juga berpengaruh pada sumber daya? dan Apakah ada literatur tentang perbandingan berbagai codec video lossless yang berbeda dalam hal sumber daya? Hampir semuanya mengklaim sebagai yang tercepat.

— rowman

@rowman Apakah Anda mencoba contoh saya? Menggunakan x264 untuk membuat output lossless harus memberikan kinerja yang agak mirip dibandingkan dengan encoders lain yang saya daftarkan. Mungkin sedikit lebih lambat; mungkin sedikit lebih cepat, tetapi saya membayangkan perbedaannya tidak terlalu besar.

— Logan

@ LordNeckbeard, ya saya lakukan. x264 dalam contoh Anda memiliki 60-70% kelebihan pada cpu saya sementara huffyuv, utvideo, ffv1 memiliki rata-rata 25-35%. Saya memiliki atom intel yang solid;)

— rowman