Recherche avancée

Médias (91)

Autres articles (108)

  • Qu’est ce qu’un masque de formulaire

    13 juin 2013, par

    Un masque de formulaire consiste en la personnalisation du formulaire de mise en ligne des médias, rubriques, actualités, éditoriaux et liens vers des sites.
    Chaque formulaire de publication d’objet peut donc être personnalisé.
    Pour accéder à la personnalisation des champs de formulaires, il est nécessaire d’aller dans l’administration de votre MediaSPIP puis de sélectionner "Configuration des masques de formulaires".
    Sélectionnez ensuite le formulaire à modifier en cliquant sur sont type d’objet. (...)

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

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

Sur d’autres sites (15909)

  • Greed is Good ; Greed Works

    25 novembre 2010, par Multimedia Mike — VP8

    Greed, for lack of a better word, is good ; Greed works. Well, most of the time. Maybe.

    Picking Prediction Modes
    VP8 uses one of 4 prediction modes to predict a 16x16 luma block or 8x8 chroma block before processing it (for luma, a block can also be broken into 16 4x4 blocks for individual prediction using even more modes).

    So, how to pick the best predictor mode ? I had no idea when I started writing my VP8 encoder. I did not read any literature on the matter ; I just sat down and thought of a brute-force approach. According to the comments in my code :

    // naive, greedy algorithm :
//   residual = source - predictor
//   mean = mean(residual)
//   residual -= mean
//   find the max diff between the mean and the residual
// the thinking is that, post-prediction, the best block will
// be comprised of similar samples

    After removing the predictor from the macroblock, individual 4x4 subblocks are put through a forward DCT and quantized. Optimal compression in this scenario results when all samples are the same since only the DC coefficient will be non-zero. Failing that, when the input samples are at least similar to each other, few of the AC coefficients will be non-zero, which helps compression. When the samples are all over the scale, there aren’t a whole lot of non-zero coefficients unless you crank up the quantizer, which results in poor quality in the reconstructed subblocks.

    Thus, my goal was to pick a prediction mode that, when applied to the input block, resulted in a residual in which each element would feature the least deviation from the mean of the residual (relative to other prediction choices).

    Greedy Approach
    I realized that this algorithm falls into the broad general category of "greedy" algorithms— one that makes locally optimal decisions at each stage. There are most likely smarter algorithms. But this one was good enough for making an encoder that just barely works.

    Compression Results
    I checked the total file compression size on my usual 640x360 Big Buck Bunny logo image while forcing prediction modes vs. using my greedy prediction picking algorithm. In this very simple test, DC-only actually resulted in slightly better compression than the greedy algorithm (which says nothing about overall quality).

    prediction mode quantizer index = 0 (minimum) quantizer index = 10
    greedy 286260 98028
    DC 280593 95378
    vertical 297206 105316
    horizontal 295357 104185
    TrueMotion 311660 113480

    As another data point, in both quantizer cases, my greedy algorithm selected a healthy mix of prediction modes :

    • quantizer index 0 : DC = 521, VERT = 151, HORIZ = 183, TM = 65
    • quantizer index 10 : DC = 486, VERT = 167, HORIZ = 190, TM = 77

    Size vs. Quality
    Again, note that this ad-hoc test only measures one property (a highly objective one)— compression size. It did not account for quality which is a far more controversial topic that I have yet to wade into.

  • H264 Encoders other than ffmpeg x264

    5 septembre 2016, par 0pcl

    The iPhone app I am working on captures images in series within certain user-defined time interval, I am looking for a way to combine these images into H264 encoded videos. I have done some research on Google, it looks like I will have to use something like ffmpeg/mencoder on iPhone ? (Also found someone ported ffmpeg to iPhone, ffmpeg4iPhone)

    However, I found that x264 is under GPL license, and requires me to open source my project if I use ffmpeg. Also found some people suggested to use Ogg Theora, but I will need to port it to iPhone if I use it. (Which I am not sure how to do it now).

    Is there any workaround for this ? Any ideas ? Thanks.

  • Can't record audio with ffmpeg linux

    20 novembre 2011, par FGraviton

    I'm trying to do a screencast with ffmpeg on OpenSUSE but the audio isn't working :

    ffmpeg -f oss -i /dev/audio -f x11grab -s $SCREEN -r 24 -b 100k -bf 2 -g 300 -i :0.0 -ar 22050 -ab 128k -acodec libmp3lame -vcodec libxvid -aspect 1.6 -sameq out.avi

    this one shows me that /dev/audio isn't there !!

    Any pointers ?

    Thanks Community,

Navigation