Bonjour,
oui il est tout à fait possible de récupérer la vidéo produite en fichier MP4.
On peut aussi décider de publier la vidéo sur le serveur de stream et partager une URL de à la youtube like(ex: https://dev.polymny.studio/v/Y3lJZ/ )
Merci pour ce retour fort sympa sur l'application.
Une petite fonctionnalité qui me semblerait pas inintéressante et que j'imagine assez simple à implémenter serait d'avoir la possibilité de simplement utiliser l'image et l'enregistrement sur toute la surface de l'écran sans diapos.
Trais bonne idée ! On va le rajouter. Faut jus que l'on fasse quelques tests et correctifs pour gérer les webcams en HD . Et si c'est du SD ne pas trop agrandir l'image pour éviter la pixelisation.
Comme il est parfois difficile de commencer à parler directement en appuyant sur la barre d'espace, un petit compte à rebours pourrait aider certains (dont moi :-))
Pareil, bonne remarque: on pourrait le rajouter comme option (démarrer avec ou sans compte à rebours)
Concernant le fond vert virtuel, je ne sais pas ce que vous envisagez quand vous écrivez histoire de changer de fond.
On n'a pas été très clair sur ce point. On prévoit de détourer la tête parlante et l'incruster dans la planche. Et dans le cas de la "tête parlante" seule: proposer à l'utilisateur d'en charger un.
Bien plus complexe à coder j'imagine, ce serait super (même si sans doute dispensable) si on pouvait avoir l'image prise par la caméra dans un fenêtre que l'on place où l'on veut sur la diapo, que l'on peut agrandir ou réduire comme l'on veut et idéalement qu'il soit même possible de recadrer la vidéo.
A voir aussi, là c'est surtout comment réaliser et présenter cela coté ui que réside la difficulté.
Cette dépêche rappellera aux lecteurs que les trolls sur le JPEG 2000 et >la norme DCI commencent à se faire dangereusement oublier et que la >dernière des dépêches cinéma date sérieusement !
Ces dommages. Réveillons-le! Au souvenir il y a celui la aussi: Dindon
Bon depuis on a bien avancé, convergé, fraternisé, etc, etc …
Mais bon c'est pas pour dire, mais si gstreamer supporte le jpeg2000, ca n'implique pas vraiment de lien avec le cinéma DCI. y manque encore des petites choses.
Mais que gstreamer supporte le JPEG2000, c'est vraiment une bonne nouvelle.
>Tu fais des projections de films de plus de 6h ? :)
>Je n'ai jamais vu un DCP avoir cette taille, même en 3D.
>Le range serait entre 60 et 120 Go suivant le temps et si c'est du 24 ou 48 FPS
C'est marrant ca. Dans la spec DCI chapitre 7.5.3.7 je vois des exemples allant de 123 Gb (rate de 80 Mbits/sec) jusqu'à 378 Gb (rate de 250 Mbits/sec) pour des films de 3 heures. et cela pour du 24fps.
>> KDM = DRM for cinema
>Erroné.
>Ce n'est pas parce qu'on utilise un système de chiffrement par clef que cela est >automatiquement un DRM.
>(dans la DCI, c'est indiqué "Digital Rights Management", mais c'est un terme générique)
Pourtant on donne bien dans la DRM une info disant que l'on peut projeter le film uniquement sur une période donnée.(cf. section 9.3.2 de la spec du DCI). C'est ce genre de contrainte qui font que la notion de KDM et DRM sont proches. C'est le distributeur qui impose la durée de projection non pas l'exploitant ( effectivement après discussion commerciale j'imagine). Du coup ce modèle fitte bien avec les besoins des multiplexes, mais pas pour les exploitants indépendants. Qui semaine après semaine décide suivant le film de continuer à le projeter, ou bien de le projeter plus tard, etc ... Et apprécie cette liberté de projection
>> qui gère les clefs ?
>Tu devrais le savoir si tu connais ton sujet :)
Pour faire la KDM il faut la clef publique du serveur de projection de l'exploitant de salle. Ces clef publiques sont gérés par qui ? Existe-t-il un organisme les gérants. Comment un distributeur a accès a ces clef ? Tout cela afin de permettre une génération de KDM, une fois les accords commerciaux conclus, quelque sois la salle.
>> un modèle sans clef n'existe pas
>Heu, j'espère avoir très mal compris, mais si: il te suffit de générer un DCP non crypté.
Dans ce cas reste-t-on conforme à la spec du DCI ? Je ne pense pas.
On a d'un coté, une organisation, DCI, qui établit les normes du cinéma numérique "coté salle", avec une jolie doc libre, une jolie procédure de test qui contient des bons morceaux de codes libres.
Le DCI a produit une spécification, qui est plus proche de la recommandation que de la norme. Comme il est indiqué dans le document This document is a specification developed and adopted by Digital Cinema Initiatives, LLC. This
document may be revised by DCI. It is intended solely as a guide for companies interested in developing products, which can be compatible with other products, developed using this document.
Elle propose surtout une inter-opérabilité. J'avoue ne pas comprendre ce que l'on entend par norme/spécification libre ou pas libre. Elle est en effet téléchargeable gratuitement et basé sur les normes de la SMPTE qui sont payants ( comme la plupart des normes), mais cela n'a toujours rien à voir avec le libre.
A propos de ces normes, on est actuellement en pleine validation internationale. Pratiquement toutes les normes du SMPTE sur le cinéma numérique sont passé norme ISO. Là il y a un décalage car d'après un rapport récent de le comission europééene [http://www.google.com/url?sa=t&source=web&cd=1&v(...)]
il faudrait encore travailler sur ces normes pour proposer un modèle adapter à tout les besoins du cinéma européen( "flexibility and transparency in the standardisation process, so that digital cinema projection standards can meet the diverse needs of European cinemas;")
Le document du DCI n'est pas uniquement "coté salle", puisqu'il décrit aussi la réalisation des masters ( coté post production). Il se positionne sur toute la chaine de production cinématographique.
La norme DCI s'appuie sur plusieurs normes SMPTE, qui ne sont pas libres mais payantes mais ont l'avantage d'etre utilisée largement dans le milieu depuis des dizaines d'années. Et ces normes retenues dans le cadre de la norme DCI sont systèmatiquement orientée dans le sens du libre (openjpeg2000, openssl, wav...).
La aussi je pense qu'il ne faut pas opposer libre et payant. Le SMTPE préconise plutot le [[JPEG_2000]] qui est aussi une norme. openjpeg [http://www.openjpeg.org] est un codec implémentant le Jpeg2000 développé, en libre, initié par le groupe de recherche EDCine.
Par contre, aujourd'hui, on ne trouve pas de lecteur libre capable de lire ces fameux DCP et il faut malheureusement passer par des outils propriétaires pour cela. Magie, ces outils propriétaires (de marque Doremi, Dolby, GDC, ...) sont tous basés sur du gnu/linux.
On peut tout à fais avoir des solutions propriétaires sous linux ( cf. Flash)
A mon avis, il ne faut pas limité le débat entre le libre et le cinéma numérique à une vision microscopique/technique ( savoir quel outil libre on utilise ou pas). Il faut aussi l'étendre à une vision macroscopique. A l'heure actuelle pour les exploitants de salles cela veux dire payer un matériel numérique 2 à 3 fois plus cher que l'ancien, ayant une durée de vie 3 fois inférieure ( 10 ans au lieu de 30). Tout cela au final pour la même qualité d'image ( hormis l'épiphénomène de la 3d).
Du coup la transition vers le numérique dans le cinéma amène un surplus de contrainte, à l'inverse de transition numérique dans d'autres domaines ( photo par exemple).
Le passage au numérique devrait donner une plus grande flexibilité pour tout les exploitants. La norme du DCI est pensé pour les grands exploitants et semble bien convenir. Mais en Europe les multiplexes représente 10 % des cinémas et 31% des cinémas sont des salles a un seul écran ( chiffres du rapport européen COM(2010) 487 final).
Le modele du DCI s'dapate mal aux petites salles et aux indépendants comme le souligne l'European Digital Cinema Security White Book [http://www.edcine.org/edcine] dans ses recommandations.
Le cinéma a besoin de normes, régit par des organismes internationaux. Mais c'est normes doivent d'un point de vue économique et pratique être utilisable par tout les "acteurs" de l'industrie cinématographique. Certaines des propositions de la spécification du DCI vont dans ce sens ( en particulier celles sur le DCP), mais celles sur la sécurité ou bien sur le format des masters ( 8To pour un master 4k) pas du tout.
Le modèle du logiciel libre pourrait proposer des solutions moins lourdes; autant d'un point de vue de l'équipement que celui du logiciel. Mais la bataille se passe aussi du côté des normes en les faisant évoluer afin d'accepter d'autres formats ou bien en allégeant certaines contraintes.
Atamiak: tu bosses dans le milieu, je prévois de faire une thèse sur la transition vers le cinéma numérique. Pourrais-je éventuellement t'interviewer dans ce cadre ?
Je serai aussi intéresse par tout avis/interview de personnes travaillant dans le domaine
La bonne réponse est : Luciole n'est pas encore un multiplateforme.
C'est bien une des raisons du choix du trio python/gtk/gstreamer , mais le développeur est un peu frileux à se lancer sur du Mac et surtout du windows. Là dessus il aurait bien besoin d'un coup de main ;-) ( Drivers de webcam, de camera DV et packaging )
Merci pour ce forum . Cela me fait plaisir de savoir que cela fonctionne avec cette webcam . Pour que je puisse compléter mon tableau de compatibilité de webcam, peux tu me dire avec quel ubuntu tu as testé ?
A propos des remarques en vrac :
1 °) En fait les valeurs de 25 , 12.5 , etc .. . C'est en raison de l'export et des standards , en DV en particulier. C'est un choix de simplification. En effet pour du PAL DV on est 25 images par secondes, donc à que des sous-multiples de ce 25. Si on est à 25 images/seconde je répète l'image 1 fois, à 12.5 je répète l'image 2 fois, etc ... Avec 15 image/seconde je ne peux pas exporter en format DV. Mais peut-être en d'autre format ... je vais réfléchir à la question.
2°) Proposition intéressante. Je vais voir à comment la mettre la place dans des versions futures.
3°)et 4°) Propositions encore plus intéressantes ;-)
Salut effectivement les paquets ne son dispo pour l'instant que pour ubuntu. On prévois de le faire pour debian lenny mais ce n'est pas encore en place.
Mais vu que c'est du python uniquement et que si dans tes sources tu ajoutes :
deb http://repository.inattendu.org hardy main
puis un apt-get update et apt-get install luciole ca devrait tourner.
[^] # Re: récupération des vidéos ?
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Polymny Studio 1.0. Évalué à 2.
Bonjour,
oui il est tout à fait possible de récupérer la vidéo produite en fichier MP4.
On peut aussi décider de publier la vidéo sur le serveur de stream et partager une URL de à la youtube like(ex: https://dev.polymny.studio/v/Y3lJZ/ )
[^] # Re: Mes souhaits pour l'à venir
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Polymny Studio. Évalué à 2.
Merci pour ce retour fort sympa sur l'application.
Trais bonne idée ! On va le rajouter. Faut jus que l'on fasse quelques tests et correctifs pour gérer les webcams en HD . Et si c'est du SD ne pas trop agrandir l'image pour éviter la pixelisation.
Pareil, bonne remarque: on pourrait le rajouter comme option (démarrer avec ou sans compte à rebours)
On n'a pas été très clair sur ce point. On prévoit de détourer la tête parlante et l'incruster dans la planche. Et dans le cas de la "tête parlante" seule: proposer à l'utilisateur d'en charger un.
A voir aussi, là c'est surtout comment réaliser et présenter cela coté ui que réside la difficulté.
# Le troll endormi
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche GStreamer dégaine la version 1.2. Évalué à 2.
Bon depuis on a bien avancé, convergé, fraternisé, etc, etc …
Mais bon c'est pas pour dire, mais si gstreamer supporte le jpeg2000, ca n'implique pas vraiment de lien avec le cinéma DCI. y manque encore des petites choses.
Mais que gstreamer supporte le JPEG2000, c'est vraiment une bonne nouvelle.
Et bravo pour la belle écriture de cet article.
# Erreur de lien
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Luciole 0.8.7 est de sortie. Évalué à 3.
Sur le lien de téléchargement des sources il y a une erreur. Le lien pointe vers la version instable 0.9.2 ( pas vraiment conseillé d'utiliser)
Le lien correct est : version 0.8.7
[^] # Re: Quelle version ?
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Luciole 0.8.7 est de sortie. Évalué à 3.
C'est la version 0.8 la version stable.
La 0.7 est l'ancienne. La version 0.9 est en développement.
Va falloir mettre cela à jour sur le site de LP.
# Milieu
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Pour un cinéma numérique durable et open source. Évalué à 3.
On se croirait dans le parrain : « Gardez vos amis près de vous, mais gardez vos ennemis encore plus près. »
Ou encore en image [http://www.dailymotion.com/video/xmsh6_le-parrain-tete-de-ch(...)]
Au final de quel "milieu" parle-t-on ?
[^] # Re: Manquement d'objectivité.
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Pour un cinéma numérique durable et open source. Évalué à 1.
>Je n'ai jamais vu un DCP avoir cette taille, même en 3D.
>Le range serait entre 60 et 120 Go suivant le temps et si c'est du 24 ou 48 FPS
C'est marrant ca. Dans la spec DCI chapitre 7.5.3.7 je vois des exemples allant de 123 Gb (rate de 80 Mbits/sec) jusqu'à 378 Gb (rate de 250 Mbits/sec) pour des films de 3 heures. et cela pour du 24fps.
>> KDM = DRM for cinema
>Erroné.
>Ce n'est pas parce qu'on utilise un système de chiffrement par clef que cela est >automatiquement un DRM.
>(dans la DCI, c'est indiqué "Digital Rights Management", mais c'est un terme générique)
Pourtant on donne bien dans la DRM une info disant que l'on peut projeter le film uniquement sur une période donnée.(cf. section 9.3.2 de la spec du DCI). C'est ce genre de contrainte qui font que la notion de KDM et DRM sont proches. C'est le distributeur qui impose la durée de projection non pas l'exploitant ( effectivement après discussion commerciale j'imagine). Du coup ce modèle fitte bien avec les besoins des multiplexes, mais pas pour les exploitants indépendants. Qui semaine après semaine décide suivant le film de continuer à le projeter, ou bien de le projeter plus tard, etc ... Et apprécie cette liberté de projection
>> qui gère les clefs ?
>Tu devrais le savoir si tu connais ton sujet :)
Pour faire la KDM il faut la clef publique du serveur de projection de l'exploitant de salle. Ces clef publiques sont gérés par qui ? Existe-t-il un organisme les gérants. Comment un distributeur a accès a ces clef ? Tout cela afin de permettre une génération de KDM, une fois les accords commerciaux conclus, quelque sois la salle.
>> un modèle sans clef n'existe pas
>Heu, j'espère avoir très mal compris, mais si: il te suffit de générer un DCP non crypté.
Dans ce cas reste-t-on conforme à la spec du DCI ? Je ne pense pas.
[^] # Re: Mais encore?
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Pour un cinéma numérique durable et open source. Évalué à 0.
On ne sait pas de quoi tu parles ;-)
Nico
[^] # Re: Manquement d'objectivité.
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Pour un cinéma numérique durable et open source. Évalué à 1.
[^] # Re: Mais c'est déjà libre ma bonne dame !
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Pour un cinéma numérique durable et open source. Évalué à 6.
Le DCI a produit une spécification, qui est plus proche de la recommandation que de la norme. Comme il est indiqué dans le document
This document is a specification developed and adopted by Digital Cinema Initiatives, LLC. This
document may be revised by DCI. It is intended solely as a guide for companies interested in developing products, which can be compatible with other products, developed using this document.
Elle propose surtout une inter-opérabilité. J'avoue ne pas comprendre ce que l'on entend par norme/spécification libre ou pas libre. Elle est en effet téléchargeable gratuitement et basé sur les normes de la SMPTE qui sont payants ( comme la plupart des normes), mais cela n'a toujours rien à voir avec le libre.
A propos de ces normes, on est actuellement en pleine validation internationale. Pratiquement toutes les normes du SMPTE sur le cinéma numérique sont passé norme ISO. Là il y a un décalage car d'après un rapport récent de le comission europééene [http://www.google.com/url?sa=t&source=web&cd=1&v(...)]
il faudrait encore travailler sur ces normes pour proposer un modèle adapter à tout les besoins du cinéma européen( "flexibility and transparency in the standardisation process, so that digital cinema projection standards can meet the diverse needs of European cinemas;")
Le document du DCI n'est pas uniquement "coté salle", puisqu'il décrit aussi la réalisation des masters ( coté post production). Il se positionne sur toute la chaine de production cinématographique.
La norme DCI s'appuie sur plusieurs normes SMPTE, qui ne sont pas libres mais payantes mais ont l'avantage d'etre utilisée largement dans le milieu depuis des dizaines d'années. Et ces normes retenues dans le cadre de la norme DCI sont systèmatiquement orientée dans le sens du libre (openjpeg2000, openssl, wav...).
La aussi je pense qu'il ne faut pas opposer libre et payant. Le SMTPE préconise plutot le [[JPEG_2000]] qui est aussi une norme. openjpeg [http://www.openjpeg.org] est un codec implémentant le Jpeg2000 développé, en libre, initié par le groupe de recherche EDCine.
Par contre, aujourd'hui, on ne trouve pas de lecteur libre capable de lire ces fameux DCP et il faut malheureusement passer par des outils propriétaires pour cela. Magie, ces outils propriétaires (de marque Doremi, Dolby, GDC, ...) sont tous basés sur du gnu/linux.
On peut tout à fais avoir des solutions propriétaires sous linux ( cf. Flash)
A mon avis, il ne faut pas limité le débat entre le libre et le cinéma numérique à une vision microscopique/technique ( savoir quel outil libre on utilise ou pas). Il faut aussi l'étendre à une vision macroscopique. A l'heure actuelle pour les exploitants de salles cela veux dire payer un matériel numérique 2 à 3 fois plus cher que l'ancien, ayant une durée de vie 3 fois inférieure ( 10 ans au lieu de 30). Tout cela au final pour la même qualité d'image ( hormis l'épiphénomène de la 3d).
Du coup la transition vers le numérique dans le cinéma amène un surplus de contrainte, à l'inverse de transition numérique dans d'autres domaines ( photo par exemple).
Le passage au numérique devrait donner une plus grande flexibilité pour tout les exploitants. La norme du DCI est pensé pour les grands exploitants et semble bien convenir. Mais en Europe les multiplexes représente 10 % des cinémas et 31% des cinémas sont des salles a un seul écran ( chiffres du rapport européen COM(2010) 487 final).
Le modele du DCI s'dapate mal aux petites salles et aux indépendants comme le souligne l'European Digital Cinema Security White Book [http://www.edcine.org/edcine] dans ses recommandations.
Le cinéma a besoin de normes, régit par des organismes internationaux. Mais c'est normes doivent d'un point de vue économique et pratique être utilisable par tout les "acteurs" de l'industrie cinématographique. Certaines des propositions de la spécification du DCI vont dans ce sens ( en particulier celles sur le DCP), mais celles sur la sécurité ou bien sur le format des masters ( 8To pour un master 4k) pas du tout.
Le modèle du logiciel libre pourrait proposer des solutions moins lourdes; autant d'un point de vue de l'équipement que celui du logiciel. Mais la bataille se passe aussi du côté des normes en les faisant évoluer afin d'accepter d'autres formats ou bien en allégeant certaines contraintes.
Atamiak: tu bosses dans le milieu, je prévois de faire une thèse sur la transition vers le cinéma numérique. Pourrais-je éventuellement t'interviewer dans ce cadre ?
Je serai aussi intéresse par tout avis/interview de personnes travaillant dans le domaine
Nico.
# Luciole 0.8.4
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.8.2 !. Évalué à 2.
Suite à la diffusion de luciole , quelques bugs sont revenus. Du coup une version 0.8.4 est disponible maintenant.
[^] # Re: Mandriva
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.8.2 !. Évalué à 2.
Merci pour ce packaging si rapide
[^] # Re: multiplateforme ?
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.7. Évalué à 3.
Aurai tu un tuto/howto pour une install dans /opt/ ?
[^] # Re: multiplateforme ?
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.7. Évalué à 3.
C'est bien une des raisons du choix du trio python/gtk/gstreamer , mais le développeur est un peu frileux à se lancer sur du Mac et surtout du windows. Là dessus il aurait bien besoin d'un coup de main ;-) ( Drivers de webcam, de camera DV et packaging )
[^] # Re: Très prometteur, bravo
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.7. Évalué à 2.
[^] # Re: Très prometteur, bravo
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.7. Évalué à 5.
A propos des remarques en vrac :
1 °) En fait les valeurs de 25 , 12.5 , etc .. . C'est en raison de l'export et des standards , en DV en particulier. C'est un choix de simplification. En effet pour du PAL DV on est 25 images par secondes, donc à que des sous-multiples de ce 25. Si on est à 25 images/seconde je répète l'image 1 fois, à 12.5 je répète l'image 2 fois, etc ... Avec 15 image/seconde je ne peux pas exporter en format DV. Mais peut-être en d'autre format ... je vais réfléchir à la question.
2°) Proposition intéressante. Je vais voir à comment la mettre la place dans des versions futures.
3°)et 4°) Propositions encore plus intéressantes ;-)
Nico
[^] # Re: Sources...
Posté par Nicolas Bertrand (site web personnel) . En réponse à la dépêche Sortie de Luciole 0.7. Évalué à 5.
Mais vu que c'est du python uniquement et que si dans tes sources tu ajoutes :
deb http://repository.inattendu.org hardy main
puis un apt-get update et apt-get install luciole ca devrait tourner.
Sinon les sources sont ici :
http://launchpad.net/luciole/trunk/0.7.2/+download/luciole_0(...)
Nico