Recherche avancée

Médias (1)

Mot : - Tags -/MediaSPIP 0.2

Autres articles (85)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • Organiser par catégorie

    17 mai 2013, par

    Dans MédiaSPIP, une rubrique a 2 noms : catégorie et rubrique.
    Les différents documents stockés dans MédiaSPIP peuvent être rangés dans différentes catégories. On peut créer une catégorie en cliquant sur "publier une catégorie" dans le menu publier en haut à droite ( après authentification ). Une catégorie peut être rangée dans une autre catégorie aussi ce qui fait qu’on peut construire une arborescence de catégories.
    Lors de la publication prochaine d’un document, la nouvelle catégorie créée sera proposée (...)

  • 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 (...)

Sur d’autres sites (5490)

  • Anomalie #4692 : Utilisation de memoization en remplacement de xcache si disponible pour retrouver...

    9 mars 2021, par cedric -

    Oui et non : quand on a un filesystem qui est en de type NFS sur les mutus ou "cloud" le gain commence à être très marginal, et par ailleurs filecache créé un nombre fini de slots pour ne pas avoir à gérer la purge, et si on l’utilise a tort et à travers pour des broutilles on va donc écraser les slots des cache SPIP qui sont très couteux à calculer par des cache de résultat de fonction (qui sont bien moins couteux) et au final on y perdra largement.

    La fonction cache_me() de memoization ne fait pas le distinguo de savoir quelle méthode de cache est dispo, si c’est un cache mémoire rapide et "infini" ou un cache disque lent à utiliser avec parcimonie (et idéalement c’est pas elle qui doit le faire, mais chaque méthode qui devrait elle même déclarer dans quelle catégorie elle se place)

  • Revision df90d58f4f : Speed up motion estimation using small partitions' result(experiment) Current p

    3 juillet 2013, par Yunqing Wang

    Changed Paths :
     Modify /vp9/encoder/vp9_block.h


     Modify /vp9/encoder/vp9_encodeframe.c


     Modify /vp9/encoder/vp9_onyx_if.c


     Modify /vp9/encoder/vp9_onyx_int.h


     Modify /vp9/encoder/vp9_rdopt.c



    Speed up motion estimation using small partitions' result(experiment)

    Current partition checking starts from small sizes, and then goes up
    to large sizes. This experiment uses the small partitions' motion
    estimation result, which is already available, to speed up the
    large partition's motion estimation. We can decide to skip some
    patition checkings if they are unlikely choices. We could use the
    motion vector(MV) result as current partition's prediction MV, limit
    the search range and reference frame.

    Current result at speed 1 :
    psnr loss : 1.19% for stdhd, 0.287% for derf.
    speed gain : 14% for sunflower(hd), 11% for akiyo.

    Further improvement will be done later.

    Change-Id : I5abfd070e9cace2e91e2a0247d1325df313887ab

  • Revision d8b0d40bf6 : Allow blocks to directly copy motion information from neighbors A new set of pr

    29 août 2014, par Yue Chen

    Changed Paths :
     Modify /configure


     Modify /vp9/common/vp9_blockd.h


     Modify /vp9/common/vp9_entropymode.c


     Modify /vp9/common/vp9_entropymode.h


     Modify /vp9/common/vp9_mvref_common.c


     Modify /vp9/common/vp9_mvref_common.h


     Modify /vp9/common/vp9_pred_common.c


     Modify /vp9/common/vp9_pred_common.h


     Modify /vp9/decoder/vp9_decodeframe.c


     Modify /vp9/decoder/vp9_decodemv.c


     Modify /vp9/encoder/vp9_bitstream.c


     Modify /vp9/encoder/vp9_encodeframe.c


     Modify /vp9/encoder/vp9_encoder.h


     Modify /vp9/encoder/vp9_rdopt.c



    Allow blocks to directly copy motion information from neighbors

    A new set of prediction modes, called copy modes, is implemented
    to allow blocks to directly copy motion information from a neighbor.
    The motivation is to create regions of arbitrary shapes in which
    blocks share same motion parameters and hence to save bits spent on
    duplicated side information.
    Compression gain :
    derf : 0.894% ; stdhd : 1.513%.

    Change-Id : I5e026b12c902bc6985c199ec38f1b3b67ac7d930

Navigation