Recherche avancée

Médias (91)

Autres articles (101)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • 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 (...)

Sur d’autres sites (11277)

  • tools : Don't include the direct library names when linking

    28 septembre 2023, par Martin Storsjö
    tools : Don't include the direct library names when linking
    

    When linking the main tools, the object files to link are set up
    via the variable OBJS-<name>, but for the tools, we've only
    used the target's list of dependencies.

    In most cases, this has been fine, but it has caused specifying
    the libraries to link in a duplicate fashion ; the linking command
    has looked like this :

    $CC -Llibavutil ... tools/tool.o libavutil/libavutil.a -lavutil

    Normally, the libraries to link are handled with "-Llibavutil -lavutil" ;
    when linking the main fftools, this is how they are linked.

    In the case of the binaries under the "tools" directory (within the
    make variable TOOLS), we've passed the full set of dependencies
    to the linker, via $^, which does contain the names of the
    dependency libraries as well.

    When libraries are built as regular static libraries, or shared
    unix libraries, this has all worked fine. When libraries are
    built as DLLs for Windows, though, the norm is not to pass the
    actual DLL to the linker, but an import library.

    Mingw tools generally can handle linking directly against a DLL
    as well, but MSVC tools don't support that, and error out with
    a very cryptic error message :

    libavdevice\avdevice.dll : fatal error LNK1107 : invalid or corrupt file : cannot read at 0x2D8

    By omitting these parts of the dependencies, linking of these tool
    executables succeed in MSVC builds with shared libraries enabled.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] Makefile
  • Build : Can't override top-level methods

    30 juin 2015, par jzaefferer
    Build : Can’t override top-level methods
  • lavf/matroska : add "binary" pseudo-MIME type.

    16 avril 2014, par Nicolas George
    lavf/matroska : add "binary" pseudo-MIME type.
    

    Avoid long scan and "Could not find codec parameters for stream"
    error when an attachment has this type.

    • [DH] libavformat/matroska.c