 Bonjour, Jean-Martinez, je suis le développeur de Media Info aussi et pour le moment je travaille sur un nouveau projet qui s'appelle Workhooks. Workhooks convertira un file raw dans Matroska, FFv1 et Flac. Matroska pour le contenu, FFv1 pour le vidéo et Flac pour l'audio. FFv1 vient du projet FFmpeg, c'est un format de compréhension des vidéos sans vidéo. C'est complètement open source et patent-free. Le patent-free est très important pour l'archive, il n'y a pas d'accepter H264, par exemple, même si il y a un mode sans vente, parce qu'on doit avoir aucun risque de patent. C'est déjà adopté par plusieurs archives. Le problème des FFv1 est qu'il n'y a pas de standardisation. Nous travaillons avec IETF sur la standardisation. La grande chose des FFv1 est que les frames puissent être séparées par slice. Si nous perdons des contenus dans le storage, nous perdons seulement un slice et pas une frame. Nous avons beaucoup de checksum, il y a un checksum par slice, donc nous pouvons savoir exactement quand quelque chose est perdu. La standardisation à IETF, Steve a déjà parlé un peu. Il y a un matroscar pour la conteneur FFv1 et un flag. La partie FFv1 est bien avancée. Nous espérons avoir la standardisation à la prochaine IETF. Mais nous avons besoin d'une réveil externe. Nous avons besoin d'aide pour réveiller la spécification. Si tout va bien, nous standardiserons la version de FFv1. Nous pouvons travailler sur FFv1 v4, la prochaine version avec plus d'improvement de la compression. Pour le moment, avec FFv1 v3, nous pouvons avoir une bonne compression. J'ai un exemple avec 1 seconde, d'exemple avec un film de 10 bits HD. A mon computer, si j'ai un file avec un tar et un zip incompressé, c'est quelque chose que les archives font, parce qu'ils ne veulent pas avoir un grand impact quand des bits sont perdues. Cela peut se passer durant l'archiving. 1 seconde de cela est assez grande, c'est 200 megabytes. Si nous comprenons avec un zip ou un LZMA, ce n'est pas très bon, c'est très lent, ce n'est pas très bien compréhensible. Et si nous utilisons quelque chose adapté pour la vidéo, nous avons une bonne ratio de compression, quasiment divisé par 2 dans l'exemple, et assez rapidement. Donc, sur ma machine, ce n'est pas vraiment un temps réel. Si vous avez un service, ce n'est pas vraiment un temps réel, sans problème. Donc, l'advantage avec cette méthode, les archives currently use FFmpeg quand elles peuvent, c'est l'open source et 3, c'est bien. Avec FFv1, selon la source, nous avons une ratio de compression entre 1.5 et 3. Nous avons avec FFmpeg, aussi un checksum de clusters, je vais vous montrer un peu plus tard, Matroska 5 coude les vidéos, par exemple, un seconde cluster. Et dans ce cluster, il y a aussi un checksum CSC32, donc nous pouvons savoir quand il y a des issues de transmission ou des issues de storage. Nous avons aussi un checksum par slice, et avec FFmpeg, vous pouvez choisir exactement combien de slices vous pouvez avoir par frame. Donc, c'est bien d'avoir beaucoup de slice, parce que si vous perdez 1 byte, vous n'aurez pas de slice. Un retour pour avoir beaucoup de slice, c'est que la compression ratio est moins bonne, donc vous devez choisir entre la compression ratio et la sécurité, quand vous choisissez le contexte de slice que vous avez. Les slices sont nettoyables par VLC et FFmpeg, donc il y a des difficultés avec VLC et des vidéos, donc par exemple, les 6 bits par component vidéo, il y a des difficultés pour VLC, mais ils travaillent sur ça, merci. Donc, l'archive, il y a beaucoup de différentes bits d'esprit, par exemple, il y a 16 bits par component, donc c'est 48 bits pour RGB et 64 bits pour RGBA, et c'est assez grand, c'est parfois difficile pour des outils, mais nous travaillons sur l'improving de la compression et tout. Infortuniellement, il y a des gros backs avec FFmpeg, parce que FFmpeg ne craint pas toute la metadata à l'intérieur de la vidéo, seulement le contenu vidéo est élevé. Donc, nous perdons le scan software, la colorimétrie, la code d'extrême, l'angle shutter, tout le metadata de la wave, quand on convertit de la wave PCM à la flac. Et pour l'archive, c'est un problème, parce qu'ils ont besoin de savoir exactement comment faire le file. Donc, ils ont besoin de réagir aux outils, parfois ils ne veulent pas seulement le contenu de la vidéo, ils veulent toute la metadata. Donc, avec FFmpeg, l'issue est qu'on ne peut pas faire exactement le même contenu avec la metadata. Donc, le file MD5, les files résultats ne sont pas les mêmes. Donc, nous créons Wacook. Wacook. Nous stockons, en fait, le header de la DPX à l'intérieur des elements de Matrosky. Et nous stockons aussi les noms de source, parce que l'archive veut aussi les noms de source. Nous stockons d'autres files de cartes dans les directrices. Par exemple, il y a des files MD5, des files lookup-table. Et ils ont besoin de garder cette information aussi. Donc, je suis désolé. Nous mettons ça en attachement dans Matrosky. Donc, nous pouvons convertir tout de la file à Matrosky. Et nous pouvons convertir en bas pour les originales files, exactement en bas à bas. Cette structure est la même. Avec ça, si quelqu'un souhaite un file de source, il est complètement transparent pour la personne qui demande pour le file. Aucune metadata de l'input de l'input sera à l'output aussi. Donc, si il y a une certaine metadata dans un file, il sera gardé, et la conversion vidéo va perdre ça. Donc, nous pouvons utiliser Matrosky FFV1 et de la compression avant d'attendre le contenu pour l'LTO, pour le backup. Et sur le request, il sera complètement transparent. Donc, nous extractons le file MKIV de l'LTO. Nous revendons le PCM, si nécessaire. Et nous donnons le package à l'utilisateur. Et l'utilisateur est heureux. Il n'a rien perdu. Il trouve exactement le même contenu comparé à ce qu'il a senti. Donc, il est complètement transparent. Un autre outil d'utilisation est le transport. Si vous avez besoin de transporter le contenu de l'un à l'autre par Internet, vous pouvez envoyer le DPIX directement, c'est très frais parce que c'est très grand. Et nous pouvons, avant de envoyer le code, nous transportons le FFV1 et Matrosky, etc. Et nous décode directement. Donc, c'est aussi complètement transparent pour l'utilisateur parce que le ND5 match. Cette méthode est très bonne pour la saveur. Pour la saveur, donc, la coste de l'utilisation est un peu plus haute. Il y a un peu d'objets, inférieurement. Le compression FFV1 coûte beaucoup de CPU. Donc, ce n'est pas comme un TAR. Vous devez compresser, et c'est assez. Mais nous travaillons sur la version de la version FFV1. Et un autre issue c'est que nous perdons la complete slice si il n'y a pas de bête. Donc, nous travaillons aussi sur l'utilisation des issues pour ajouter des codes réor corrects, etc. Pour le moment, nous avons une version alpha, un snapshot de développement. Nous avons un Github Repo. Et nous planchons d'avoir un réel stable dans l'après-midi. Pour le moment, la repositorie a des flavors de Dpx supportés, donc, BigDeaf, BigEngine, etc. Nous n'avons pas de Dpx, mais nous travaillons sur ça. Nous analysons le Dpx Header. Nous créons un file data pour l'éversibilité. Et pour le moment, nous avons un file pour l'éversibilité, mais c'est uniquement temporaire. Nous voulons utiliser un dédicat de Matroska dans le futur. Et le Tool de WarCook a des commandes FFM pour encoder les files. Pour l'éversibilité, nous passons des bytes de Matroska et nous décodons donc il y a encore beaucoup de travail. Nous n'avons pas de PCM, c'est planté. Nous n'avons pas de directeur avec l'attachement, avec les files MD5 etc. Nous n'avons pas de GUI et c'est important pour l'archive. Nous n'avons pas d'utilisation de commandes. Nous planterons pas seulement des dpx, mais aussi des tifs et des exerces etc. Et nous devons supporter tous les flavors dpx. Il y a des informations sur la fondation, mais nous avons des sponsors. Le principal sponsor est la préservation AV par WETO.ch. Et 3 autres archives et des médias. De Luxembourg, de Norway et d'Airland. Et nous espérons avoir plus de fonds sur l'archive quand nous pouvons avoir une bonne démonstration. Nous voulons rester open source, mais c'est sometimes difficile d'avoir une bonne fondsion. Nous avons des supports de tous les flavors dpx. Nous avons des démons, nous avons des 10 bits, dpx, et pour plus de fonds, nous allons bloquer la binarie et nous demandons la clé. Mais tout dans l'archive est open source, et quand nous délivrons l'archive, c'est all open source. Donc, je termine. OK. Je voulais demander le format FF1. Vous savez comment c'est comparé avec Lossless VP9, parce que je sais que c'est aussi Lossless Compression. Non, nous n'avons pas checké Lossless VP9, mais dans mon opinion, avec VP9, c'est un peu risqué de patteurs. Donc, VP9, si vous modifiez la spécification, et que vous avez un agreement avec le pétain de poulon, seulement pour la pétain de poulon, en fait, dans VP9, et nous ne pouvons pas exprimer. Et pour le moment, il n'y a pas 16 supports dans VP9, donc ce n'est pas juste pour nous. Nous avons besoin de 16 supports, 16 supports. Alors, pour le moment que je comprends, il n'y a pas compression entre les frames. Est-ce qu'il n'a pas le sens d'avoir une compression entre les frames et d'utiliser plus de codes correctifs? C'est correct. Il n'y a pas de p-frame, par exemple. C'est le cas pour l'archive. On n'a pas l'impact d'une bête à la prochaine frame. Donc, si on perd une bête, on veut avoir l'impact d'une bête. FFV1 permet d'avoir quelque chose de p-frame. Il y a quelque chose dans FFV1. Mais, sur notre côté, en raw-cooked, on ne l'utilise pas. La performance de compression est meilleure. Quand vous l'utilisez d'une bête à la prochaine, c'est beaucoup mieux pour la compression. Mais, si vous l'utilisez d'une bête à la prochaine, vous l'utilisez de la prochaine frame. Et nous n'avons pas l'impact d'une bête à l'archive. Mais si vous avez des codes correctifs en long range, comme sur le scale de la frame, vous pourrez peut-être réconstruire la frame. C'est possible avec un raw-cooked, mais dans tous les cas, il y a toujours un problème que si on perd une bête et si on perd trop de bêtes, nous perdrons trop de contents. C'est un point d'archiving que vous préférez pas utiliser. Il serait possible si ils l'ont, c'est seulement un flag. Mais, pour le moment, leur décision est de rester avec Antoine. Mais il serait possible si l'archive est intégré. Okay. Any other question? No question? Okay. Okay, thank you, Jérôme.