Prae a écrit 2843 commentaires

Format ouvert : Je te défie de me montrer un décodeur DCP basé uniquement sur les specs fournies dans ton lien.

Je vois pas ce que tu veux dire. Les specs ne fournissent pas le code source d’un décodeur DCP, cela n’a pas de sens.
Au mieux, ce que tu as, ce sont des bouts de code pour tels ou telles parties (genre vérif d’un hash crypto, ou de check xml, etc…)
Et la doc DCI formalise pas mal de choses et faire des références sur des normes.

Spoiler : tu n'y arriveras pas, vu que le site que tu pointes ne fournit pas tout, juste 1% des specs (celles qui disent "utilisez MXF et JPEG 2000", sachant que les specs MXF et JPEG 2000 sont derrière un paywall est que tu n'as pas intérêt pour ta santé à les diffuser)

Tu es sérieusement entrain de m’apprendre ce qu’est le SMPTE ? :)
Que les docs SMPTE ne soient pas dispos à tout à chacun, oooh bordel oui, c’est relou.
Mais cela ne veut pas dire que tu peux pas implémenter toi-même, cela ne veut pas dire que tu peux pas lire la documentation, ni même faire ce que tu veux du format indiqué dans le document (après, tu fais ce que tu veux de l’implémentation, c’est ton problème)
Ou alors pour toi, cela voudrait donc dire « libre == gratuit » ?

Format libre : DCP n'est pas libre. la ligne dans les specs "Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited." est 0% compatible avec les 4 libertés.

J’ai déjà donné ma réponse au dessus.
Tout le monde peut participer aux specs DCI et aux normes SMPTE, il suffit d’être dans un groupe de travail et de faire une proposition (style RFC).

pas MXF

What ?
J’ai vu aucune indication de non-liberté dans le SMPTE-377, ni même dans le bouquin de Nick Wells.
Et c'est même écrit en préambule du SMPTE-377 qu'à leur connaissance, il n'y a droit de brevet sur le format MXF.

Et j’ai vu personne avoir de problème pour l’implémentation d’un read/write d’un MXF dans leurs logiciels et encore moins de takedown sur des projets opensources, même connu par tous.

Donc sa phrase est bien plus proche de la vérité que la tienne.

Nop.

JPEG 2000 n'est pas sans perte, donc tu as des artefacts. Moins visible en cinéma car wavelet + débité élevé, ça n'enlève pas leur existence en soit, juste moins prononcé.

Sa phrase laisse supposer qu’on voit ses artefacts comme de vulgaire gros carrés de compression. Donc non.

Non, j'ai interdiction de rediffuser 99% de la spec DCP.

Prendre les PDF sur dcimovies.com, tu fais ce que tu veux, j’ai vu personne avoir de problème avec et cela depuis plus de 15 ans.
Ou alors tu parles des docs SMPTE.

mais bon parser du DCP "seul" me fournit… Absolument rien en contenu audiovisuel.

Tu me feras pas croire que tu sais pas parser du MXF :)
Tu me feras pas croire que tu sais pas comment marche un MXF :)
Et tu me feras jamais croire que après avoir trouvé et récupéré les KLV des images, tu peux pas appliquer une passe openjpeg dessus :)
Et allez, vu qu’une partie semble bloqué sur le JPEG2000: dans les MXF subs, ce sont des PNG, donc on a une succession de KLV facilement lisible par tout à chacun et dont certains sont justes des PNG, tu vas me faire croire que tu n’as absolument rien en contenu audiovisuel ?
(et tu oublies les MXF Audio, le WAV est devenu proprio ?)

Non, j'ai interdiction de modifier 100% de la spec DCP, y compris 100% du texte que sur le XML du DCP.

