Christophe --- a écrit 231 commentaires

Bonjour,
Je voie 3 options possibles:

• il y a une option "bg" pour un mount en nfs, je l'utilise sans problème et ça devrait fonctionner aussi dans ton cas à la place de "_netdev";

• comme suggéré par thierrybo ci-dessus; cela fonctionne parfaitement pour moi (et pas de problème a attendre avec NFS, cela a été prévu pour à la base);

• quand tu dis que le problème reviens à chaque version, je me pose la question: as-tu pensé a signaler le bug à la distribution? Si ça n'est pas le cas, c'est plutôt normal qu'il revienne. Si tu l'as signalé, effectivement, va falloir partir sur un plan B…

Sinon, pour l'option "_netdev", elle demande au système de ne pas monter le filesystem maintenant, mais y a-t'il bien, plus tard, le "mount -a" qui va faire les montages complémentaires?
De mon côté (debian), je voie que le "mount -a" dans /etc/init.d/mountall.sh filtre déjà nfs, donc pas besoin de de rajouter _netdev. Mais je ne connais pas la procédure de démarrage précisément, c'est juste une hypothèse.

D'après Qwant (premier résultat), il existe.

Mais j'avais aussi constaté chez moi (apt search) qu'il n'existe plus, j'avais compté sur le fait que tu aurais plus de «chance» que moi…

Il ne te reste donc comme solution probablement que de recompiler le package toi-même? Sachant qu'il faudra peut-être modifier les options pour inclure les symboles de debug (puisqu'apparemment ils ne sont pas inclus par défaut), et sachant aussi que tu n'auras peut-être plus non plus le crash… Bref, que du bonheur en perspective :-/
Je compatis…

Bonjour,
Une piste qui ne t'aidera pas beaucoup, mais pour avoir des info «intéressantes», c'est bien avec gdb que ça se passe mais il te faut installer le paquet «golang-dbg».
Il est possible que «gdb» ne charge toujours pas les symboles par défaut, il faut voir du côté de la variable debug-file-directory.
Ainsi tu aurais les noms des fonctions ainsi que les noms de fichier avec numéro de ligne.
Christophe.

Ou peut-être plus grave encore, la névrose zygomatique?

Pour le poulet, je suis pas sûr, y'en a qui sont mort pour moins que ça…

La remarque humoristique du monsieur portait sur la "fonte de la silice", ce qu'Apple ne fait pas et ne fera très probablement pas dans le futur.

Apple conçoit ses propres circuits depuis environ 2008 (Apple A4) mais la fabrication se fait chez un fondeur (Samsung, TSMC).

Mais dans les fait, c'est le concepteur qui décide ce qu'il met dans son circuit, donc tu as parfaitement raison, Apple participe à l'inclusion (ou pas) de AV1 dans le hardware.

Bonjour,

Voici une fonction d'exemple qui te donne la syntaxe pour extraire les informations:

proc get_it {table idx key} {
   return [dict get [lindex [lindex $table $idx] 0] $key]
}

# Et un exemple pour l'utiliser:
for {set i 0} {$i < [llength $mytable]} {incr i} {
    puts "($i) -> ([get_it $mytable $i name] = [get_it $mytable $i nodeaddr])"
}

Y'aurait probablement moyen de faire plus adapté selon ce que tu veux faire tes données.
Sinon je n'ai pas compris ta remarque ci-dessus sur les retours à la ligne et les liste. En TCL le parseur est très simple, et la pratique générale est d'utiliser les accolades pour les listes avec les espaces/tabs/CR entre les éléments, par exemples:

set une_liste {element1 elm2 elm3}

mais aussi:

set une_autre_liste {
   un_element
   "un deuxieme element" {un troisieme element}
   le_quatrieme
}

TCL est simple, mais il possède un défaut: il faut le connaitre pour l'apprécier. Comme tous les autres langages en fait. Après, il est vrai qu'il est passé de mode, mais ça, ça arrivera à tous les langages.

