Recherche avancée

Médias (2)

Mot : - Tags -/doc2img

Autres articles (85)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

Sur d’autres sites (18436)

  • Revision 81419 : Indentation, un cartel semblable partout des intval au lieu de ...

    11 juin 2018, par kent1@… — Log

    Indentation, un cartel semblable partout
    des intval au lieu de sql_quote sur les id_article
    La bonne url de documentation
    Version 1.0.6

  • Revision cc7d981de1 : Merge "Add skin detection."

    12 février 2015, par Marco

    Merge "Add skin detection."

  • 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 ?

    


Navigation