fengalin a écrit 20 commentaires

Si tu préfères découper le fichier à la main, peux-être serais-tu intéressé par mon projet media-toc. Tu peux facilement positionner / modifier les limites entre les "chapitres" et chercher la fin des syllabes (click droit sur la forme d'onde en mode pause).

Le projet n'est pas encore bien packagé, mais je pourrais générer un binaire au besoin.

Comme pour les autres commentaires ci-dessus, voici la réponse de Sebastian, puis une traduction :

All the security issues in GStreamer in the past year (and hundreds of other bugs) would've been impossible with Rust. Or D, Go, Haskell, JavaScript, …, just that those languages have other disadvantages that make them not suitable for GStreamer (except for application development).

Tous les problèmes de sécurité qui sont apparus l'année dernière dans GStreamer (ainsi que des centaines d'autres bogues) auraient été impossibles avec Rust. Ça aurait également été le cas en utilisant D, Go, Haskell, JavaScript, … à la différence que ces langages comportent d'autres inconvénients qui ne les rendent pas appropriés pour GStreamer (à part pour le développement d'applications).

Commentaire de Sebastian, puis traduction:

They're "using" it as much as GStreamer so far, AFAIU. It's not part of the main codebase yet, unless something has changed.

But yes, VLC and ffmpeg people are also looking into Rust, which is great, also for GStreamer :) One of the VLC people for example wrote a FLV demuxer, around which I wrote a GStreamer plugin in Rust (also he wrote nom, which is generally useful). Or in the case of ffmpeg it would directly give the advantages to GStreamer without any work being needed on the GStreamer side (via the ffmpeg GStreamer plugin).

À ma connaissance, ils l'« utilisent » autant que GStreamer pour le moment. Ça ne fait pas encore partie du tronc principal du projet, à moins que quelque chose ait changé.

Mais en effet, les gens de VLC et de ffmpeg regardent aussi du côté de Rust, ce qui est super et ce, aussi pour GStreamer :) Par exemple, l'un des membres du projet VLC a écrit un démultiplexeur FLV autour duquel j'ai écrit une extension GStreamer en Rust (il a également écrit mom, qui est utile plus globalement). En ce qui concerne ffmpeg, cela profitera directement à GStreamer sans nécessiter de travail supplémentaire (grâce à l'extension ffmpeg de GStreamer).

Voici la réponse Sebastian dont je vous propose une traduction à la suite.

I completely agree with you, but you have to make some simplifications. I could do a whole presentation about the topic you're speaking of.

The audience however is full of C developers, and everybody who ever wrote some C knows that a memory unsafety in one place could show up somewhere completely different. Nonetheless, it is caused by a single "unsafe block" in the end.

Similarly, if your safe abstractions in Rust around unsafe code are leaky and broken, something completely different can explode later. But the bug itself is going to be in an unsafe block.

So, IMHO what I said is right (minus compiler/language bugs), just a big simplification that everybody who ever wrote code in a memory unsafe language should understand.

Je suis complètement d'accord avec toi, mais il est parfois nécessaire de passer par des simplifications. Je pourrais faire toute une présentation sur le sujet que tu évoques.

Le public [de la conférence GStreamer] est constitué de plein de développeurs C et tous ceux qui ont écrit du code C savent qu'une utilisation non sûre de la mémoire à un endroit donné peut ré-apparaître à un endroit totalement différent. Néanmoins, en fin de compte, le problème est bien provoqué par un bloc non sûr donné.

De la même façon, en Rust, si tes abstractions sûres basées sur du code non sûr fuient ou sont boguées, quelque chose de complètement différent risque d'exploser plus tard. Mais, le bug en lui-même se trouvera dans un bloc non sûr.

Donc selon moi, ce que j'ai dit est exact (mis à parts les bugs du compilateur ou du langage), c'est une grosse simplification que tous ceux qui écrivent du code dans un langage à gestion de la mémoire non sûre devraient comprendre.

Merci yPhil et merci aussi pour l'explication et les exemples parlants ! J'ai hésité, mais d'ailleurs je préfère, et je dis « qu'est-ce qui manque » dans la vraie vie.

Je ne vais pas m'exprimer au nom de la communauté, mais il m'a semblé lire assez souvent que Rust permettait d'éviter un certain nombre de failles de sécurité sans toutefois garantir un logiciel infaillible. Je pense que l'avantage du langage sur ce sujet réside principalement dans les contraintes imposées au développeur dès la compilation. Ces contraintes imposent des pratiques éprouvées pour permettre d'éviter un grand nombre de failles de sécurité. Je trouve que c'est quelque chose que Sebastian détaille vraiment bien dans les premières sections de la présentation. Voir aussi l'échange avec Renault dans mon précédent journal.

Selon moi, Sebastian mentionne les CVE en C à la fin de l'article (le lien renvoie vers l'article Wikipedia, et non vers une liste de CVE lâchées en patûre ;-)) en écho à sa remarque en tant que développeur et mainteneur de GStreamer :

Tous les problèmes de sécurité que nous avons rencontrés dans GStreamer les années passées auraient pu être évités en utilisant Rust.

Rust doit faire ses preuves, comme les autres. Il est particulièrement prometteur et on sait déjà qu'il permet de faciliter la vie des développeurs.

En effet, c'est le risque avec la traduction d'une présentation destinée à une conférence spécialisée. Ton commentaire me suggère une dépêche sur le développement avec GStreamer du coup. Je n'en suis pas un spécialiste, donc une rédaction à plusieurs mains pourrait être vraiment adaptée.

