Recherche avancée

Médias (91)

Autres articles (62)

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

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • MediaSPIP Init et Diogène : types de publications de MediaSPIP

    11 novembre 2010, par

    À l’installation d’un site MediaSPIP, le plugin MediaSPIP Init réalise certaines opérations dont la principale consiste à créer quatre rubriques principales dans le site et de créer cinq templates de formulaire pour Diogène.
    Ces quatre rubriques principales (aussi appelées secteurs) sont : Medias ; Sites ; Editos ; Actualités ;
    Pour chacune de ces rubriques est créé un template de formulaire spécifique éponyme. Pour la rubrique "Medias" un second template "catégorie" est créé permettant d’ajouter (...)

Sur d’autres sites (3602)

  • FFmpeg : Is it better to make a application then using ffmepg directly

    14 juillet 2020, par Mirabeau

    For all my IP camera streams, I use, under Linux, ffmpeg by a bash script which allows me at the same time to manage :

    


    1/ Convert the RTSP streams to HTTP (HLS) for the "Live" and therefore which generates "m3u8" file and *.ts segments

    


    2/ Backup the stream for archiving (in increments of 5 minutes), a cron remove older files (xx days)

    


    ffmpeg -i "rtsp://[IP_CAM01]" -rtsp_transport tcp -c copy -map 0 -f segment -segment_time 300 -segment_atclocktime 1 -segment_format mkv "cam01-% 03d.mkv" -c copy -f segment -segment_list cam01.m3u8 -segment_list_flags + live -segment_time 2 -segment_list_size 20 -segment_wrap 20 cam01-% 03d.ts


    


    The question I ask myself, and the reason for this message is as follows :

    


      

    • would there be an interest (memory / cpu / speed) to develop a program (C/C++/other ?) to do the same thing by using the libraries of ffmpeg ?
    • 


    • or the "gain" and the interest would be so minimal that it is not worth the expenditure of energy and time ?
    • 


    


    I appeal to your feedback, your opinions, your tips !, and if you had leads (sample) to attack this kind of development, I am interested.

    


    Thank you very much in advance for your feedback.
(this is my fist question on stackoverflow, Champagne ! ;))

    


  • avformat/mlvdec : demux LJ92 huffman comressed frames

    13 décembre 2024, par Peter Ross
    avformat/mlvdec : demux LJ92 huffman comressed frames
    

    A minimal DNG header is added to each LJ92 compressed frame, allowing
    thme to be decoded by the TIFF decoder. The TIFF decoder is responsible
    for setting up the MJPEG decoder, signalling the correct s->bayer flag,
    and setting pix_fmt.

    The LJ92 compressed frames can be muxed out to DNG files, and manipulated
    in DNG software. Tested with darktable and rawtherapee.

    Contributor : South East <8billion.people@gmail.com>

    • [DH] libavformat/mlvdec.c
  • FFMPEG re-broadcast/proxy MJPEG stream

    10 septembre 2022, par Ollie Pugh

    I have an MJPEG stream coming from an RPI on my home network and have an NGINX acting as a proxy on an EC2.

    &#xA;

    For the camera access the flow of stream to the user is the following

    &#xA;

    RPi -> mjpeg-proxy (running on EC2) -> NGINX (running on same EC2) -> user

    &#xA;

    the point of mjpeg-proxy is to reduce the load on the RPi and only have one stream to the Pi and allow the EC2 to distribute that one stream.

    &#xA;

    Now this work fine-ish from my PC (on same network as Pi) the streams work perfectly. But when it comes to my phone on roaming data, the stream is super choppy and the latency grows massively (this project needs minimal latency, like sub 300ms).

    &#xA;

    I can't understand why this would happen ? Because even when running of my local PC its going through the Proxy hosted in the cloud, so its not as if its an advantage to it being local ?

    &#xA;

    the stream is fine on another device, e.g. my laptop, but thats on the same network as the RPi. But like I said, it shouldn't makea difference as its going through a proxy !

    &#xA;

    I was wondering if using FFMPEG to re-stream the mjpeg stream would be beneficial as node is notoriously slow. But I don't really want to be writing my own mjpeg-proxy in C++ to speed this all up.

    &#xA;

    I have looked online for answers to FFMPEG MJPEG proxy and have been very unsuccesful

    &#xA;