ffmpeg를 사용한 스크린 캐스팅 (너무 빠름)


9

ffmpeg를 사용하여 스크린 캐스트를 만들 수 있습니다.

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

그러나 출력 속도가 너무 빠릅니다. GTK RecordMyDesktop인코딩을 즉석에서 활성화하면 발생합니다 . 따라서 질문은 정상적인 비디오 속도를 얻는 방법입니다. 또한 ffmpeg로 사운드를 캡처하려면 어떤 옵션을 사용해야합니까?

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

-f alsa -i pulse오디오 입력을 받아야합니다. 완전한 커트되지 않은 명령 행 출력도 제공 할 수 있습니까?
slhck

1
내가 볼 x11grab-framerate옵션을 . NTSC에 그것은 기본적으로, 그래서 당신은 아마 사용할 수 -framerate 30-r 30함께 출력 하시나요?
slhck

@ slhck, 감사합니다. 게시물은 귀하의 제안에 따라 업데이트되지만 동일한 문제입니다. 내 컴퓨터도 그렇게 빠르지 않습니다.
rowman

@ slhck, 나는 어떤 일이 생길지 모른다고 생각합니다. 인코딩을하는 동안 사이에 약간의 샷이 누락 된 것 같습니다. 그것이 더 빨리 보이는 이유입니다. 특히 부하가 높을수록 프레임 손실률이 훨씬 높아지고 비디오가 점프합니다. GTK RecordMyDesktop으로 캡처가 완료되면 인코딩없이 비디오를 캡처하고 비디오를 인코딩하는 방법이 있습니까?
rowman

-r 30" 문제는 이것이 들어오는 데이터 타임 스탬프를 무시하고 마치 정확히 30fps 인 것처럼 처리 함"을 의미 하는 첫 번째 문제라고 생각합니다. 대신 "-framerate 30"을 시도하십시오
rogerdpack

답변:


5

무손실 인코더를 사용하여 화면을 캡처 한 다음 원하는 경우 더 작은 파일을 만들었 으면 출력을 다시 인코딩하십시오. 이 방법의 장점은 캡처 프로세스 속도가 더 빠를 수있는 덜 집중적 인 캡처 프로세스입니다. 물론 결과는 다를 수 있습니다.

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

CPU에 선언 된 프레임 속도로 특정 화면 캡처 크기로 인코딩 할 수있는 기능이 없을 수도 있습니다. 이 경우 더 작은 -s값을 시도 할 수 있습니다 . huffyuv, ffv1 또는 utvideo와 같은 다른 무손실 인코더로 실험 해 볼 가치가 있지만 개인적으로 스크린 캐스트에는 시도하지 않았습니다.

더 많은 정보:


언급 한 다른 무손실 코덱은 x264에 비해 리소스 집약도가 적습니다. 나중에 그것에 대해 더 정확하게 언급 할 것입니다.
rowman

1
@rowman 거의 모든 인코더는 x264 (또는 일반적으로 h.264 인코더)보다 리소스를 덜 사용합니다. 이는 단순히 인코딩하는 데 걸리는 시간과 품질의 문제입니다. 이것이 실시간 인코딩에있어 많은 사용자들이 여전히 XviD 또는 이와 유사한 것을 고집하는 이유입니다.
slhck

| @slhck 좋은 지적입니다. 컨테이너도 리소스에 영향을 줍니까? 리소스 측면에서 다양한 무손실 비디오 코덱을 비교하는 문헌이 있습니까? 거의 모든 것이 가장 빠른 것으로 주장합니다.
rowman

@rowman 내 예를 보았습니까? x264를 사용하여 무손실 출력을 만들면 나열된 다른 인코더와 비교하여 다소 유사한 성능을 제공해야합니다. 어쩌면 조금 느려질 수도 있습니다. 어쩌면 조금 더 빠를 지 모르지만 차이점이 크지 않아야한다고 생각합니다.
llogan

@LordNeckbeard, 그렇습니다. 귀하의 예에서 x264는 내 CPU에 과부하가 60-70 % 인 반면, huffyuv, utvideo, ffv1은 평균 25-35 %입니다. 나는 단단한
지능
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.