Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (58)

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

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, 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 autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (8177)

  • How to close ffplay when video is over ?

    25 juillet 2017, par scrapy

    To get the duration time with ffprobe.

    ffprobe test.mp3 2>&1 | awk -F'[ ,]' '/Duration/{print $4}'
    
00:03:51.05

    To set duration time with -t argument.

    ffplay  -t '231'  test.mp3

    The ffplay command can’t stop when test.mp3 is over.
    How to close ffplay when video is over ?

  • FFMPEG video encoding time increases over time

    8 août 2018, par NStof

    I am creating a fairly basic DVR in C# using the FFMPEG wrapper in Accord.net. Essentially it works by getting the raw frames from the on-board frame grabber, displays the frame on screen and places it in a buffer. In a Separate thread in 20 second intervals, the frames are taken from the buffer and using Accord.Video.FFMPEG.VideoFileWriter.WriteVideoFrame(Bitmap bmp) the frame is encoded and saved to disk. Video is saved in two minute file chunks.
    This works happily for about 24-30 hours, however after that it looks like the average time it takes to encode/save each frame increases to the point where it gets new frames faster than they can be saved. This causes buffer to grow and ends in tears.

    What I would like to know is why does the time it takes to complete the WriteVideoFrame(Bitmap bmp) function increase over time.

    What I think I know so far :
    I do not know if this problem is caused by something in FFMPEG or in the Accord.net wrapper.
    I am reasonably sure it is not caused by hardware. Neither CPU usage nor HDD are working particularly hard. In fact, when I monitor the CPU usage, it does not work any harder or less hard when the encoding time increases.
    When I stop recording (close and dispose all Accord.net objects) and start again, it does not reset the encoding speed. Only when I close the software and start it again does it fix the problem.
    Any thoughts and help with this will be greatly appreciated. If more information is required, please let me know.

  • Revision 32759 : oups, correction : la propagation du env melangeait les parametres du menu ...

    8 novembre 2009, par cedric@… — Log

    oups, correction :
    la propagation du env melangeait les parametres du menu avec le env, ce qui entrainait des effets indesirables.
    On isole le env dans une entree env du contexte du menu, et on expose aussi le menu dynamique

Navigation