
Recherche avancée
Médias (1)
-
Video d’abeille en portrait
14 mai 2011, par
Mis à jour : Février 2012
Langue : français
Type : Video
Autres articles (33)
-
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...) -
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 -
Les formats acceptés
28 janvier 2010, parLes commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
ffmpeg -codecs ffmpeg -formats
Les format videos acceptés en entrée
Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
Les formats vidéos de sortie possibles
Dans un premier temps on (...)
Sur d’autres sites (9344)
-
ffprobe for metadata - different output on Mac/Linux
16 mars 2023, par omega1I am trying to get the metadata from a live .m3u8 stream and I was testing this using Mac and it is working and I can get the data I need, but when putting it onto a Linux (Debian) box, it omits the part that I need, the command is :


ffprobe -show_data http://livestreamurl.com



Which on Mac, outputs the data I need :


Input #0, hls, from 'http://livestreamurl.com':
 Duration: N/A, bitrate: N/A
 Program 0
 Metadata:
 variant_bitrate : 130000
 Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp
 Metadata:
 variant_bitrate : 130000
 title : Crowded House - Locked Out



Specifically, it is the
title
part which is "Crowded House - Locked Out"

But when run on Linux, I get this :


Input #0, hls,applehttp, from 'http://livestreamurl.com':
 Duration: N/A, bitrate: N/A
 Program 0
 Metadata:
 variant_bitrate : 130000
 Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp
 Metadata:
 variant_bitrate : 130000



The Mac version is 4.4 and the Debian version is 3.2.16 (but says it is the latest version available), could this be the issue ?


Is there a way for me to get what I need using the Linux box, which is the title section of the metadata on the audio stream ?


Thanks.


-
ffmpeg : transmission problems / artifacts in rtsp screen grab - might be a WiFi problem
1er décembre 2022, par Jo KernerIn short : Is there a way to "force" ffmpeg to not save a grabbed frame if there are transmission problems ? Or any other software that does the same and I just don't know of ?


Long story :


Updating my house surveillance from almost 10 years old DCS-932L cameras to Tapo C100 Cameras, I changed the image delivery method from ftp push to rtsp grab via ffmpeg.


I had written a program in C++ to check for "bad" pictures from the old cameras, where parts of the picture tended to be simply black once every minute or so (I'm grabbing a pic every 2 seconds). The Tapo C100 doesn't feature ftp-push, thus I tried (after a few days trying)


ffmpeg.exe -y -i rtsp://user:pass@10.0.0.%ld:554/stream1 -vframes 1 %scamera\rtsp.jpg -loglevel quiet



This works absolutely perfect in my main house, which features a Fritz !Box 7590 and a set of Fritz !Powerline (510/and two 540e) repeaters, plus one WiFi repeater Fritz 600) as my phone line and the router are in the basement.


In my holiday home, though, it doesn't. The Wifi is managed by a Hybrid DSL/5G - box I have no alternative to, which is a Huawei DN9245W and works as DHCP Server, because this is almost impossible to change. Everything "real" is managed by another Fritz !Box 7590, connected via ethernet, and another set of Fritz !Powerline 510 and two 540e repeaters plus half a dozen Wifi Repeaters, mostly Fritz ! 310, 450E and 600. The house was partially built with local stones, which are very iron-y, and there's a lot of metallized glass. Full set is show in Image


Now, this does produce different artifacts, about two per minute or in every 15th picture, see
Image with artifacts No. 1


Thinking this might be a transmission problem, I tried forcing the streamgrab via TCP, because while rtsp doesn't have error correction, TCP does :


ffmpeg.exe -rtsp_transport tcp -i
rtsp://user:pass@10.0.0.%ld:554/stream1 -y -f image2 -update 1 -r
1 -vframes 1 -qscale:v 30 %scamera\rtsp.jpg -loglevel quiet



Which didn't change the artifacts much, see Image with artifacts No. 2


The house now has a total of 12 Cameras, six of which are each "managed" by an older Dell Optiplex Desktop bought used off ebay with an i3 or i5 processor from about 2015, which goes to about 65% load. My software will check if the grabbed picture is finished saving (to RAMdisk), rename it, check if there are artifacts, if so, drop it, if not, convert to bitmap and then compare it to previous image, guess if there's a change, mark that change with a rhombus and rate it, save that as a jpeg file, and then some other stuff that's not relevant here. See : Image of my program running with six cameras


I did try grabbing keyframes only, but a bunny or deer or burglar hopping through my property doesn't produce a keyframe, so that turned out to be missing the point.


I'm out of ideas here. It does work flawlessly in the main house. It doesn't in the holiday house. I can hardly install more repeaters ; I already tried mesh and not-mesh, and the problem isn't exactly wifi overload, because even with just one camera running, it still persists. In certain places. Some have no problems. Reasons ? No clue. I really hope someone has a good idea.


-
Revision 109074 : Revision de la moderation par email des messages de forum pour se proteger ...
21 février 2018, par cedric@… — LogRevision de la moderation par email des messages de forum pour se proteger des bots qui cliquent dans les mails
Principe : les bots etant betes ils cliquent sur les 3 boutons de moderation en tres peu de temps, on attends donc quelques secondes avant d’executer la modif en base
* si 10s apres la demande on en a pas eu d’autre contradictoire, on l’execute
* sinon on ne fait rien et on purge les demandes pour peu qu’elles soient suffisament anciennes (il faut gerer le cas ou une deuxieme salve d’un bot a commence : si on purge betement on risque de rendre valide une demande qui arrivera juste derriere)