Bonjour,
C'est une idée amusante qui «sur le papier» me fait rêver aussi… Mais j'émettrais les réserves suivantes pour la réalisation:

• pour prendre le cas du CX355 cité ci-dessus, c'est un lecteur audio: je ne pense pas qu'il contienne un lecteur de CD façon lecteur d'ordinateur mais plutôt une mécanique spécifique, je doute qu'il soit simple de remplacer le lecteur (mais probablement pas impossible si tu est prêt pour de GROS bricolages), je dis cela d'expérience quand j'avais ouvert mon bien vieux C325;

• sur le choix du médium: tu as dit que tu «aimerais garder» les fichier, je te déconseillerais le choix des CD-R/DVD-R. Si certains articles parlent de 100-200 ans de rétentions (ça fait rêver), il semblerait que la pratique soit légèrement plus faibles, entre 2 et 5 ans. Trois fois rien.

Mais bon, si tu continue dans cette voie, n'hésites pas à partager avec nous ton aventure, je suis sûr que ça plaira a beaucoup de lecteurs de linuxfr! (moi le premier).

En fait, si personne ne répond, c'est probablement parce qu'il n'y a pas de question?
Le monsieur viens de découvrir le package numlockx. Oh, trois fois rien, juste un petit package qui ne fait pas grand chose… mais qui le fait bien et qui rend la vie plus agréable. Et sous le coup de la bonne humeur, le monsieur a souhaité la partager avec nous.
Un utilisateur satisfait, c'est toujours bien ;-)
(mais je t'accordes volontiers que le message n'est pas forcement super clair).

Je suis d'accord avec toi, avec ta carte ça devrait passer à l'aise. La deuxième piste que j'avais en tête serait du côté de l'utilisation mémoire dans ton appareil avec cause du débit; si tu as moyen de régler cela ce serait intéressant de voir si en baissant le bitrate (par ex 22->18) tu obtiens moins de framedrop?

Si ce qui gène kdenlive c'est le MTS mais pas le h246, une solution possible serait de faire une conversion du conteneur mais sans recoder les flux audio et vidéo (par ex. avec ffmpeg: -c:v copy et -c:a copy), ça devrait être rapide et ça évite de dégrader les flux.

Pour les 500 vidéos, je comprend que ce soit un peu lourd, même si je doute que ce soit une limite volontaire de l'outil; la solution que j'aurais pris dans ce cas c'est de faire le boulot en plusieurs fois, en rassemblant par exemple déjà les vidéos par paquet de 20, mais cela suppose que ce soit compatible avec ton utilisation…

Enfin, pour le protocole de test, cela vient d'une habitude (déformation professionnelle?) qui consiste à avancer par dichotomie: si le bitrate de départ est à X, on se met à mi-chemin entre X et 0, donc X/2. On regarde le résultat, et on continue à mi-chemin: si le résultat était bon, on prend la plage basse (0-X/2 donc X/4), sinon la plage haute (X/2-X donc X/2+X/4), et ainsi de suite jusqu'à trouver la limite. C'est un algo assez classique pour arriver le plus rapidement possible à la solution dans ce genre de cas.

Apparemment tu as pris mon message pour un attaque, et je te prie de m'en excuser car ce n'était pas mon but, seulement de faire avancer la discussion.

Maintenant, je vais quand même rajouter un peu de réflexion car le sujet m'intéresse, mais dans le cas d'archivage choisir une «qualité» ne me semble pas non plus la meilleure option: soit tu dispose d'un espace infini et dans ce cas mieux vaux partir sur du «lossless», soit tu as un espace fini et dans ce cas il vaux mieux contrôler la taille de tes fichiers, donc… choisir un bitrate et laisser le compresseur faire au mieux pour tenir la spec de taille.

Et comme je ne peux pas m'empêcher de taquiner, je te ferais remarquer que dans le sujet de Stinouff il n'est pas question d'archivage mais de travailler les vidéos, ce qui suggère donc plutôt en théorie du lossless.
Mais pragmatiquement tu as raison, dans ce cas un choix de «qualité» sera probablement la meilleure option.

