Recherche avancée

Médias (1)

Mot : - Tags -/graphisme

Autres articles (78)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

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

  • Le profil des utilisateurs

    12 avril 2011, par

    Chaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
    L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...)

Sur d’autres sites (7453)

  • FFMpeg Continuous Real-time Image to Video Encoding

    4 juillet 2014, par Ben

    I am trying to use FFMpeg to take a stream of image files and turn them into a video. Now, I have successfully done this, but only after I have already captured all the images that I want. What I would like to do is turn the images into a video as they are saved to disk (real-time video recorder). Currently, when I call FFMpeg while frames are still being grabbed, it only encodes the number of images that are present when it is called. If FFMpeg is called every time an image is grabbed, it floods the CPU with a ton of processes. Ideally, FFMpeg would continue to encode the images until there are no more images being captured (I.E., check if there are more image files since it was first called). Is there an argument for FFMpeg that I’m missing, or is this not possible ? Or is the only way to do this through messing around with the libraries ?

  • Real-time seeking and playback ffmpeg use case

    6 octobre 2023, par BlackIce2107

    What is best approach to store the 24x7 RTSP recorded streams and format that can satisfy near real-time seeking and playback preferably without concatenating or trimming them first and then serving the resulting file ?

    


    We have attempted using h264 videos that are segmented into 15 minute chunks with a high key frame interval where the user may request for a start and end time that can span either multiple videos or a single video file.

    


    With FFMPEG this is relatively straightforward but we would need to either concatenate or trim files based on the input which takes a tiny bit of time even with copy codec accurately and even on higher-end EC2s thereby leading to a unsatisfactory user experience.

    


    Additonally attempted to use hevc/h265 to also tackle cost efficiency as this is also a factor in the long run but hevc videos are not widely supported on most browsers.

    


  • How to decode video in ffmpeg in real time ?

    18 juillet 2021, par Guerlando OCs

    Basic ffmpeg decoding consists of avcodec_send_packet to send encoded packets and avcodec_receive_frame to receive the decoded frames.

    


    avcodec_send_packet returns EAGAIN in case it's full. That is, in case no one is calling avcodec_receive_frame.

    


    Suppose I'm reading an mp4 file and rendering on the screen. That is, I want real time playback of the video. One way to do that would be to tell the renderer the exact fps the file has, for example :

    


    If the file should play at 30 fps, then the renderer calls avcodec_receive_frame 30 times per second, and the avcodec_send_packet only sends new packets when it can. If it receives EAGAIN, it waits and sends again in 1 millisecond, instead of discarding the packet.

    


    Is this the right way to do ? Because getting the fps of the file is not trivial. At least I've never seen this in ffmpeg. Maybe a .mp4 file has this information, but what about a raw .h264 file ? VLC player can play raw .h264 in the right time, but I don't know how it does that

    


Navigation