Recherche avancée

Sur d’autres sites (6196)

• Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde standard des q’un prefixe ....

  31 octobre 2014, par YannX spip

  Salut,

  Le 31/10/2014 12:00, Ybbet Spip a écrit :

  Le 31 octobre 2014 11:19, YannX SPIP <yannx.spip@hotmail.fr
  yannx.spip@hotmail.fr>> a écrit :

  Le 30/10/2014 17:57, redmine@spip.org redmine@spip.org> a
  écrit :

  La demande #3196 a été mise à jour par cedric -.

  • Statut changé de /Nouveau/ à /Fermé/
  • Resolution mis à /invalid/

  Bon, faute de description et suite a r21750 / r21752 je ne
  constate aucun probleme de backup sur une base avec un prefixe
  different de ’spip’

  ---

  Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde
  standard des q’un prefixe ....
  <http://core.spip.org/issues/3196#change-10189>

  • Auteur : YannX spip
  • Statut : Fermé
  • Priorité : Normal
  • Assigné à :
  • Catégorie :
  • Version cible : 3.0
  • Resolution : invalid
  • Navigateur :

  Deux avertissements :
  - prévenir que la sauvegarde peut etre incomplète
  - préciser le prefixe utilisé "qq.part" dans l’interface
  (pour qu’un gestionnaire pas trop expérimenté ne galère pas trop !)

  Merci
  YannX

  ---

  Vous recevez ce mail car vous êtes impliqués sur ce projet.
  Pour changer les préférences d’envoi de mail, allez sur
  http://core.spip.org/my/account

  Le problème est simple, bien que quelque peu aléatoire...
  depuis que la sauvegarde est passée sous sqlite,
  je crois n’avoir pas souvent réussi
  (sur une douzaine au moins de sites SPIP 3.x chez OVH) une
  sauvegarde complète d’une base SPIP.

  Encore en milieu de semaine sur SPN : la restauration a zappé
  totalement
  la tables ARTICLES .. et la table RUBRIQUES

  La seule solution a été de ré-intégrer "a la mano" par Adminer
  (merci Suske)
  de petits bouts du dump SQL que prudent j’avais AUSSI fait avec
  Save_auto

  Peut-etre que ce souci serait aussi dû à l’implémentation SQlite
  chez OVH ?
  (j’avais constaté que l’instalaltion automatique SQlite SPIP
  créait un MySQL non-accessible ! )
  mais il me faudrait demander à Bernard de vérifier sur son serveur
  kimSufi
  si c’est également le cas....

  Je n’ose imaginer un utilisateur moins aguerri...

  Et ça ne serait pas dans ton cas un soucis de timeout ? Ou de mémoire ?

  Sauf si je n’ai pas vu un rechargement de page,
  j’apercois bien l’ecran final de SPIP qui m’affiche parfois (0/...) sur
  certaines tables :
  donc si c’etait un timeout, ce serait plutot de la base.... mais pas dès
  les premières tables ??

  Non, je vais commencer à croire à un conflit d’implémentation
  MySQL-SQlite chez OVH
  (si ce n’est un bug dû au préfixe, ou au principe de SQlite...) mais je
  ne sais déterminer d’ici !

  Si cette hypothèse se verifiait (appel a tous les utilisateurs de bases
  SPIP_préfixées chez OVH ??),
  cela serait très gênant pour de nouveaux utilisateurs,
  car tout le monde ne peut pas etre hébergé chez Nursit ! ;-)

  —
  YannX
  http://www.spippourlesnuls.fr

• src/ : Remove un-needed MSVC6 workaround.

  4 juillet 2014, par Erik de Castro Lopo

  src/ : Remove un-needed MSVC6 workaround.
  MSVC6 was not able to cast from a uint64_t to a double and this
  
  commit removes some #ifdef hackery designed to work around this
  
  problem.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] src/flac/decode.c
  • [DH] src/flac/encode.c
  • [DH] src/libFLAC/fixed.c
  • [DH] src/libFLAC/stream_decoder.c
  • [DH] src/utils/flactimer/main.cpp

• avformat/rtpdec_jpeg : fix low contrast image on low quality setting

  24 mars 2016, par Ico Doornekamp

  avformat/rtpdec_jpeg : fix low contrast image on low quality setting
  Original mail and my own followup on ffmpeg-user earlier today :
  I have a device sending out a MJPEG/RTP stream on a low quality setting.
  
  Decoding and displaying the video with libavformat results in a washed
  
  out, low contrast, greyish image. Playing the same stream with VLC results
  
  in proper color representation.
  Screenshots for comparison :
    http://zevv.nl/div/libav/shot-ffplay.jpg
  
    http://zevv.nl/div/libav/shot-vlc.jpg
  A pcap capture of a few seconds of video and SDP file for playing the
  
  stream are available at
    http://zevv.nl/div/libav/mjpeg.pcap
  
    http://zevv.nl/div/libav/mjpeg.sdp
  I believe the problem might be in the calculation of the quantization
  
  tables in the function create_default_qtables(), the attached patch
  
  solves the issue for me.
  The problem is that the argument ’q’ is of the type uint8_t. According to the
  
  JPEG standard, if 1 <= q <= 50, the scale factor ’S’ should be 5000 / Q.
  
  Because the create_default_qtables() reuses the variable ’q’ to store the
  
  result of this calculation, for small values of q < 19, q wil subsequently
  
  overflow and give wrong results in the calculated quantization tables. The
  
  patch below uses a new variable ’S’ (same name as in RFC2435) with the proper
  
  range to store the result of the division.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtpdec_jpeg.c