Ah, il va falloir choisir: tu veux que l'encodeur s'adapte ou tu veux lui fixer un setting?

Si j'avais pris la peine de mettre «qualité» entre guillemets, c'est parce que la notion de qualité est subjective et que les algo de compressions n'ont pas encore de self-learning neural networks pour en juger (ça fait des points au business loto).

Ce que l'on appelle «qualité» dans les algorithmes actuels, cela correspond surtout au «quantifier» à utiliser. C'est lui qui détermine la quantité d'information que l'on va accepter de jeter pour réduire le besoin en bande passante.

Fixer le quantifier, en théorie ça n'est pas terrible car tu assume qu'un seul quantifier est valable pour toute la vidéo, ce qui n'est pas optimal: tu veux probablement un quantifier plus précis sur les détails et un moins précis sur les zones homogènes.

C'est pourquoi les compresseurs modernes proposent en pratique de viser un quantifier moyen et de les laisser s'adapter. Ce qui nous ramène au point de départ: quel est le bon quantifier à choisir? car cela dépend beaucoup de la vidéo en entrée, avec l'exemple flagrant de Stinouff: les settings par défaut sont très bien… sauf dans le cas de sa vidéo bruité!

Enfin pour les bitrate, s'il est vrai que le constant (CBR) a disparu c'est parce que le coût de compression pour bien le respecter est faramineux, et le VBR permet d'arriver au même résultat pour bien moins cher.

Il y a 2 cas pour lesquels un bitrate est tout de même plus important: pour les DVD/BD, car il y a le débit max du lecteur à respecter, et descendre en dessous veut dire une sous utilisation de l'espace disponible, donc pas la meilleur qualité auquel le cinéphile s'attend; et le streaming (internet, mais aussi TNT, satellite, …), pour lequel un débit est disponible, il n'est aussi pas possible de le dépasser, et hors internet remplir la bande passante inutilisée n'est pas souhaitable à cause de son coût à rentabiliser.

Deux applis certes mineures mais qui font que les normes prévoient en premier un bitrate et pas une qualité, et qui font que tous les codecs proposent un réglage par bitrate.

Mais je crois que je viens de faire un TL qui va finir en DR.

Je peux me tromper, mais quand je voie les débits en jeu, je soupçonnerais que tu as une carte SD de classe C4, ce qui fait qu'a 24Mb/s elle à le temps d'écrire, mais si tu passes de 25 à 30 fps, en supposant que ton appareil soit réglé sur une qualité constante plutôt qu'un bitrate, alors le surcout en bande passante nécessaire (x1.2 théorique, x1.4 d'après tes chiffres) fait que la carte n'a pas le temps de suivre, et ton appareille jette quelques images pour compenser. Mais ça n'est pas la seule raison possible.

Effectivement, vu que tu fait cela pour travailler les fichier, j'aurais tendance à abonder dans ton sens en disant que ça n'est pas la peine de ré-encoder les fichiers, surtout si ton logiciel les accepte.

Si tu a envie de continuer tout de même quelques essais, ce serait de viser déjà un bitrate/2 en restant en x264 (le gain en x265 n'en vaut pas la peine tant que ça n'est pas du final, à cause des surcouts de compression et décompression) et voir ce que cela donne sur les images les plus bruitées, donc ici un VBR=11Mb/s en restant en h264 pour comparer; et selon le résultat essayer 11/2 (si ok) ou (11+22)/2 (si pas ok).

Bonjour,

Si j'en crois notre amis Wikipedia, le MTS c'est du MPEG2 qui peut contenir soit du h.262, du h.264 ou du VC-1;
Ce serait une bonne idée de commencer par savoir ce que tu as dans ta vidéo d'origine: format et bitrate.

