Recherche avancée

Médias (0)

Mot : - Tags -/interaction

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

Autres articles (61)

  • Pas question de marché, de cloud etc...

    10 avril 2011

    Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
    sur le web 2.0 et dans les entreprises qui en vivent.
    Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
    Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
    le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
    Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...)

  • Activation de l’inscription des visiteurs

    12 avril 2011, par

    Il est également possible d’activer l’inscription des visiteurs ce qui permettra à tout un chacun d’ouvrir soit même un compte sur le canal en question dans le cadre de projets ouverts par exemple.
    Pour ce faire, il suffit d’aller dans l’espace de configuration du site en choisissant le sous menus "Gestion des utilisateurs". Le premier formulaire visible correspond à cette fonctionnalité.
    Par défaut, MediaSPIP a créé lors de son initialisation un élément de menu dans le menu du haut de la page menant (...)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

Sur d’autres sites (5953)

  • Merge commit ’d347a7b248d4ffdc278373fecf033b0ade030343’

    5 octobre 2013, par Michael Niedermayer
    Merge commit ’d347a7b248d4ffdc278373fecf033b0ade030343’
    

    * commit ’d347a7b248d4ffdc278373fecf033b0ade030343’ :
    ismindex : Use the individual stream duration instead of the global one

    Merged-by : Michael Niedermayer <michaelni@gmx.at>

    • [DH] tools/ismindex.c
  • How to interpret ndarray in a pyAV AudioFrame ?

    30 janvier 2024, par Sachin Dole

    I want to process streaming audio (coming in from a person speaking on the peer of a webRTC peer connection) to detect when the person is done talking. I have got the audio track and access to individual frames. I see that each frame can be converted to an nd_array using Frame.to_ndarray. I can also see values in the ndarray changing depending on what the person is speaking, what pitch, what volume etc. Now, I want to detect silence on the stream. My question is what is in the ndarray and how can I make sense of the data ?

    &#xA;

            while True:&#xA;            try:&#xA;                frame:AudioFrame = await track.recv()&#xA;                frame_nd_array = frame.to_ndarray() &#xA;

    &#xA;

    Where can I learn what is in the frame_nd_array ?

    &#xA;

  • avcodec/dcahuff : Combine tables, use ff_init_vlc_from_lengths()

    6 septembre 2022, par Andreas Rheinhardt
    avcodec/dcahuff : Combine tables, use ff_init_vlc_from_lengths()
    

    Up until now, initializing the dca VLC tables uses ff_init_vlc_sparse()
    with length tables of type uint8_t and code tables of type uint16_t
    (except for the LBR tables, which uses length and symbols of type
    uint8_t ; these tables are interleaved). In case of the quant index
    codebooks these arrays were accessed via tables of pointers to the
    individual tables.

    This commit changes this : First, we switch to ff_init_vlc_from_lengths()
    to replace the uint16_t code tables by uint8_t symbol tables
    (this necessitates ordering the tables from left-to-right in the tree
    first). These symbol tables are interleaved with the length tables.

    Furthermore, these tables are combined in order to remove the table of
    pointers to individual tables, thereby avoiding relocations (for x64
    elf systems this amounts to 96*24B = 2304B saved in .rela.dyn) and
    saving 1280B from .data.rel.ro (for 64bit systems). Meanwhile the
    savings in .rodata amount to 2709 + 2 * 334 = 3377B. Due to padding
    the actual savings are higher : The ELF x64 ABI requires objects >= 16B
    to be padded to 16B and lots of the tables have 2^n + 1 elements
    of these were from replacing uint16_t codes with uint8_t symbols ;
    the rest was due to the fact that combining the tables eliminated
    padding (the ELF x64 ABI requires objects >= 16B to be padded to 16B
    and lots of the tables have 2^n + 1 elements)). Taking this into
    account gives savings of 4548B. (GCC by default uses an even higher
    alignment (controlled by -malign-data) ; for it the savings are 5748B.)

    These changes also necessitated to modify the init code for
    the encoder tables.

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

    • [DH] libavcodec/dcaenc.c
    • [DH] libavcodec/dcahuff.c
    • [DH] libavcodec/dcahuff.h