Recherche avancée

Sur d’autres sites (3178)

• FFMPEG using a screen capture for an overlay results in serious visual flaws

  3 octobre 2017, par Joey

  I’m trying to overlay a screen capture of a specific window on top of a background image, and output the result - it works but results in unacceptable visual flaws.

  The command I’m using is :

  ffmpeg -loop 1 -r 30 -i background.jpg -f gdigrab -r 30 -i title=Calculator \
  
  -filter_complex "[0:v][1:v]overlay=10:10[video]" -map "[video]" -c:v libx264 \
  
  -f flv output.flv

  which places a screencap of the calculator window on the background at position 10,10.

  This is what the output looks like :

  

  All the buttons on the calculator are super muddied and appear bold, almost as if it was overlaid several times at slightly different positions. Is there something wrong with the command or any way to fix it and preserve visual integrity of the original ? Changing the output format doesn’t have any effect, nor does setting -crf 0 or adjusting any other encoding settings.

  This doesn’t happen when I screen capture just the calculator by itself without overlaying it on anything. For reference here is what the output looks like when I only record the calculator with no overlaying :

  

• intreadwrite : Indicate potential aliasing in AV_RN/AV_WN for Clang/MSVC mode

  1er août 2023, par Martin Storsjö

  intreadwrite : Indicate potential aliasing in AV_RN/AV_WN for Clang/MSVC mode
  Use the GCC specific codepath for Clang in MSVC mode too.
  
  This matches the condition used in a number of other places.
  MSVC doesn't have a way to signal potential aliasing, while GCC
  
  (and Clang) can use __attribute__((may_alias)) for this purpose.
  When building with Clang in MSVC mode, __GNUC__ isn't defined but
  
  _MSC_VER is as Clang primarily impersonates MSVC - but even then it
  
  does support the GCC style attributes.
  The GCC specific codepath uses av_alias, which expands to
  
  the may_alias attribute if supported. The MSVC specific codepath
  
  doesn't use av_alias so far (as MSVC doesn't support any
  
  corresponding attribute).
  This fixes a couple HEVC decoder tests when built with Clang 14 or
  
  newer in MSVC mode (with issues observed on all of x86_64, armv7
  
  and aarch64).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavutil/intreadwrite.h

• Evolution #3039 (Nouveau) : Spip 2.1 : prise en compte des champs_extra dans editer_artcile

  11 août 2013, par Arnaud Dupin de Beyssat

  Bonjour
  Après la création d’un formulaire Spip (sans usage de plugin) remplissant un article avec champs_extra, je me suis aperçu que les champs_extra n’étaient pas pris en compte.
  Après recherche, j’ai contaté que le pb venait du fichier action/editer_article qui limite la saisie aux champs Spip.
  Je l’ai donc patché en ajoutant les intitulés de mes champs extra, comme suit :

  function articles_set($id_article, $set=null)
  $err = ’’ ;
  // unifier $texte en cas de texte trop long
  trop_longs_articles() ;

  $c = array();<br />    foreach (array(<br />        'surtitre', 'titre', 'soustitre', 'descriptif',<br />        'nom_site', 'url_site', 'chapo', 'texte', 'ps'<br />//patch ADB        <br />        , 'latitude', 'longitude', 'cartes', 'zone_meteo', 'capitainerie', 'secours', 'freq_radio', 'distances', 'svce_meteo', 'jour', 'nuit', 'dangers', 'feux', 'acces', 'te', 'places', 'equipement', 'services', 'avitaillement', 'location', 'svce_divers', 'tourisme', 'mouillage', 'decor'<br />// fin patch ADB<br />    ) as $champ)<br />        $c[$champ] = _request($champ,$set);

  De ce fait les champs extra sont remplis.

  Serait-il possible, pour les Spip 2.1, de faire en sorte que les champs_extra existant éventuellement dans la table Articles soient automatiquement pris en compte ?

  Merci