Recherche avancée

Médias (91)

Autres articles (55)

  • Gestion générale des documents

    13 mai 2011, par

    MédiaSPIP ne modifie jamais le document original mis en ligne.
    Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
    Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...)

  • List of compatible distributions

    26 avril 2011, par

    The table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
    If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

Sur d’autres sites (5331)

  • Evolution #4146 (Fermé) : Invalideur lors de la publication : facultatif

    26 septembre 2018, par cedric -

    Bon pour commencer la ligne pointée est pas la bonne :)
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/action/editer_objet.php#L118 dit que si on modifie un objet déjà publié, ça invalide le cache, et c’est normal !

    C’est dans https://core.spip.net/projects/spip/repository/entry/spip/ecrire/action/editer_objet.php#L409 que l’on invalide le cache au moment de la publication.

    Et je ne pense vraiment pas qu’il faille changer ça en y mettant des dérogations.
    Par contre, si dans formidable les réponses sont juste stockées en base pour utilisation dans le back-office sans publication côté public, pourquoi leur donner le statut ’publie’ ? Appelons un chat un chat ! Le statut "publie" ça veut bien dire "à caractère publique, affichable sur le site public".

    Dans le cas présent, si tes données ne sont pas publiques, tu les mets en ’modération a priori’ dans la configuration de formidable et elles seront en statut ’proposée’ ce qui corrige tout tes problèmes sans gérer de cas particulier et en gardant la cohérence de tout le fonctionnement de SPIP

  • Why does an "ffmpeg fail" occur when trying to export frames from my "data_src.mp4" file, while using DeepFaceLab ?

    28 août 2020, par Toby Ryberg

    I've been following this step-by-step videoin installing and using DeepFaceLab on my Macbook Pro, which uses OS Catalina. I've been stuck at the step which begins at the 4:42 mark, where he enters this code :

    


    python main.py videoed extract-video —input-file WORKSPACE/data_src.mp4 —output-dir WORKSPACE/data_src

    


    After entering the command, I'm prompted to enter an FPS value ; no problem. Next, it asks for a file output type, which is where I get tied up— as far as I know. It appears as though I can enter either png or jpeg, but receive the same error message, which looks like this :

    


    / !\ ffmpeg fail, job commandline :['ffmpeg', '-i', '/Users/tobyryberg/Documents/deepfakes/DeepFaceLab/WORKSPACE/data_src.mp4', '-pix_fmt', 'rgb24', '/Users/tobyryberg/Documents/deepfakes/DeepFaceLab/WORKSPACE/data_src/%5d.png']

    


    I have no idea what went wrong, as I BELIEVE that I have been doing everything right thus far. If this is at all necessary information, I've opted to use an 18+ minute long video for my source clip, which is an .mp4 file, without audio. If there's someone out there who has the patience to work with me and figure out what went wrong, I'll be forever grateful !

    


  • Revision acf0d56f0b : Get rid of "this_mi", use "mi_8x8[0]" everywhere instead The only case where th

    10 octobre 2013, par Guillaume Martres

    Changed Paths :
     Modify /vp9/common/vp9_blockd.h


     Modify /vp9/common/vp9_findnearmv.c


     Modify /vp9/common/vp9_pred_common.c


     Modify /vp9/common/vp9_pred_common.h


     Modify /vp9/common/vp9_reconinter.c


     Modify /vp9/decoder/vp9_decodemv.c


     Modify /vp9/decoder/vp9_decodframe.c


     Modify /vp9/decoder/vp9_detokenize.c


     Modify /vp9/decoder/vp9_onyxd_if.c


     Modify /vp9/encoder/vp9_bitstream.c


     Modify /vp9/encoder/vp9_encodeframe.c


     Modify /vp9/encoder/vp9_encodemb.c


     Modify /vp9/encoder/vp9_firstpass.c


     Modify /vp9/encoder/vp9_mbgraph.c


     Modify /vp9/encoder/vp9_onyx_if.c


     Modify /vp9/encoder/vp9_quantize.c


     Modify /vp9/encoder/vp9_rdopt.c


     Modify /vp9/encoder/vp9_segmentation.c


     Modify /vp9/encoder/vp9_tokenize.c



    Get rid of "this_mi", use "mi_8x8[0]" everywhere instead

    The only case where they were intentionally pointing to different
    structures was in mbgraph, and this didn't have the expected behavior
    because both of these pointers are used interchangeably through the code

    Change-Id : I979251782f90885fe962305bcc845bc05907f80c

Navigation