Recherche avancée

Médias (91)

Autres articles (51)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • 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 ;

  • Ecrire une actualité

    21 juin 2013, par

    Présentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
    Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
    Vous pouvez personnaliser le formulaire de création d’une actualité.
    Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)

Sur d’autres sites (11240)

  • h264_mp4toannexb : Copy one NAL unit at a time

    14 décembre 2019, par Andreas Rheinhardt
    h264_mp4toannexb : Copy one NAL unit at a time

    If processing an input NAL unit triggers the insertion of data from
    
extradata in front of said NAL unit, the output packet is grown (i.e.
    
reallocated) once to accomodate both the new extradata as well as the
    
input NAL unit itself ; this has been changed : In such a situation, the
    
packet is now grown twice. While this is bad for performance, it allows
    
to simplify the code and ultimately to stop reallocating the packet
    
altogether.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/h264_mp4toannexb_bsf.c

  • Revision 509fb0bc9d : mips msa vp8 copy mem optimization average improvement 2x-4x Change-Id : I3af3

    23 juillet 2015, par Parag Salasakar

    Changed Paths :
     Add /vp8/common/mips/msa/copymem_msa.c


     Modify /vp8/common/mips/msa/vp8_macros_msa.h


     Modify /vp8/common/rtcd_defs.pl


     Modify /vp8/vp8_common.mk



    mips msa vp8 copy mem optimization

    average improvement 2x-4x

    Change-Id : I3af3ecced96c5b8e0cb811256e5089e28fe013a2

  • ffmpeg - pts drift after seek with codec copy

    24 mars 2021, par Andrey Rikunov

    There are two ffmpeg commands. First one is used to seek and copy video chunk. Second one is used to transcode video chunk applying select filter for exact frames match.

    &#xA;

    Here is how :

    &#xA;

      &#xA;
    1. ffmpeg -ss  -to  -copyts -i <input /> -map 0:v:0 -c copy chunk.mp4

      2. &#xA;

    2. ffmpeg -copyts -i chunk.mp4 -vf &#x27;select=between(pts\,\,)&#x27; transcoded_cunk.mp4

      3. &#xA;

    &#xA;

    It works fine most of the times. But for some inputs there is a little pts drift in downloaded chunk so missing frames is possible. In other words pts of the same packets (compared by hash) are shifted by several points (in my case 0,0002 sec) between input and chunked output.

    &#xA;

    What is the possible reason for such pts drift ?

    &#xA;

    UPDATE 1 : That's because ffmpeg set timescale=1000 in mvhd atom so edit list media time to start from looses precision. Is it possible to force mvhd timescale ?

    &#xA;

    UPDATE 2 : It's not possible to change mvhd timescale because ffmpeg uses constant (MOV_TIMESCALE 1000) :

    &#xA;

    https://github.com/FFmpeg/FFmpeg/blob/82bd02a2c73bb5e6b7cf5e5eba486e279f1a7358/libavformat/movenc.c#L3498

    &#xA;

    UPDATE 3 : same issue discussed earlier

    &#xA;

Navigation