Recherche avancée

Sur d’autres sites (8867)

• Failed to run the ffmpeg binary : The process "ffmpeg exceeded the timeout of 60 seconds

  6 janvier 2024, par Sufian The Geek

  I am using FSPOSTER wordpress plugin to share videos on instagram as a reels and story. I have installed wordpress on amazon aws ec2 t2.micro. FsPoster required FFmpeg plugin to work with the videos.

  


  Whenever I share the video, I get error after 60 seconds. There are some videos that are easily getting shared as a reel and story. I looked into the plugin code and changed every single timeout function value to 300 seconds including php.ini file. There are some libraries like symfony in the plugin, I also changed the timeout 60 sec to 300 seconds. Restarted the server and all but still getting the error.

  


  


  Failed to run the ffmpeg binary : The process "'ffmpeg' -v error -y -i '/opt/bitnami/wordpress/wp-content/uploads/2024/01/videoWater-First-18.mp4' -vf 'crop=w=1280:h=720:x=0:y=0' -metadata:s:v rotate="" -f mp4 -c:v libx264 -preset fast -crf 24 -strict -2 -c:a aac -b:a 96k '/tmp/fs_65994ac0ddf8b.mp4'" exceeded the timeout of 60 seconds.

  


  


  I am using bitnami wordpress on ec3 aws t2.micro that has 1 vcpu and 1 GB ram. I also switched to 2 vcpu and 8 gb ram but still this timeout issue.

  


• FFMPEG and HTTPS

  14 juin 2012, par Joel

  ffmpeg lists http as a protocol when I ask : ffmpeg -protocols

  Does this also mean support for a https url ? Do I need to encode this url somehow for the command line. I get "No such file or directory", but with http urls (at least some) it does work.

  A url (created for a Amazon S3 bucket) similar to this one does not seem to work :
  https://mycompany-video-test.s3.amazonaws.com/client/btr/video/xyz0011-x403-snap-n-go-ex/1/video/baby-laugh-ripping-paper.mp4?AWSAccessKeyId=AVIAZL9J6SIRPAA&Expires=1323709667&Signature=pTvS9F2do2t8%3D

  I suspect the format of the url is problematic, I've also tried enclosing in quotes... Yes, this URL does not currently work as it has expired, but even while its valid, its a problem.

  In short :
  1) Should https work ?
  2) Do I need to format the url somehow ?

• Anomalie #3260 (Nouveau) : Problème de dump sur les tables comportants des index de longueur spéci...

  28 août 2014, par b b

  Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=@476655#forum476655

  En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu’à spip_mysql_show_table() (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump).

  J’ai d’abord étudié ce qui se passe dans base_copier_table() de ecrire/base/dump.php :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536

  À ce niveau, dans $desc_source['key'] la longueur des index n’est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente.

  Du coup, j’en suis remonté à sql_showtable(), et plus précisemment à spip_mysql_show_table() :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754

  Depuis phpmyadmin, un SHOW CREATE TABLE renvoie bien ce qu’il faut, ex :

  CREATE TABLE `spip_gis` (
   `id_gis` bigint(21) NOT NULL AUTO_INCREMENT,
   `titre` text NOT NULL,
   `descriptif` text NOT NULL,
   `lat` double DEFAULT NULL,
   `lon` double DEFAULT NULL,
   `zoom` tinyint(4) DEFAULT NULL,
   `adresse` text NOT NULL,
   `pays` text NOT NULL,
   `code_pays` varchar(255) NOT NULL DEFAULT ’’,
   `region` text NOT NULL,
   `departement` text NOT NULL,
   `ville` text NOT NULL,
   `code_postal` varchar(255) NOT NULL DEFAULT ’’,
   PRIMARY KEY (`id_gis`),
   KEY `lat` (`lat`),
   KEY `lon` (`lon`),
   KEY `pays` (`pays`(500)),
   KEY `code_pays` (`code_pays`),
   KEY `region` (`region`(500)),
   KEY `ville` (`ville`(500)),
   KEY `code_postal` (`code_postal`),
   KEY `departement` (`departement`(500))
  ) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  

  Il semble que la regex de la ligne 736 ne match pas la table spip_gis certainement à cause des (500) :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736

  Et du coup, on bascule sur le plan B, qui ne fait qu’un simple SHOW COLUMNS FROM ne contenant pas l’information de longueur des index :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765

  Wala où j’en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.