Recherche avancée

Médias (1)

Mot : - Tags -/net art

Autres articles (111)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (8967)

  • Révision 17266 : - changer la classe sur le body pour la preference icone/icone+texte/texte

    18 février 2011, par cedric -

    correction sur les icones horizontales en mode texte

  • Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

    12 août 2014, par eric@… — Log

    Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
    - la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
    - ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
    - ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
    - ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
    - utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
    Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
    En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
    Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

  • Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

    12 août 2014, par eric@… — Log

    Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
    - la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
    - ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
    - ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
    - ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
    - utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
    Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
    En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
    Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

Navigation