Ceci connu, il faut savoir que le bruit est en général un gros problème à compresser, donc si tu connais un programme avec un bon algo de réduction du bruit ça devrait aider si tu veux vraiment de petits fichiers à la fin (non, je n'en connais pas, sinon je n'aurais pas manqué de les partager ici).

Pour ce qui est du choix de la compression, il y a plusieurs possibilités:
- viser un bitrate (constant ou variable), donc connaitre celui d'origine et par une règle de 3 tu peux estimer la taille du fichier d'origine, et seuls des essais te permettrons ensuite de trouver un bitrate correct pour ton cas;
- fixer une "qualité" (le terme n'est pas correct, mais reflète l'idée, c'est le CRF proposé ci-dessus), ce qui est moins bien mais une fois trouvé la valeur qui va bien pour ton cas ça peut fonctionner (il te faudra donc aussi faire des essais);

La doc de ffmpeg suggère pour le CRF des valeurs entre 18 et 28, mais dans ton cas (vidéo sombre + bruit), faudra peut-être descendre plus bas?

Vu les temps de compression que tu annonce, je te suggère de limiter la compression à ~10 secondes de vidéo tant que tu n'a pas trouvé la config qui va bien…

Bonjour,

En fait, si tu regarde le prototype de la fonction vsnprintf qui est utilisé dans l'exemple, tu verra que:

• ça n'est pas: vsnprintf(str, size, format, ...)
• c'est: vsnprintf(str, size, format, va_list ap)

Donc dans ton cas, il ne faut pas définir:
void get_data_nesteed2(const char *pfmt, ...)

mais ceci:
void get_data_nesteed2(const char *pfmt, va_list args)

avec le code a simplifier en conséquence.

Si tu ne peut pas changer le prototype de get_data_nested2, il va falloir penser le problème autrement, car il ne me semble pas possible de transmettre des variadics autrement que par l'intermédiaire du type va_list (si c'était possible, il n'y aurais pas 2 fonctions snprintf et vsnprintf pour faire la même chose)

Les deux formations me semblent très proche, comme le confirment les pages "Description Générale du Métier", je comprend que tu ais du mal à choisir entre les deux…

Dans les 2 cas cela va biens plus loin que la simple gestion de serveurs car ils proposent de s'initier à la programmation et à l'électronique, ce qui est probablement une bonne idée.

Les solutions qu'il te reste, c'est:
- discuter avec des anciens de chaque filière pour voir le métier qu'ils font et avoir leur avis;
- sinon, tu peux aussi faire pour chaque formation un tableau localc; pour chaque matière listée dans la "Grille Horaire" tu assignes une note (1=ça me plaît, 0=neutre, -1=m’intéresse pas), multiplier par le nombre d'heures cumulées sur les 3 ans puis faire la somme pour voir qui a la meilleure note.

Je ne pourrais pas t'aider plus, je n'ai pas choisi ce genre de formation, mais peut-être auras-tu plus d'avis?

Bonjour,

Je ne connais pas les spécificités de ces programmes, mais en première approche, je pense qu'une différence est ici:

• informatique industrielle, cela se rapporte à l'informatique embarquée, celle que l'on ne voie pas, dans tous les circuits intégrés qui font marcher le matériel (sous entendu: non-PC, je parle voiture, train, électroménager, …) aujourd'hui;

• technologies de l'informatique, je pense qu'au contraire c'est plus tourné vers les ordinateurs (PC, serveurs, …)

Mais après il faut voir le programme pour plus de précision… Tu peux toujours en partager un peu ici, il y a plein de gens qui ont de l'expérience dans les 2 domaines et qui n'hésiterons pas a partager leur avis, comme cela à déjà été le cas par le passé.

Bonjour,

Si tu veux inverser les lignes et les colonnes, il va falloir commencer par lire l'ensemble du fichier et le stocker dans une table, par exemple:

{
  for (i = 1; i <= NF; i++) {
    array[NR, i] = $i;
  }
  max_col = max(max_col, NF);
}

Tu vas te retrouver avec tous les champs séparés dans le tableau array, et au passage on garde le nombre de champs pour la ligne qui en as le plus, car cela donnera le nombre de lignes a générer.

Une fois que tu as les valeurs, il ne reste donc plus qu'a les ressortir dans l'ordre que tu veux, dans cet exemple:

END {
  for (y = 1; y <= max_col; y++) {
    printf "%s", array[1, y];
    for (x = 2; x <= NR; x++) {
      printf " %s", array[x, y];
    }
    printf "\n";
  }
}

Attention, pour que tout fonctionne il faut savoir que (g)awk ne définit pas la fonction max, donc c'est à toi de le faire en rajoutant ceci au début:

function max(a, b) {
  if (a > b) { return a; } else { return b; }
}

Enfin, si tu souhaites prendre l'habitude de faire du code explicite, pour être plus facile à reprendre plus tard et avec moins de risque de bugs, je t'invite à initialiser explicitement les variables, ce qui se fait ainsi:

BEGIN {
  max_col = 0;
}

Voila, une fois tout ceci remis dans l'ordre, chez-moi-ça-marche.

La même, mais en différent, parce que le bas à pas l'air très correct:

J'avoue que je n'utilise aucune de ces deux fonctions, donc ma description s'est basé sur ce que j'ai compris du message de commit, lui même un peu trop sibyllin pour moi…

Mais en effet, après relecture du patch lui-même, c'est en effet ce que semble être la nouveauté

Il me semble que la question a été soulevée sur la liste de discussion, mais sans trouver de réponse.

Cependant, ce que j'ai pu lire du fonctionnement de Wayland me laisse penser que ce doux rêve ne pourra malheureusement se concrétiser.

Sur le site, la première ligne c'est:

Designed for programmers with large heterogeneous trees of source code

La valeur ajoutée, c'était sa capacité à chercher en récursif dans une arborescence de fichier (ce que, si je me souviens bien, grep ne faisait pas à l'époque), et en faisant le tri pour éviter les fichier inintéressants (binaires, …).

