Recherche avancée

Médias (0)

Mot : - Tags -/acrobat

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

Autres articles (111)

  • Récupération d’informations sur le site maître à l’installation d’une instance

    26 novembre 2010, par

    Utilité
    Sur le site principal, une instance de mutualisation est définie par plusieurs choses : Les données dans la table spip_mutus ; Son logo ; Son auteur principal (id_admin dans la table spip_mutus correspondant à un id_auteur de la table spip_auteurs)qui sera le seul à pouvoir créer définitivement l’instance de mutualisation ;
    Il peut donc être tout à fait judicieux de vouloir récupérer certaines de ces informations afin de compléter l’installation d’une instance pour, par exemple : récupérer le (...)

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

  • Ajouter notes et légendes aux images

    7 février 2011, par

    Pour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
    Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
    Modification lors de l’ajout d’un média
    Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)

Sur d’autres sites (11694)

  • Revision 5a3e3c6d3f : Adaptive txfm size selection depending on residual sse/variance This commit ena

    26 juin 2014, par Jingning Han

    Changed Paths :
     Modify /vp9/encoder/vp9_encodeframe.c


     Modify /vp9/encoder/vp9_pickmode.c


     Modify /vp9/encoder/vp9_speed_features.c



    Adaptive txfm size selection depending on residual sse/variance

    This commit enables an adaptive transform size selection method
    for speed -6. It uses largest transform size when the sse is more
    than 4 times of variance, i.e., most energy is compacted in the
    DC coefficient. Otherwise, use the default TX_8X8. It improves
    the compression efficiency for rtc set of speed -6 by 0.8%, no
    speed change observed.

    Change-Id : Ie6ed1e728ff7bf88ebe940a60811361cdd19969c

  • How to re-encode an audio to match another one, to avoid re-encoding the whole audio

    21 mars 2024, par Bernard Wiesner

    I have an audio editor in the browser using ffmpeg (WebAssembly), and I want to insert new audio into the existing audio without having to re-encode everything. Re-encoding everything takes a long time, especially in the browser, so I would like to only re-encode the inserted file, match it to the original one and concatenate them using the copy command.

    


    On ffmpeg concatenate docs it says :

    


    


    All files must have the same streams (same codecs, same time base, etc.)

    


    


    But it is not clear what is meant by time base. So far I have observed I need to match :

    


      

    • codec

      • 


    • bit rate

      • 


    • sample rate

      • 


    • channels (mono, stereo)

      • 


    


    Is there anything else I need to match so that the resulting audio is not corrupt/broken when concatenating ?

    


    I have observed with mp3 for example it has VBR, CBR, and ABR. If the original audio has a bit rate of 128 kb/s, I am assuming it is a CBR, so I match it with :

    


    ffmpeg -i original.mp3
# > Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s

ffmpeg -i input.mp3 -b:a 128k -ar 44100 -ac 2 re_encoded.mp3

# then merge
# concat_list.txt contains the original audio and the re_encoded.mp3

ffmpeg -f concat -i concat_list.txt -safe 0 -c copy merged.mp3


    


    And that works fine for CBR such as 8, 16, 24, 32, 40, 48, 64, 80, 96, 112, 128, 160, 192, 224, 256, or 320 (docs), as far as I have tested.

    


    The issue is when the original.mp3 has a VBR (variable bit rate) or ABR, such as 150 kb/s.

    


    If I try to match it like below :

    


    ffmpeg -i input.mp3 -b:a 150k -ar 44100 -ac 2 re_encoded.mp3
ffmpeg -i re_encoded.mp3
# Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 160 kb/s


    


    The resulting bitrate is rounded to the nearest CBR which is 160.

    


    I can solve this with mp3 by using -abr 1 :

    


    ffmpeg -i input.mp3 -abr 1 -b:a 150k -ar 44100 -ac 2 re_encoded.mp3
ffmpeg -i re_encoded.mp3
# Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 150 kb/s


    


    Now the bitrate matches the original audio, however I am not sure this is correct since I am modifying the new audio to an ABR and concatenating it with a VBR ? I am not even sure how to check with ffmpeg if the audio is VBR, CBR or ABR, or if that even matters when concatenating.

    


    Another issue also happens with aac files. When I try to match the original audio bitrate I can't.

    


    ffmpeg -i input.mp3 -b:a 128k -ar 44100 -ac 2 re_encoded.aac
ffmpeg -i re_encoded.aac
# Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp, 135 kb/s


    


    The resulting bitrate always seems to be variable (135 in this case), and hence I can't match it to the original one.

    


    So my question is, what conditions need to be met when concatenating audios with different streams, and how can I achieve re-encoding only one audio to match the other one. Or if there is some package that can do this, it would be of great help.

    


  • Revision 9922e4344a : Enable Hadamard transform based cost estimate for all block sizes This commit t

    3 avril 2015, par Jingning Han

    Changed Paths :
     Modify /vp9/encoder/vp9_pickmode.c



    Enable Hadamard transform based cost estimate for all block sizes

    This commit turns on the Hadamard transform based rate distortion
    estimate for all block sizes in RTC coding mode. It conditionally
    skips the rate distortion estimation if all zero block flag is set
    on. No significant encoding speed change is observed. The
    compression performance of speed -6 is improved by 1.7% over using
    it only for block sizes of 32x32 and below.

    Change-Id : I768145e6f05c737b05b5b5f1ee674e929532cafb

Navigation