Recherche avancée

Médias (91)

Autres articles (78)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

Sur d’autres sites (11541)

  • pictor : Correctly check frame dimensions

    7 février 2017, par Michael Niedermayer
    pictor : Correctly check frame dimensions

    Fixes : 559/clusterfuzz-testcase-6424225917173760
    
Bug-Id : CVE-2017-7862
    
CC : libav-stable@libav.org
    

    Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    
(cherry picked from commit 8c2ea3030af7b40a3c4275696fb5c76cdb80950a)
    
Signed-off-by : Diego Biurrun <diego@biurrun.de>
    • [DBH] libavcodec/pictordec.c

  • version.sh : Print versions based on the last git tag for release branches

    28 juillet 2014, par Michael Niedermayer
    version.sh : Print versions based on the last git tag for release branches

    release branches are detected by checking if "git" is not in RELEASE
    
This changes "N-64706-g2f71aeb" to "n2.3-8-g2f71aeb"
    
for git master theres no change
    

    This should improve the readability of lists of versions which come from
    
more than 1 release branch or master + release. fate.ffmpeg.org is
    
one possible example
    

    Reviewed-by : Timothy Gu <timothygu99@gmail.com>
    
Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
    
(cherry picked from commit ee606fd0317df202b59946cf9b738c0a01056316)
    

    Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
    • [DH] version.sh

  • Stream RTSP to HTML5 Video - which is the best approach ?

    13 janvier 2020, par Daniel

    As this task is very complicated I’ve created two approaches and I’d like to know which is the better approach for my purpose.

    Approach 1 :

    H264 frames are grabbed out of RTSP stream on the server (i.e. by ffmpeg), then they are put into a websocket and sent to the client. Client uses mp4box.js to fragment the h264 and then HTML5 video can render it with MSE.

    Approach 2 :

    H264 frames are grabbed out of RTSP stream and also fragmented on the server (i.e. by ffmpeg), then they are transferred directly to the client’s HTML5 video to render it with MSE.
    Here is an example for this approach.

    If we consider today’s client devices (modern phones, notebooks), we can state approach1 would be a better solution because it would prevent the central load on the server.

    However I have not really found any good resource or material on how to use approach1, hence I could not yet tried it out.

    I would like to know if approach1 is really better than approach2 ?

    because maybe grabbing and fragmenting would not put much higher load on the server than grabbing only

    (why I’m asking this ? because for approach2 I’ve a concrete example, whereas for approach1 I don’t. If approach1 is really better, I’ll go for it and implement the whole thing.)

    To put it more exact : does ffmpeg stress the server more if it grabs and fragments an rtsp-h264 stream to fmp4 than when it only grabs the frames from rtsp-h264 stream ?

Navigation