Recherche avancée

Sur d’autres sites (7569)

• Merge commit '3ff8fbbf5a7bc40c09db74d4952364997fd3c611'

  11 décembre 2017, par James Almer

  Merge commit '3ff8fbbf5a7bc40c09db74d4952364997fd3c611'
  * commit '3ff8fbbf5a7bc40c09db74d4952364997fd3c611' :
  
    vaapi_h265 : Add named options for setting profile and level
  
    vaapi_h264 : Add named options for setting profile and level
  
    vaapi : Make the decode profile matching more explicit
  
    vaapi_h264 : Fix VUI max_dec_frame_buffering
  
    vaapi_h265 : Enable VBR mode
  This commit is a noop, see
  
  385cafb07ac1e46433931ea9749a134efd7350be
  
  f31478ba1472afe5c1eed60f219ae331816425a2
  
  efd0612fdcb7490ed371899f532d73ef8bb7cba0
  
  c490fc9536dcea7fdf1245a340bf075533610bc2
  
  71421f382f5c53b1a109489a906a80c1b7e3eed7
  Merged-by : James Almer <jamrial@gmail.com>
  

• Find the right path to my folder on server to execute cmd php

  12 avril 2021, par Meds

  exec("ffmpeg -i $temp_name -r $FPS -vf scale='$resolutionWidth:$resolutionHeight' -b:v $bitrateVideo -bufsize $bitrateAudio videos/$videoURLnameTemp.mp4", $res);

  


  This command works well locally, but once in production, the files are not stored in the video folder which is at the same level as the file in the server. Is there any way to get the output on the exec function to catch an error or something ? I tried the output by reference in the method but when I do a var_dump of the result, I get an array(0) {}.

  


  I also tried to put the realpath in the path but it doesn't seem to work. ffmpeg is located at the same level as all files and the videos folder.

  


• avcodec/svq1enc : Workaround GCC bug 102513

  25 octobre 2022, par Andreas Rheinhardt

  avcodec/svq1enc : Workaround GCC bug 102513
  GCC 11 has a bug : When it creates clones of recursive functions
  
  (to inline some parameters), it clones a recursive function
  
  eight times by default, even when this exceeds the recursion
  
  depth. This happens with encode_block() in libavcodec/svq1enc.c
  
  where a parameter level is always in the range 0..5 ;
  
  but GCC 11 also creates functions corresponding to level UINT_MAX
  
  and UINT_MAX - 1 (on -O3 ; -O2 is fine).
  Using such levels would produce undefined behaviour and because
  
  of this GCC emits bogus -Warray-bounds warnings for these clones.
  Since commit d08b2900a9f0935959303da668cb00a8a7245228, certain
  
  symbols that are accessed like ff_svq1_inter_multistage_vlc[level]
  
  are declared with hidden visibility, which allows compilers
  
  to bake the offset implied by level into the instructions
  
  if level is a compile-time constant as it is in the clones.
  
  Yet this leads to insane offsets for level == UINT_MAX which
  
  can be incompatible with the supported offset ranges of relocations.
  
  This happens in the small code model (the default code model for
  
  AArch64).
  This commit therefore works around this bug by disabling cloning
  
  recursive functions for GCC 10 and 11. GCC 10 is affected by the
  
  underlying bug (see
  
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513), so the workaround
  
  also targets it, although it only produces three versions of
  
  encode_block(), so it does not seem to trigger the actual issue here.
  The issue has been mitigated in GCC 12.1 (it no longer creates clones
  
  for impossible values ; see also commit
  
  1cb7fd317c84117bbb13b14851d62f77f57bb9ce), so the workaround
  
  does not target it.
  Reported-by : J. Dekker <jdek@itanimul.li>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  
  Signed-off-by : J. Dekker <jdek@itanimul.li>
  

  • [DH] libavcodec/svq1enc.c