Recherche avancée

Médias (91)

Autres articles (6)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

  • La gestion des forums

    3 novembre 2011, par

    Si les forums sont activés sur le site, les administrateurs ont la possibilité de les gérer depuis l’interface d’administration ou depuis l’article même dans le bloc de modification de l’article qui se trouve dans la navigation de la page.
    Accès à l’interface de modération des messages
    Lorsqu’il est identifié sur le site, l’administrateur peut procéder de deux manières pour gérer les forums.
    S’il souhaite modifier (modérer, déclarer comme SPAM un message) les forums d’un article particulier, il a à sa (...)

Sur d’autres sites (1827)

  • Simple Build of Libavcodec.so and libavformat.so on Mac

    11 mai 2013, par Dave Lowerre

    Who needs ffmpeg ? Not me. What I need is to be able to decode a video stream along with its audio stream, so that can put the frames on an opengl surface in sync with the audio.

    FFmpeg is a tool that transcodes video. That is not what I need. I need its libraries.

    The problem is that every example for building FFmpeg includes junk I just dont need. The latest example I wasted my time on :

    https://github.com/appunite/AndroidFFmpeg

    uses things like freetype2 that I really, REALLY, do not need. Whats more annoying is that it wont even build as described because the example references freetype, not freetype2 so the build steps are broken. Don't even get me started on the problems I had with libtool.

    The kicker is finding libav.org, where they describe on their about page the chaos in the ffmpeg project. Perhaps that is why this is so difficult.

    So, should it be so hard to build just the shared libs ? Can someone point me to some documentation, or a tutorial that works ? I admit that this is new territory for me but all I have found using Google is chaos.

  • How to transcode video stream by changing only the resolution ?

    3 mai 2013, par user1051417

    I would like to transcode video stream using ffmpeg tool and change only the video stream resolution, i.e. the video and audio parameters should remain the same.

    According to the man page of the ffmpeg the following command line should provide the desired result :

    ffmpeg -i input.mp4 -vcodec copy -acodec copy -s WxH output.avi

    The Video codec of the input stream is compatible with avi container.

    The actual result is that the resolution remains unchanged and it seems that the stream is just repacked in avi container.

    The resolution of the output stream is changed successfully without -vcodec copy option, but the video codec is changed : h264 (Constrained Baseline) - > mpeg4 (Simple Profile).

  • Revision 3d655805f2 : Use same intra prediction for all block size The commmit changed to use same in

    23 avril 2013, par Yaowu Xu

    Changed Paths :
     Modify /vp9/common/vp9_reconintra.c


     Modify /vp9/common/vp9_reconintra4x4.c



    Use same intra prediction for all block size

    The commmit changed to use same intra prediction function for all
    block sizes.

    Some details on the changes :
    1. All directional modes except DC/TM/V/H now have built-in filtering
    for all pixels with filter taps either (1, 2, 1)/4 or (1, 1)/2.
    2. Above edge get automatic extended to double width (bw*2), which
    makes a lot of the prediciton mode computation simpler.
    3. Same intra prediction function is called with different size
    for i4x4_pred and all other larger size.

    Overall, the change helped keyframe only coding for both cif size
    and std-hd size test sets by .5% consistently on all encodings.
    For normal coding with single/auto key frame, the change now also
    is consistently net positive for all encodings. The overall gains
    is about .15% on std-hd set.

    Change-Id : I01ceb31fbc73d49776262e6bdc06853b03bbd1d1

Navigation