Recherche avancée

Médias (0)

Mot : - Tags -/optimisation

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (76)

  • Configuration spécifique d’Apache

    4 février 2011, par

    Modules spécifiques
    Pour la configuration d’Apache, il est conseillé d’activer certains modules non spécifiques à MediaSPIP, mais permettant d’améliorer les performances : mod_deflate et mod_headers pour compresser automatiquement via Apache les pages. Cf ce tutoriel ; mode_expires pour gérer correctement l’expiration des hits. Cf ce tutoriel ;
    Il est également conseillé d’ajouter la prise en charge par apache du mime-type pour les fichiers WebM comme indiqué dans ce tutoriel.
    Création d’un (...)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Participer à sa documentation

    10 avril 2011

    La documentation est un des travaux les plus importants et les plus contraignants lors de la réalisation d’un outil technique.
    Tout apport extérieur à ce sujet est primordial : la critique de l’existant ; la participation à la rédaction d’articles orientés : utilisateur (administrateur de MediaSPIP ou simplement producteur de contenu) ; développeur ; la création de screencasts d’explication ; la traduction de la documentation dans une nouvelle langue ;
    Pour ce faire, vous pouvez vous inscrire sur (...)

Sur d’autres sites (5124)

  • Extremely slow ffmpeg/sws_scale() - only on heavy duty

    28 septembre 2020, par user2328447

    I am writing a video player using ffmpeg (Windows only, Visual Studio 2015, 64 bit compile).
With common videos (up to 4K @ 30FPS), it works pretty good. But with my maximum target - 4K @ 60FPS, it fails. Decoding still is fast enough, but when it comes to YUV/BGRA conversion it is simply not fast enough, even though it's done in 16 threads (one thread per frame on a 16/32 core machine).

    



    So as a first countermeasure I skipped the conversion of some frames and got a stable frame rate of 40 that way. Comparing the two versions in Concurrency Visualizer, I found a strange issue I don't know the reason of.

    



    .

    



    Here's an image of the frameskip version :
enter image description here
You see that the conversion is pretty quick (average roughly 35ms)
Thus, as multiple threads are used, it also should be quick enough for 60FPS, but it isn't !

    



    .

    



    The image of the non-frameskip version shows why :
enter image description here
The conversion of a single frame has become ten times slower than before (average roughly 350ms). Now a heavy workload on many cores would of course cause a minor slowdown per core due to reduced turbo - let's say 10 or 20%. But never an extreme slowdown of 1000%.

    



    .

    



    Interesting detail is, that the stack trace of the non-frameskip version shows some system activity I don't really understand - beginning with ntoskrnl.exe!KiPageFault+0x373. There are no exceptions, other error messages or such - it just becomes extremely slow.

    



    Edit : A colleague just told me that this looks like a memory problem with paged-out memory at first glance - but my memory utilization is low (below 1GB, and more than 20GB free)

    



    Can anyone tell me what could be causing this ?

    


  • Revision 15801 : Formulation française cohérente avec le reste des options de conf ...

    20 juin 2010, par da@… — Log

    Formulation française cohérente avec le reste des options de conf (infinitifs)

  • dnn_backend_native_layer_mathunary : add sinh support

    29 juin 2020, par Ting Fu
    dnn_backend_native_layer_mathunary : add sinh support

    Signed-off-by : Ting Fu <ting.fu@intel.com>
    • [DH] libavfilter/dnn/dnn_backend_native_layer_mathunary.c
    • [DH] libavfilter/dnn/dnn_backend_native_layer_mathunary.h
    • [DH] tools/python/convert_from_tensorflow.py
    • [DH] tools/python/convert_header.py

Navigation