Mais bullshit bordel, on le fait nous ! Même Dolby.
On modifie des DCP, on rajoute des trucs.
Le seul truc, c’est que tu perds ta « normalisation » DCP, tu peux plus appeler cela DCP (pas au sens juridique), tu es obligé de dire que tu as rajouté des trucs et que si certains outils font des tests d’intégrité très sévères, ils peuvent le refuser (et c’est normal !)
Et si tu veux que tes metadatas ou tes modifs soient prises en compte par l’ensemble du secteur, et bien tu écris une jolie RFC aka SMPTE Draft pour que cela devienne valide pour tous (et encore, t’es même pas obligé, tu peux très bien faire une doc technique classique et la publier, je crois même que Dolby avait fait cela au début pour son format Atmos)
Si t’as envie de faire un DCP à ta sauce, tu le fais, mais après faut pas se plaindre que les outils des copains soient ne l’aime pas, soit le refuse.
C’est comme si tu voulais modifier des trucs dans les headers d’un PNG sans respecter la norme PNG et après râler que les outils n’arrivent plus à ouvrir ton PNG.

A ma connaissance ce n'est pas donné. Faisable pour des gros cinémas, plus difficile pour des petits (ticket d'entrée…), et pour d'autres encore plus petit c'est juste impossible.

Et ?
On va encore avoir cette discussion sur le prix du matériel en salle et donc « il faudrait une norme pour réduire les coûts »
Désolé, mais vous avez 15 de retard, j’ai déjà eu ce genre de discussion ici en plus.

Le cinéma numérique est 0% libre, c'est un fait.

Non, c’est ton fait. Tu peux faire ce que tu veux du format, tu peux même rajouter des types de KLV dans le MXF sans que personne ne vienne te prendre la tête. Mais après, si ce n’est pas dans une doc, ne vient pas chouiner que personne ne supporte tes ajouts.

Le cinéma est un autre monde, un autre budget, et se fout du lossless

Le monde du cinéma est vaste. C’est comme parler d’informatique et n’évoquer que le rôle d’un sysadmin.
Le monde du cinéma ne se fout pas du lossless, quand je suis en tournage, j’ai vu aucun chef opérateur dire « ouais, je m’en fous qu’on est une compression dégueulasse qui va saloper mon boulot ».
Le reste du workflow, que ce soit en tournage, en postproduction ou en archivage, j’ai vu quasi personne de sérieux me dire « je m’en fous de perdre en qualité ».
Le seul moment où ils sont tolérants (et je parle bien de tolérance, pas de je-m’en-foutisme), c’est lors des copies séries pour les envoyer dans les salles de cinéma. Ils acceptent, là, de perdre un peu. Et quand je dis un peu, c’est que cela a été validé par le chef-opérateur en postprod et le réalisateur.
Et pour info, ils avaient cette même tolérance avec le 35mm, d’où le fait que les copies pour les salles de cinéma étaient différentes des tirages pour les festivals.

mais eux ont la thune et utilisent déjà JPEG 2000

C’est quoi ce lien avec « JPEG2000 == thune » Quel est le rapport ?
Tu penses que ça sera moins coûteux de faire une master FFV1 qu’un master JPEG2000 ?
Le JPEG2000 demande pas des coûts supplémentaires, ce qui coûte le plus cher en mastering, c’est le travail dessus: les gens bossant dessus.

Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited.

Bah, ça parait normal que seul le DCI peut valider le document final.

Mais derrière, c'est du même acabit qu'un RFC: on a des groupes de discussions techniques, chacun peut participer, chacun peut apporter sa pierre à l'édifice, mais au final, il faut des normes, des specifications, un tronc commun. Quand on propose des drafts pour le SMPTE, n'importe qui peut le faire (même moi, pour dire), puis il y a une discussion globale avec tout le monde du secteur du cinéma (et on parle surtout de techos dans les discussions, pas de financier). Et à la fin, quand tout le monde a challengé la proposition technique, elle est considéré comme validée et elle part en specs/normes.

Et c'est justement grâce à cela qu'on évite que des sociétés tierces (style Dolby par exemple), imposent leurs propres formats au détriment des specs/normes définies par l'ensemble des gens.

Mais pour les titiller on y travaille. Par le biais des archivistes dans un premier temps, mais ça permet de faire accepter FFV1 dans des logiciels… Donc après les autres peuvent basculer quand ils veulent.

Salut Zenitram,

A l'heure actuelle, je n'ai pas entendu parlé de FFV1 pour l'IMF (je suppose que c'est de cela dont tu parles) dans notre milieu;

