Recherche avancée

Sur d’autres sites (17913)

• FFmpeg - Partial fade effect on overlay image

  22 octobre 2023, par antoox

  I'm having trouble with ffmpeg.

  


  I want to make a 3-second video (example here : https://streamable.com/7uhi7f) with :

  


  

  • A background image (300x350 jpeg file)

  


  • A logo overlaid in the center of the background image (100x40 png file)

  


  • And I would like the logo to fade in and out with the following opacity timeline :

  


  


  

  1. At 0 seconds, the opacity is 0.5

  


  2. At 1 second, the opacity is 1

  


  3. At 2 seconds, the opacity is 0.2

  


  4. At 3 seconds, the opacity is 1.

  


  


  So far I only succeeded in adding an overlay with a fully fade IN (between 0 to 1s) and a fully fade OUT (from 2s to 3s) :

  


  ffmpeg -loop 1 -i background.jpeg -framerate 30 -loop 1 -i logo.png -filter_complex "[0]format=rgba,scale=300:250[o];[1]format=rgba,fade=in:st=0:d=1:alpha=1,fade=out:st=2:d=1:alpha=1[i];[o][i]overlay=x=(W-w)/2:(H-h)/2" -c:v libx264 -t 3 output.mp4

  


  I also tried geq & blend filters without any success.

  


  What would be the more appropriate approach to handle that kind of effect ?

  


• fftools/ffmpeg_enc : move encoding to a separate thread

  2 juin 2023, par Anton Khirnov

  fftools/ffmpeg_enc : move encoding to a separate thread
  As for the analogous decoding change, this is only a preparatory step to
  
  a fully threaded architecture and does not yet make encoding truly
  
  parallel. The main thread will currently submit a frame and wait until
  
  it has been fully processed by the encoder before moving on. That will
  
  change in future commits after filters are moved to threads and a
  
  thread-aware scheduler is added.
  This code suffers from a known issue -  if an encoder with a sync queue
  
  receives EOF it will terminate after processing everything it currently
  
  has, even though the sync queue might still be triggered by other
  
  threads. That will be fixed in following commits.
  

  • [DH] fftools/ffmpeg_enc.c

• Anomalie #3894 : Jointures (erronées ?) avec les boucles documents et leurs critères

  27 janvier 2017, par marcimat ☺☮☯♫

  Jointure avec Documents / id_mot¶

  Par ailleurs pour les mots la jointure que montre tcharles est correcte justement. Cependant, là il cherche les mots clés présents sur les documents, ce qui contredit ce que je disais en 2012 là http://marcimat.magraine.net/SPIP-3-Documents-Mots :

  Ce que SPIP va décider lorsqu’il y a ambiguïté, c’est à dire comme ici (DOCUMENTS){id_mot} alors qu’il existe les 2 tables spip_documents_liens et spip_mots_liens, c’est qu’il va préférer interpréter cela comme une liaison sur la table de lien de la boucle en cours, c’est à dire sur spip_documents_liens, ce qui signifie donc que ça va retourner « les documents attachés à un mot clé »

  Donc, pour ce point, quelque part à un moment donné il y a eu un changement.

  Autres test.¶

  Je viens de remarquer que le problème survient dès lors qu’il y a plusieurs critères optionnels sur la boucle. De telle sorte les boucles suivantes ont une seule jointure sur spip_documents_liens :
  -
  -
  - (+ 1 jointure sur spip_mots_liens)

  C’est dès lors qu’on utilise plusieurs critères optionnels que les problèmes surviennent :
  -

  Si on appelle page=test&id_breve=1 (1er critère) on aura 1 seule jointure :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L1.id_objet = 1)
      AND (L1.objet = ’breve’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_article=1 (2è critère) on aura 2 jointures :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.id_objet = 1)
      AND (L2.objet = ’article’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_rubrique=1 (3è critère) on aura 2 jointures (le L s’incrémente à L3) :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L3.id_objet = 1)
      AND (L3.objet = ’rubrique’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Autrement dit, je pense que SPIP crée une jointure pour la possibilité d’avoir id_breve dans l’URL (L1), pareil pour id_article (L2), etc pour les suivantes.
  Le champ "vu" utilise la première jointure possible (toujours L1 du coup ici). Ensuite SPIP nettoie les jointures inutiles en fonction des paramètres d’environnement reçus, mais il ne peut enlever L1 car le champ "vu" l’utilise (alors qu’il faudrait qu’il utilise une autre jointure, L3 par exemple si id_rubrique dans l’env, et enlever L1).