Recherche avancée

Sur d’autres sites (11510)

• Anomalie #3920 (Nouveau) : sur Sauvegarde SQLite (SPIP 3.1.3 et 3.1.4 mini)

  11 mars 2017, par YannX DYX

  En SPIP 3 la sauvegarde standard pose parfois des problèmes, que j’ai trop souvent vus...
  Cette fois j’ai investigué sur un SPIP 3.1.4 OVH (avec prefix spécifique), toutes les tables ne sont pas sauvegardées, au contraire de la sauvegarde SQL : certes un message existe mais !
  - d’une part des tables vides ou non déclarées dans un plugin activé sont omises : pourquoi ?
  (encore une fois au contraire de la sauvegarde SQL encore disponible en plugin !)
  => est-il possible d’apporter un lien vers une aide plus détaillée, explicitant les causes possibles ?
  (cf. http://forum.spip.net/fr_262960.html & http://forum.spip.net/fr_266342.html par exemple).
  - le long libellé affiché <:dump:texte_sauvegarde:> ne signale aucunement ces aspects et indications ; le lien vers http://www.spip.net/fr_article1489.html est-il encore pertinent (je n’ai jamais tenté une restauration d’une autre version SQLite : comment se passerait une table non déclarée ou non connue dans le SPIP cible ? ) ?
  - d’autre part la lecture du message en fin des erreurs est peu explicite à la lecture (cf. ci-dessous),
  il me semblerait plus significatif d’afficher : Nombre de tables non sauvegardées : 12/58
  - d’ailleurs l’affichage est incorrect, car il n’indique pas le bon préfixe (en cas de préfixe non-standard !!)
  (et de ce fait, je vais avouer avoir jusqu’à présent négligé ces erreurs incomprises, et... patatras !)
  _ S’il est intéressant de faire une sauvegarde dé-préfixée (ce que j’ai parfois trouvé utile), peut-etre serait-il intéressant de faire apparaitre (dans un commentaire ou une meta) le préfixe d’origine, à titre de documentation !

  En recherchant de la documentation, je n’ai trouvé que http://www.spip.net/fr_article3418.html qui mériterait peut-etre d’etre complété avec les informations/explications ci-dessus (et leurs conséquences)...

  En complément, le site exemple ayant été migré d’anciennes versions SPIP 2, montre encore les anciennes tables@ spip_mots_xx@
  je ne me souviens pas d’un plugin qui éliminerait ces anciennes tables résiduelles (pour ceux qui ne savent utiliser phpMyAdmin ou Adminer)... ce qui supprimerait ensuite ces erreurs / voir par exemple sur les forums SPIP)

• How to process and upload large video files directly to cloud with ffmpeg but without fragmented MP4 ?

  9 avril 2024, par volume one

  I am using ffmpeg via fluent-ffpmeg for Node.js to process videos uploaded by users.

  


  The problem I have is if a user uploades a huge movie file, say 8GB in size, then I don't want to store the file on the server as it will soon reach full capacity of space.

  


  I thought a way to tackle this was to stream the output from ffmpeg straight to cloud storage like AWS S3. The only way to do this (I believe) is using a PassThrough() stream :

  


  import PassThrough from 'node:stream' ;
import FFMpeg from 'fluent-ffmpeg' ;

  


  let PassThroughStream = new PassThrough() ;

  


           FFMpeg('/testvideo.mp4')
                .videoCodec('libx264')
                .audioCodec('libmp3lame')
                .size(`640x480`)
                // Stream input requires manually specifying input format
                .inputFormat('mp4')
                // Stream output requires manually specifying output formats
                .format('mp4')
                // Must be fragmented for stream to work. This causes duration problem.
                .outputOptions('-movflags dash')
                .pipe(PassThroughStream, {end: true})


  


  When the video is created using fragmented MP4, there is no duration associated with the file which means it has no length metadata. That makes playback difficult in a browser and is unacceptable :

  


  

  


  The only way I have been able to get a proper length property set in the file's metadata is by not using fragmented MP4 (that is the -movflags dash part in the code above). By not using this, I cannot stream the output directly to cloud storage - I have to save the file somewhere locally first.

  


  I think I am missing something but don't know what. How could this be solved ? I want to process and write the output to AWS S3 without storing the file locally without creating a fragmented MP4.

  


• avutil/mem : limit alignment to maximum simd align

  3 décembre 2023, par Timo Rothenpieler

  avutil/mem : limit alignment to maximum simd align
  FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
  
  which then end up heap-allocated.
  
  By declaring any variable in a struct, or tree of structs, to be 32 byte
  
  aligned, it allows the compiler to safely assume the entire struct
  
  itself is also 32 byte aligned.
  This might make the compiler emit code which straight up crashes or
  
  misbehaves in other ways, and at least in one instances is now
  
  documented to actually do (see ticket 10549 on trac).
  
  The issue there is that an unrelated variable in SingleChannelElement is
  
  declared to have an alignment of 32 bytes. So if the compiler does a copy
  
  in decode_cpe() with avx instructions, but ffmpeg is built with
  
  — disable-avx, this results in a crash, since the memory is only 16 byte
  
  aligned.
  Mind you, even if the compiler does not emit avx instructions, the code
  
  is still invalid and could misbehave. It just happens not to. Declaring
  
  any variable in a struct with a 32 byte alignment promises 32 byte
  
  alignment of the whole struct to the compiler.
  This patch limits the maximum alignment to the maximum possible simd
  
  alignment according to configure.
  
  While not perfect, it at the very least gets rid of a lot of UB, by
  
  matching up the maximum DECLARE_ALIGNED value with the alignment of heap
  
  allocations done by lavu.
  

  • [DH] libavutil/mem.c
  • [DH] libavutil/mem_internal.h