A tout hasard, j'ai regardé rapidement ta doc (https://mediaarea.net/ollistd/MXF_FFV1)
Est-ce que tu aurais des MXF avec du FFV1 (mode Frame et mode Clip) accessible quelque part ?

Et à quand un format cinéma libre? 😉

Devant ce titre, c'est laisser supposer que le format DCP est un format propriétaire. Ce qui est le plus éloigné de la vérité. Les spécifications DCI sont disponibles à tous (cf. https://www.dcimovies.com/) [on pourra rétorquer qu'il faut aussi les docs SMPTE, il est vrai, c'est casse-bonbon, même pour moi]

Genre le cinéma (imaginez de vilains artefacts sur votre écran de cinéma géants).

Des artefacts sur un écran cinéma ?
En sachant que le JPEG2000 est wavelet, je comprends pas ce que tu as voulu dire.
(ou alors tu parles des projections MPEG/H264/265 qui sont en dehors du cinéma numérique)

les fichiers sont simplement trop lourds, donc impossible de décompresser en temps réel 24 (ou pire 30) images par seconde.

Je le fais depuis mon modeste portable.
Il suffit pour cela de choisir un autre layer de résolution.

avec (j'imagine) du décodage hardware.

Oui, c'est du FPGA la plupart du temps, une carte dédiée à la décompression JPEG2000 et une autre partie pour la partie cryptographique (ceci dit, j'ai bien vu un player tout faire directement via le CPU directement…)

à quand un format libre pour le cinéma où on remplacerait le JPEG2000 par du FFV1? Ça pourrait même être le même conteneur DCP sauf que les canaux vidéos seraient FFV1. Je pense que la question serait très politique (lobbying du cinéma)

C'est la même question que depuis 15 ans: "mais pourquoi le MXF DCI/DCP gère pas plus de format" (déjà le MXF le fait, on peut mettre d'autres format).

Il existe plusieurs réponses à cela:

1. Le format DCP se voulait être clair et précis: ne pas reprendre les erreurs du e-cinema (pre-d-cinema, donc avant 2005): celui d'avoir plusieurs formats possibles mais provoquant de multiples noeuds dans le cerveau pour la filière: Un cinéma qui peut gérer du MPEG ne pourra peut-être pas gérer du H264, et inversement (et là, je parle que de deux formats). Les distributeurs devront alors demander à chaque cinéma "quels formats tu supportes ?" en supposant que le projectionniste ou l'exploitant saura y répondre. (ou alors passer le relai au labo qui devra contacter chaque cinéma pour chaque release).

2. Cela coûte plus cher: supporter plus de format a un coût. Que ce soit en maintenance (les upgrades logiciels/hardwares) mais aussi côté distributeur et laboratoire: Il faudrait donc X versions d'un DCP pour gérer l'ensemble des formats possibles. Cela n'est pas possible ni viable sur la longueur.

3. Eviter la fuite en avant d'upgrade: C'est le principal reproche qu'on a eu dès 2005-2006: "Ouiiii mais vos truuuuucs, faudra tout le temps faire des mises-à-jour, avec le 35, c'était plus simple". Certes, mais bon, techniquement, un DCP de 2006 marche encode sur un projecteur de maintenant (et normalement un DCP de 2021 [Interop] devrait marcher sur un player DCP/DCI de 2006…)

