Recherche avancée

Sur d’autres sites (11216)

• avcodec/libsvtav1 : properly enforce CQP mode when set in wrapper

  25 septembre 2021, par Limin Wang

  avcodec/libsvtav1 : properly enforce CQP mode when set in wrapper
  SVT-AV1 seems to have switched their default from CQP to CRF in February,
  
  so enforce the controlling option accordingly.
  Signed-off-by : Limin Wang <lance.lmwang@gmail.com>
  

  • [DH] libavcodec/libsvtav1.c

• lavfi/qsvvpp : support async depth

  31 mars 2021, par Fei Wang

  lavfi/qsvvpp : support async depth
  Async depth will allow qsv filter cache few frames, and avoid force
  
  switch and end filter task frame by frame. This change will improve
  
  performance for some multi-task case, for example 1:N transcode(
  
  decode + vpp + encode) with all QSV plugins.
  Performance data test on my Coffee Lake Desktop(i7-8700K) by using
  
  the following 1:8 transcode test case improvement :
  
  1. Fps improved from 55 to 130.
  
  2. Render/Video usage improved from 61%/ 38% to 100%/ 70%.(Data get
  
  from intel_gpu_top)
  test CMD :
  
  ffmpeg -v verbose -init_hw_device qsv=hw :/dev/dri/renderD128 -filter_hw_device                 \
  
   hw -hwaccel qsv -hwaccel_output_format qsv -c:v h264_qsv -i 1920x1080.264                     \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
  
   vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null -
  Signed-off-by : Fei Wang <fei.w.wang@intel.com>
  
  Reviewed-by : Linjie Fu <linjie.justin.fu@gmail.com>
  
  Signed-off-by : Zhong Li <zhongli_dev@126.com>
  

  • [DH] libavfilter/qsvvpp.c
  • [DH] libavfilter/qsvvpp.h
  • [DH] libavfilter/vf_deinterlace_qsv.c
  • [DH] libavfilter/vf_vpp_qsv.c

• Can you think of a reason why windows might not enable audio if noone is logged in ?

  3 juillet 2017, par Caius Jard

  I’m having a bizarre problem with some virtual servers created to record podcasts. They run on amazon AWS as windows server 2012 instances and a small c# app tells FFMPEG to do the heavy lifting of capturing from the virtual screen and reading from the virtual sound card (Virtual Audio Cable : https://en.wikipedia.org/wiki/Virtual_Audio_Cable) via DirectShow filters

  The problem I have is if I leave the machine to do its stuff unattended, the recordings are sometimes silent. If I log in via VNC and watch it doing its stuff the audio is recorded just fine. All other aspects of the test op are the same, and the virtual machine is shut down between successive recordings so each one should theoretically be a clean slate. The app runs under a logged in session (hence the use of VNC rather than RDP)

  I’m now wondering if there is some optimisation of the windows sound engine whereby it doesn’t bother playing audio if it thinks noone is listening. The confusing thing to me is that not every virtual machine suffers these problems ; some of them record fine (and they’re all created from the same seed virtual hard disk image) in unattended mode

  I’m asking this question with the aim of getting together a list of things I can check/look into/debug.. I don’t have much knowledge of how MME/DirectSound/WASAPI work internally...