Recherche avancée

Sur d’autres sites (11553)

• How to disable switchable graphics ?

  20 juillet 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


  


  My obvious 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).

  


  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.

  


• fate/oggvorbis : Fix tests after fixing AV_PKT_DATA_SKIP_SAMPLES

  10 juillet 2021, par Guangyu Sun

  fate/oggvorbis : Fix tests after fixing AV_PKT_DATA_SKIP_SAMPLES
  After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
  
  the actual decoded samples become fewer. Three fate tests are failing :
  fate-vorbis-20 :
  
  The samples in 6.ogg are not frame aligned. 6.pcm file was generated by
  
  ffmpeg before the fix. After the fix, the decoded pcm file does not match
  
  anymore. Ideally the ref file 6.pcm should be updated but it is probably
  
  not worth it including another copy of the same file, only smaller.
  
  SIZE_TOLERANCE is added for this test case.
  fate-webm-dash-chapters :
  
  The original vorbis_chapter_extension_demo.ogg is transmuxed to dash-webm.
  
  The ref file webm-dash-chapters needs to be updated.
  fate-vorbis-encode :
  
  This exposes another bug in the vorbis encoder that initial_padding is not
  
  correctly set. It is fixed in the previous patch.
  Signed-off-by : Guangyu Sun <gsun@roblox.com>
  

  • [DH] tests/fate/vorbis.mak
  • [DH] tests/ref/fate/webm-dash-chapters

• pulling file size, in mb, in batch, then use it as a conditionnal for further commands

  6 juillet 2021, par Youcef

  I'm new and very novice with batch and don't fully understand how conditionals and executions work within it. So please bear with me.
I'm starting up with these two lines

  


  "%~dp0\ffmpeg.exe" -i "%~1" -threads 8 -ss 00:04:03.000 -to 00:04:17.000 -c:v libvpx -crf 4 -r 30 -b:v 2050K -vf scale=-1:520 -an -f webm -pass 1 -y NUL
"%~dp0\ffmpeg.exe" -i "%~1" -threads 8 -ss 00:04:03.000 -to 00:04:17.000 -c:v libvpx -crf 4 -r 30 -b:v 2050K -vf scale=-1:520 -an -pass 2 -y "%~n1.webm"


  


  most of it you don't need to worry about. I'm just using ffmpeg commands to produce a webm from a drag & dropped video file (the "% 1" at the start). It works ! I'm only missing the batch portion of this (conditionals/variables) to do what I want to do :

  


  I'm trying to algorithmically pick the best bitrate (which is the -b:v 2050K) to get as close to 3mb as possible. (I known by using constant bitrate, there is a way to force a specific file size, it is lower quality though)

  


  The simplest steps that I could think about to achieve this (and probably in no way the most optimized)
  
1- run the two lines once with a ridiculous bitrate like 6000k
  
2- get file size of the first webm (put it into a variable ?)
  
3- calculate new bitrate with simple rule of three (newbitrate = (oldbitrate x 2.99)/sizeoffirstwebm)
  
4- run the two lines once a gain with the newbitrate
  
5- get the file size of the second webm
  
6- calculate new bitrate with simple rule of three (newbitrate = (oldbitrate*2.99)/sizeofSECONDwebm)
  
7- produce final webm which should be close to my target file size
The reason i'm doing that twice is because bitrate and size are closely, but not perfectly, linearly correlated, so it helps me hone on my 3mb target more closely
  
Sure, it will take like 3 times the time to render anything, but I think it's worth it since I'm already doing that manually.