Recherche avancée

Sur d’autres sites (10080)

• Improve ffmpeg x11grab screen capture performance

  10 janvier 2020, par Toby Eggitt

  I have been doing screen-only (no sound) capture using ffmpeg with libx264 for the encoding quite successfully on an old machine built around a Core2 Quad Q6600 processor. I now need to include audio in this, but the fans on this ancient machine are too loud. So, I found a fanless motherboard (https://www.asrock.com/mb/Intel/J5005-ITX/index.asp) that has an Intel Pentium Silver J5005 processor and decided to use this instead. The CPU’s benchmarks put it in a similar bracket to the Q6600, and the general performance seems to be significantly better, presumably at least in part because it’s now using DDR4 memory that’s faster access.

  However, the machine fails horribly at the screen capture. It’s missing frames all over the place ; I actually end up with video that’s missing almost half the frames, and plays back at about double speed. Also, any audio is just messed up so badly I can hardly think how to describe it, best I can come up with is that I get perhaps a quarter second of sound then a few seconds pause (the video meanwhile is actually still playing back, albeit with no sense of time).

  Some things occur to me that might be the cause, or cure, of my troubles, some of which I might be able to fix, others not so much. What other things should I try ? (I’d prefer to avoid simply throwing money at the issue with random ideas that are baseless !)

  1) perhaps the CPU lacks some "extensions" to the instruction set (I recall years ago some CPUs gaining MMX extensions") so that the CPU is fast at mundane computing but sucks at video encoding.

  2) perhaps the fact that the old machine had a dedicated graphics card, while this new one is sharing main memory with the graphics system means that reading the screen pixels is much slower.

  3) perhaps the fact that this new machine has a single DDR4 memory stick in it means that I’m forcing all the memory reads and writes for the computations through the same memory as is holding the screen, and that’s too much (implying that adding an additional memory stick might jus possibly help ?)

  4) perhaps there’s some bios setting that would allow more efficient sharing of video memory ?

  5) my favorite, perhaps there’s a better compression library that I could use to get decent quality screen capture with much less CPU usage.

  I should also note that I have tried this with -threads 0, and the CPU usage hovers between 100% and 200% ; around 100% when the screen is static, and rising as I move windows around and otherwise create more output.

  6) the motherboard claims to have some kind of hardware video encoder built into it. I haven’t paid this any attention to this point, as I assumed it was for the purpose of taking HDMI input and encoding it, but maybe there’s a way to use this, if so, what libraries might I need to get ffmpeg to do this.

  Edits :

  • This is an off the shelf ffmpeg. I’m certainly willing to try building it myself if I have some idea what I should do different.
  • The motherboard claims to have hardware encoders, but I’m struggling to find out what they are (seems like it’s an Intel chip called "UHD Graphics 605" but nothing I can find suggests ffmpeg can work with that)

  • command line right now has been (without audio) :

    ffmpeg  -video_size 1280x720   -f x11grab  -i ${DISPLAY}+100,100  -vcodec libx264  -f alsa -i pulse -acodec ac3 -threads 0  ./video$(date +%F-%H-%M-%S).mp4

  Log from a short recording session is :

  ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  
    built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  
    configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  
    libavutil      55. 78.100 / 55. 78.100
  
    libavcodec     57.107.100 / 57.107.100
  
    libavformat    57. 83.100 / 57. 83.100
  
    libavdevice    57. 10.100 / 57. 10.100
  
    libavfilter     6.107.100 /  6.107.100
  
    libavresample   3.  7.  0 /  3.  7.  0
  
    libswscale      4.  8.100 /  4.  8.100
  
    libswresample   2.  9.100 /  2.  9.100
  
    libpostproc    54.  7.100 / 54.  7.100
  
  [x11grab @ 0x561a723e5ac0] Stream #0: not enough frames to estimate rate; consider increasing probesize
  
  Input #0, x11grab, from ':0+100,100':
  
    Duration: N/A, start: 1578693116.465807, bitrate: N/A
  
      Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1280x720, 29.97 fps, 1000k tbr, 1000k tbn, 1000k tbc
  
  Unknown decoder 'libx264'
  
  simon@studio:~$ ffmpeg  -video_size 1280x720   -f x11grab  -i ${DISPLAY}+100,100  -vcodec libx264 -threads 0  ./video$(date +%F-%H-%M-%S).mp4
  
  ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  
    built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  
    configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  
    libavutil      55. 78.100 / 55. 78.100
  
    libavcodec     57.107.100 / 57.107.100
  
    libavformat    57. 83.100 / 57. 83.100
  
    libavdevice    57. 10.100 / 57. 10.100
  
    libavfilter     6.107.100 /  6.107.100
  
    libavresample   3.  7.  0 /  3.  7.  0
  
    libswscale      4.  8.100 /  4.  8.100
  
    libswresample   2.  9.100 /  2.  9.100
  
    libpostproc    54.  7.100 / 54.  7.100
  
  [x11grab @ 0x558225bc29a0] Stream #0: not enough frames to estimate rate; consider increasing probesize
  
  Input #0, x11grab, from ':0+100,100':
  
    Duration: N/A, start: 1578693132.513351, bitrate: N/A
  
      Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1280x720, 29.97 fps, 1000k tbr, 1000k tbn, 1000k tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
  
  Press [q] to stop, [?] for help
  
  [libx264 @ 0x558225bcd360] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
  
  [libx264 @ 0x558225bcd360] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit
  
  [libx264 @ 0x558225bcd360] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 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=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to './video2020-01-10-14-52-12.mp4':
  
    Metadata:
  
      encoder         : Lavf57.83.100
  
      Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv444p, 1280x720, q=-1--1, 29.97 fps, 30k tbn, 29.97 tbc
  
      Metadata:
  
        encoder         : Lavc57.107.100 libx264
  
      Side data:
  
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
  
  Past duration 0.806847 too large     256kB time=00:00:00.43 bitrate=4835.3kbits/s dup=16 drop=0 speed=0.207x    
  
  frame=  371 fps= 29 q=-1.0 Lsize=     639kB time=00:00:12.27 bitrate= 426.6kbits/s dup=16 drop=14 speed=0.971x    
  
  video:634kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.813096%
  
  [libx264 @ 0x558225bcd360] frame I:2     Avg QP:18.16  size:221502
  
  [libx264 @ 0x558225bcd360] frame P:93    Avg QP:14.97  size:  2007
  
  [libx264 @ 0x558225bcd360] frame B:276   Avg QP:20.13  size:    69
  
  [libx264 @ 0x558225bcd360] consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
  
  [libx264 @ 0x558225bcd360] mb I  I16..4: 44.6%  0.0% 55.4%
  
  [libx264 @ 0x558225bcd360] mb P  I16..4:  0.2%  0.0%  0.3%  P16..4:  0.7%  0.1%  0.1%  0.0%  0.0%    skip:98.5%
  
  [libx264 @ 0x558225bcd360] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  1.0%  0.0%  0.0%  direct: 0.0%  skip:99.0%  L0:50.9% L1:49.0% BI: 0.1%
  
  [libx264 @ 0x558225bcd360] coded y,u,v intra: 41.3% 37.5% 37.4% inter: 0.1% 0.0% 0.0%
  
  [libx264 @ 0x558225bcd360] i16 v,h,dc,p: 58% 41%  1%  0%
  
  [libx264 @ 0x558225bcd360] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 30% 14%  2%  4%  4%  5%  3%  5%
  
  [libx264 @ 0x558225bcd360] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x558225bcd360] ref P L0: 59.2%  8.8% 25.5%  6.5%
  
  [libx264 @ 0x558225bcd360] ref B L0: 59.4% 39.0%  1.6%
  
  [libx264 @ 0x558225bcd360] ref B L1: 96.5%  3.5%
  
  [libx264 @ 0x558225bcd360] kb/s:419.29
  
  Exiting normally, received signal 2.