Ta conclusion est précisément ce qui m'a donné envie de partager cette présentation avec vous. Merci pour Sebastian.

Merci pour les liens. Je ne connaissais pas RustBelt, l'approche semble très intéressante.

J'ai prévu de rédiger un résumé des commentaires à l'attention de Sebastian, bien sûr ta remarque en fera partie.

J'ai ajouté un bouton pour répéter le chapitre en cours. Bon, ça reste minimaliste…

Un lecteur un peu comme celui-ci du coup ? ;)

Carrément ! Moi aussi ça m'intéresse pour la guitare. Je pourrais ajouter une fonction de répétition d'un chapitre. Note que c'est déjà possible avec les contrôles avancés de VLC (fonction A-B). Tu peux même passer de chapitre en chapitre avec le bouton >|, si ton fichier comporte une table des matières.

Oui, ce serait sympa et ça irait dans le sens d'une indexation hiérarchique comme proposée dans ce commentaire.

Je comptais aussi implémenter une option pour la génération des fichiers cue sheet. Et aussi des options pour éviter les transitoires suite aux découpages, la gestion du ReplayGain, … Pas mal de boulot encore :)

Merci devnewton ! C'est noté !

La discussion cite d'autres problèmes et je pense que ceux que tu mentionnes pourraient venir s'ajouter à la liste. Si le sujet t'intéresse, tu devrais jeter un œil, le débat est plutôt intéressant. Cela dit, la conversation date d'il y a 6 mois.

Voici quelques pointeurs vers des bibliothèques Rust actives offrant un toolkit (évidemment, cette liste n'est pas exhaustive) :

• Le binding GTK dont il est question ici. Le projet est actif et il fait ce que je veux qu'il fasse, même si mon IHM reste assez conventionnelle. Sa seule spécificité réside dans le rendu des waveforms et pour cela j'utilise Cairo qui permet le dessin vectoriel.
• Le projet C++ to Rust de Qt offre des bindings vers les bibliothèques de Qt et semble actif. Voir la doc pour QtGui et QtWidgets. Je ne peux pas donner mon avis vu que je n'ai pas testé. Note cependant la mention : "Il s'agit un travail en cours, l'API va changer significativement à l'avenir. Certaines méthodes manquent encore et certaines ne sont pas pratiques à utiliser. Certaines méthodes ne sont pas sûres alors qu'elles ne sont pas déclarées comme telles". Pour un projet personnel comme le mien, c'est pas ça qui m'arrêterait ;-)

Il y a des projets pour d'autres toolkits, mais ils semblent pas très actifs. Ex. :

• wxWidget.

Un peu HS, mais méritent d'être mentionnés :

• Orbital, le projet qui concentre les développements pour l'IHM de Redox.
• rustty pour réaliser des IHM dans le terminal.
• Le binding sur SDL2.
• Piston, un moteur modulaire de développement de jeux.

Oui, les logiciels de montage vidéo ou les multi-pistes audio devraient pouvoir exporter des pistes, moyennant quelques opérations manuelles. J'ai tenté avec Ardour, mais j'ai fini par lâcher l'affaire.

Pour l'export de tables de matières avec ce type de logiciels, après une recherche rapide, je n'ai rien trouvé de probant. Cinelerra sait créer un menu pour DVD à l'aide d'une description XML et un outil en ligne de commande. Je n'ai rien vu pour d'autres conteneurs audio-vidéos.

Note aussi que des commentaires plus bas suggèrent d'autres cas d'utilisation qui semblent pouvoir être couverts sur la base de l'interface existante. On devrait pouvoir aboutir à un logiciel simple d'utilisation et répondant à des besoins que je n'avais pas imaginés initialement.

Merci pour tes retours !

Merci pour ton retour et pour la déclaration de bug ! Je n'ai pas encore observé ce problème, je te demanderai probablement des précisions quand je m'y mettrai.

En effet, je m'amuse bien :)

Issue créée. Reste à voir comment ça peut s'articuler avec le projet initial.

Salut !

Je ne connaissais pas, merci pour les pointeurs.
J'ai créé une issue.

Pour le moment, seul l'affichage des chapitres est géré dans media-toc et il n'y a pas de structure hiérarchique. Ça ne devrait pas présenter de difficulté d'améliorer cela.

Tout à fait d'accord. Rust apporte des garde-fous.

L'idée principale que je voulais exprimer (à la suite du texte que tu cites) était que malgré une certaine frustration ressentie parfois face aux contraintes imposées à la compilation, je continue de penser que ces contraintes ont de la valeur. C'est l'histoire du coût de la résolution des bugs selon le moment où ils sont détectés, c.f. aussi mon exemple de cartes à puce. Par ailleurs, je me rends compte que j'ai dû intégrer ces contraintes car je ne me souviens pas avoir ramé ces derniers temps.

En effet, et j'ai assez peu cherché à vrai dire. En fait, ce n'était pas si important pour moi. Souviens-toi que ce projet n'est qu'un prétexte ! ;)

Pour être un peu plus précis, j'ai eu l'occasion d'utiliser rapidement mkvtoolnix récemment. C'est un peu le couteau suisse pour le conteneur Matroska. C'est grâce à lui que j'ai créé les 3 chapitres pour ma vidéo d'exemple (celle avec mon fidèle Ernest). Pour l'édition des chapitres, je cherche néanmoins quelque chose de plus ergonomique et interactif. Par ailleurs, media-toc pourrait servir pour d'autres formats.