Archiver ses vidéos : retour d’expérience

• # Mes propres fonctions shell

  Posté par Yth (Mastodon) le 18 janvier 2024 à 09:40. Évalué à 10.

  

  Pour ce genre d'opérations, avec ffmpeg, j'ai un fichier avec des fonctions bash dedans, il suffit de le sourcer et on peut les utiliser :

  On a d'abord une série de fonctions pour extraire quelques infos à partir de ffprobe. La première série extrait une info spécifique d'un fichier, la seconde liste ces infos pour chaque fichier dans la ligne de commande, avec des couleurs, et enfin la dernière fonction ffinfo regroupe un peu tout en une ligne.
  Et il faudrait que je la réécrive, puisqu'à l'origine elle devait peu servir donc tant pis si on exécute 5 fois ffprobe, mais en pratique c'est la seule que j'utilise.
  Avec des codes ANSI pour les couleurs aussi.

  ANSICLEAR="\033[0;m"
  ANSIBLACK="\033[30m"
  ANSIRED="\033[31m"
  ANSIGREEN="\033[32m"
  ANSIORANGE="\033[33m"
  ANSIBLUE="\033[34m"
  ANSIMAGENTA="\033[35m"
  ANSICYAN="\033[36m"
  ANSIWHITE="\033[37m"
  ANSILBLACK="\033[90m"
  ANSILRED="\033[91m"
  ANSILGREEN="\033[92m"
  ANSILORANGE="\033[93m"
  ANSILBLUE="\033[94m"
  ANSILMAGENTA="\033[95m"
  ANSILCYAN="\033[96m"
  ANSILWHITE="\033[97m"
  
  ff_size() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^.*video: .*[0-9]*x[0-9]*[, ].*$" | head -1 | sed 's/.* \([0-9]*x[0-9]*\)[, ].*/\1/')
  }
  ff_fps() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^.*video: .*[0-9]*x[0-9]*[, ].*$" | head -1 | sed 's/.* [0-9]*x[0-9]*[, ].* \([0-9.]*\) fps.*/\1/')
  }
  ff_len() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^.*Duration: .*[0-9]*:[0-9]*:[0-9]*\.[0-9]*[, ].*$" | head -1 | sed 's/.* \([0-9]*:[0-9]*:[0-9]*\.[0-9]*\)[, ].*/\1/')
  }
  ff_srt() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^.*Stream #[0-9]:[0-9](.*): Subtitle: .*$" | sed 's/.*Stream #[0-9]:[0-9][(]\([^)]*\)[)].*/\1/' | xargs | tr \  ,)
  }
  ff_audio() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^.*Stream #[0-9]:[0-9](.*): Audio: .*$" | sed 's/.*Stream #[0-9]:[0-9][(]\([^)]*\)[)].*/\1/' | xargs | tr \  ,)
  }
  ff_title() {
   [ -f "$1" ] && echo $(ffprobe "$1" 2>&1 | grep -Ei "^\s*title\s*: .*$") | sed 's/title : //'
  }
  ffsize() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local SIZE=$(ff_size "$FILE")
    echo -e "${ANSIRED}$SIZE\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  fflen() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local LEN=$(ff_len "$FILE")
    echo -e "${ANSIRED}$LEN\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  fffps() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local FPS=$(ff_fps "$FILE")
    echo -e "${ANSIRED}$FPS\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  ffsrt() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local SRT=$(ff_srt "$FILE")
    echo -e "${ANSIRED}$SRT\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  ffaudio() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local AUDIO=$(ff_audio "$FILE")
    echo -e "${ANSIRED}$AUDIO\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  fftitle() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local TITLE=$(ff_title "$FILE")
    echo -e "${ANSIRED}$TITLE\t: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }
  ffinfo() {
   while [ ! -z "$1" ]; do
    local FILE="$1" && shift
    if [ ! -f "$FILE" ]; then continue; fi
    local SIZE=$(ff_size "$FILE")
    local LEN=$(ff_len "$FILE")
    local FPS=$(ff_fps "$FILE")
    local SRT=$(ff_srt "$FILE")
    local AUDIO=$(ff_audio "$FILE")
    [ ! -z "$SRT" ] && SRT="[$SRT]\t"
    [ ! -z "$AUDIO" ] && AUDIO="{$AUDIO}\t"
    echo -e "${ANSIRED}$LEN\t$SIZE${ANSILRED}@$FPS\t$AUDIO$SRT: ${ANSIORANGE}${FILE}${ANSICLEAR}"
   done
  }

  Par exemple :

  $ ffinfo vidéo.mkv vidéautre.mkv
  00:58:53.97 960x480@23.98   {eng}   [eng]   : vidéo.mkv
  02:04:33.65 1280x692@23.98  {fre,jpn}   [fre,eng]   : vidéautre.mkv

  Ensuite une multifonction (au moins suisse) de conversion.
  Elle est assez imbitable, mais elle fait ce qu'elle prétend faire dans le Usage : Usage ff [unmap] [format:mkv|mk4|mp4|ogm|mp3|ogg|opus|audio] [scale width] [destination directory] file [files|non existant destination file]
  Il y a une variable d'environnement CRF=22, qu'on peut bien sûr modifier en ligne de commande.

  En gros, elle prend un fichier source, le balance à la destination, et converti.
  L'option unmap permet de virer des infos inconvertibles, comme parfois des chapitrages qui ne passent pas d'un avi vers un mkv, ou un truc du genre. Par défaut on copie tous les flux, en transformant l'audio et la vidéo, avec unmap on converti l'audio et la vidéo, on copie les sous-titres, et on oublie le reste. Quand ça plante j'essaie avec unmap, voilà.

  Ensuite le format de sortie, ça fait des choix en fonction de mes besoins ponctuels, pas du tout en fonction des besoins du monde entier :
  * mkv : par défaut, conversion x265 vers fichier .mkv
  * mk4 : conversion x264 vers fichier .mkv, pour compatibilité avec un matériel plus ancien.
  * mp4 : conversion x264 vers .mp4, pour compatibilité windows sans VlC.
  * ogm : pour faire de l'ogg/vorbis en .ogm, en pratique je n'utilise jamais.
  Et les formats d'extraction audio mp3, ogg, opus qui convertissent le flux audio dans le format mentionné, et enfin audio pour extraire le format audio sans y toucher.

  L'option suivante est intéressante : elle permet de redimensionner à la largeur souhaitée, en conservant le ratio. Donc pour passer de 4k à fullHD on va mettre 1920, si on veut faire tourner la vidéo sur la vieille machine qui gère pas le fullHD on va mettre 720 par exemple, on aura en 16/9è une vidéo en 720x405.

  Après, soit on met [fichier source] [fichier destination], le fichier de destination est facultatif, il sera construit à partir du nom du fichier source - soit on met [répertoire de destination] [plein de fichiers source…], et là aussi les noms de fichiers de destination sont construits à partir de noms des fichiers sources.

  On pourra noter si on arrive à déchiffrer les hiéroglyphe bashiques de la 4ème dynastie et demi de l'empire sed, que le nom de fichier est nettoyé : les espaces deviennent des _, on vire ce qui est après le premier ., des trucs du genre. Ça peut être très pourri si la vidéo s'appelle ma.video.de.vacances.avi on va avoir ma.mkv avec le nommage automatique. Bien fait.

  Attention aussi, c'est codé avec des moufles, donc l'ordre des options est impératif, c'est comme ça, et c'est tout. Autant dire que je lance toujours ff sans rien d'abord pour me rappeler de l'ordre, sinon je fais n'importe quoi.

  export CRF=22
  ff() {
   local EXT="mkv"; local SCALE=""; local WIDTH=""; local MAP="-map 0 -c copy"; local DESTDIR=""; local VCODEC=""; local NN=""; local ACODEC=""; local VCODEC=""
   [ -z "$1" ] && echo "Usage ${FUNCNAME[0]} [unmap] [format:mkv|mk4|mp4|ogm|mp3|ogg|opus|audio] [scale width] [destination directory] file [files|non existant destination file]" && return
   [ "$1" == "unmap" ] && MAP="-scodec copy" && shift
   [[ "$1" =~ ^mkv$|^mk4$|^mp4$|^ogm$|^mp3$|^ogg$|^opus$|^audio$ ]] && EXT=$1 && shift
   [[ "$1" =~ ^[0-9]+$ ]] && WIDTH=$1 && shift
   [ -d "$1" ] && DESTDIR="$(realpath "$1")" && shift && NN="-n"
   while [ ! -z "$1" ]; do
    ACODEC="-c:a aac -b:a 128k"
    [ $EXT == "mp3" ]   && MAP="-map a" && SCALE="" && ACODEC="-c:a libmp3lame -q:a 2"
    [ $EXT == "ogg" ]   && MAP="-map a" && SCALE="" && ACODEC="-c:a libvorbis -q:a 5"
    [ $EXT == "opus" ]  && MAP="-map a" && SCALE="" && ACODEC="-c:a libopus -b:a 96k -vbr on -compression_level 10"
    [ $EXT == "audio" ] && MAP="-map a" && SCALE="" && ACODEC="-q:a 0"
    [ $EXT == "mkv" ] && VCODEC="-c:v libx265 -preset medium -crf $CRF"
    [ $EXT == "mk4" ] && VCODEC="-c:v libx264 -preset medium -crf $CRF" && EXT="mkv"
    [ $EXT == "mp4" ] && VCODEC="-c:v libx264 -preset medium -crf $CRF"
    [ $EXT == "ogm" ] && VCODEC="-c:v libtheora -q:v 7" && ACODEC="-c:a libvorbis -q:a 5" && EXT='ogg'
    local SRC="$1"; local DEST="$1"
    shift
    #echo "#=$#"
    [ "$#" -eq 1 ] && [ ! -f "$1" -o $(sed 's/.*\.//' <<< "$1") = "srt" ] && DEST="$1" && shift
    DEST="$(sed 's/ /_/g;s/__/-/g;s/_-_/-/g;s/-0/-/;s/\([^-]*-[0-9]*\)x/\1/;s/\(.*\)\.[^.].*/\1/;s/-Epi.*//;s/'"'"'/’/g' <<< "$DEST").$EXT"
    [ ! -z "$DESTDIR" ] && DEST="$DESTDIR/$(basename "$DEST")"
    echo "$SRC -> $DEST"
    if [ ! -z "$WIDTH" ]; then
     local SIZE=$(ff_size "$SRC")
     local W=$(cut -dx -f1 <<< $SIZE)
     local H=$(cut -dx -f2 <<< $SIZE)
     local HEIGHT=$((($H*$WIDTH/$W+2)/4*4))
     local SCALE="-vf scale=${WIDTH}x${HEIGHT}"
    fi
    local CMD="ffmpeg $NN -i '$SRC' $SCALE $MAP $VCODEC $ACODEC '$DEST'"
    echo $CMD
    [ -z "$DEBUG" ] && ffmpeg -n $NN -i "$SRC" $SCALE $MAP $VCODEC $ACODEC "$DEST"
   done
  }

  Donc typiquement on va faire pour un lot avec une qualité plus basse : $ CRF=28; ff 720 ~/tmp/ ~/vidéos_à_traiter/* où on notera bien le mix de paramètres et de variable d'environnement, pour l'incohérence.

  Et enfin la dernière fonction pratique, qui attends qu'un fichier existe, par exemple si on le télécharge et qu'il est en .part, et qu'il a son nom définitif, sans le .part, à la fin du téléchargement, ou si on le construit par ailleurs, et qu'il est déplacé dans le répertoire de traitement. Puis qui attends qu'il n'y ait pas d'autre processus ffmpeg qui tourne. Et enfin qui appelle ff. La syntaxe est incohérente avec celle de ff c'est pour mieux embrouiller les gens :

  ffifo() {  # Wait for {file} to be available, then wait for no ffmpeg process to run, then call ff()
   # ffifo file.part file.srt
   local DIR=$(dirname "$1")
   local FILE=$(basename "$1" .part)
   shift
   local DEST=$1
   shift
   echo "ff $@ \"$DIR/$FILE\" \"$DEST\""
   while [ ! -f "$DIR/$FILE" ]; do echo -n .; sleep 10; done
   while [ $(pidof ffmpeg > /dev/null && echo 1) ]; do echo -n °; sleep 10; done
   echo
   echo "# $DIR/$FILE"
   ff $@ "$DIR/$FILE" "$DEST"
  }

  Ça ne fonctionne qu'en mode source->destination pas en lots, et toutes les options de ff sont mises à la fin plutôt qu'au début.
  Donc on va faire :

  ffifo ~/Téléchargements/ma_vidéo_de_chat.touyube.[TROLOL].4K.x437.aac.dolby.camrip.webm.part ~/Mes_Vidéos/Chats/une_autre_vidéo_de_chats.mp4 720
  # Qui appellera plus tard :
  # ff 720 [src...].webm [dest...].mp4

  Et aller se préparer un thé.
  Dès que le téléchargement en cours est terminé, la conversion va commencer, et si on en fait deux en parallèle, le premier va convertir et le second attendre que le premier ait terminé avant de démarrer.
  Pas de surcharge bourrine de la machine, merci !
  Et même pas besoin d'attendre le nez devant l'écran que le téléchargement se termine.
  Après on peut envoyer ça à sa cousine qui pourra montrer sa super vidéo de chats en classe à tous ses élèves de terminale sur son PC de l'éducation nationale, avec un format et une qualité que la poussive machine saura probablement appréhender.

  • Yth.

  • [^] # Re: Mes propres fonctions shell

    Posté par nud le 18 janvier 2024 à 10:24. Évalué à 4.

    

    Je seconde pour ffprobe.

    Sur Synology par exemple ffprobe n'est pas disponible mais ffmpeg l'est, donc il est possible d'utiliser ffmpeg -i "$file" 2>&1 pour un résultat similaire.

    La date de création est souvent incluse dans les informations relatives au flux MPEG mais ce ne semble pas être le cas pour les vidéos générées par des anciens appareils (par exemple les vieux iphones qui sortaient des fichiers .MOV) donc dans ce cas pour obtenir la date je me base sur deux infos: le ctime du fichier (qui est souvent inexact) et les dates des photos qui viennent avant/après pour déterminer la date de la vidéo.

    • [^] # Re: Mes propres fonctions shell

      Posté par Yth (Mastodon) le 18 janvier 2024 à 18:15. Évalué à 2.

      

      Ah c'est fou, ils ont dû faire un effort pour le retirer ffprobe, c'est construit et installé par défaut dans le make install de ffmpeg !

      Mais effectivement l'affichage est sensiblement le même avec ffmpeg -i, outre le message d'erreur.

      • Yth.

    • [^] # Re: Mes propres fonctions shell

      Posté par vincent prelat le 22 janvier 2024 à 09:15. Évalué à 2.

      

      ffprobe est bien disponible mais pas dans le path
      Chez moi il est à cet emplacement avec le paquet synocommunity
      /volume1/\@appstore/ffmpeg/bin/ffprobe

      • [^] # Re: Mes propres fonctions shell

        Posté par sebas le 22 janvier 2024 à 10:13. Évalué à 2.

        

        Sur une debian (MX-linux), c'est dans le path :

        % where ffprobe
        /usr/bin/ffprobe
        /bin/ffprobe
        % apt-cache search ffprobe
        ffmpeg - Tools for transcoding, streaming and playing of multimedia files
        anacrolix-dms - Go UPnP DLNA Digital Media Server with basic video transcoding
        golang-github-anacrolix-dms-dev - Go source for UPnP DLNA Digital Media Server
        golang-github-anacrolix-ffprobe-dev - Go ffprobe wrapper
        golang-gopkg-vansante-go-ffprobe.v2-dev - Library to easily get the ffprobe output of a given file (library)
        

      • [^] # Re: Mes propres fonctions shell

        Posté par nud le 22 janvier 2024 à 11:25. Évalué à 3. Dernière modification le 22 janvier 2024 à 11:27.

        

        J'étais content en voyant ta réponse mais malheureusement je n'ai pas de dossier ffmpeg dans le dossier @appstore, ni de paquet ainsi nommé dans le Package Center. Je suppose que ça dépend de la version de DSM ou du modèle de NAS ?

        Update: bon je suppose que tu fais en fait référence à https://synocommunity.com/ que je ne connaissais pas mais qui a l'air de mériter le coup d'oeil.

• # Choix du format

  Posté par damaki le 18 janvier 2024 à 09:44. Évalué à 8.

  

  Est-ce une bonne idée de mettre tous ses œufs dans le même panier (un seul format de conteneur, un seul codec video, un seul codec audio) , même si ces formats sont libres et, pour H265, lisible avec des logiciels libres, ce qui est tout de même une bonne assurance pour l’avenir ?

  Les formats mainstream ont une très longue durée de support dans les softs open source. Si tu regardes par exemple VLC, le MPEG qui date pourtant d'il y a plus de 30 ans est toujours supporté.

  • [^] # Re: Choix du format

    Posté par nud le 18 janvier 2024 à 10:37. Évalué à 7.

    

    Pour ma part je garde le format initial de la photo ou de la vidéo dans la mesure du possible. Pour les photos en raw, je garde généralement le raw et le jpeg généré par l'appareil côte à côte (je pense que je n'ai jamais "développé" aucun fichier raw en vrai, je configurais l'appareil pour le faire lui-même à une époque où le format était mal supporté avec Linux)

    En effet chaque conversion d'un format avec pertes à un autre format avec pertes implique de nouvelles pertes (sauf exceptions dûment documentées comme une conversion de JPEG en JPEG-XL).

    Aujourd'hui on sait lire à peu près tout avec Linux, et je pense que la "disparition" complète du support d'un format un tant soit peu utilisé est très improbable. Du coup j'ai du RAW, du TIFF, du JPG, du HEIC, du MPEG2 (des fichiers .MOD), du MOV, du MPEG4 avec des pistes vidéos et audio de formats divers…

  • [^] # Re: Choix du format

    Posté par dr191 le 18 janvier 2024 à 17:35. Évalué à 1.

    

    Oui d'accord pour VLC qui nous sauvra sans doute encore la mise sur des vidéos de 2000 dans 15-20 ans dans le futur.

    Mais au niveau matériel grand public, c'est moins la fete: Une TV samsung de 4-5 ans ne lit deja plus les xvid. J'ai pas creusé plus en détails, peut etre un simple pb d'extension ou de conteneur mais c'est pas glop. Je ne me vois pas réencoder en x265 du xvid ou autre codec de cette génération.

    • [^] # Re: Choix du format

      Posté par Glandos le 18 janvier 2024 à 22:45. Évalué à 10.

      

      Une TV samsung de 4-5 ans ne lit deja plus les xvid.

      Ma TV Samsung n'a jamais lu aucun média. Parce que, c'est une TV, avec un tuner dedans, pas un ordinateur.

      Par contre, j'y ai branché un ordinateur dessus, que j'ai consciencieusement appelé mediacenter, avec Kodi dessus. Bon, VLC fait très bien l'affaire. Mais aujourd'hui, ça tient sur un ordinateur de la taille d'un RaspberryPi qui peut, au pire, se retrouver scotché derrière l'écran, qui n'a rien d'autre à faire que son travail : afficher un maximum de points en couleurs avec un maximum de contraste.

      Oui, je n'aime pas du tout l'idée des ordinateurs embarqués dans les écrans, qu'on appelle « Smart TV ». On ne peut pas les mettre à jour, ça devient obsolète bien trop vite, et c'est probablement une source de faille de sécurité et de vie privée.

      • [^] # Re: TV bête

        Posté par Micromy (site web personnel) le 03 février 2024 à 22:57. Évalué à 2.

        

        Effectivement ça devient dur de trouver une TV de qualité sans une partie "smart". Entre les constructeurs qui cherchent à donner une impression de valeur pour justifier prix et marges, et les consommateurs qui pour la plupart adorent avoir toujours plus, y compris de l'inutile, on ne va pas dans la bonne direction…
        Même si je comprends bien l'idée des système intégrés, j'avoue que comme tout ordinateur qu'on ne peut pas mettre [facilement] à jour (logiciel et/ou matériel) c'est un beau gâchis.
        Surtout que pour garder les fonctionnalités à jour on fini souvent par effectivement ajouter un appareil dédié (Raspberry, PC barebone, HTPC, Android box, Chromecast, décodeur TV de box internet et j'en passe).

• # Vidéo + THM / backup / site statique + commentaires

  Posté par AncalagonTotof le 18 janvier 2024 à 10:16. Évalué à 6.

  

  Wow, merci pour ce … Pavé ! Je le lirai en détail plus tard.
  Merci de me conforter dans ma méthode de "classement" : Année/{12 mois 01..12}/{yyyy.mm.dd}-Lieu+autres détails

  Mon dada, c'est le renommage des RAW, JPG, et vidéo quand c'est possible.
  Je me suis concocté un soft qui va chercher les infos dans les fichiers, avec exiv2 (en librairie intégrée, ou en commande externe, selon les plateformes).
  J'aime bien quand le nom du fichier commence par {yyyy.mm.dd}-{HHhMMmSSs}-...{vitesse d'obturation}-{ouverture}...{objectif+ouverture max+focale}, et pas mal d'autres détails.
  Ça prend en compte mon appareil et ceux que j'ai eu avant. Et j'ajoute, je complète, au cas par cas, quand je rencontre des cas particuliers (photos issues d'autres modèle que les miens, de smartphones, etc).
  C'est très lié avec Qt. Vous pensez que ça peut intéresser d'autres personnes ? Attention, c'est pas un modèle du genre … Ou alors, c'est éducatif, ça expose un paquet de chose à ne pas faire quand on crée un soft …

  Quoi qu'il en soit, concernant les vidéos, à ma connaissance, il n'y a pas ou quasiment pas de tags dans les fichiers eux-mêmes.
  Mais parfois, la vidéo est accompagnée d'un fichier .THM (thumbnail), qui est en fait une image avec des tags qu'on peut récupérer avec exiv2. J'ai exploité cette particularité dans mon soft.

  Pour le backup : un stockage type NAS RAID5. Et de temps en temps, un backup du NAS sur un autre en RAID5 également. Le minimum quasiment, mais pourrait mieux faire, mais c'est plus cher !

  Pour la visu, il y a 20 ans environ, j'utilisais Gallery dans sa version 2. Tout tournait très bien. Et puis une mise à jour de Debian l'a basculé en version 3. Et là, c'est le drâââme … Le fait que ça repose sur une DB principalement. Tout cassé …

  J'ai fini par me rabattre sur une génération de site statique à l'aide de Lazygal et de templates et styles personnalisés, récemment avec Bootstrap pour que ça ressemble moins à du Frontpage ;-)
  Le cheminement de fichiers est le suivant :

  • je traite les RAW, sous Windows, avec un soft propriétaire (non, un autre !), je sais, c'est mal … Chuicon, je le paye en plus …
  • backup des RAW sur le NAS
  • conversion des RAW en JPG
  • classement des JPG selon le principe décrit plus haut

  Pour Lazygal, j'ai un répertoire Album.sources et un autre Album.build :

  • un répertoire par thème dans Album.sources, par exemple Vacances, Bricolage, etc
  • pour chaque album, je crée un lien symbolique dans l'un des sous répertoire de Album.sources, vers un des répertoires de stockage des JPG (+ vidéos)
  • quelques scripts pour reconstruire ou rafraîchir les albums à l'aide de Lazygal : ils vont chercher les originaux à travers les liens symboliques, et créent les albums, c'est à dire vignettes + pages HTML statiques dans la même arborescence dans Album.build
  • les originaux ne sont pas copiés. Les pages crées pointent dessus
  • un peu de configuration nginx pour mettre ça à disposition. Yapuka regarder !

  Le principal inconvénient de Lazygal, c'est la gestion des permissions : inexistante ! Si je veux limiter l'accès, à moi de le gérer au cas par cas à travers nginx
  Un autre inconvénient de Lazygal, c'est le traitement des vidéos. Normalement, ça passe … Mais … Bon, ma mémoire me fait un peu défaut, mais il me semble que ça dépend des formats de vidéo, du ffmpeg du moment, et de la version de Lazygal. Je ne me rappelle plus précisément pourquoi, mais j'ai une VM avec une ancienne version de Debian, et donc de Lazygal, rien que pour ça.

  Dernier point : les commentaires d'albums ou de photos/vidéos.
  Gallery fait ça bien, il utilise un DB non pas uniquement pour la gestion des albums, mais aussi pour les comptes utilisateurs (avec plus ou moins de permissions) et les commentaires, façon blog.
  De base, Lazygal n'affiche des commentaires que si un fichier (par album et par photo) est présent au moment de la construction/rafraîchissement ! Pas de compte utilisateur, seul l'admin (moi …) peut gérer ces fichiers … Vraiment raz des pâquerettes.
  Là aussi, je me suis fait mon utilitaire qui me permet de parcourir un album, de le commenter, ainsi que chaque photo. Là encore avec Qt … Avec gestion des cas particulier causés par le passage au HTML (caractères spéciaux, ajout de formatage ou autre tag, etc). Ça me revient en l'écrivant, c'est d'ailleurs un des points qui change de comportement en fonction des versions de Lazygal. Il me semble que les anciennes versions laissent tels quels les tags que je mets dans les commentaires (je peux alors mettre en gras, ou insérer des liens, etc), alors que les versions plus récentes se croient malignes en les transformant pour les afficher sous la forme de tag source dans les pages web, pfffff !

  Voilà voilà, moi aussi j'ai fini par pondre un pavé ;-)

  • [^] # Re: Vidéo + THM / backup / site statique + commentaires

    Posté par lareunionlela le 19 janvier 2024 à 07:08. Évalué à 3.

    

    Quoi qu'il en soit, concernant les vidéos, à ma connaissance, il n'y a pas ou quasiment pas de tags dans les fichiers eux-mêmes.

    Sauf erreur de ma part, je me souviens que ffprobe m'a déjà affiché des métadonnées pour les vidéos : date et heure de prise de vue, et même coordonnées GPS pour les caméras de type GoPro (c).

    • [^] # Re: Vidéo + THM / backup / site statique + commentaires

      Posté par AncalagonTotof le 19 janvier 2024 à 10:26. Évalué à 2.

      

      Ah, je connaissais pas, merci pour le tuyau.
      Ceci dit, après quelques tests rapides, je me demande si ça ne dépend pas de deux choses :

      • le conteneur : mkv, avi, mp4 … Il ne proposent peut-être pas tous les mêmes options de metadata
      • le soft (ou la puce dédiée ?) ayant créé la vidéo. Capable ou pas, codé ou pas pour ajouter des tags pertinents

      Les quelques fichiers de mes tests ne montrent pas beaucoup d'infos intéressantes.

      • [^] # Re: Vidéo + THM / backup / site statique + commentaires

        Posté par potate le 21 janvier 2024 à 11:40. Évalué à 3.

        

        • le conteneur : mkv, avi, mp4 … Il ne proposent peut-être pas tous les mêmes options de metadata

        On dirait que oui. D'après cette liste des tags supportés par ffmpeg selon le format, pour avi la liste des tags est finie tandis que pour d'autres formats (dont mp4 et mkv) il est possible de définir des tags arbitraires.

        Ces tags m'ont l'air d'être prévu pour des contenus "du commerce" (films, séries) en première intention (vu que l'on retrouve à peu près les mêmes que pour l'audio : artiste, genre, copyright, etc.).
        Je n'ai pas vu de tags standards pour préciser des informations liées à la capture de la vidéo (mais si ça se trouve, réutiliser les noms des tags existant pour les photos permet aux visionneuses d'afficher correctement les infos).

  • [^] # Re: Vidéo + THM / backup / site statique + commentaires

    Posté par pmetras le 28 janvier 2024 à 20:50. Évalué à 1.

    

    Pour la visu, il y a 20 ans environ, j'utilisais Gallery dans sa version 2. Tout tournait très bien. Et puis une mise à jour de Debian l'a basculé en version 3. Et là, c'est le drâââme … Le fait que ça repose sur une DB principalement. Tout cassé …

    J'ai fini par me rabattre sur une génération de site statique à l'aide de Lazygal et de templates et styles personnalisés, récemment avec Bootstrap pour que ça ressemble moins à du Frontpage ;-)

    J'avais présenté, il y a 3 ans, la galerie MyPhotoShare qui génère un site statique à partir d'une arborescence de répertoires contenant des photos et des vidéos.

    Je l'utilise pour la même raison de ne pas être dépendant d'une base de données. Le scanner de répertoires supporte la lecture des métadonnées depuis les fichiers, mais également à partir de fichiers de configuration dans chaque répertoire, ce qui permet d'étendre la galerie avec des plugins. Par exemple, j'ai développé un script qui effectue de la reconnaissance de visages dans mes photos et met à jour des fichiers pour ajouter des tags avec le nom des personnes reconnues. Ainsi, je peux effectuer des recherches dans MyPhotoShare par le nom des membres de ma famille.

    Le principal inconvénient de Lazygal, c'est la gestion des permissions : inexistante ! Si je veux limiter l'accès, à moi de le gérer au cas par cas à travers nginx

    MyPhotoShare dispose également d'un système permettant de gérer les permissions d'accès aux dossiers (répertoires) de médias. Ça permet de conserver des dossiers privés et de gérer qui peut y accéder.

    Ça fait un certain temps que je n'ai pas mis à jour le paquet Debian avec une version à jour de MyPhotoShare. Il va falloir que je dégage du temps pour regarder ce que Paolo Benvenuto, le principal contributeur a ajouté…

• # Pérennité des formats

  Posté par 🚲 Tanguy Ortolo (site web personnel) le 18 janvier 2024 à 15:26. Évalué à 8.

  

  la possibilité de lire des fichiers dans plusieurs années (je pense à des fichiers Publisher 2.0 que je ne suis plus parvenu à lire par la suite – et non : les versions ultérieures à Publisher 2.0 ne lisent pas ces fichiers.

  Ça, c'est un problème réservé aux utilisateurs de logiciels propriétaires. Ça peut éventuellement arriver avec du logiciel libre pour des usages de niche.

  Mais pour des trucs comme l'image, la vidéo et le son, dès que tu utilises des formats ouverts un minimum connus, tu peux être certain de pouvoir les relire… tant qu'on aura des ordinateurs et des logiciels.

  Avec des formats standardisés, tu as aussi une assez bonne garantie de pouvoir les relire plus tard.

  • [^] # Re: Pérennité des formats

    Posté par Funix (site web personnel, Mastodon) le 18 janvier 2024 à 18:12. Évalué à 5.

    

    Oui c'est ce que je me dis aussi, mais même les formats ouverts peuvent évoluer et la compatibilité descendante n'est pas acquise, il me semble nécessaire de veiller à cela dans le temps.

    https://www.funix.org mettez un manchot dans votre PC

• # Chiffrer ses disques et pérennité

  Posté par Hotshot92 le 22 janvier 2024 à 22:43. Évalué à 1.

  

  Merci pour ce retour d'expérience.

  Comment chiffres-tu tes disques pour garantir que tu seras capable de les relire sur le long terme (c.-à-d. à la même échelle de temps que ce que tu supposes pour les formats des vidéos choisis) ?
  Me concernant, j'ai eu la mauvaise surprise de ne me plus me rappeler un mot de passe quelques années après. Si tu choisis un support physique pour héberger ta clé, il faut gérer la pérennité de ce support également, ainsi que l'indépendance vis-à-vis du vol puisque c'est cette menace pour laquelle tu indiques chiffrer tes archives.

  • [^] # Re: Chiffrer ses disques et pérennité

    Posté par lareunionlela le 23 janvier 2024 à 08:56. Évalué à 2.

    

    Bonjour
    dans le didacticiel en lien, cela utilise luks. Je ne suis pas du tout un spécialiste de crypto mais, si j'ai bien compris :
    - si j'oublie mon mot de passe, c'est mort (sauf si maman travaille à la NSA)
    - si l'endroit où est stocké la clé est corrompu par un bit lunatique, c'est mort aussi.

    C'est pour cela que j'utilise au moins trois sauvegardes (je me dis que, statistiquement, le risque que les trois claquent en même temps est faible).
    LUKS est sous licence libre et la doc est en ligne : comme les formats évoqués, c'est un garant de pérennité, me semble t il
    Donc le risque principal (si l'on excepte le problème de support) est l'oubli du mot de passe principal.
    Pour la petite histoire, un ami avait un disque chiffré sous windows ou mac qu'il avait gardé plusieurs années mais qu'il ne pouvait plus lire. Il se souvenait du mot de passe mais le logiciel ayant servi à chiffrer le disque n'était plus installable sur son ordi. On est passé par mon linux, il a saisi son mot de passe et tout est revenu ! Même moi, ça m'a impressionné !

    • [^] # Re: Chiffrer ses disques et pérennité

      Posté par wismerhill le 23 janvier 2024 à 17:21. Évalué à 4.

      

      Avec LUKS, il est possible de faire une sauvegarde de l'en-tête (avec la commande cryptsetup luksHeaderBackup).
      Cette sauvegarde doit bien entendu être conservée dans un endroit bien sécurisé, sinon c'est elle le maillon faible.

      Aussi, LUKS prévoit plusieurs slots de clés dans son en-tête (je ne sais plus si c'est 4 ou 8). Chaque slot contient la clé de chiffrement du périphérique, mais elle-même chiffrée avec un mot de passe (éventuellement) différent.
      L'usage de base est de permettre à plusieurs personnes de partager un même périphérique sans devoir partager le mot de passe, mais ça peut aussi servir à se prémunir d'une corruption d'un slot en utilisant d'emblée plusieurs (éventuellement avec le même mot de passe).

• # Pour encoder en AV1

  Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 24 janvier 2024 à 11:39. Évalué à 2.

  

  Y'a cette appli qui a l'air sympa sur Flathub : Aviator

• # #mavie

  Posté par Dring le 24 janvier 2024 à 14:23. Évalué à 6.

  

  Y'a 25 ans, j'ai acheté un camescope. J'ai fait quelques films - très peu. C'était encore sur bande. Et puis j'ai oublié le camescope dans le garage, et je suis tombé dessus il y a 4/5 ans. Y'avait les cassettes, et tout.

  Et là, tout à coup, de façon aussi soudaine que violente, dans un éclair, que dis-je, une foudroyance de lucidité, je me suis rendu compte que…

  …j'en avais absolument rien à foutre.

  En fait, autant ça m'arrive de retourner sur un album photo d'il y a 15 ans, autant ça ne m'arrive JAMAIS avec les vidéos. Les vidéos personnelles, à regarder, je trouve ça juste chiant. Je dis pas : la vidéo des premiers pas de bébé, sa première descente en ski, j'ai été très content de pouvoir les montrer à Papy et Mamy qui n'étaient pas là. Mais une fois qu'ils l'ont vue, elle ne sert plus à rien.

  Mais ma vérité (rien qu') à moi, c'est qu'après, je peux les supprimer, ça changera rien à ma vie.

  J'ai regardé : actuellement, je sauvegarde tout ce qui traîne sur mon ordiphone ou sur mon appareil photo, que ce soit vidéo ou photo (en passant, j'utilise "<Année>/<Date & Lieu ou Evènement>" ; le mois en plus ça m'apporte rien). Mais je ne m'occupe jamais des vidéos. Et en toute logique, il va falloir que je fasse le ménage, pas en les réencodant/optimisant. Non non. Juste un gros "rm -rf *.avi" des familles.

  D'un point de vue énergétique/écologique, c'est imbattable. D'un point de vue gain de temps, c'est presque imbattable (il faudrait que j'arrête de faire des vidéos que je ne regarde pas après). Et toutes les questions annexes disparaissent.

  C'est évidemment très personnel, mais j'encourage tout le monde à se poser la question : à quoi servent toutes ces vidéos ? Est-ce que quelqu'un va vraiment les regarder ?

  Y'a un autre truc qui me travaille : depuis 150 ans, toute personne partant dans l'autre monde laisse une dizaine d'albums photos. J'ai déjà observé ça : après l'enterrement, on se retrouve à "faire le tri", et là, c'est l'enfer. La progéniture tourne autour du pot, mais se rend compte que 90% des photos concernent des gens ou des évènements dont ils ne savent rien. Certes, y'a Pépé et Mémé quand ils étaient petits, c'est émouvant, mais… qu'est-ce qu'on va faire de ça ? On ajoute à nos propres albums photos, et nos arrière-petits-enfants se reposeront la question ?

  Je trouve que ça ajoute au traumatisme de la disparition : devoir sacrifier tous ces trucs inutiles, en culpabilisant parce que "c'était à Pépé et Mémé, quand même".

  Pour les vivants, on a toujours envie de se dire "mon rejeton sera content de voir cette vidéo et de la montrer à ses enfants". Ou "ah ah, je la diffuserai le jour de son mariage". Mais en fait, c'est rarement vrai ; c'est rarement mis en pratique. Et quand ça l'est, c'est 1 minute facilement oubliable. Donc pour moi, tout ça, c'est juste de l'utilisation d'énergie, de temps et d'espace pour rien. Je pense que je vais prendre le pli de supprimer purement et simplement toute vidéo de plus d'un an, et être beaucoup plus sélectif sur les photos.

  • [^] # Re: #mavie

    Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 24 janvier 2024 à 14:59. Évalué à 3.

    

    Et pour les photos, il y a la question, surtout pour les grandes familles "mais qui c'est ?". En plus, avec le numérique tu fais encore plus facilement des photos donc tu entasses encore plus clichés sans grand intérêt.

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: #mavie

      Posté par Dring le 24 janvier 2024 à 15:59. Évalué à 4.

      

      Et puis tu fais 15 photos du même truc "pour être sûr", et l'iPhone te fait la photo "Live" (donc photo + vidéo de 2 secondes). C'est sympa sur le coup, mais à la fin, c'est du travail (inutile) en plus. Tu dois classer toute cette merde, sélectionner, etc.

      C'est une autre forme de surconsommation ; l'abondance fait qu'on ne réfléchit plus à ce qui est utile, et on s'emprisonne dans des nouvelles tâches qui servent à rien.

      Dans une entreprise, on qualifierait ça de "bullshit job". Dans la vie perso, on accepte ça comme si c'était inévitable et utile. Ce n'est rien de tout ça.

      • [^] # Re: #mavie

        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 24 janvier 2024 à 23:39. Évalué à 4.

        

        Et ça coûte cher quand tu te retrouves avec des To de données à sauvegarder.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: #mavie

      Posté par pmetras le 28 janvier 2024 à 23:39. Évalué à 3.

      

      Et pour les photos, il y a la question, surtout pour les grandes familles "mais qui c'est ?"

      J'ai hérité de je ne sais qui l'incapacité à reconnaître les personnes sur les photos. Mais comme mes parents font de la généalogie et me fournissent de nombreuses photos de parents plus ou moins éloignés, j'ai développé un plugin pour la galerie médias que j'utilise (MyPhotoShare) qui se charge de reconnaître les personnes apparaissant sur les photos. Ça évite de perdre le souvenir de qui était présent sur la photo!

    • [^] # Re: #mavie

      Posté par Funix (site web personnel, Mastodon) le 01 février 2024 à 19:09. Évalué à 3.

      

      Et pour les photos, il y a la question, surtout pour les grandes familles "mais qui c'est ?"

      Facile, j'utilise digikam avec 20 ans de photos numérisés et reconnaissance automatique des personnes, j'attends pas d'avoir un stock et je fais ça régulièrement pour identifier les personnes

      https://www.funix.org mettez un manchot dans votre PC

      • [^] # Re: #mavie

        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 01 février 2024 à 19:19. Évalué à 3.

        

        Je parlais de plus anciennes photos ! Genre les photos de mes arrières-grandes familles : fin du 19e et début du 20e !

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: #mavie

          Posté par Xanatos le 23 février 2024 à 14:22. Évalué à 3.

          

          Ohoh merci pour digikam

          J'ai vu psser pub pour myheritage qui pourrait peut-être t'aider à ce sujet, si on fait abstraction:
          - saas
          - CGU à lire, privacy toussaaa
          - origine du siège de la boite

  • [^] # Re: #mavie

    Posté par Faya le 24 janvier 2024 à 15:47. Évalué à 6.

    

    Comme tu dis "c'est très personnel". Parce que moi, grand nostalgique (à une époque j'avais voulu le pseudo nostalgeek mais il était déjà très répandu…) je garde un maximum de trucs et je suis toujours content de les revoir. Bon il y a des choses qui ne servent à rien genre les vidéos de feux d'artifices… mais je re-regarde mes vidéos de voyage régulièrement, les diverses étapes de la petite enfance de mon fils, les vidéos que j'ai faite avec mon caméscope quand j'avais 13 ans (et où l'on peut voir des proches disparus entre temps) etc. Et j'aime voir les photos/vidéos de la jeunesse de mes parents & grand-parents, d'ailleurs ça me sert aussi à mettre des visages sur les noms dans l'arbre généalogique que je complète régulièrement.
    Le soucis c'est que je ne m'arrête pas aux vidéos, j'ai la 1ère paire de chaussettes de mon fils, ma peluche préférée quand j'étais bambin (elle a plus de 40 ans !), le dé à coudre de mon arrière grand-mère, et bien sûr mes 1ères disquettes Debian et mon tout 1er disque dur (IBM Aptiva, 540Mo)… Bref je m'accroche très fort à tout ce qui est souvenir. Non je n'ai pas de syndrôme de Diogène, aucune difficulté à jeter ce qui n'est pas lié à un souvenir particulier.

    • [^] # Re: #mavie

      Posté par Xanatos le 25 janvier 2024 à 13:01. Évalué à 2.

      

      Je ne trouve pas la démarche déraisonnable.
      L'archivage des vidéos pour les souvenirs des disparus aussi.
      Journal très complet mais malheureusement j'en suis à l'étape précédente de tout archiver au même endroit et dédupliquer.

  • [^] # Re: #mavie

    Posté par 16aR le 26 janvier 2024 à 01:00. Évalué à 5.

    

    Ma mère a encodé des vidéos sur bandes d'il y a 30 ans.

    J'ai revu mon père, et surtout, réentendu sa voix que je n'ai plus entendu depuis 20 ans. Je peux te dire que j'étais très ému. Je ne savais même pas qu'on avait des restes de ces bandes. Mon père étant décédé avant l'avènement des smartphone caméra bonne qualité, j'ai un énorme manque de souvenirs en dehors des photos.
    J'avais oublié sa voix et sa manière d'interagir, etc. Ce qui est d'ailleurs triste.

    Donc oui, personnellement, je garde beaucoup de choses car je me transporte facilement dans ces moments de souvenirs.

• # Organisation de dossiers

  Posté par 16aR le 26 janvier 2024 à 01:06. Évalué à 1. Dernière modification le 26 janvier 2024 à 01:09.

  

  J'ai plus ou moins la même organisation de dossier.
  Je me suis fait un outil pour scanner un dossier + sous-dossier avec toutes les photos/vidéos pour les ranger dans l'ordre YYYY/MM/YYYY-MM-DD_/<file> dans un dossier de destination.
  La destination doit être dans le même point de montage car mon système utilise des hard links afin que les opérations soient rapides et ne prennent pas plus de place.
  Ça me permet de faire du tri en 2 temps.

  C'est assez roots (ça marche bien pour un dossier photo venant d'un samsung galaxy), mais bon, si ça peut servir: https://github.com/dolanor/dirpic

  Petite particularité, je regroupe les photos d'un jour jusqu'à 6h du matin le lendemain. Je fais plus souvent des photos de soirées qui durent au petit matin que des photos à 4h du mat pour une journée qui démarre. Je préfère qu'elles soient regroupé dans le dossier du jour d'avant plutôt que du lendemain où tout le monde dort.

• # Qualité visuelle

  Posté par Crao le 27 janvier 2024 à 17:31. Évalué à 7.

  

  L’encodage en deux passes permet d’obtenir une meilleure qualité visuelle (de ce que j’ai compris) mais au prix d’un temps de calcul doublé.
  

  Alors non, l'encodage en deux passes n'a rien à voir avec la qualité visuelle.

  Le seul intérêt d'utiliser cette technique est de pouvoir prévoir la taille finale de la vidéo en fonction du bitrate choisi, ou au contraire de choisir un bitrate pour obtenir une taille spécifique. C'était utilisé à l'époque pour faire tenir un film du 1 ou 2 CD, puis ensuite en HD sur 1 DVD, ce qui permettait de graver le film.

  Mais l'encodage en deux passes n'a pas de rapport avec la qualité visuelle. Si la vidéo a énormément de mouvement, il est très certain que la qualité visuelle sera mauvais parce que le bitrate sera trop faible. Au contraire si la vidéo est essentiellement des plans fixes avec peu d'éléments qui bouge, ce sera un gaspillage de place.

  Pour avoir une qualité visuelle constante, il faut utiliser un encodage en une passe avec un paramètre de qualité. Le codec choisira ensuite d'allouer plus ou moins de bitrate en fonction de la complexité de chaque scène. Une vidéo qui bouge beaucoup aura ainsi un bitrate bien plus élevé qu'une vidéo de paysage où il ne se passe rien, mais les deux vidéos auront la même qualité visuelle.

  Avec x265 c'est le paramètre --crf qu'il faut utiliser pour avoir une qualité constante. Voici un lien qui explique le fonctionnement :
  https://slhck.info/video/2017/02/24/crf-guide.html

• # Expérience depuis 8 ans.

  Posté par Stinouff le 01 février 2024 à 10:55. Évalué à 3. Dernière modification le 01 février 2024 à 10:58.

  

  Salut,

  J'organise très proprement mes photos et vidéos depuis plusieurs années ; il y a quelques différences dans mon organisation et mes usages :

  • Premièrement, mes vidéos sont renommées avec un script qui récupère la date (à partir de mediainfo, grep, cut, etc.) et me propose d'inscrire un nom, ça donne par exemple ceci : 2023-04-29-141020 - Anniversaire Tux - 1.mkv (du coup, il y a la date et l'heure de prise de vue, ce qui peut être pratique lors de journées chargées en captures ou même si j'ai différentes sources pour la même journée, ce qui arrive aussi)
  • J'utilise libopus (qui prend un peu moins de place que mp3 et j'ai eu des problèmes pour partager des audios mp3 avec des utilisateurs disposant d'Iphones)
  • Je ne fais qu'une seule passe sur des vidéos 4K avec un processeur récent ; j'ai noté peu de différence (voire aucune) de qualité sur la plupart des vidéos et la taille des vidéos n'a pas vraiment bougé non plus
  • Pour conserver les métadonnées, je fais simplement : -map_metadata 0
  • Je n'utilise pas de script d'encodage de masse parce que je coupe les vidéos que je fais et que je les traite au cas par cas (s'il fait sombre, je change la qualité [le fameux -crf], si la vidéo n'est pas très esthétique, je baisse la qualité, je choisis le preset)…Le script me pose des questions pour chaque élément qui est important et ça me prend environ 10 secondes par vidéo (plus le visionnage, plus l'encodage, environ à 1/4 de la durée de la vidéo je pense ? Une vidéo de 30 secondes est encodée en 2 minutes environ, sauf si je choisis un preset lent)

  Voilà. :)

  • [^] # Re: Expérience depuis 8 ans.

    Posté par lareunionlela le 05 février 2024 à 06:59. Évalué à 1.

    

    Ce que tu décris semble très intéressant. je suis preneur des scripts, si tu peux les copier-coller dans les commentaires… Merci

    • [^] # Re: Expérience depuis 8 ans.

      Posté par Stinouff le 06 février 2024 à 14:56. Évalué à 2. Dernière modification le 06 février 2024 à 22:43.

      

      Salut,

      Voilà le premier (pardon pour la mise en forme, je galère sur linuxfr avec ça).

              #!/bin/bash
      
              # Fichier d'entrée
              read -e -p "Fichier d'entrée : " input_file
      
              # Résolution
              read -e -p "Résolution (vide pour origine) : " resolution
              if [[ ! -z "$resolution" ]]; then
                resolution="-s $resolution"
              fi
      
              # Codec audio
              read -e -p "Codec audio (par défaut: libopus) : " audio_codec
              if [[ -z "$audio_codec" ]]; then
                audio_codec="libopus"
              fi
      
              # Codec vidéo
              read -e -p "Codec vidéo (par défaut: libx265) : " video_codec
              if [[ -z "$video_codec" ]]; then
                video_codec="libx265"
              fi
      
              # Qualité vidéo
              read -e -p "Qualité vidéo (par défaut: 28) : " video_quality
              if [[ -z "$video_quality" ]]; then
                video_quality="28"
              fi
              crf="-crf $video_quality"
      
              # Rapidité d'encodage
              read -e -p "Rapidité d'encodage (par défaut: medium) : " encoding_speed
              if [[ -z "$encoding_speed" ]]; then
                encoding_speed="medium"
              fi
              preset="-preset $encoding_speed"
      
              # Début de la vidéo
              read -e -p "Début de la vidéo (format: HH:MM:SS) (vide pour commencer au début) : " start_time
              if [[ ! -z "$start_time" ]]; then
                start_time="-ss $start_time"
              fi
      
              # Durée de la vidéo
              read -e -p "Durée de la vidéo (vide pour conserver la durée d'origine) : " duration
              if [[ ! -z "$duration" ]]; then
                duration="-t $duration"
              fi
      
              # Nom du fichier de sortie
              read -e -p "Fichier de sortie : " output_file
      
              # Génération de la commande ffmpeg
              ffmpeg_cmd="ffmpeg -i \"$input_file\" $resolution -c:a $audio_codec -c:v $video_codec $crf $preset $start_time $duration -map_metadata 0 \"$output_file\""
      
              # Affichage de la commande ffmpeg
              echo "Voici la commande ffmpeg générée : "
              echo "$ffmpeg_cmd"
      
              # Demande de confirmation
              read -p "Voulez-vous exécuter cette commande ? (o/n) : " confirm
              if [[ "$confirm" == "o" ]]; then
                eval "$ffmpeg_cmd"
              fi
              echo "Rappel de la commande générée :"
              echo "$ffmpeg_cmd"

      Le second est une simple for avec renommage via mediainfo (c'est 3 lignes).

      • [^] # Re: Expérience depuis 8 ans.

        Posté par BAud (site web personnel) le 06 février 2024 à 15:47. Évalué à 2.

        

        (pardon pour la mise en forme, je galère sur linuxfr avec ça).

        il te manque un saut de ligne avant le ``` et tu as aide-edition § #toc-code-avec-coloration-syntaxique qui te l'aurait rappelé…

        il y a le bouton Prévisualiser pour s'assurer que c'est bien formaté en outre.

        • [^] # Re: Expérience depuis 8 ans.

          Posté par Stinouff le 06 février 2024 à 16:31. Évalué à 3.

          

          Salut,

          Oui, je me sers du bouton prévisualiser, mais après une vingtaine de tentatives, je perds confiance en moi. :D

          Merci pour le lien, je vais travailler là-dessus.

• # Pour moi pour la musique c'est FLAC

  Posté par carlo le 23 février 2024 à 09:11. Évalué à 1.

  

  Étant grand amateur de musique (mélomane je crois qu'on dit), pour moi le stockage de celle-ci c'est en FLAC et rien d'autre. C'est sous ce format que je les récupère (après achat sur bandcamp par ex), que je les rippait d'un CD à l'époque.

  Pour les photos c'est un vrai autre problème… les appareils photos me produisent du RAW+JPG généralement… que je trie quand j'ai le temps. Les téléphones produisent du JPG.

  Quant à la sauvegarde… oulala c'est mon métier de gérer des sauvegardes donc tout va bien, non ? :-/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.