• avcodec/h264_slice : don't sync default_ref[] between threads.

  18 juillet 2017, par Wan-Teh Chang

  avcodec/h264_slice : don't sync default_ref[] between threads.
  default_ref[] is unconditionally initialized in h264_initialise_ref_list()
  
  (called from ff_h264_build_ref_list(), called from h264_slice_init()).
  This fixes the following tsan warning when running fate-h264 :
  WARNING : ThreadSanitizer : data race (pid=31070)
  
    Write of size 8 at 0x7bbc000082a8 by thread T1 (mutexes : write M1628) :
  
      #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
  
  (ffmpeg+0x10de9d)
  
      #1 h264_initialise_ref_list ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
  
      #2 ff_h264_build_ref_list ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
  
      #3 h264_slice_init ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
  
  [..]
  
    Previous read of size 8 at 0x7bbc000082a8 by main thread (mutexes :
  
  write M1630) :
  
      #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
  
  (ffmpeg+0x10de9d)
  
      #1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)
  Signed-off-by : Wan-Teh Chang <wtc@google.com>
  
  Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
  

  • [DH] libavcodec/h264_slice.c

• why reducing the resolution a percentage doesn't reduce the video the same proportion using ffmpeg ?

  14 mars 2023, par user44551

  I'm using this command :

  


  -y -r -i $inVideoUri -movflags faststart -c:v libx265 -s $videoResolution -c:a copy -preset ultrafast $outPutUri"


  


  However, if "videoResolution" is a 50% of the original video resolution, the resulting file size is not 50% of the original one. I assume there are some headers or metadata added during the process but I would like to know how to estimate the final video size.