En quoi ça explique qu'il ait viré le code de GitHub?
NON, ce n'est pas un process de réécriture classique, quand tu réécris tu ne supprimes pas le vieux code de GitHub (au pire de le met en "unsupported, at your own risk")
On n'a vraiment pas la même notion de "réécriture classique".
Jusqu'à preuve du contraire, il fait ce qu'il veut de ses sources et de la manière dont il veut laisser sa propre copie de travail à disposition.
Tu as ta méthode de travail, d'autres ont différentes méthodes de travail, cela ne fait de ta méthode, meilleure que les autres.
Pour avoir croisé Nadim il y a quelques mois et de nous avoir parlé de Cryptocat, c'est juste un process de réécriture classique qui commençait à germer dans sa tête. A mon avis, il a juste eu enfin un peu de temps pour s'y remettre là. Faut arrêter de flipper, de voir du complot ou de lire les articles de Numerama (d'ailleurs, Guillaume se fait sauvagement shampoigné - encore une fois - sur twitter par l'auteur de CryptoCat)
Si toi tu peux vérifier ton vote, le gars qui a acheté ta voix aussi (tu lui filera ton uuid généré).
Tu es le seul à proposer un contre exemple intéressant sur un cas particulier.
Encore faut-il donner le bon UUID (ou le conserver).
Sachant que l'UUID est généré en discrétion juste après son vote, seul le votant connait son propre UUID.
Sinon pour avoir un logement HLM, il faudra laisser trainer, par inadvertance bien entendu, ton uuid afin que la commission d'attribution puisse évaluer correctement ton cas.
L'autre truc qui est marrant c'est dans x années lorsqu'un petit dictateur arrivera au pouvoir, les force de l'ordre pourront se servir des uuid saisis chez les particulier (personne ne va retenir un identifiant à 15 caractères, il vont le noter quelque part) pour aggraver son cas par un délit d'opinion dans le cas où il aurait 'mal' voté.
Mais surtout toute ces débauche de technologie, ne répond pas au pourquoi? Qu'est ce qui ne va pas dans notre système actuel?
Le point qu'on pourrait améliorer facilement c'est l'émargement, avoir une liste nationale, et voter dans n'importe quel bureau.
Par contre, là, tu tombes dans le même argumentaire qu'au dessus: Qui te dit qu'il faut garder l'UUID après le vote final ? Personne ne conserve ses bulletins non-votants après un vote à ce que je sache.
L'UUID ne sert que vérificateur personnel pendant le dépouillement. Une personne peut très bien le détruire juste après son vote ou alors ne conserver aucune trace s'il ne souhaite pas vérifier personnellement lors du dépouillement si son vote a été respecté.
Tu m'as l'air un peu tendu pour un simple exemple.
Qui te dit de garder ton UUID ?
Tu le conserves le temps du dépouillement puis après tu le détruis. A priori, quand tu fais un vote, on te donne des bulletins pour l'ensemble des participants. Vu que tu les conserves un minimum de temps (entre ton départ vers le lieu du vote et un laps de temps après le vote), quelqu'un peut facilement retrouver la correspondance "bulletin manquant = résultat de ton vote". A ce que je sache, personne ne conserve ces éléments après le vote final.
Je ne vois pas en quoi c'est plus falsifiable que le bourrage des urnes et la vérification actuelle. Pour rappel, la vérification n'est effective par personne et encore moins par le votant. Tu ne peux même pas déterminer lors du dépouillement si ton vote n'a pas été falsifié au cours du temps.
Une interrogation comme cela, et si à chaque vote, le système génère un UUID avec le résultat du vote.
L'ensemble des votes est publique avec un couple "UUID = RESULTAT"
Ainsi, chacun peut vérifier si son vote est bien correcte en gardant une anonymisation de bout-en-bout.
Désolé si je donne l'article via web-archive, j'ai perdu mes articles suite à un upgrade foireux du gestionnaire de news (un jour je penserais à le remettre)
donc projettent avec un couple vidéoproj / ordi portable donc dans ce cas là il est en effet préférable d'avoir un format plus léger…
Pourquoi ne pas projeter un DCP depuis un ordinateur portable vers un vidéoprojecteur ? (c'est ce que je fais). C'est techniquement faisable. Qu'est ce qui vous a bloqué à ce niveau ?
C'est un peu juste ;-)
Il y a des valeurs minimales en profondeur, hauteur, largeur, … d'un écran cinéma (recommandations techniques de la CST) (dans mes souvenirs, il faut 3, 40m minimum de hauteur)
tu peux tout à fait avoir des images 8 bits sombres avec des superbes dégradés
Oui, oui, tu peux en avoir. J'ai une caméra Sony A7S qui génère des vidéos à 8-bit et le dégradé n'est pas déconnant (sans être parfait sur des steps plus hautes). Sur un tournage d'un long-métrage, dans des conditions difficiles, au lieu d'utiliser une ARRI, nous avons utilisé une A7S en sortie 4K, les dégradés sont superbes sur un grand écran de salon. On va dire que tu auras moins de problème d'effet escalier en 10-bit qu'en 8-bit sur un petit écran que sur un écran cinéma. (@frachop m'informe qu'on peut utiliser du dithering pour compenser ce genre de problème)
Légal, on va dire oui, tant que tu te fais pas prendre en abusant…
En fait, la CST (pendant technique du CNC, si je peux résumer rapidement) est le vérificateur des aspects techniques pour - comme tu l'indiques - avoir le droit de s'appeler "Cinéma". La CST ne peut se déplacer chaque jour dans les 5600 salles en France.
Il existe beaucoup de petites astuces. Exemple: les sièges ne peuvent être placés à certains endroits de la salle (trop proche de l'écran, trop sur les côtés, …). Lors d'un passage de la CST, les sièges "litigieux" ne sont pas installés. La CST effectue son contrôle. Elle donne une validation. Juste après, l'exploitant rajoute les sièges "litigieux". C'est une technique assez connu dans le milieu. Il en existe plusieurs autres.
Après, il ne faut pas croire qu'ils sont tous pourris, c'est juste que parfois, certains abusent. Comme dans tous les métiers :)
Le pire, c'est que c'est souvent trop sombre. Et lors des forts contrastes (genre gardien de la galaxie, lors des scènes avec le gros méchant sur son siège), il y a des "ghosts" partout.
En fait, ce n'est pas un problème de cinéma numérique, c'est un problème de "lampe, de coût et de rentabilité pour l'exploitant".
Je m'explique: Pour un film 2D, tu as ta lampe qui en utilisation normale à 100% (intensité). Les exploitants, pour économiser en durée, baissent son intensité (80%). Cela permet de gagner en heure avant de devoir la changer. En 3D, à cause des lunettes 3D (passives ou actives), tu as un léger filtre de lumière (effet "lunettes de soleil"), il y a donc moins de particules lumineuses passant à travers les lunettes 3D et arrivant dans l'oeil. Les lampes 3D doivent donc être au minimum à 100% voire 110%-120% lors d'une projection 3D pour compenser. Les exploitants ne le font en général pas du tout (quand ce n'est pas le projecteur qui n'a pas été calibré correctement depuis 1 an, ce qui fait que ton parallaxe est complètement décalé au bout du compte).
Je pense que ce défaut disparaîtra avec l'avènement des projecteurs lasers où on passera d'une durée de vie lampe à 1 an grand max - en toussotant et avec le vent dans le dos - à plus de 7 ans sans sourciller.
Le terme exact est "solarisation" ? En gros, tu as des dégradés sombres et l'image te fait une rupture qui n'existe pas, et au lieu d'un joli dégradé, tu as des formes bizarres mouvantes sur les murs ou autour des personnages. Le pire, c'est une scène de nuit, dans le brouillard.
Je me doutais que c'était ce défaut que tu avais remarqué.
Alors effectivement, c'est parce que le bit-depth est trop bas (8-bit ou 10-bit). Ce qui fait que tu n'as que 256 ou 1024 de "différences colorimétriques" entre deux couleurs. Ce qui fait que pour passer du noir total au blanc total, tu auras soit un dégradé assez moche au lieu d'un beau dégradé.
D'après mes souvenirs, c'est soit le 4K, soit les 60 fps mais pas les 2 sur les projecteurs actuels. J'imagine qu'il y a une limite de bande passante.
Tu as raison sur un point, il existe une limitation de 250Mbits/sec dans les spécifications DCI mais qui va être réhaussé pour les nouvelles demandes (500 Mbits/sec, voire plus).
Je ne parlerais pas des conventions de nommages, puisque ce ne sont que des conventions mais qui suffisent pour être refusées par le serveur.
Effectivement, il n'y a pas de convention de nommage officielle DCI, hormis le connu "DCI Naming Convention" (http://digitalcinemanamingconvention.com) qui est une initiative "d'habitude" des laboratoires et opérateurs appliqué au fur-et-à-mesure des années.
Cette convention n'existe que pour la lecture humaine et la compréhension rapide dans les échanges entre laboratoire et projectionniste, les encodeurs et lecteurs acceptent tous les types de nommage (j'ai déjà fait des DCP avec des noms vraiment très bizarres). Ce nommage est apparu rapidement car chaque laboratoire avait sa propre nomenclature et le projectionniste avait du mal à savoir la différence entre le DCP "SUPERMAN" (peut-être la VO) et le DCP "SUPERMAN" (peut-être la VF). Les players peuvent récupérer ces informations dans les metadatas et les afficher sans problèmes, mais certains n'affichent pas toutes ces informations. Ils prennent par défaut les metadatas "AnnotationText" et/ou "ContentTitleText" pour afficher le titre :
Avoir une qualité équivalente à une télé ou presque, cela fait bizarre (sauf scène sombre, je n'ai jamais compris pourquoi h264 était si mauvais ).
Révélation de l'année: Les bobines 35mm shootés pour la diffusion en salle depuis 15 ans étaient au format 2K :-)
Pour les scènes sombres en H264, c'est peut-être parce que le bit-depth est à 10bit (après, je ne sais pas ce que tu entends par "mauvais dans les scènes sombres"). Là, il faut voir avec sieur @frachop, il s'y connaît plus que moi :)
En plus, on est pas prêt d'avoir du 4k/60 fps non plus
Il existe bien des projections en 4K. Et le 60 FPS est bien utilisé en salle. Ou alors je n'ai pas compris ton commentaire :(
Je pense surtout qu'ils n'ont pas accès à des spécialistes comme toi. Il faut voir aussi qu'il n'existe pas encore de lecteur libre de DCP. VLC ramouille trop (ou alors, il faut une machine de guerre).
En fait, le souci du player DCP via VLC est qu'il n'est pas possible via l'interface de définir la "tile" de définition. Donc par défaut, il va prendre la définition maximale, d'où le "il faut une machine de guerre" :). Quand on utilise les librairies et on fait cela en ligne de commande, on peut lire un DCP sur un portable classique.
Sans transition, je le disais encore y'a 10 minutes à @frachop (on travaille ensemble sur le DCI depuis ses débuts), si certaines personnes avaient arrêté de vouloir réinventer la roue pendant des années en proposant "un autre format", prendre à bras-le-corps les spécifications DCI et implémenter un player DCP libre, nous ne serions pas en 2015 avec un prototype de player DCP opensource mais plusieurs parfaitement fonctionnelles. (Il n'a fallu que 1-2 mois à @frachop pour faire un player DCP compatible Linux/MacOS)
A l'époque déjà (2007-2008), on me rétorquait que les logiciels libres ne pouvaient gérer du DCP, j'avais alors pondu un encodeur DCP à base que d'opensource ( https://www.quickdcp.com ) et dans le pipeline, un petit player (manque de temps). Donc oui, il est parfaitement possible de pouvoir gérer des DCP via des briques opensources.
Notez que dans les specs, déjà à l'époque, il est indiqué l'utilisation d'openssl, linux, vi, audacity, …
J'ai l'impression que tu n'as jamais lu les spécifications DCI/SMPTE pour dire cela :)
Le DCP n'est absolument pas une usine à gaz, tu as des MXF : Audio et Image (en général seulement 2), 2 XML (CPL, PKL) qui définissent les metadatas. Et - parfois - des informations sous-titres (XML+PNG, …). En gros, tu as 4 fichiers dans un répertoire.
une norme changeante
"La norme changeante" n'a pas changé depuis 2007. Mes premiers DCP de 2007 sont toujours lisibles.
Je ne parle même pas des incompatibilités nombreuses des couples projos/serveurs.
Jamais entendu parlé. Et je travaille dessus depuis les débuts des spécifications DCI pourtant.
J'ai entendu dire que certains se passaient du DCP en lisant directement le MXF. Cela fait un conteneur de trop en moins.
C'est le principe d'un conteneur MXF, tu peux le lire indépendamment si tu le souhaites.
Le DCP a fait partie du coeur de notre problématique sur les formats audiovisuels qui tendent à limiter le cinéma aux acteurs ayant les moyens de les utiliser.
"aux acteurs ayant les moyens de les utiliser".
On parle bien d'un DCP avec un format MXF, XML, PNG, JPEG2000 lisible par tous avec des logiciels libres ?
Cela me fait penser aux différentes discussions que j'ai pu avoir ici où des gens pensent vouloir révolution le cinéma numérique en proposant un "nouveau format top-moumoute" mais sans aucune concertation avec des professionnels qui bossent véritablement dessus (et finalement, les "révolutionnaires" font des choix erronés car ils ne comprennent pas les tenants et aboutissants techniques)
Quand je lis les specs dans le PDF, c'est - pour être poli - étrange: projeter dans une véritable salle et sur un écran cinéma lambda, le moindre cinéaste va vous crier dessus. Quand aux rajouts (référence, synopsis.pdf, etc…) rien ne vous empêche de l'intégrer dans un DCP (dans les miens, je rajoutais l'affiche et des annotations).
Je ne comprends pourquoi réinventer la roue et faire votre propre "standard" qui est moins bon.
Je viens de sortir d'une course "rapide-de-fin-de-journée-de-travail" (on connaît tous cela).
En caisse après le passage : Caissière: "Ah désolé, mais vous avez des produits non-consommables." Moi: "Ok, dans 'un pain, un steak-haché et un dessert', lequel n'est pas consommable ?" Caissière: "Désolé, je ne fais qu'appliquer les règles…"
Les règles… j'adore quand on se cache derrière des soit-disantes règles pour accepter les plus belles conneries illogiques ou immorales…
Une question qui me vient, est-ce que FLIF gère les tiles multi-résolutions comme le JPEG2000 ?
Je crois en reconnaître les spécifications sous l'appellation "Responsive images" mais pas sûr.
Pour suivre grsec depuis très longtemps, le plus gros problème - à mon sens - est le fait que Brad Spengler a un rapport avec les développeurs du kernel assez conflictuel. A chaque release, et même depuis les premières, il ne se privait pas pour envoyer des petits tacles ou de se foutre de la gueule de la sécurité du kernel Linux (même encore maintenant, on voit, de temps à autres, apparaître des tweets assez sarcastiques là-dessus). A mon avis, cela n'aide pas. Malheureusement :-\
[^] # Re: Dont Keep Calm & Don't Hold On !
Posté par Prae . En réponse au journal Cryptocat a disparu. Évalué à -1.
Jusqu'à preuve du contraire, il fait ce qu'il veut de ses sources et de la manière dont il veut laisser sa propre copie de travail à disposition.
Tu as ta méthode de travail, d'autres ont différentes méthodes de travail, cela ne fait de ta méthode, meilleure que les autres.
# Keep Calm & Hold On !
Posté par Prae . En réponse au journal Cryptocat a disparu. Évalué à 5.
Pour avoir croisé Nadim il y a quelques mois et de nous avoir parlé de Cryptocat, c'est juste un process de réécriture classique qui commençait à germer dans sa tête. A mon avis, il a juste eu enfin un peu de temps pour s'y remettre là. Faut arrêter de flipper, de voir du complot ou de lire les articles de Numerama (d'ailleurs, Guillaume se fait sauvagement shampoigné - encore une fois - sur twitter par l'auteur de CryptoCat)
[^] # Re: 1946 ou 2016 année poisseuse?
Posté par Prae . En réponse au journal yippee ki-yay. Évalué à 1.
Maaaiis non. C'est juste que le président a toujours le bras long dans le milieu.
[^] # Re: j'ai du mal à comprendre
Posté par Prae . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à -3. Dernière modification le 21 novembre 2015 à 15:34.
Tu es le seul à proposer un contre exemple intéressant sur un cas particulier.
Encore faut-il donner le bon UUID (ou le conserver).
Sachant que l'UUID est généré en discrétion juste après son vote, seul le votant connait son propre UUID.
Par contre, là, tu tombes dans le même argumentaire qu'au dessus: Qui te dit qu'il faut garder l'UUID après le vote final ? Personne ne conserve ses bulletins non-votants après un vote à ce que je sache.
L'UUID ne sert que vérificateur personnel pendant le dépouillement. Une personne peut très bien le détruire juste après son vote ou alors ne conserver aucune trace s'il ne souhaite pas vérifier personnellement lors du dépouillement si son vote a été respecté.
[^] # Re: j'ai du mal à comprendre
Posté par Prae . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à -3.
Tu m'as l'air un peu tendu pour un simple exemple.
Qui te dit de garder ton UUID ?
Tu le conserves le temps du dépouillement puis après tu le détruis. A priori, quand tu fais un vote, on te donne des bulletins pour l'ensemble des participants. Vu que tu les conserves un minimum de temps (entre ton départ vers le lieu du vote et un laps de temps après le vote), quelqu'un peut facilement retrouver la correspondance "bulletin manquant = résultat de ton vote". A ce que je sache, personne ne conserve ces éléments après le vote final.
Ton exemple est donc erroné.
[^] # Re: j'ai du mal à comprendre
Posté par Prae . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à -2.
Je ne vois pas en quoi c'est plus falsifiable que le bourrage des urnes et la vérification actuelle. Pour rappel, la vérification n'est effective par personne et encore moins par le votant. Tu ne peux même pas déterminer lors du dépouillement si ton vote n'a pas été falsifié au cours du temps.
[^] # Re: j'ai du mal à comprendre
Posté par Prae . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à 0.
Une interrogation comme cela, et si à chaque vote, le système génère un UUID avec le résultat du vote.
L'ensemble des votes est publique avec un couple "UUID = RESULTAT"
Ainsi, chacun peut vérifier si son vote est bien correcte en gardant une anonymisation de bout-en-bout.
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Tu vas rire, mais je viens de me souvenir ce matin que j'avais fait une news il y a fort longtemps : lire un film cinéma numérique avec des logiciels open source.
Désolé si je donne l'article via web-archive, j'ai perdu mes articles suite à un upgrade foireux du gestionnaire de news (un jour je penserais à le remettre)
Les différents tests ici:
https://ffmpeg.org/pipermail/ffmpeg-devel/2013-April/143022.html
En attendant une news plus conséquence sur le sujet… :P
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Pourquoi ne pas projeter un DCP depuis un ordinateur portable vers un vidéoprojecteur ? (c'est ce que je fais). C'est techniquement faisable. Qu'est ce qui vous a bloqué à ce niveau ?
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
C'est un peu juste ;-)
Il y a des valeurs minimales en profondeur, hauteur, largeur, … d'un écran cinéma (recommandations techniques de la CST) (dans mes souvenirs, il faut 3, 40m minimum de hauteur)
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Oui, oui, tu peux en avoir. J'ai une caméra Sony A7S qui génère des vidéos à 8-bit et le dégradé n'est pas déconnant (sans être parfait sur des steps plus hautes). Sur un tournage d'un long-métrage, dans des conditions difficiles, au lieu d'utiliser une ARRI, nous avons utilisé une A7S en sortie 4K, les dégradés sont superbes sur un grand écran de salon. On va dire que tu auras moins de problème d'effet escalier en 10-bit qu'en 8-bit sur un petit écran que sur un écran cinéma. (@frachop m'informe qu'on peut utiliser du dithering pour compenser ce genre de problème)
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Légal, on va dire oui, tant que tu te fais pas prendre en abusant…
En fait, la CST (pendant technique du CNC, si je peux résumer rapidement) est le vérificateur des aspects techniques pour - comme tu l'indiques - avoir le droit de s'appeler "Cinéma". La CST ne peut se déplacer chaque jour dans les 5600 salles en France.
Il existe beaucoup de petites astuces. Exemple: les sièges ne peuvent être placés à certains endroits de la salle (trop proche de l'écran, trop sur les côtés, …). Lors d'un passage de la CST, les sièges "litigieux" ne sont pas installés. La CST effectue son contrôle. Elle donne une validation. Juste après, l'exploitant rajoute les sièges "litigieux". C'est une technique assez connu dans le milieu. Il en existe plusieurs autres.
Après, il ne faut pas croire qu'ils sont tous pourris, c'est juste que parfois, certains abusent. Comme dans tous les métiers :)
Pour en savoir plus sur les normes de la CST, le livre d'Alain Besse sur la conception, réalisation et exploitation d'une salle de cinéma
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
En fait, ce n'est pas un problème de cinéma numérique, c'est un problème de "lampe, de coût et de rentabilité pour l'exploitant".
Je m'explique: Pour un film 2D, tu as ta lampe qui en utilisation normale à 100% (intensité). Les exploitants, pour économiser en durée, baissent son intensité (80%). Cela permet de gagner en heure avant de devoir la changer. En 3D, à cause des lunettes 3D (passives ou actives), tu as un léger filtre de lumière (effet "lunettes de soleil"), il y a donc moins de particules lumineuses passant à travers les lunettes 3D et arrivant dans l'oeil. Les lampes 3D doivent donc être au minimum à 100% voire 110%-120% lors d'une projection 3D pour compenser. Les exploitants ne le font en général pas du tout (quand ce n'est pas le projecteur qui n'a pas été calibré correctement depuis 1 an, ce qui fait que ton parallaxe est complètement décalé au bout du compte).
Je pense que ce défaut disparaîtra avec l'avènement des projecteurs lasers où on passera d'une durée de vie lampe à 1 an grand max - en toussotant et avec le vent dans le dos - à plus de 7 ans sans sourciller.
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Je me doutais que c'était ce défaut que tu avais remarqué.
Alors effectivement, c'est parce que le bit-depth est trop bas (8-bit ou 10-bit). Ce qui fait que tu n'as que 256 ou 1024 de "différences colorimétriques" entre deux couleurs. Ce qui fait que pour passer du noir total au blanc total, tu auras soit un dégradé assez moche au lieu d'un beau dégradé.
Les projecteurs peuvent faire les deux (voire les 3: 4K, 3D et HFR): Projecteur Barco Galaxy 4K-HFR-3D
Tu as raison sur un point, il existe une limitation de 250Mbits/sec dans les spécifications DCI mais qui va être réhaussé pour les nouvelles demandes (500 Mbits/sec, voire plus).
[^] # Re: Le DCP est mort, vive le MXF ?
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 3.
Effectivement, il n'y a pas de convention de nommage officielle DCI, hormis le connu "DCI Naming Convention" (http://digitalcinemanamingconvention.com) qui est une initiative "d'habitude" des laboratoires et opérateurs appliqué au fur-et-à-mesure des années.
Cette convention n'existe que pour la lecture humaine et la compréhension rapide dans les échanges entre laboratoire et projectionniste, les encodeurs et lecteurs acceptent tous les types de nommage (j'ai déjà fait des DCP avec des noms vraiment très bizarres). Ce nommage est apparu rapidement car chaque laboratoire avait sa propre nomenclature et le projectionniste avait du mal à savoir la différence entre le DCP "SUPERMAN" (peut-être la VO) et le DCP "SUPERMAN" (peut-être la VF). Les players peuvent récupérer ces informations dans les metadatas et les afficher sans problèmes, mais certains n'affichent pas toutes ces informations. Ils prennent par défaut les metadatas "AnnotationText" et/ou "ContentTitleText" pour afficher le titre :
Si le lecteur a refusé, c'est que cela venait d'autre chose. Que te disait le lecteur en erreur ? (type de modèle et année ?)
[^] # Re: dcp ?
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 3.
J'y pense, j'y pense… ;-)
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 4.
Révélation de l'année: Les bobines 35mm shootés pour la diffusion en salle depuis 15 ans étaient au format 2K :-)
Pour les scènes sombres en H264, c'est peut-être parce que le bit-depth est à 10bit (après, je ne sais pas ce que tu entends par "mauvais dans les scènes sombres"). Là, il faut voir avec sieur @frachop, il s'y connaît plus que moi :)
Il existe bien des projections en 4K. Et le 60 FPS est bien utilisé en salle. Ou alors je n'ai pas compris ton commentaire :(
[^] # Re: dcp ?
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
En fait, le souci du player DCP via VLC est qu'il n'est pas possible via l'interface de définir la "tile" de définition. Donc par défaut, il va prendre la définition maximale, d'où le "il faut une machine de guerre" :). Quand on utilise les librairies et on fait cela en ligne de commande, on peut lire un DCP sur un portable classique.
Sans transition, je le disais encore y'a 10 minutes à @frachop (on travaille ensemble sur le DCI depuis ses débuts), si certaines personnes avaient arrêté de vouloir réinventer la roue pendant des années en proposant "un autre format", prendre à bras-le-corps les spécifications DCI et implémenter un player DCP libre, nous ne serions pas en 2015 avec un prototype de player DCP opensource mais plusieurs parfaitement fonctionnelles. (Il n'a fallu que 1-2 mois à @frachop pour faire un player DCP compatible Linux/MacOS)
A l'époque déjà (2007-2008), on me rétorquait que les logiciels libres ne pouvaient gérer du DCP, j'avais alors pondu un encodeur DCP à base que d'opensource ( https://www.quickdcp.com ) et dans le pipeline, un petit player (manque de temps). Donc oui, il est parfaitement possible de pouvoir gérer des DCP via des briques opensources.
Notez que dans les specs, déjà à l'époque, il est indiqué l'utilisation d'openssl, linux, vi, audacity, …
[^] # Re: Pourquoi faire simple ? En effet !
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
Pourquoi snif ?
[^] # Re: Le DCP est mort, vive le MXF ?
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 3.
J'ai l'impression que tu n'as jamais lu les spécifications DCI/SMPTE pour dire cela :)
Le DCP n'est absolument pas une usine à gaz, tu as des MXF : Audio et Image (en général seulement 2), 2 XML (CPL, PKL) qui définissent les metadatas. Et - parfois - des informations sous-titres (XML+PNG, …). En gros, tu as 4 fichiers dans un répertoire.
"La norme changeante" n'a pas changé depuis 2007. Mes premiers DCP de 2007 sont toujours lisibles.
Jamais entendu parlé. Et je travaille dessus depuis les débuts des spécifications DCI pourtant.
C'est le principe d'un conteneur MXF, tu peux le lire indépendamment si tu le souhaites.
[^] # Re: dcp ?
Posté par Prae . En réponse au journal Cinéma Libre 3 ans après.... Évalué à 2.
"aux acteurs ayant les moyens de les utiliser".
On parle bien d'un DCP avec un format MXF, XML, PNG, JPEG2000 lisible par tous avec des logiciels libres ?
Cela me fait penser aux différentes discussions que j'ai pu avoir ici où des gens pensent vouloir révolution le cinéma numérique en proposant un "nouveau format top-moumoute" mais sans aucune concertation avec des professionnels qui bossent véritablement dessus (et finalement, les "révolutionnaires" font des choix erronés car ils ne comprennent pas les tenants et aboutissants techniques)
Quand je lis les specs dans le PDF, c'est - pour être poli - étrange: projeter dans une véritable salle et sur un écran cinéma lambda, le moindre cinéaste va vous crier dessus. Quand aux rajouts (référence, synopsis.pdf, etc…) rien ne vous empêche de l'intégrer dans un DCP (dans les miens, je rajoutais l'affiche et des annotations).
Je ne comprends pourquoi réinventer la roue et faire votre propre "standard" qui est moins bon.
[^] # Re: Mon expérience
Posté par Prae . En réponse au journal L'absurdité des tickets restau. Évalué à 6.
"J'y peux rien, c'est mon supérieur qui m'a demandé de mettre ces gens dans ces wagons". (point godwin, je sais)
[^] # Re: Mon expérience
Posté par Prae . En réponse au journal L'absurdité des tickets restau. Évalué à 6.
C'est drôle, je me retrouve dans ton commentaire.
Je viens de sortir d'une course "rapide-de-fin-de-journée-de-travail" (on connaît tous cela).
En caisse après le passage :
Caissière: "Ah désolé, mais vous avez des produits non-consommables."
Moi: "Ok, dans 'un pain, un steak-haché et un dessert', lequel n'est pas consommable ?"
Caissière: "Désolé, je ne fais qu'appliquer les règles…"
Les règles… j'adore quand on se cache derrière des soit-disantes règles pour accepter les plus belles conneries illogiques ou immorales…
# FLIF Tiles
Posté par Prae . En réponse à la dépêche FLIF, un format d’image sans perte, intelligent et « performant », sous licence GPL. Évalué à 4.
Intéressant.
Une question qui me vient, est-ce que FLIF gère les tiles multi-résolutions comme le JPEG2000 ?
Je crois en reconnaître les spécifications sous l'appellation "Responsive images" mais pas sûr.
[^] # Re: Inclusion
Posté par Prae . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 2.
Pour suivre grsec depuis très longtemps, le plus gros problème - à mon sens - est le fait que Brad Spengler a un rapport avec les développeurs du kernel assez conflictuel. A chaque release, et même depuis les premières, il ne se privait pas pour envoyer des petits tacles ou de se foutre de la gueule de la sécurité du kernel Linux (même encore maintenant, on voit, de temps à autres, apparaître des tweets assez sarcastiques là-dessus). A mon avis, cela n'aide pas. Malheureusement :-\