
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (87)
-
Publier sur MédiaSpip
13 juin 2013Puis-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 -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe 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, parLes 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 (8367)
-
Revision d115dbc24c : Adjust style to match Google Coding Style a little more closely. Most of these
30 octobre 2012, par Ronald S. BultjeChanged Paths : Modify /vp8/common/onyx.h Modify /vp8/encoder/bitstream.c Modify /vp8/encoder/dct.c Modify /vp8/encoder/encodeframe.c Modify /vp8/encoder/encodeintra.c Modify /vp8/encoder/firstpass.c Modify /vp8/encoder/generic/csystemdependent.c (...)
-
FFMPEG silencedetect output does not match Audacity Sound Finder
12 avril 2017, par tngoI’m currently working on labeling sound sections in an audio file.
When I ran my audio file through Audacity Sound Finder with the following settings this is what I get
0.448980 0.498866 1
0.698413 0.927891 2
1.147392 1.426757 3
1.566440 1.815873 4These are the first 4 labels for the audio file where the sounds were found to be louder than -12dB.
However when I ran the same audio file through FFMPEG silencedetect filter with n=-12dB:d=0.1 this is the output
[silencedetect @ 000000000272a8c0] silence_start: -0.00712018
[silencedetect @ 000000000272a8c0] silence_end: 0.371519 | silence_duration: 0.378639
[silencedetect @ 000000000272a8c0] silence_start: 0.457279
[silencedetect @ 000000000272a8c0] silence_end: 0.650159 | silence_duration: 0.19288
[silencedetect @ 000000000272a8c0] silence_start: 0.828798
[silencedetect @ 000000000272a8c0] silence_end: 1.11456 | silence_duration: 0.28576
[silencedetect @ 000000000272a8c0] silence_start: 1.38608
[silencedetect @ 000000000272a8c0] silence_end: 1.8576 | silence_duration: 0.1
[silencedetect @ 000000000272a8c0] silence_start: 2.31488For FFMPEG to detect sound I’m considering silence_end to be sound_start and silence_start to be sound_end. With that logic the output from FFMPEG actually is
0.371519 0.457279 1
0.650159 0.828798 2
1.11456 1.38608 3
1.8576 2.31488 4To me it seems like all the timestamps from FFMPEG are shifted to the left compare to Audacity Sound Finder. Is there something that I’m missing ?
Any help would be much appreciated.
Thanks, -
FPS from RTSP stream info does not match actual framerate
17 mai 2021, par KrapowI 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.