La question du lobbying est un peu galvauder: les distributeurs/exploitants s'en foutent un peu, les studios aussi; les labos idem. Tout ce qu'on veut c'est avoir un workflow stable sur la durée. Et le but du DCI, c'était de créer un format utilisable par tous et pour tous et sans être emmerdé par une société qui pourrait faire pression (à l'époque, on voulait éviter que Microsoft y fasse main-basse)

VPF pour aider financièrement les petites salles à se numériser

Les plus petites salles n'ont pas eu de VPF (dans le sens classique).
Mais c'est une autre histoire (et celle là est très politique)

Et c'est sûr que c'est toujours plus intéressant d'avoir des formats libres.

En règle général ou pour le cinéma ? (en règle général oui)

Pour le cinéma ? hmmmm; un DCP c'est surtout du XML, de la cryptographie classique et approuvée, du PNG, du WAV/PCM, un gros container tout simpliste (MXF) qu'avec 5-6 lignes de python, tu le parses dans les grandes lignes.

On peut revenir sur le JPEG2000 mais tous les contributeurs qui ont participé et/ou des patents dessus (sur les premières 'Parts') ont clairement annoncé renoncer à faire quoique ce soit dessus - et pour ainsi dire, je vais être même plus radical, s'il n'y avait pas eu du JPEG2000, j'aurais peut-être milité pour du DPX ou OpenEXR directement, (voirement même un encodage direct des pixels RGB ou XYZ en 12 ou 16 bits directement dans les Picture Essence du MXF, donc Lossless), mais bon, la taille des DCP après…

Depuis 2005, j'ai fait des tonnes de DCP avec mon popre code ou avec des outils opensources (et je parle pas des outils de maintenant comme opendcp ou dcpomatic, à l'époque, il n'existait pas). A l'époque, on le faisait à coup de script shell, openssl, imagemagick et OpenJPEG.

Et puis, c'est pas comme si dans les specs DCI et CTP, on voyait pas des morceaux de code source en C pour aider aux implémentations.

Tu me diras "tu parles interopérabilité, pas de format libre", pourtant, le format DCP est très libre. Tous le monde a pu coder des trucs dessus, le réutiliser, en faire ce qu'ils voulaient (même rajouter des trucs dedans sans être inquiété et je parle en connaissance de causes), que ce soit pour des solutions pro(priétaire) comme des solutions opensources. Et de cette expérience assez heureuse, on l'a poussé jusqu'à développer son petit frère l'IMF - avec ses propres extensions et - miracle - la possibilité d'avoir d'autres formats dans les containers MXF (oui, n'avoir que du JPEG2000 non-lossless, c'est pas top pour l'archivage)

Désolé d'être un peu tendu sur la question, c'est juste que le débat "le cinéma numérique, c'est caca car pas libre, je l'entends depuis 2005 avec toujours les mêmes arguments.

Faire croire que limiter empêchera à un étudiant de suivre des cours ou à un citoyen de s'informer, c'est vraiment du foutage de gueule.

Et pourtant.

Tu fais comment le distinguo entre l'étudiant qui doit suivre des cours en vidéoconférence et l'autre qui va télécharger en P2P - hormis de surveiller les flux et/ou de faire des whitelist/greylist/blacklist sur les usages.

On va peut-être arrêter de se voiler la face sur le fameux "la police est représentative de la population française" et se dire que la police amène ou abrite plus facilement des racistes et xénophobes en son sein.

A titre personnel, j'ai entendu plus facilement des petites réflexions racistes/xénophobes dans un commissariat de police en quelques minutes qu'en 20 ans dans des entreprises.

Et aussi que la police n'est pas forcément représentative de la population quand tu sais que la moyenne d'intention de vote extrême-droite est de 27% et que pour la police et militaire elle est de 51%, quasiment le double.

C'est pas glorieux…

Génial, encore plus simple ;)

Un petit patch pour ceux qui vont l'utiliser, il faut rajouter des "\" avant les "(" et ")" sinon le shell n'aime pas :-P

Si vous cherchez un logement et devez déposer des dossiers contenant vos fiches de paie ou autres documents sensibles, dans la mesure du possible essayez de marquer les documents.

Je fais toujours cela : A chaque fois qu'on me demande un document - même dans une agence de location qui fait la photocopie pour toi - je rajoute un filigrane ou des éléments ne pouvant pas être réutilisés. Je rajoute le nom de la société plusieurs sur le(s) document(s), je rature des éléments, je cache des numéros, je barre des passages. C'est pas le truc ultime, mais cela permet de faire abandonner les moins téméraires. (j'imaginais bien qu'un gars avec un photoshop pouvait se faire suer à corriger le document, mais j'avais pas pensé aux artefacts cachés façon stégano, c'est pas idiot, j'y penserai la prochaine fois)

Petite astuce technique, voici une commande imagemagick quick&dirty que j'utilise souvent:

convert \
    -density 150 \
  document_origine.pdf \
    -gravity center \
    -pointsize 8 \
    -fill 'rgba(100, 100, 100, 0.25)' \
    -draw "text 0,0 '$(cat filigrane.txt)'" \
    -fill blue \
    -compress zip \
  document_modifie.pdf

Attention, filigrane.txt doit contenir une tonne de texte.
En général, je rajoute un texte répété avec ce bout de code quick&dirty:

for ((i=0;i<100;i++)); do
   printf "${text}%.0s" {1..100} >> pdf-filigrane.txt
   echo >> pdf-filigrane.txt
done

Il y a probablement de meilleurs méthodes, mais j'ai pas voulu me taper toute la doc imagemagick pour trouver de meilleurs options, surtout pour une utilisation en quick&dirty.

A priori, il y a maintenant des avancées sur les remotes backups:
- https://borgbackup.readthedocs.io/en/stable/quickstart.html#automating-backups
- https://borgbackup.readthedocs.io/en/stable/quickstart.html#remote-repositories
A tester de nouveau, en espérant qu'il ne construise pas des fichiers locaux temporaires ou non

On avait utilisé Borg pour un projet, sur le papier, c'est très intéressant, en pratique, c'est autre chose. Son plus gros défaut (à l'époque, je ne sais pas si cela existe encore), c'est qu'il fallait le double d'espace disque pour créer l'archive chiffrée. Un véritable problème quand tu veux faire du backup sur des grosses données. La seule solution possible aurait été de monter le FS distant pour stocker directement l'archive avant l'upload. Après, peut-être que cela a changé avec le temps, en tout cas, à l'époque, Borg a été recalé à cause de ce souci.

Quand j'ai besoin de communiquer facilement avec des moins technophiles, c'est plus simple.

A choisir entre :

1. Envoyer un lien pour être en visioconférence en 5 secondes

Et entre :

1. Il faut aller sur tel site
2. Cliquer sur "Télécharger" (ou "Download")
3. Installer la bonne version par rapport à l'OS de la personne
4. Se créer un compte
5. Valider la création du compte (donc se connecter sur son mail)
6. Prendre l'ID de la salle ou l'ID de la personne
7. Être enfin conférence

Il y a pas photo sur le choix.

Et puis, entre installer un gros binaire dont on ne sait ce qu'il y a dedans (qui a dit Zoom…?) et passer par une URL d'un navigateur dont on peut faire une relative confiance, le choix est vite fait en fin de compte.

Je me demande ce que cette news vient faire sur LinuxFR.

Hormis d'utiliser Kdenlive, je vois rien qui nécessite de mettre en avant ce clip.

C'est mal produit, c'est mal tourné, c'est mal édité.

Si encore le clip avait été tourné avec la caméra opensource Apertus, pourquoi pas, mais là, il y a rien à sauver.
Et en plus, on s'attire tous les cul-bénits qui sont choqués d'avoir un clip dans un lieu de culte.

Si vous voulez mettre en avant des productions audiovisuelles qui utilisent pleinement de l'opensource, il y a en a plein qui font (beaucoup) mieux. Je suis sûr que LibreArt (LILA) saura faire ressortir des projets intéressants et qui méritent une véritable mise en avant.

En tant qu'athée, seul le côté technique m'a agressé.

Et travaillant dans l'image, la qualité du clip est d'un niveau amateur.

Je vois pas trop ce que ce contenu vient faire sur LinuxFR. Si encore le clip avait été tourné avec la caméra Apertus, mais même pas, on dirait que cela a été tourné avec un capteur de téléphone. Même avec un petit boitier, on arrive à de meilleurs images.

Je vais être moins enchanté que pas mal de gens ici.

Ce n'est pas une critique envers Poetry (que je n'ai pas encore utilisé), mais une critique envers l'écosystème Python.

Comme annoncé en début d'article, on a (eu) plusieurs systèmes, chacun avec ses propres mécanismes, ses propres fichiers de confs.

A la fin, si on essaye d'être assez "propre" dans son projet python, on se retrouve avec une tonne de fichiers à la racine, c'est ingérable.

Surtout que cela n'a aucun sens: setup.py n'indique rien de précis (setup.py pourrait-être un fichier de setup du projet en lui-même et non le fichier de 'conf' pour un tool python), cela pourrait être tout et n'importe quoi, idem avec requirements.txt.

Il faudra un jour (peut-être?) avoir un consensus, sinon on va se retrouver avec encore plusieurs outils concurrents et encore plus de fichiers de configurations ou autres bordels.

Déjà, il aurait peut-être été pertinent de mettre tout ce bordel dans un répertoire (.python ?), d'avoir un seul système de packaging (easy_install, pip, pipenv, quoi d'autres la prochaine fois ? python-composer ? apt-python ? npythonm ?).

Ainsi qu'avoir des fichiers de configurations un peu compatibles entre eux (j'évoque ceux qui ont des syntaxes équivalentes mais chacun à son nom de fichier personnalisé sans prendre en compte l'existant, par exemple, alors que son but officieux est de remplacer l'ancien)

