Recherche avancée

Médias (91)

Autres articles (62)

  • Les statuts des instances de mutualisation

    13 mars 2010, par

    Pour des raisons de compatibilité générale du plugin de gestion de mutualisations avec les fonctions originales de SPIP, les statuts des instances sont les mêmes que pour tout autre objets (articles...), seuls leurs noms dans l’interface change quelque peu.
    Les différents statuts possibles sont : prepa (demandé) qui correspond à une instance demandée par un utilisateur. Si le site a déjà été créé par le passé, il est passé en mode désactivé. publie (validé) qui correspond à une instance validée par un (...)

  • Le plugin : Gestion de la mutualisation

    2 mars 2010, par

    Le plugin de Gestion de mutualisation permet de gérer les différents canaux de mediaspip depuis un site maître. Il a pour but de fournir une solution pure SPIP afin de remplacer cette ancienne solution.
    Installation basique
    On installe les fichiers de SPIP sur le serveur.
    On ajoute ensuite le plugin "mutualisation" à la racine du site comme décrit ici.
    On customise le fichier mes_options.php central comme on le souhaite. Voilà pour l’exemple celui de la plateforme mediaspip.net :
    < ?php (...)

  • Problèmes fréquents

    10 mars 2010, par

    PHP et safe_mode activé
    Une des principales sources de problèmes relève de la configuration de PHP et notamment de l’activation du safe_mode
    La solution consiterait à soit désactiver le safe_mode soit placer le script dans un répertoire accessible par apache pour le site

Sur d’autres sites (6734)

  • x264 encoding taking longer when encoding static frames (than

    14 septembre 2015, par Danilo

    ​Hi,
    I’m using x264 for live video streaming and I’ve noticed that the thread
    responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

    This seems somewhat counter intuitive to me, as I would expect x264 to use
    more processing power when encoding complex scenes other then static ones.

    My encoder settings are the following :

    1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
    
me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
    
8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
    
sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
    
constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
    
intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
    
qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

    I created a github gist based on the example.c encoder bundled in x264’s
    source code and tested encoding times with it. (You can find it here :
    https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

    Average encoding time for the static scene is 38% bigger than for a scene
    with movements. (You can find my test case and also the output from my test
    encoder on the link above).

    ​​
    ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

    ​
    ​Could anyone, please, shed some light on the reasons for this odd behavior ?
    ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​

  • lavfi/eq : rework expression evaluation

    13 mars 2015, par arwa arif
    lavfi/eq : rework expression evaluation

    In particular, add support for t, pos, n, r parameters, and add an eval
    
mode option.
    

    Also, partially reword option documentation.
    

    With several major edit by Stefano Sabatini.
    

    Signed-off-by : Stefano Sabatini <stefasab@gmail.com>
    • [DH] doc/filters.texi
    • [DH] libavfilter/version.h
    • [DH] libavfilter/vf_eq.c
    • [DH] libavfilter/vf_eq.h

  • avfilter/avfiltergraph : Avoid allocation for AVFilterGraphInternal

    10 février 2024, par Andreas Rheinhardt
    avfilter/avfiltergraph : Avoid allocation for AVFilterGraphInternal

    To do this, allocate AVFilterGraphInternal jointly with AVFilterGraph
    
and rename it to FFFilterGraph in the process (similarly to
    
AVStream/FFStream).
    
The AVFilterGraphInternal* will be removed on the next major version
    
bump.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavfilter/avfilter.c
    • [DH] libavfilter/avfilter_internal.h
    • [DH] libavfilter/avfiltergraph.c
    • [DH] libavfilter/pthread.c

Navigation