Recherche avancée

Sur d’autres sites (7494)

• Fix description of —rice-partition-order in flac -H

  9 janvier 2016, par Thomas Zander

  Fix description of —rice-partition-order in flac -H
  This is more of a "human language versus programmer parlor" issue.
  
  src/flac/main.c will return usage error for an argument greater
  
  than FLAC__MAX_RICE_PARTITION_ORDER (15u).
  
  While in programming "0..16" usually means "from zero to 15", in
  
  natural human-to-human talk, it would rather mean "from zero to 16".
  
  This changes the wording a bit to avoid this misunderstanding.
  Closes : http://sourceforge.net/p/flac/bugs/352/
  
  Signed-off-by : Erik de Castro Lopo <erikd@mega-nerd.com>
  

  • [DH] src/flac/main.c

• Anomalie #3609 (Fermé) : Problème avec les externals

  29 novembre 2015, par b b

  Il n’y a que 7 archives dans le XML et elles sont bien listées dans le privé sur la page du dépôt ecrire/ ?exec=depot&id_depot=X. Le problème est du côté de smart paquets, l’outil qui génère les xml du côté de la zone. Je ferme le ticket et t’invite à signaler le problème sur la liste spip-zone.

• How to save ffmpeg segmets to disk immediately with sub-second intervals ?

  20 octobre 2023, par amfast

  I'm trying to record video on a raspberry and have it save as much as possible (sub-second resolution) in case of a power cutoff.

  


  I use -f segment to save the encoded stream in 100ms segments with the hope that all but the interrupted (by power cutoff) segment will be saved in memory. Unfortunately, when cutting off power, all the destination files (output_0001.mp4, output_0002.mp4, ...) are created, but empty.

  


  To save the files to disk immediately, I added the -strftime 1 option that allows formatting the output filename as time. It seems weird that this is the (only ?) way to trigger immediate saving of files, but it works - untill I try to have segments smaller than 1 second. The problem seems to be that the format string %d, that previously added a sequence number in my output filenames, now represents "day" (i.e. date) and the smallest resolution time format string is %S for second. I saw %f suggested somewhere for smaller resolutions, but it only prints "%f".

  


  The result is that the segmentation part of ffmpeg does create 100ms segments and save them to disk immediately, but the strftime feature gives the output files names that only change every second, so all the interim files are overwritten.

  


  Example of the failing command below. Without the -strftime option this creates nice segments, but does not save them to disk immediately.

  


  libcamera-vid --flush \
    --framerate ${FRAMERATE} \
    --width ${WIDTH} \
    --height ${HEIGHT} \
    -n \
    -t ${TIMEOUT} \
    --codec yuv420 \
    -o - | 
ffmpeg \
    -fflags nobuffer \
    -strict experimental \
    -loglevel debug \
    -flags low_delay \
    -f rawvideo \
    -pix_fmt yuv420p \
    -s:v ${WIDTH}x${HEIGHT} \
    -r ${FRAMERATE} \
    -i - \
    -c:v h264_v4l2m2m \
    -f segment \
    -segment_time 0.1 \
    -segment_format mp4 \
    -reset_timestamps 1 \
    -strftime 1 \
    -b:v ${ENCODING_BITRATE} \
    -g 1 \
    "output_%04d.mp4"


  


  Question :
  
Is there another way besides -strftime to trigger immediate saving ? Or is there a mechanism to feed finer resolution format strings to the output filename ?