Recherche avancée

Médias (91)

Autres articles (32)

  • Emballe Médias : Mettre en ligne simplement des documents

    29 octobre 2010, par

    Le plugin emballe médias a été développé principalement pour la distribution mediaSPIP mais est également utilisé dans d’autres projets proches comme géodiversité par exemple. Plugins nécessaires et compatibles
    Pour fonctionner ce plugin nécessite que d’autres plugins soient installés : CFG Saisies SPIP Bonux Diogène swfupload jqueryui
    D’autres plugins peuvent être utilisés en complément afin d’améliorer ses capacités : Ancres douces Légendes photo_infos spipmotion (...)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (6203)

  • lavc/vvc : Store MIP information over entire CU area

    28 novembre 2024, par Frank Plowman
    lavc/vvc : Store MIP information over entire CU area

    Previously, the code only stored the MIP mode and transpose flag in the
    
relevant tables at the top-left corner of the CU.  This information ends
    
up being retrieved in ff_vvc_intra_pred_* not based on the CU position
    
but instead the transform unit position (specifically, using the x0 and
    
y0 from get_luma_predict_unit).  There might be multiple transform units
    
in a CU, hence the top-left corner of the transform unit might not
    
coincide with the top-left corner of the CU.  Consequently, we need to
    
store the MIP information at all positions in the CU, not only its
    
top-left corner, as we already do for the MIP flag.
    

    Signed-off-by : Frank Plowman <post@frankplowman.com>
    • [DH] libavcodec/vvc/ctu.c

  • Store a live stream when internet connection is interrupted ?

    6 juin 2019, par Marcello Moreira

    I’m building a solution using drone and 3g/4g connection.
    I have an IP camera encoded in H.264 by a hardware encoder connected to a raspberry pi and a 3g/4g modem. The hardware encoder livestream de video via RTMP to a remote server I have. All these devices are in a moving platform, and sometimes the modem loses connection with internet for a few seconds/minutes. When this happens, I want to store the live footage in the raspberry with ffmpeg, and when the connection restores I can send it back to the server. I have access to the encoded livestream from the raspberry pi over LAN even when internet is down.

    I do not know how and where should I start.
    I see two approaches for this.

    First approach

    One is to do all the streaming via ffmpeg, and disable the automatic hardware stream, when ffmpeg detects that it can’t send stream to the remote server, it starts to store the video (like a buffer) until the connection is restore. The issue with this, is that I don’t know if ffmpeg can detect if internet connection is down, and how can I buffer the video. Also by doing this, when connection is restored, live video would have a huge delay, and I can’t have lot’s of delay in my solution.

    Second approach

    The second is simultaneously store with ffmpeg the live video, when internet goes down, a process records the timestamp, and keeps watching until internet connection is restored. Then it sends to my server only the missing piece. At my server I would need to figure out a way to join those streams back up.. (I would gladly accept tips on that too). Issue with this is that there’s limited space in my raspberry, so I can only store a limited amount. Also, my device may be turned off when it lands so I need to send the video recording ASAP after connection is restored.

    So, which approach seems to be the better one ?

  • How can I store a live stream when internet connection is interrupted ?

    5 juin 2019, par Marcello Moreira

    I’m building a solution using drone and 3g/4g connection.
    I have an IP camera encoded in H.264 by a hardware encoder connected to a raspberry pi and a 3g/4g moldem. The hardware encoder livestream de video via RTMP to a remote server I have. All these devices are in a moving platform, and sometimes the moldem loses connection with internet for a few seconds/minutes. When this happens, I want to store the live footage in the raspberry with ffmpeg, and when the connection restores I can send it back to the server. I have access to the encoded livestream from the raspberry pi over LAN even when internet is down.

    I do not know how and where should I start.
    I see two approaches for this.

    First approach

    One is to do all the streaming via ffmpeg, and disable the automatic hardware stream, when ffmpeg detects that it can’t send stream to the remote server, it starts to store the video (like a buffer) until the connection is restore. The issue with this, is that I don’t know if ffmpeg can detect if internet connection is down, and how can I buffer the video. Also by doing this, when connection is restored, live video would have a huge delay, and I can’t have lot’s of delay in my solution.

    Second approach

    The second is simultaneously store with ffmpeg the live video, when internet goes down, a process records the timestamp, and keeps watching until internet connection is restored. Then it sends to my server only the missing piece. At my server I would need to figure out a way to join those streams back up.. (I would gladly accept tips on that too). Issue with this is that there’s limited space in my raspberry, so I can only store a limited amount. Also, my device may be turned off when it lands so I need to send the video recording ASAP after connection is restored.

    So, which approach seems to be the better one ?

Navigation