Przesyłanie ekranu za pomocą ffmpeg (za szybko)

Za pomocą ffmpeg mogę wykonywać rzutowania ekranu:

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

Jednak wyniki okazują się zbyt szybkie. Dzieje się tak również wtedy, GTK RecordMyDesktopgdy włączę kodowanie w locie. Pytanie brzmi więc, jak uzyskać normalne tempo wideo. Również, aby uchwycić dźwięk za pomocą ffmpeg, jakiej opcji należy użyć?

Wyjście 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

— wioślarz
źródło

-f alsa -i pulsepowinien zapewnić ci wejście audio. Czy możesz również podać nam pełne, nieocięte dane wyjściowe z wiersza poleceń?

— slhck 13.10.12

Widzę, x11grabma -framerateopcję . Domyślnie jest to NTSC, więc możesz użyć -framerate 30i -r 30dla wyjścia w połączeniu?

— slhck 13.10.12

@slhck, dzięki. post jest aktualizowany zgodnie z twoją sugestią, jednak ten sam problem. Mój komputer też nie jest tak szybki.

— rowman

@slhck, myślę, że mam jakieś pojęcie, co się dzieje. Wygląda na to, że brakuje niektórych ujęć pomiędzy nimi podczas jednoczesnego kodowania. Dlatego wydaje się szybszy. Zwłaszcza, gdy obciążenie jest wyższe, szybkość utraty klatek jest znacznie wyższa, a wideo po prostu przeskakuje. Czy istnieje metoda przechwytywania bez kodowania i kodowania wideo po zakończeniu przechwytywania, tak jak w przypadku GTK RecordMyDesktop?

— rowman

Uważam, że problem jest pierwszy, -r 30co oznacza „zignoruj znaczniki czasowe danych przychodzących i traktuj to tak, jakby to było dokładnie 30 fps,„ spróbuj ”-framerate 30” zamiast tego

— rogerdpack

Spróbuj użyć bezstratnego kodera, aby przechwycić ekran, a następnie ponownie zakoduj dane wyjściowe, gdy skończysz, aby w razie potrzeby utworzyć mniejszy plik. Zaletą tej metody jest często mniej intensywny proces przechwytywania, który może skutkować „szybszą” liczbą klatek przechwytywania. Oczywiście wyniki mogą się różnić.

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

Możliwe, że Twój procesor po prostu nie ma możliwości kodowania z zadeklarowaną liczbą klatek na sekundę przy określonym rozmiarze przechwytywania ekranu. W takim przypadku możesz wypróbować mniejszą -swartość. Być może warto eksperymentować z innymi bezstratnymi koderami, takimi jak huffyuv, ffv1 lub utvideo, ale ja osobiście nie próbowałem ich do screencastów.

Więcej informacji:

HOWTO: Właściwe wyświetlanie ekranu w systemie Linux
Przechwytywanie dźwięku za pomocą FFmpeg i ALSA (jako alternatywa dla impulsu)

— Llogan
źródło

Wygląda na to, że inne bezstratne kodeki, o których wspomniałeś, są mniej zasobochłonne w porównaniu do x264. Skomentuje to dokładniej później.

— rowman

@rowman Prawie każdy koder wymaga mniej zasobów niż x264 (lub ogólnie kodery h.264), co jest po prostu kwestią jakości w porównaniu do czasu potrzebnego na kodowanie. To dlatego wielu użytkowników nadal trzyma się XviD lub podobnego, jeśli chodzi o kodowanie w czasie rzeczywistym.

— slhck 14.10.12

| @slhck Dobra uwaga. Czy kontener ma również wpływ na zasoby? oraz Czy istnieje literatura na temat porównywania różnych bezstratnych kodeków wideo pod względem zasobów? Prawie wszyscy twierdzą, że są najszybsi.

— rowman

@rowman Czy próbowałeś mojego przykładu? Użycie x264 do stworzenia bezstratnego wyjścia powinno dać nieco podobną wydajność w porównaniu do innych koderów wymienionych na liście. Może trochę wolniej; może trochę szybciej, ale wyobrażam sobie, że różnice nie powinny być znaczne.

— llogan

@ LordNeckbeard, tak zrobiłem. x264 w twoim przykładzie ma 60-70% przeciążenia mojego procesora, podczas gdy huffyuv, utvideo, ffv1 mają średnio 25-35%. Mam solidny atom wywiadu;)

— rowman