Recherche avancée

Sur d’autres sites (9012)

• Evolution #4080 : Raccourci puce : se débarasser de l’image

  28 septembre 2018, par cedric -

  Je note que la demande initiale simple était "ne plus avoir une image sur cette puce parce qu’on ne peut pas la personaliser" et qu’à la fin il s’agit de tout revoir le fonctionnement des raccourcis SPIP et donc qu’on ne fera rien :)

  Pour revenir au point de départ :

  1/ peut-être ça manque de documentation mais la puce est totalement personnalisable via le mes_options.php :
  

  $GLOBALS[’puce’] = ’’ ;
  $GLOBALS[’puce_rtl’] = ’’ ;
  $GLOBALS[’puce_prive’] = ’’ ;
  $GLOBALS[’puce_prive_rtl’] = ’’ ;
  

  2/ ça paraitrait moderne de passer à une puce unicode par défaut décorée en CSS avec un fallback texte pour les sites qui upgraderont sans avoir la CSS qui va bien
  

  —
  avec les styles suivants :
  .spip-puce b display:none ;
  
  .spip-puce 
  
    position : relative ;
  
    top : 1px ;
  
    display : inline-block ;
  
    font-style : normal ;
  
    font-weight : normal ;
  
    line-height : 1 ;
  
    -webkit-font-smoothing : antialiased ;
  
    -moz-osx-font-smoothing : grayscale ;
  
  
  
  .spip-puce:before 
  
  content : "\2023" ;
  
  
  

  Avec puce à choisir parmi
  https://unicode-table.com/fr/2023/
  https://unicode-table.com/fr/25B8/
  https://unicode-table.com/fr/25B6/

  Du coup sans ces styles spécifiques, la puce est un simple tiret typographique, et avec les styles c’est un caractère qui s’affiche dans la couleur et taille de texte courante, et stylable

  2b/
  Voire si on veut faire une transition vraiment smoothly on garde le img actuel en fallback dans le span (au lieu du simple tiret), et il ne s’affichera plus que sur les anciens sites qui n’ont pas ajoutés la nouvelle CSS
  (et on prévient que dans une prochaine version cette puce image disparaitra complètement)

  3/ à partir du moment où on a un plugin qui permet de transformer ces puces en liste je pense que garder le comportement actuel par défaut dans SPIP est pertinent et le plus logique

• Latest FFmpeg fails to create a good MP4 out of JPG file (Windows 10)

  30 décembre 2023, par mengrie

  I am using FFmpeg to create an MP4 file out of several JPG files. The command to accomplish this

  


  ffmpeg.exe ^
-hide_banner -nostats -loglevel error -y ^
-loop 1 -t 6 -i 001.jpg ^
-loop 1 -t 6 -i 002.jpg ^
-loop 1 -t 6 -i 003.jpg ^
-loop 1 -t 6 -i 004.jpg ^
-loop 1 -t 6 -i 005.jpg ^
-loop 1 -t 6 -i 006.jpg ^
-filter_complex ^
"[0:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=out:st=5:d=1[v0]; ^
[1:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=in:st=0:d=1,fade=t=out:st=5:d=1[v1]; ^
[2:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=in:st=0:d=1,fade=t=out:st=5:d=1[v2]; ^
[3:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=in:st=0:d=1,fade=t=out:st=5:d=1[v3]; ^
[4:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=in:st=0:d=1,fade=t=out:st=5:d=1[v4]; ^
[5:v]scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fade=t=in:st=0:d=1,fade=t=out:st=5:d=1[v5]; ^
[v0][v1][v2][v3][v4][v5]concat=n=6:v=1:a=0,format=yuv420p[v]" -map "[v]" -r 30 006.mp4


  


  Using "ffmpeg version 2022-12-25-git-eeb280f351-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12.1.0 (Rev2, Built by MSYS2 project)" does the job as expected.

  


  However, yesterdag I downloaded (from gyan.dev - Windows - ffmpeg-git-full.7z) the latest version and upgrade the tool. "ffmpeg version 2023-12-28-git-c1340f3439-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project)"

  


  Using this version, the MP4 contains only a few JPGs and timing is also messed up, resulting in a useless MP4.

  


  Has something changed or are these parameters causing a new behaviour ?

  


  Thx

  


  In meanwhile I went back to older version

  


• ffprobe not showing language tag for ASS files in Ubuntu

  9 juillet 2023, par Efraín

  This is something that has me totally lost, because I'm not sure what could I have done, but from one week to another, "language" stopped appearing in the tags of an ASS track on a MKV. I know this just started to appear, because just last week I ended working on an script to detect the language of tracks, and today that I decided to test it again, I noted that it started to fail, and from my debug it's because ffprobe is now printing this

  


  {
    "index": 2,
    "codec_name": "ass",
    "codec_long_name": "ASS (Advanced SSA) subtitle",
    "codec_type": "subtitle",
    "codec_tag_string": "[0][0][0][0]",
    "codec_tag": "0x0000",
    "r_frame_rate": "0/0",
    "avg_frame_rate": "0/0",
    "time_base": "1/1000",
    "start_pts": 0,
    "start_time": "0.000000",
    "duration_ts": 1430816,
    "duration": "1430.816000",
    "disposition": {
        "default": 1,
        "dub": 0,
        "original": 0,
        "comment": 0,
        "lyrics": 0,
        "karaoke": 0,
        "forced": 0,
        "hearing_impaired": 0,
        "visual_impaired": 0,
        "clean_effects": 0,
        "attached_pic": 0,
        "timed_thumbnails": 0
    },
    "tags": {
        "BPS-eng": "85",
        "DURATION-eng": "00:23:34.830000000",
        "NUMBER_OF_FRAMES-eng": "262",
        "NUMBER_OF_BYTES-eng": "15128",
        "_STATISTICS_WRITING_APP-eng": "mkvmerge v40.0.0 ('Old Town Road + Pony') 32-bit",
        "_STATISTICS_WRITING_DATE_UTC-eng": "2023-07-02 11:29:54",
        "_STATISTICS_TAGS-eng": "BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES"
    }
}


  


  Where it should be a field called "language" in the "tags", like this(Note that other file types, like SRT, or audio tracks show it correctly)

  


  "tags": {
    "language": "eng",
    "BPS-eng": "128000",
    "DURATION-eng": "00:23:50.813000000",
    "NUMBER_OF_FRAMES-eng": "61620",
    "NUMBER_OF_BYTES-eng": "22893018",
    "_STATISTICS_WRITING_APP-eng": "mkvmerge v40.0.0 ('Old Town Road + Pony') 32-bit",
    "_STATISTICS_WRITING_DATE_UTC-eng": "2023-07-02 11:29:54",
    "_STATISTICS_TAGS-eng": "BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES"
}


  


  The weird part is that is the same file I used for testing(And it worked), and I haven't edited it, so I'm not sure why is this happening, Does someone knows if I might have messed up something installing a library for another thing that might have caused it ?

  


  Just in case is necessary, this is the command I use : ffprobe -v quiet -print_format json -show_streams <file></file>