Recherche avancée

Médias (10)

Mot : - Tags -/wav

Autres articles (9)

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

  • Gestion générale des documents

    13 mai 2011, par

    MédiaSPIP ne modifie jamais le document original mis en ligne.
    Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
    Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

Sur d’autres sites (5286)

  • Evolution #3899 (Nouveau) : Comportement des inclusions avec le paramètre connect.

    10 février 2017

    Il y a un comportement contre-intuitif dans un cas d’usage des inclusions et du paramètre connect, ce qu’à révélé une petite analyse dans #3823.
    J’en fais un ticket dédié car c’est un problème distinct de ce qui est soulevé là bas.

    Fonctionnement actuel

    Le paramètre d’URL connect

    Le paramètre connect=truc dans une URL d’un site SPIP permet d’indiquer à SPIP qu’il doit utilise le connecteur SQL ’truc’ dans les squelettes et les boucles utilisés,
    et donc utiliser config/truc.php en lieu et place de config/connect.php. À différents endroits du compilateur, ce paramètre est séparé du contexte d’environnement
    du squelette, notamment dans les boucles où il atterrit dans $boucles[$idb]->sql_serveur et sera utilisé pour les requêtes SQL générées.

    Inclusions en indiquant un connect spécifique

    Une autre manière d’indiquer que les squelettes / boucles utilisent un connecteur spécifique est de transmettre l’environnement connect=truc aux inclusions, de la sorte :

    #INCLUREfond=test, connect=truc

    Cette option d’inclusion est prise en compte dans recuperer_fond().

    Inclusion connect=truc et paramètre d’url connect=bidule

    Lorsqu’on a à la fois dans l’URL &connect=bidule, et une inclusion qui indique un connect spécifique tel que #INCLURE{fond=test, connect=truc}
    alors d’inclusion actuellement est chargée avec le paramètre d’URL, c’est à dire en utilisant connect=bidule.
    C’est cela qui est assez contre-intuitif et logiquement non désiré (le connect forcé ici devrait prendre le pas sur celui d’environnement).

    Comment améliorer ?

    Où cela se passe dans le code ?

    Ce qui se passe lorsqu’il y a cette écriture est, comme expliqué, que le connect dans l’URL reste prioritaire sur celui de l’argument transmis à #INCLURE ou <inclure></inclure>.

    Solutions ?

    À ces 2 endroits, il faudrait du coup prendre en compte en priorité le $contexte['connect'] si existant

    • soit dans les 2 appels à la constante CODE_RECUPERER_FOND plutôt que d’écrire directement _request('connect'), mais c’est un peu compliqué car c’est du code compilé
    • soit directement dans recuperer_fond(), plus facile, inverser l’ordre :
          if (isset($contexte[’connect’])) 
              $connect = ($connect ? $connect : $contexte[’connect’]) ;
              unset($contexte[’connect’]) ;
          
      


      deviendrait :

          if (isset($contexte[’connect’])) 
              $connect = $contexte[’connect’] ;
              unset($contexte[’connect’]) ;
          
      

    Cette dernière correction serait la plus simple et la plus facile. Ça permettrait même d’annuler un connect superieur dans une inclusion
    en passant {connect=''}.

    Des avis ?

  • why cmd just print command and dosen't work ?

    11 octobre 2019, par 杨士弘

    I tried create a website that could upload mp4 then my server would transcode it to ts and create a m3u8 playlist。
    I wanted to use cmd to control ffmpeg to do this,and I use visual basic to do this.

    Here is my code:

     Dim fileName As String = "borderoflife"
     Dim file As String = "borderoflife.mp4"
     Dim appPath As String = "C:\allen0916\"
     Dim saveDir As String = "test2\"

     Dim savePath As String = appPath &amp; saveDir
     Dim saveResult As String = savePath &amp; file

     Dim Content_Type_A As String = "video/mp4"

     Dim m3u8Path As String = Path.Combine(savePath, fileName + ".m3u8")
     Dim para As String = String.Format("/C ffmpeg -i {0} -profile:v baseline -level 3.0 -s 640x360 -start_number 0 -hls_time 10 -hls_list_size 0 -f hls {1} ", saveResult, m3u8Path)

     Dim output As String = "none"
     Dim p As Process = New Process()

     p.StartInfo.FileName = "cmd.exe"
     p.StartInfo.UseShellExecute = False
     p.StartInfo.RedirectStandardInput = True
     p.StartInfo.RedirectStandardOutput = True
     p.StartInfo.RedirectStandardError = True
     p.StartInfo.CreateNoWindow = True
     p.Start()
     p.StandardInput.WriteLine(para)
     p.StandardInput.WriteLine("exit")
     p.StandardInput.AutoFlush = True
     p.StandardInput.Close()
     output = p.StandardOutput.ReadToEnd()
     p.WaitForExit()
     p.Close()

    If System.IO.File.Exists(m3u8Path) &lt;> True Then
         context.Response.Write(output)
     Else
         context.Response.Write("Success")
     End If  

    and every time output just returns :

    Microsoft Windows [version 10.0.17763.737]
    (c) 2018 Microsoft Corporation.

    c:\windows\system32\inetsrv>/C ffmpeg -i C:\allen0916\test2\borderoflife.mp4 -profile:v baseline -level 3.0 -s 640x360 -start_number 0 -hls_time 10 -hls_list_size 0 -f hls C:\allen0916\test2\borderoflife.m3u8

    c:\windows\system32\inetsrv>exit

    it seems cmd.exe just print my command and not working,
    Dose somebody know why?

  • Roadmap #3844 : Gérer la parenté dans la déclaration d’un objet éditorial.

    12 mars 2018, par RastaPopoulos ♥

    J’ai continué dans la réflexion, ayant besoin de parent et enfants dans le plugin Duplicator. J’ai expliqué différents problèmes dans la liste Zone, mais pour pas le perdre, je vais copier ça dans ce ticket.

    Proposition de deux fonctions d’API génériques

    À mon avis il faut aller stable et plus abstrait que juste la déclaration dans l’objet, car
    1) ça peut éventuellement changer
    2) il faudrait pouvoir prendre en compte les cas courants magiquement même quand ya pas eu de déclaration explicite (id_rubrique, id_parent…)
    3) ça donne le parent d’un type d’objet pour remonter, mais ça ne donne pas l’inverse, les enfants

    Donc dans tous les cas il faudrait sûrement une fonction du genre
    array objet_info_parent($objet)
    dont l’algorithme serait :
    - s’il y a une déclaration explicite, c’est ça qu’on utilise
    - s’il y a un champ id_rubrique, on fait comme si ça avait été déclaré avec la rubrique array(type=>rubrique, champ=>id_rubrique)
    - s’il y a un champ id_parent, on considère que l’objet est arborescent de lui-même, et donc comme si ça avait été déclaré comme ça array(type=$objet, champ=>id_parent)

    Mais je pense aussi une fonction cette fois un peu plus longue, qui donnerait l’ensemble des enfants directs qu’on a réussi à trouver
    array objet_info_enfants($objet)
    dont l’algorithme serait :
    - un tableau de résultats en static pour toujours faire qu’une fois par hit
    - si $enfants[$objet] déjà rempli en renvoie
    - sinon on boucle sur tous les objets déclarés
    - pour chaque, si on trouve que l’objet peut avoir comme parent direct le $objet qu’on cherche, alors on l’ajoute à son tableau des enfants possibles
    - donc soit si dans sa clé "parent" ya $objet, soit s’il a un id_rubrique et qu’on cherchait pour "rubrique", soit s’il a un id_parent et qu’on cherchait pour son type

    Un parent direct dont l’objet n’est pas fixe

    Encore autre chose, je ne sais pas si c’est prévu, mais il faudrait pouvoir gérer les cas où le parent direct (on parle bien toujours de parentée directe, pas de liens multiples) peut être n’importe quel objet. Dans ce cas, il y a les champs objet et id_objet directement dans la table de l’objet.

    Un parent encore plus compliqué avec deux cas à tester pour le même contenu

    Mais il y a encore plus compliqué, et c’est le cas pour mes Chapitres, mais aussi le cas pour les Forums fournit par SPIP : le parent direct
    peut être
    - SOIT l’objet lui-même car il est arborescent avec un id_parent
    - SOIT n’importe quel autre contenu SI ET SEULEMENT SI le champ id_parent=0 !

    C’est bien le cas pour les forums :
    - le premier forum d’un fil a pour parent un objet SPIP, avec objet et id_objet remplis dans sa table ET id_parent=0
    - les sous-forums ont AUSSI gardé en mémoire objet et id_objet du forum racine, mais avec id_parent rempli avec l’identifiant id_forum de leur parent

    Dans ce cas on ne peut pas se baser uniquement sur le fait que objet et id_objet sont remplis. Le parent est un objet SPIP quelconque si objet et id_objet remplis ET id_parent=0. Et dès que id_parent>0 alors le parent direct est le même objet (forum, chapitre ou autre).

    Bref ya des cas comme ça qui sont plus complexes, mais pourtant légitimes, et en plus fournis dans la dist, maintenus par le core, donc il faut savoir les gérer aussi.

    Du coup pour conclure, j’ai pas forcément de solution directe pour la déclaration générique qui doit intégrer le noyau au final, mais c’est pour expliquer pourquoi peut-être, possiblement, il y aurait besoin d’un pipeline dédié dans Duplicator pour gérer ces enfantillages compliqués tant que dans l’API de parent c’est pas encore résolu.

    En tout cas ça fait avancer la réflexion :)