Sauf erreur de ma part, mais le commentaire de Ruminant était au 2nd degrés :)

Pour compléter: Le conflit est apparu avec la création des chaînes satellites du groupe AB: TF1 voyait d'un mauvais oeil de financer une grosse partie du chiffre d'affaire d'un potentiel futur concurrent. Il faut dire que AB était le plus gros producteur sur la chaîne dans les années 90, c'était parfois 8h d'antenne de disponible pour le groupe sur la première chaîne d'Europe.

Création AB Sat: 23 décembre 1996
Fin du Club Dorothée: 30 août 1997

Autant dire que TF1 a laissé la fin de l'année télévisuelle à AB1 (les renouvellements de grille s'effectuant en septembre à la reprise et en janvier après les fêtes si cela s'avère nécessaire, exemple un programme avec de mauvaise audience ou mal produit)

DLFP, c'était le lieu de joutes incessantes:
* les libertariens et les conservateurs s'étripaient avec les socialistes au coté des anarcho-collectivistes.
* L'Europe, le TCE, tous sujets afférents à la politique, surtout à l'approche des échéances électorales, ne demandaient qu'à jaillir des moindres entre-filets qui pouvaient lui servir de prétexte au travers des commentaires.
* La guerre des DVCS n'attendait qu'un feu de brindille pour se propager comme un incendie de forêt.
* Microsoft, tel l'Empire s'abritait derrière quelques chevaliers noirs en face d'une horde de Jedi, tandis qu'on reprenait en choeur: "Google isn't Evil"
* Le controversé milliardaire qui maintenait son jouet sous perfusion faisait la quasi-unanimité contre lui alors qu'il ne suscite aucune réaction maintenant qu'il "pivote"

