Recherche avancée

Médias (10)

Mot : - Tags -/wav

Autres articles (48)

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

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

Sur d’autres sites (7100)

  • FPS from RTSP stream info does not match actual framerate

    17 mai 2021, par Krapow

    I have a 25FPS RTSP stream coming from an IP-camera. I can successfully display the video stream. But when analyzing the stream with ffmpeg (ffprobe actually), I observe fewer frames per second rate :

    


    $ ffprobe -rtsp_transport tcp -i rtsp://camera_ip:554/stream -select_streams v:0 -show_frames -show_entries frame=coded_picture_number,pkt_pts_time -of csv=p=0
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 640x480, 25 fps, 25 tbr, 90k tbn, 50 tbc
0.400000,0
0.080000,1
0.120000,2
0.200000,3
0.240000,4
0.320000,5
0.360000,6
0.440000,7
0.480000,8
0.560000,9
0.600000,10
0.680000,11
0.720000,12
0.800000,13
0.840000,14
0.920000,15
0.960000,16
1.040000,17
1.080000,18
1.160000,19
1.200000,20
1.280000,21
1.320000,22
1.400000,23
1.440000,24
1.520000,25
1.560000,26
1.640000,27
1.680000,28
1.760000,29
1.800000,30
1.880000,31
1.920000,32
2.000000,33


    


    We can clearly see the 80ms gap between some of the frames, resulting in a 16fps stream.

    


    I have observed the same framerate issue with GStreamer (printing information in the rtpjitterbuffer indicates the frame gap is sometimes 80ms and sometimes 40ms). But the weird thing is, I encountered the same issue with an HDMI-RJ45 decoder, and I doubt the same issue comes from 2 different devices.
I didn't get much more informations using -loglevel debug or trace.
Does anybody have an idea about what is going wrong in the stream ?

    


    (I used ffprobe 4.2.3 and the last "2021-05-09-git-8649f5dca6-full_build-www.gyan.dev" with the same results, and GStreamer 1.16.2 with a pipeline like "urisourcebin ! h264depay ! h264parse ! fakesink")

    


    EDIT : The camera skipping of frames was caused by the activation of a third stream in the options. I find it really weird that it skips exactly the same frames every seconds. However, I still haven't found the cause of the downrate on my RTSP encoder.
Anyway, this was actually hardware related and not software related.

    


  • Android ffmpeg save and append h264 streamed videos

    8 octobre 2012, par Stefan Alexandru

    I need to save a video file generated by two video streams coming from two different sources. I'm using rtsp over tcp/ip, and the videos are encoded with h264.
    I need to first record the video from the first source and than continue with the second source.
    So what I tried was to declare two AVFormatContext instances, initialize both with avformat_open_input(&context, "rtsp://......",NULL,&options)
    and then read frames with av_read_frame(context,&packet)
    and write them in the video file av_write_frame(oc,&packet);
    It works fine saving the video from the first source, but if by example I saved y frames from the first context, when I try reading and saving the frames from the second context in the same file, for the first y frames I am tring to save, av_write_frame(oc,&packet2);
    would retun -22
    , and would not add the frame to the file.

    I think the problem is that the context variable remembers how many frames were read, and it gives every read packet an identification number, to make sure it isn't written twice. But when I'm using a new context those identification numbers reset, the AVOutputFormat or the AVFormatContext also retain the id of the package they are expecting to receive, and would not write anything until they receive a package with that id.
    Now I'm wondering how could I solve this inconvenience. I can't find any setter for that id, or any way to reuse the same context. I thought to modify the ffmpeg sources but they are pretty complex and I couldn't find what I was looking for.
    An alternative would be to save the two video in two different files but, I don't know how to append them afterwards, as ffmpeg can only append videos encoded with mpeg and rencoding the video isn't really an option, as it will take to much time. Also I couldn't find any other functional way to append two mp4 videos encoded with h264.

    I'll be happy to hear any kind of usable ideea to this problem.

  • I'm attempting to retrieve the dimensions of in-memory video buffer objects in Node.js without writing to disk

    23 mars 2021, par undefined

    All right, so I have a Node.js server where media files can be uploaded by the user. It's important for displaying the media in the client later on that I can retrieve and store the width and height dimensions of the video in advance.

    


    For performance reasons, disk space limitations, and a few other reasons, I'm attempting to do so without saving the video buffer object (retrieved via Multer) to disk as it has terrible performance on the server I am using.

    


    I have FFmpeg and ffprobe, as well as the nom get-video-dimensions module, but I can't find a way to get media statistics without writing the file. For example, get-video-dimensions only allows you to enter a file path.

    


    Is there a way to either feed the buffer into one of these utilities using either a stream/pipe to simulate the source coming from disk, or is there an rpm module I've overlooked that could achieve this task ?

    


    if (imageBufferObject.media_type == "video") {
  // Get resolution

  // Save to disk
  let write_response = await writeFile(imageBufferObject)
  // Use utility
  let dim = await dimensions(path.join(__dirname, 'tmp', newName))
  // Delete file
  let delete_response = await deleteFile(imageBufferObject)


   async function writeFile(file){
     return new Promise((resolve, reject)=>{
       fs.writeFile(path.join(__dirname, 'tmp', file.newName), file.buffer, (err)=>{
         resolve(200)
        })
     })
   }
   async function deleteFile(file){
     return new Promise((resolve, reject)=>{
       fs.unlink(path.join(__dirname, 'tmp', file.newName), (err)=>{
         resolve(200)
       })
     })
   }


    


    I desperately want to avoid using the hard disk !