Recherche avancée

Médias (91)

Autres articles (51)

  • Dépôt de média et thèmes par FTP

    31 mai 2013, par

    L’outil MédiaSPIP traite aussi les média transférés par la voie FTP. Si vous préférez déposer par cette voie, récupérez les identifiants d’accès vers votre site MédiaSPIP et utilisez votre client FTP favori.
    Vous trouverez dès le départ les dossiers suivants dans votre espace FTP : config/ : dossier de configuration du site IMG/ : dossier des média déjà traités et en ligne sur le site local/ : répertoire cache du site web themes/ : les thèmes ou les feuilles de style personnalisées tmp/ : dossier de travail (...)

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Qualité du média après traitement

    21 juin 2013, par

    Le bon réglage du logiciel qui traite les média est important pour un équilibre entre les partis ( bande passante de l’hébergeur, qualité du média pour le rédacteur et le visiteur, accessibilité pour le visiteur ). Comment régler la qualité de son média ?
    Plus la qualité du média est importante, plus la bande passante sera utilisée. Le visiteur avec une connexion internet à petit débit devra attendre plus longtemps. Inversement plus, la qualité du média est pauvre et donc le média devient dégradé voire (...)

Sur d’autres sites (6390)

  • fate : split off adpcm-ms-mono test from dxa-feeble

    11 mai 2012, par Mans Rullgard

    fate : split off adpcm-ms-mono test from dxa-feeble

  • Revised FATE Test Spec System

    9 juin 2010, par Multimedia Mike — FATE Server

    FATE involves some database tables that define the test specifications. Like everything else in FATE, the concept could use some improvement. After I prototyped an improved, multithreaded testing client, the next logical revision seemed to be the test spec system.

    History
    The test spec system has been handled by a single table that includes an FFmpeg command line (with a few possible modifiers thrown in), an integer ID, a human-friendly ID, a description, the expected command line return code, the expected command output, a maximum runtime, and a Boolean to indicate whether the test is to be considered active.

    Adjunct to this test database is a large corpus of test media named the FATE suite.

    At first, the FATE testing script used a direct MySQL database protocol to query the test specs from the server before every build/test cycle. I soon realized this was ludicrously inefficient since the test specs don’t change that often. So I cached the tests in a static file to be retrieved via HTTP, first in Python’s "pickled" (serialized) format, then in an SQLite database.

    Planned Upgrades
    There are 2 major features I would like to build into the system going forward :

    1. The ability to version the entire suite so that it’s possible to test old branches of FFmpeg
    2. Another database field to indicate which, if any, other test specs must be executed before this spec can be executed

    I think I will take this opportunity to switch the test cache serialization format to JSON. I switched from Python pickling to SQLite because the latter was more portable between languages. JSON has that same benefit. Further, working with JSON data doesn’t require a round trip to disk (i.e., want to generate an SQLite database for sending via HTTP ? It needs to go onto disk first. It’s possible to create and manipulate a database entirely in memory but not fetch the bits).

    Things To Research

    • Pondering how version control systems operate and what they have to teach regarding how to version this data (including the question of whether I can just use an existing version control mechanism instead of creating my own system)
    • Efficient caching mechanism
    • Tagging test specs for alternate purposes such as longevity testing
    • Learn about web form programming in the 21st century so that it’s not quite as painful to maintain the system.

    Preliminary Versioning Concept
    Here is one approach I am thinking of : Create test groups. Each test spec is assigned to at least one test group. I can think of at least 2 groups : functional (the base test set in existence that validates functionality) and profiling (the projected test set that will be used for ongoing performance and memory profiling). The web frontend will allow for the creation of labels that will apply to a single group. Doing so will apply that label to all active tests in the group.

  • Revision 4bbca2e263 : README : add a note about the test vectors Change-Id : I8b3299bf1579962c6dbb29b61

    31 mai 2014, par James Zern

    Changed Paths :
     Modify /README



    README : add a note about the test vectors

    Change-Id : I8b3299bf1579962c6dbb29b61c16801fef2460fd

Navigation