P'tit jeune !

Les véritables joutes étaient sur l'avenir du système d'exploitation le plus fameux du siècle, MultideskOS et les capacités techniques explosives du nouveau codec révolutionnaire i2BP.

Ça, c'était de la joute !

hashtagvieuxcon

Il devait avoir probablement son gilet jaune à l'envers: https://www.ladepeche.fr/article/2018/10/28/2896676-landes-gascogne-blesse-apres-coups-feu-entre-chasseurs-garde-chasse.html

Sacrés déconneurs ces chasseurs, un peu de chevrotines dans les fesses de Gérard, et hop, tout le monde gueule. Si on peut plus déconner avec du plombs. #onpeutplusriendire

Il n'y a que la petite équipe de Haiku pour regarder encore 20 ans en arrière et croire cue c'est là que se trouve le futur ;)

Je trouve cette phrase quand même assez méprisante pour les membres de l'équipe de Haiku :-\

Je suis sûr qu'on pourrait trouver ce même genre de phrase au début des années 90s venant de Microsoftien qui regardait Linux, comme un ersatz d'Unix, avec ses 20-30 ans de carrière "et croire que c'est là que se trouve le futur".

Une équipe qui arrive à créer un système d'exploitation entier mérite quand même un peu plus de considération.

La citation est quand même un peu sortie du contexte: Elle provient de Cédric Villani qui va émettre plusieurs suppositions en décrivant le cassage du code et la présence de Turing dans l'histoire.

