Recherche avancée

Sur d’autres sites (4614)

• InvalidArgumentException : Missing required client configuration options Laravel + FFmpeg + ubuntu 20 + Lamp

  9 août 2020, par Ahmed Al-Rayan

  I have an upload site on a Linux VPS server, Ubuntu, the new version, which is used by Laravel and the packaged fmpeg for the upload client

  


  A problem appears to me that I will attach, but I explain the type of problem. When I upload a video, the video is supposed to be uploaded, and then it goes to the processing, but times it raises and stops, and the error appears 500 times, it is raised and goes to treatment, but it stops here and the error appears to me that I will attach it and it is a problem in the country and does not match the information please Thank you for help

  


  InvalidArgumentException: Missing required client configuration options:   region: (string)    

A "region" configuration value is required for the "s3" service   (e.g., "us-west-2"). A list of available public regions and endpoints can be   found at http://docs.aws.amazon.com/general/latest/gr/rande.html.
in /var/www/html/vendor/aws/aws-sdk-php/src/ClientResolver.php:399 


Stack trace: #0 /var/www/html/vendor/aws/aws-sdk-php/src/ClientResolver.php(295): Aws\ClientResolver->throwRequired() #1 /var/www/html/vendor/aws/aws-sdk-php/src/AwsClient.php(195): Aws\ClientResolver->resolve() #2 /var/www/html/vendor/aws/aws-sdk-php/src/S3/S3Client.php(327): Aws\AwsClient->__construct() #3 /var/www/html/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php(212): Aws\S3\S3Client->__construct() #4 /var/www/html/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php(129): Illuminate\Filesystem\FilesystemManager->createS3Driver() #5 /var/www/html/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php(101): Illuminate\Filesystem\FilesystemManager->resolve() #6 /var/www/html/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php(78): Illuminate\Filesystem\FilesystemManager->get() #7 /var/www/html/vendor/pbmedia/laravel-ffmpeg/src/FFMpeg.php(66): Illuminate\Filesystem\FilesystemManager->disk() #8 /var/www/html/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(261): Pbmedia\LaravelFFMpeg\FFMpeg->fromDisk() #9 /var/www/html/app/Jobs/StreamMovie.php(53): Illuminate\Support\Facades\Facade::__callStatic() #10 [internal function]: App\Jobs\StreamMovie->handle() #11 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): call_user_func_array() #12 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Util.php(36): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}() #13 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): Illuminate\Container\Util::unwrapIfClosure() #14InvalidArgumentException: Missing required client configuration options


  


• Optimizing x264 based remote desktop by dirty regions

  17 novembre 2016, par useprxf

  I was using x264 to achieve remote desktop, but had some problems on handling P_SKIP detection.

  Dirty regions indicate changed areas. For those 16x16 macroblocks which don’t intersect any dirty region, I would like to encode them as P_SKIP macroblocks.

  I tried to add the following code into x264_macroblock_prob_skip_internal function :

  if (! h->isdirty[h->mb.i_mb_x][h->mb.i_mb_y])       // isdirty is a 2-dim array indicating dirty macroblocks
  
      return 1;

  but there is almost no speed-up. I think it may be the information preparation for the macroblock analysis that take influence.

  How to speed up x264 by considering dirty regions ?

• 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.