Recherche avancée

Médias (0)

Mot : - Tags -/xml-rpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (101)

  • Submit enhancements and plugins

    13 avril 2011

    If you have developed a new extension to add one or more useful features to MediaSPIP, let us know and its integration into the core MedisSPIP functionality will be considered.
    You can use the development discussion list to request for help with creating a plugin. As MediaSPIP is based on SPIP - or you can use the SPIP discussion list SPIP-Zone.

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

Sur d’autres sites (11777)

  • Internecine Legal Threats

    1er juin 2011, par Multimedia Mike — Legal/Ethical

    FFmpeg and associated open source multimedia projects such as xine, MPlayer, and VLC have long had a rebel mystique about them ; a bunch of hackers playing fast and loose with IP law in order to give the world the free multimedia experience it deserved. We figured out the algorithms using any tools available, including the feared technique of binary reverse engineering. When I gave a presentation about FFmpeg at Linuxtag in 2007, I created this image illustrating said mystique :



    It garnered laughs. But I made the point that we multimedia hackers just press on, doing our thing while ignoring legal threats. The policy has historically worked out famously for us– to date, I seem to be the only person on the receiving end of a sort-of legal threat from the outside world.

    Who would have thought that the most credible legal threat to an open source multimedia project would emanate from a fork of that very project ? Because that’s exactly what has transpired :



    Click for full threat

    So it came to pass that Michael Niedermayer — the leader of the FFmpeg project — received a bona fide legal nastygram from Mans Rullgard, a representative of the FFmpeg-forked Libav project. The subject of dispute is a scorched-earth matter involving the somewhat iconic FFmpeg zigzag logo :

     
    Original 2D logo enhanced 3D logo

    To think of all those years we spent worrying about legal threats from organizations outside the community. I’m reminded of that time-honored horror trope/urban legend staple : Get out ! The legal threats are coming from inside the house !

    I’m interested to see how this all plays out, particularly regarding jurisdiction, as we have a U.K. resident engaging an Italian lawyer outfit to deliver a legal threat to an Austrian citizen regarding an image hosted on a server in Hungary. I suspect I know why that law firm was chosen, but it’s still a curious jurisdictional setup.

    People often used to ask me if we multimedia hackers would get sued to death for doing what we do. My response was always, “There’s only one way to know for sure,” by which I meant that we would just have to engage in said shady activities and determine empirically if lawsuits resulted. So I’m a strong advocate for experimentation to push the limits. Kudos to Michael and Mans for volunteering to push the legal limits.

  • aacenc_tns : clamp filter direction energy measurement

    8 février, par Lynne
    aacenc_tns : clamp filter direction energy measurement

    The issue is that :
    

    float en[2] ;
    
...
    
tns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3 ;
    
for (g = 0 ; g < tns->n_filt[w] ; g++) 
    
    tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g] ;
    

    When using the AAC Main profile, n_filt = 3, and slant is by
    
default 2 (normal long frames), g can go above 1.
    

    en is the evolution of energy in the frequency domain for every
    
band at the given window. E.g. whether the energy is concentrated
    
at the top of each band, or the bottom.
    

    For 2-pole filters, its straightforward.
    
For 3-pole filters, we need more than 2 measurements.
    

    This commit properly implements support for 3-pole filters, by measuring
    
the band energy across three areas.
    

    Do note that even xHE-AAC caps n_filt to 2, and only AAC Main allows
    
n_filt == 3.
    

    Fixes https://trac.ffmpeg.org/ticket/11418
    • [DH] libavcodec/aacenc_tns.c

  • avcodec/amfdec,rkmppdec : Use correct extradata with BSFs

    11 juin, par Andreas Rheinhardt
    avcodec/amfdec,rkmppdec : Use correct extradata with BSFs

    Otherwise the extradata used would be ISOBMFF if the input is
    
even though we use the *_mp4toannexb BSFs to convert it to
    
annex B to feed it to the actual decoder.
    

    (The mediacodec decoders also use said BSFs, yet they process
    
the extradata in a way that works even when using the ISOBMFF
    
extradata ; in fact, using the converted extradata would break
    
their check for whether to warn for missing extradata for
    
the ISOBMFF without-in-band-header profiles.
    

    Furthermore, there are several users of the *_mp4toannexb BSFs
    
that don't ever touch extradata. They have not been touched.)
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/amfdec.c
    • [DH] libavcodec/decode_bsf.h
    • [DH] libavcodec/rkmppdec.c

Navigation