Recherche avancée

Médias (16)

Mot : - Tags -/mp3

Autres articles (60)

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

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

Sur d’autres sites (9724)

  • Unmapping memory-mapped images that are created during processing

    23 avril 2013, par user2309283

    I have a pretty big issue, although I only have the symptoms, and a theory on the cause.

    I have a C++ application under Windows 7x64 that uses system calls to FFMPEG 0.7.13 to extract frames from videos. When running, the parent application maintains a nice, predicable memory footprint in memory profilers (task manager, RAMMap) of about 2MB. I can see the individual calls to FFMPEG also come and go without incident. The trouble is, after about 100 calls to FFMPEG, and 70,000+ PNGs created (no one directory has more than 1500 pngs), the Windows memory page size raises gradually from about 2.5GB to over 7.0GB, and the system is brought to its knees. The sum of the processes for all users is no where near the reported Memory Page amount.

    I thought it might be Windows Search indexing related, so I turned off the indexing for the output directories in question using SetFileAttributes() and FILE_ATTRIBUTE_NOT_CONTENT_INDEXED, and while it seems to be working as advertised, it does not seem to combat the issue at hand. My current running theory is that all of these extracted PNGs are either fully or partially memory mapped, by FFMPEG or something else. I can also see the output PNGs under the RAMMap Physical Pages tab as standby mapped files.

    Question :
    - Is there enough information here to possibly diagnose the exact problem ?
    - Do I have a way to combat this issue ?

    Thanks in advance...

  • avcodec/e ?ac3enc : Inform compiler about PutBitContext being blank

    24 mai 2024, par Andreas Rheinhardt
    avcodec/e ?ac3enc : Inform compiler about PutBitContext being blank

    This turned out to be very beneficial : For GCC 13, the codesize
    
of ac3_output_frame_header went down from 4522B to 1247B and
    
from 10762B to 9298B for eac3_output_frame_header. For Clang 17,
    
the numbers went down from 3923B to 2477B and from 8338B to 6548B
    
(always with -O3).
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/ac3enc.c
    • [DH] libavcodec/eac3enc.c

  • Revert "x86/videodsp : add emulated_edge_mc_mmxext"

    28 juin 2014, par Michael Niedermayer
    Revert "x86/videodsp : add emulated_edge_mc_mmxext"

    The commit causes minor out of array reads and was mainly intended for
    
future optimizations which turned out not to be meassurably faster.
    
Itself it was just 1 cpu cycle faster
    

    Approved-by : jamrial
    

    This reverts commit 057d2704e78b52fec357b4fc646c9de37a085413.
    • [DH] libavcodec/x86/videodsp.asm
    • [DH] libavcodec/x86/videodsp_init.c

Navigation