Recherche avancée

Sur d’autres sites (11242)

• How to fix 'ffmpeg server returned 403 forbidden (access denied) ?

  1er février, par peppah

  I'm writing a website to convert youtube videos using NodeJS. I am using a package to convert them (horizon-youtube-mp3). The package works, however, I'm having problems converting. Whenever I try to convert a youtube link, it will return 'server returned 403 forbidden access'. 
This error happens in 95% of the links. Some links actually work and convert correctly, but only a few.

  



  I tried running the script on 3 different computers running 3 different OS's. My VPS, my laptop and my home PC. I looked on the web but couldn't find anything useful.

  



  So yeah, I completely suck since I really don't understand why one video would convert, and the other won't. Even if the region of the video is the same.

  



  Any help would be highly appreciated !

  


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

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