Recherche avancée

Sur d’autres sites (3579)

• avformat/movenc : fix HEVC fmp4 HLS init segment for Apple playback

  21 juillet, par David McElroy

  avformat/movenc : fix HEVC fmp4 HLS init segment for Apple playback
  HEVC fmp4 HLS video produced by ffmpeg is currently unplayable on Apple
  
  software (Safari, QuickTime, AVFoundation).
  This is caused by an empty sdtp atom being erroneously written to the
  
  fmp4 init segment. The `has_disposable` flag can be set for a track
  
  with B-frames, but the init segment contains no actual frames
  
  (track->entry == 0). Writing an sdtp atom in this case is incorrect
  
  and causes Apple's parsers to reject the file.
  This patch fixes the issue by ensuring the sdtp atom is only written
  
  if track->entry is non-zero.
  A similar patch was proposed in November 2023 by Jay Zhang,
  
  but it was never merged.
  Link : https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317173.html
  
  Co-authored-by : Jay Zhang <wangyoucao577@gmail.com>
  
  Signed-off-by : David McElroy <david@mcelroy.online>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/movenc.c

• ffmpeg timecode based on filename

  9 mars 2023, par marven

  I have xxxxx videofiles that need to get a timecode (for working in premiere)
The filenames are all like this 2023-03-08 12.59.59 AndSomeRandowNumbers.
Is that possible with ffmpeg ?
Or if that is not possible : can ffmpeg use an other date from the metadata and use that as timecode (with exiftool is possible to use the filename and write it as creation date, and other, but not as timecode) ?

  


  ffmpeg -i file.mov -map 0 -map -0:d -c copy -timecode 02:10:22:33 outputfile.mov
that is the code that works to change the timecode to 02:10:22:33

  


• 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