Recherche avancée

Sur d’autres sites (3792)

• "Automatic" switchable graphics on desktop, is there a way to disable them ?

  14 août 2021, par Hab-Land0

  Recently, I've updated my graphic drivers for a new system I built, a mix between an amd apu and an nvidia quadro. But I stumbled upon a rare problem, every time I tried to use OpenCL acceleration on ffmpeg for libx264 encoding, ffmpeg notifies me with the next line :

  


  [libx264 @ 0000028149222780] OpenCL acceleration disabled, switchable graphics detected


  


  When searching this line on ffmpeg's code, apparently occurs when the "main OpenCL driver" (if you can call it that) is redirected in such a way that tries to use both devices (Code).

  


  My obvious next step was to search everything I could around this "switchable graphics", but almost all the tutorials on websites told me that I should search around the driver's settings, but literally either Radeon Software or Nvidia's control panel don't display any option about it (It is worth to say that almost all of the tutorials refer to laptops with dedicated graphics and were very outdated).

  


  Another way I use OpenCL is for vapoursynth's filters, such as KNLMeansCL. And, when I make use of this filter, task manager detects that both AMD's APU and Nvidia's gpu are being used simultaneously (I guess that's how the switchable graphics actually works, and partially complementing why x264 OpenCL doesn't work).

  


  My main complain with this is that I attempt to use AMD as a display driver and let Nvidia do the hard work, and I actually was able to do that before updating my drivers. And, talking about the "updates" more in-depth, I updated nvidia's from "462.59" to "471.11" and, unfortunately, I can't remember what versions were my AMD drivers.

  


  Edit : the only way I can make full use of NVIDIA's card is by using it as my main display, but that also apparently disables AMD's igpu, I am not sure if its even able to be used on small tasks (like those that were previously mentioned)

  


• avcodec/h274 : add film grain synthesis routine

  17 août 2021, par Niklas Haas

  avcodec/h274 : add film grain synthesis routine
  This could arguably also be a vf, but I decided to put it here since
  
  decoders are technically required to apply film grain during the output
  
  step, and I would rather want to avoid requiring users insert the
  
  correct film grain synthesis filter on their own.
  The code, while in C, is written in a way that unrolls/vectorizes fairly
  
  well under -O3, and is reasonably cache friendly. On my CPU, a single
  
  thread pushes about 400 FPS at 1080p.
  Apart from hand-written assembly, one possible avenue of improvement
  
  would be to change the access order to compute the grain row-by-row
  
  rather than in 8x8 blocks. This requires some redundant PRNG calls, but
  
  would make the algorithm more cache-oblivious.
  The implementation has been written to the wording of SMPTE RDD 5-2006
  
  as faithfully as I can manage. However, apart from passing a visual
  
  inspection, no guarantee of correctness can be made due to the lack of
  
  any publicly available reference implementation against which to
  
  compare it.
  Signed-off-by : Niklas Haas <git@haasn.dev>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/Makefile
  • [DH] libavcodec/h274.c
  • [DH] libavcodec/h274.h

• avcodec/h264_slice : compute and export film grain seed

  17 août 2021, par Niklas Haas

  avcodec/h264_slice : compute and export film grain seed
  From SMPTE RDD 5-2006, the grain seed is to be computed from the
  
  following definition of `pic_offset` :
  > When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
  
  > follows :
  
  >   - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
  
  > where :
  
  >   - PicOrderCnt(CurrPic) is the picture order count of the current frame,
  
  >     which shall be derived from [the video stream].
  
  >
  
  >   - PicOrderCnt_offset is set to idr_pic_id on IDR frames. idr_pic_id
  
  >     shall be read from the slice header of [the video stream]. On non-IDR I
  
  >     frames, PicOrderCnt_offset is set to 0. A frame shall be classified as I
  
  >     frame when all its slices are I slices, which may be optionally
  
  >     designated by setting primary_pic_type to 0 in the access delimiter NAL
  
  >     unit. Otherwise, PicOrderCnt_offset it not changed. PicOrderCnt_offset is
  
  >     updated in decoding order.
  Co-authored-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Niklas Haas <git@haasn.dev>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/h264_slice.c
  • [DH] libavcodec/h264dec.c
  • [DH] libavcodec/h264dec.h
  • [DH] libavutil/film_grain_params.h