Dans ton cas, t'as pas besoin de tout ça, donc tu paies la surcouche Perl pour rien…

Bonjour,

Je n'ai pas les conditions pour reproduire ton cas, mais chez moi:

egrep '^..$|^..a$|^..a.b$' /usr/share/dict/* | sort -R | head -1

répond en moins de la demi seconde (au total, 501k lignes dans la somme des fichiers sources)

Merci pour ce lien, c'est d'autant plus intéressant qu'ils ont apparemment décidé de jouer le jeu à fond, donc on y trouve un lien avec:
- la possibilité de configurer les catégories de cookies que l'on souhaite activer/désactiver;
- des explications sur à quoi servent les cookies en question!

C'est un modèle de transparence!
J'aurais presque eu envie de leur envoyer un mail de félicitation et de remerciement…

Bonjour,

J'ai un peu de mal à comprendre ce que tu vises au juste, mais voici quelques pistes que m'inspirent ton cas:

• Il n'y a pas d'unité dans ton 40/1.6, ce qui pour une longeur est probablement un problème, mais c'est peut-être une erreur de recopie?

• de base, Latex ne permet das de faire des calculs, mais il permet d'appliquer un coeffiscient lors de la référence à une longueur.

• dans ton cas, je pourrais te proser ceci:

  \newlength{\matailledimages}
  \setlength{\matailledimages}{40mm}
  
  [...]
  
  \begin{wrapfigure}{l]{0.625\matailledimages} % 1/1.6 = 0.625
  \includegraphics[width=\matailledimages}{ton_image.jpg}
  \end{wrapfigure}

• Sinon, tu peux aussi t'inspirer de ceci, non exhaustif en l'état:

  \newlength{\matailledimages}
  \setlength{\matailledimages}{0.4\textwidth}  % default=40% of text width
  \addtolength{\matailledimages}{-\intextsep}  % soustrait la marge de separation