Recherche avancée

Médias (91)

Autres articles (52)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

Sur d’autres sites (8703)

  • aarch64 : vp8 : Fix assembling with clang

    31 janvier 2019, par Martin Storsjö
    aarch64 : vp8 : Fix assembling with clang

    This also partially fixes assembling with MS armasm64 (via
    
gas-preprocessor).
    

    The movrel macro invocations need to pass the offset via a separate
    
parameter. Mach-o and COFF relocations don’t allow a negative
    
offset to a symbol, which is handled properly if the offset is passed
    
via the parameter. If no offset parameter is given, the macro
    
evaluates to something like "adrp x17, subpel_filters-16+(0)", which
    
older clang versions also fail to parse (the older clang versions
    
only support one single offset term, although it can be a parenthesis.
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DBH] libavcodec/aarch64/vp8dsp_neon.S

  • ffmpeg streaming to youtube slow

    1er avril 2017, par boygiandi

    I’m trying to send a video file to youtube as livestreaming. The stream command look like this

    ffmpeg -re -i "/tmp/4745.mkv" -acodec aac -pix_fmt yuv420p -bufsize 6000k -vb 400k -maxrate 1500k -deinterlace -vcodec libx264 -preset fast -g 60 -r 30 -crf 1 -f flv "rtmp ://...."

    The last line of output log look like this

    [ sh : 2017-04-01 7:19:54 ]size= 242706kB time=00:21:08.11 bitrate=1567.9kbits/s speed=0.882x

    As I understand, the speed=0.882x mean it send data to youtube slower than expected ( 1x mean streaming fine, lower mean buffering ). I tried to change some params of ffmpeg command, like change -preset fast to superfast, ultrafast : it faster but quality very bad and I still can’t control the out put speed. Sometime it’s 1x, sometime lower.
    Note that I run more than 1 ffmpeg instants at the same time, it may problem of CPU, RAM or Network, I checked them all.

    • CPU 40% ( top command )
    • RAM used 3Gb/7Gb
    • Network upload Avg : 8.45 MBit/s ( Max Upload : 70.76 Mbit/s - speedtest )

    So I don’t know what’s problem. Anyone can help ?

  • pthread_frame : use better memory orders for frame progress

    9 décembre 2016, par Wan-Teh Chang
    pthread_frame : use better memory orders for frame progress

    This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
    

    In ff_thread_report_progress(), the fast code path can load
    
progress[field] with the relaxed memory order, and the slow code path
    
can store progress[field] with the release memory order. These changes
    
are mainly intended to avoid confusion when one inspects the source code.
    
They are unlikely to have measurable performance improvement.
    

    ff_thread_report_progress() and ff_thread_await_progress() form a pair.
    
ff_thread_await_progress() reads progress[field] with the acquire memory
    
order (in the fast code path). Therefore, one expects to see
    
ff_thread_report_progress() write progress[field] with the matching
    
release memory order.
    

    In the fast code path in ff_thread_report_progress(), the atomic load of
    
progress[field] doesn’t need the acquire memory order because the
    
calling thread is trying to make the data it just decoded visible to the
    
other threads, rather than trying to read the data decoded by other
    
threads.
    

    In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
    
atomic_init().
    

    Signed-off-by : Wan-Teh Chang <wtc@google.com>
    
Signed-off-by : Anton Khirnov <anton@khirnov.net>
    • [DBH] libavcodec/pthread_frame.c

Navigation