Recherche avancée

Médias (91)

Autres articles (39)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

Sur d’autres sites (6059)

  • New FATE Test Coverage System

    10 août 2010, par Multimedia Mike — FATE Server

    I’ve been feeling a bit scattered for the last week since I was fired from my volunteer position as the FFmpeg QA manager, wondering if there is anything I should attempt to do with the project. It can’t be denied that the new system is working well. But one area I’ve wondered about is test coverage.

    Under my old regime I tracked test coverage as a wiki page which was a highly flawed method— tedious and error-prone. There are those 2 adjectives again— tedious and error-prone ; whenever I see those, I search for automation methods. I think that might be more plausible thanks to the new FATE’s tighter integration with the FFmpeg build system.

    I don’t think anyone is working on this problem so I wanted to toss out a brainstorm :

    1. First, run ’ffmpeg -formats’, ’ffmpeg -codecs’, etc. and parse the output to collect a list of all the features (full list : -formats, -codecs, -bsfs, -protocols, -filters, -pix_fmts). Transform these lists into a standardized list of features, e.g., "DEVSD  ffvhuff         Huffyuv FFmpeg variant" represents features ’decode-video-ffvhuff’, ’encode-video-ffvhuff’, ’ffvhuff-horizband’, and ’ffvhuff-dr1’.
    2. Next, tag each individual test spec with the features that it exercises. E.g., test ’fate-vqa-cc’ exercises features ’demux-wsvqa’, ’decode-video-vqavideo’, and ’decode-audio-adpcm_ima_ws’.
    3. Finally, compare the data from parts 1 and 2. Print a list of all the features that are not exercised in FATE.

    I think a lot of this could be implemented at the GNU make level. Then again, I’m no expert on GNU make syntax so I may be overestimating its capabilities. Or there might be simpler ways to automatically track test coverage stats based on the improved testing infrastructure.

  • Merge "Limit size of initial keyframe in one-pass."

    25 avril 2011, par John Koleszar

    Merge "Limit size of initial keyframe in one-pass."

  • Limit size of initial keyframe in one-pass.

    19 avril 2011, par John Koleszar

    Limit size of initial keyframe in one-pass.

Navigation