"Il est tout à fait plausible que sans Alan Turing, la guerre aurait durée nettement plus que ce qu'elle a duré; On peut aller jusqu'à deux années d'écarts de plus, parce qu'il n'aurait pas été possible de repérer les sous-marins nazis sans le décryptage des codes; il aurait donc pas été possible d'organiser la traversée de l'atlantique dans le cadre du débarquement en Normandie, il aurait fallu peut-être attendre deux années de plus avant que les choses soient aux points; Peut-être même qu'il aurait fallu que les américains aient recours à l'arme atomique en Europe, enfin.. pour le coup, Alan Turing est l'une des très rare personne dont on peut dire si cela se trouve, s'il n'avait pas été là, l'histoire du 20ème aurait été différente".

C'est donc plutôt des supputations d'un mathématicien avec sa vision de 2018, une méthode de pensée, qu'une affirmation via une étude historique et des éléments concrets (déclassifications de documents) dans les possibles décisions américaines.

Correction:
- - hubiC tire sa révérence
++ hubiC n'accepte plus de nouvelles inscriptions

On morcelle le "web" avec les "mobapps" et on morcelle le matériel avec une foultitude de "normes" ARM peu compatibles entre elles…

On morcelle par distribution Linux: A ce niveau, on ne sait plus ce qui est bon: la multitude de choix ou d'avoir un seul et même choix.

Sauf erreur de ma part (possible), les raccordements sont refilés à des sous-traitants et non à des techniciens Free.

capable de relancer la vidéo là où vous avez arrêté

J'ai un doute, mais je croyais que VLC le faisait déjà non ?

Je suis assez dubitatif sur le projet.

J'ai regardé rapidement le premier film, j'ai regardé les conditions de financement et de production. Pour faire simple, le budget de 6K$ me semblait extrêmement bas pour avoir de la qualité, notamment pour un "long métrage". Long métrage qui n'en est pas un, le film dure moins de 60 minutes, un film devient long-métrage en dépassant les 60 minutes. En dessous de cela, c'est un court-métrage. Au niveau de l'aspect artistique, c'est malheureusement très très amateur: des cadrages relativement pas bons, la caméra n'est pas stabilisée, des erreurs dans le montage (plans de coupe mal gérés, mauvais cut, …). Ils ont tourné en GoPro à priori et cela se voit assez rapidement: au niveau des objectifs et du rendu, c'est assez basique (une seule focale sur une bonne partie des plans que j'ai pu voir et l'étalonnage semble avoir été effectué rapidement). Il aurait été préférable pour Matt et toute son équipe de réduire la voilure: de faire un court-métrage en dessous des 10 minutes. Le budget s'y aurait mieux prêté (en espérant que son équipe technique bosse gratuitement…) et la possibilité de louer une véritable caméra (RED, Sony, ARRI, Pana) et quelques optiques de bases.

Quand je lis "Il s'agit d'un financement flexible de 11000$ - le double de la campagne précédente, vu qu'il y a deux films", cela me perturbe un peu. Cela veut dire qu'il y aura moins de financement que pour le premier film… qui n'avait déjà pas beaucoup de budget, pour un résultat qu'on connait. A titre de comparaison, le Projet Blair Witch, c'était entre 50.000$ et 60.000$ de budget. Le documentaire SuperSizeMe (tourné avec une caméra basique, sans ou peu d'équipe technique, aucun besoin en logistique et peu en régie) est déjà autour des 65.000$. Soyons sympa, citons Paranormal Activity avec ses tous petits 15.000$, mais c'était un huis-clos avec peu d'acteurs, une équipe technique très très réduite, des lights simples, peu de changements caméra (et quand cela est effectué, ils utilisent une caméra au poing, plus facile à monter et étalonner vu que cela ressemble plus à du "making-of"), et une grosse partie du coût de post-production assurée par la production. Comparons maintenant le plan initial du projet: 11K€ pour deux long-métrages :-/

J'espère malgré tout que Matt et toute son équipe arrivent à leur but.