Recherche avancée

Médias (10)

Mot : - Tags -/wav

Autres articles (45)

  • Soumettre améliorations et plugins supplémentaires

    10 avril 2011

    Si vous avez développé une nouvelle extension permettant d’ajouter une ou plusieurs fonctionnalités utiles à MediaSPIP, faites le nous savoir et son intégration dans la distribution officielle sera envisagée.
    Vous pouvez utiliser la liste de discussion de développement afin de le faire savoir ou demander de l’aide quant à la réalisation de ce plugin. MediaSPIP étant basé sur SPIP, il est également possible d’utiliser le liste de discussion SPIP-zone de SPIP pour (...)

  • Menus personnalisés

    14 novembre 2010, par

    MediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
    Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
    Menus créés à l’initialisation du site
    Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...)

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

Sur d’autres sites (10502)

  • raspberry pi 3 OpenMax EmptyThisBuffer slow response when transcoding with libav or ffmpeg

    29 septembre 2016, par A. H.

    The context is transcoding on a Raspberry Pi 3 from 1080i MPEG2 TS to 1080p@30fps H264 MP4 using libav avconv or ffmpeg. Both are using almost idenitical omx.c source file and share the same result.

    The performance is short of 30fps (about 22fps) which makes it unsuitable for live transcoding without reducing the frame rate.

    By timestamping the critical code, I noticed the following :

    1. OMX_EmptyThisBuffer can take 10-20 msec to return. The spec/document indicates that this should be < 5msec. This along would almost account for the performance deficit. Can someone explains why this OMX call is out of spec ?

    2. In omx.c, a zerocopy option is used to optimized the image copying performance. But the precondition (contiguous planes and stride alignment) for this code is never satisfied and this the optimization was never in effect. Can someone explain how this zerocopy optimization can be employed ?

    Additional question on h264_omx encoder : it seems to on accept MP4 or raw H264 output format. How difficult it is to add other format, e.g. TS ?

    Thanks

  • Flac-in-mp4 draft v0.0.0.

    4 octobre 2016, par Ralph Giles
    Flac-in-mp4 draft v0.0.0.

    We’ve been working on a draft spec for encapsulation of FLAC
    
in the ISO Base Media File Format (mp4). This is the initial
    
draft created by Monty Montgomery based on Yusuke Nakamura’s
    
Opus-in-mp4 draft.
    

    More details at https://bugzilla.mozilla.org/show_bug.cgi?id=1286097
    

    Signed-off-by : Erik de Castro Lopo <erikd@mega-nerd.com>
    • [DH] doc/isoflac.txt

  • FFMPEG lossless simple & efficient format

    30 octobre 2016, par Adminy

    I took a sample video and ran this code for each image format like this :

    ffmpeg -i test.mkv png/%d.png
    
ffmpeg -i test.mkv bmp/%d.bmp

    What I noted is that BMP at 1080P has a fixed size of 5.97 MB (6,266,934 bytes)

                                                               !6,220,800

    Then I did some maths :

    1 byte = 2^8 == 256 possible combinations
    
r + g + b form a color (0-255,0-255,0-255)
    
bmp = 3 * 1920 * 1080 = 6,220,800 bytes

    So extra is just the file headers ?! (46134 bytes for just headers ?)

    Next thing I noted that PNG size is dynamic and when the image has a lot of repetition is somewhere 2.5mb. Usually its between 10mb and 12mb.

    Also decoding BMP seemed a lot quicker compared to PNG. So there is no point in even looking at PNG. I would like to know why is it so huge over BMP if it has (zlib) compression factor.

    What is the best format to export to in terms of speed and size, preferred if its as simple as reading the file of color bytes ?

Navigation