Recherche avancée
Autres articles (22)
-
Installation en mode ferme
4 février 2011, parLe mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
C’est la méthode que nous utilisons sur cette même plateforme.
L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...) -
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 -
Emballe médias : à quoi cela sert ?
4 février 2011, parCe plugin vise à gérer des sites de mise en ligne de documents de tous types.
Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;
Sur d’autres sites (4264)
-
Anomalie #2749 (Fermé) : Problème de cookie
21 mars 2013, par guytarr °il y a bien http://forum.spip.net/fr_248457.html mais rien trouvé dans forum ou sur les listes de "récent".
-
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.


-
Chrome times out on streaming FFMPEG output from ASP.NET Web Api
3 août 2014, par Hayden McAfeeI’ve got a unique problem here !
UPDATE 2 So it turns out the development below is FALSE, the inconsistency of the bug made it seem like not closing the stream made it work... but in fact the same issue persists !
UPDATE Interesting development ; if I comment outffmpegBufferedIn.Close();below, the entire stream always goes through fine... the request just never ends. What could be going on here ?I’m writing a web service that stores audio files in Azure Blob Storage, and converts them to MP3 live when requested through my ASP.NET Web API endpoint. I accomplish this by using ’DownloadToStream’ via the Azure Storage API, feeding that stream through the STDIN of an FFMPEG process, and sending the STDOUT stream as the request response.
The block of code that does this looks like this :
public HttpResponseMessage Get(Guid songid)
{
// This could take awhile.
HttpContext.Current.Server.ScriptTimeout = 600;
Process ffmpeg = new Process();
ProcessStartInfo startinfo = new ProcessStartInfo(HostingEnvironment.MapPath("~/App_Data/executables/ffmpeg.exe"), "-i - -vn -ar 44100 -ac 2 -ab 192k -f mp3 - ");
startinfo.RedirectStandardError = true;
startinfo.RedirectStandardOutput = true;
startinfo.RedirectStandardInput = true;
startinfo.UseShellExecute = false;
startinfo.CreateNoWindow = true;
ffmpeg.StartInfo = startinfo;
ffmpeg.ErrorDataReceived += ffmpeg_ErrorDataReceived;
// Our response is a stream
var response = Request.CreateResponse();
response.StatusCode = HttpStatusCode.OK;
// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
CloudConfigurationManager.GetSetting("StorageConnectionString"));
// Create the blob client.
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
// Retrieve reference to a previously created container.
CloudBlobContainer container = blobClient.GetContainerReference("songs");
// Retrieve reference to a blob
CloudBlockBlob blockBlob = container.GetBlockBlobReference(songid.ToString());
ffmpeg.Start();
ffmpeg.BeginErrorReadLine();
// Buffer the streams
var ffmpegBufferedIn = new BufferedStream(ffmpeg.StandardInput.BaseStream);
var ffmpegBufferedOut = new BufferedStream(ffmpeg.StandardOutput.BaseStream);
blockBlob.DownloadToStreamAsync(ffmpegBufferedIn).ContinueWith((t) => {
ffmpegBufferedIn.Flush();
ffmpegBufferedIn.Close();
});
response.Content = new StreamContent(ffmpegBufferedOut);
response.Content.Headers.ContentType = new MediaTypeHeaderValue("audio/mpeg");
System.Diagnostics.Debug.WriteLine("Returned response.");
return response;
}This works quite well in all browsers - all except for Chrome, which has an interesting way of buffering audio streams. Chrome will buffer the first 2 megabytes of a stream, then keep the connection open and wait until the user gets closer to playing the next segment of a file before consuming the rest of the stream. This should be fine - and for some songs it is. For others, I get this :
At first I thought this was due to some kind of timeout - But it happens at a different time and size for each file. It is consistent within about 15 seconds on the same songs, however. The output on the server side is normal - no exceptions thrown, and FFMpeg finishes encoding the song successfully.
Here’s the server-side output of the above request :
ffmpeg version N-64919-ga613257 Copyright (c) 2000-2014 the FFmpeg developers
built on Jul 23 2014 00:27:32 with gcc 4.8.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 52. 92.101 / 52. 92.101
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.101 / 55. 48.101
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Input #0, mp3, from 'pipe:':
Metadata:
TSRC : AUUM71001516
title : Sunlight
track : 2
artist : Bag Raiders
copyright : 2010 Modular Recordings
genre : Electronic
album : Bag Raiders
album_artist : Bag Raiders
disc : 1/1
publisher : Modular Recordings
composer : Chris Stracey/Jack Glass/Dan Black
date : 2010
Duration: N/A, start: 0.000000, bitrate: 320 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg), 600x600 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
Metadata:
title :
comment : Other
Output #0, mp3, to 'pipe:':
Metadata:
TSRC : AUUM71001516
TIT2 : Sunlight
TRCK : 2
TPE1 : Bag Raiders
TCOP : 2010 Modular Recordings
TCON : Electronic
TALB : Bag Raiders
TPE2 : Bag Raiders
TPOS : 1/1
TPUB : Modular Recordings
TCOM : Chris Stracey/Jack Glass/Dan Black
TDRL : 2010
TSSE : Lavf55.48.101
Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p, 192 kb/s
Metadata:
encoder : Lavc55.69.100 libmp3lame
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
size= 6kB time=00:00:00.21 bitrate= 227.6kbits/s
size= 102kB time=00:00:04.31 bitrate= 193.7kbits/s
size= 202kB time=00:00:08.56 bitrate= 192.9kbits/s
size= 341kB time=00:00:14.49 bitrate= 192.5kbits/s
size= 489kB time=00:00:20.82 bitrate= 192.4kbits/s
size= 642kB time=00:00:27.35 bitrate= 192.3kbits/s
size= 792kB time=00:00:33.75 bitrate= 192.2kbits/s
size= 950kB time=00:00:40.49 bitrate= 192.2kbits/s
size= 1106kB time=00:00:47.15 bitrate= 192.2kbits/s
size= 1258kB time=00:00:53.63 bitrate= 192.1kbits/s
size= 1415kB time=00:01:00.31 bitrate= 192.1kbits/s
size= 1563kB time=00:01:06.66 bitrate= 192.1kbits/s
size= 1710kB time=00:01:12.90 bitrate= 192.1kbits/s
size= 1857kB time=00:01:19.17 bitrate= 192.1kbits/s
size= 2008kB time=00:01:25.63 bitrate= 192.1kbits/s
size= 2162kB time=00:01:32.21 bitrate= 192.1kbits/s
size= 2299kB time=00:01:38.03 bitrate= 192.1kbits/s
size= 2457kB time=00:01:44.80 bitrate= 192.1kbits/s
size= 2600kB time=00:01:50.89 bitrate= 192.1kbits/s
size= 2755kB time=00:01:57.52 bitrate= 192.1kbits/s
size= 2864kB time=00:02:02.17 bitrate= 192.1kbits/s
size= 3022kB time=00:02:08.88 bitrate= 192.1kbits/s
size= 3172kB time=00:02:15.31 bitrate= 192.1kbits/s
size= 3284kB time=00:02:20.06 bitrate= 192.1kbits/s
size= 3385kB time=00:02:24.40 bitrate= 192.1kbits/s
size= 3529kB time=00:02:30.51 bitrate= 192.0kbits/s
size= 3687kB time=00:02:37.25 bitrate= 192.0kbits/s
size= 3838kB time=00:02:43.71 bitrate= 192.0kbits/s
size= 3988kB time=00:02:50.11 bitrate= 192.0kbits/s
size= 4138kB time=00:02:56.53 bitrate= 192.0kbits/s
size= 4279kB time=00:03:02.54 bitrate= 192.0kbits/s
size= 4408kB time=00:03:08.03 bitrate= 192.0kbits/s
size= 4544kB time=00:03:13.85 bitrate= 192.0kbits/s
size= 4683kB time=00:03:19.78 bitrate= 192.0kbits/s
size= 4805kB time=00:03:24.95 bitrate= 192.0kbits/s
size= 4939kB time=00:03:30.67 bitrate= 192.0kbits/s
size= 5049kB time=00:03:35.38 bitrate= 192.0kbits/s
size= 5141kB time=00:03:39.32 bitrate= 192.0kbits/s
size= 5263kB time=00:03:44.49 bitrate= 192.0kbits/s
size= 5372kB time=00:03:49.17 bitrate= 192.0kbits/s
The thread 0xb24 has exited with code 259 (0x103).
size= 5436kB time=00:03:51.91 bitrate= 192.0kbits/s
size= 5509kB time=00:03:55.02 bitrate= 192.0kbits/s
size= 5657kB time=00:04:01.32 bitrate= 192.0kbits/s
size= 5702kB time=00:04:03.22 bitrate= 192.0kbits/s
video:0kB audio:5701kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.005738%Any ideas ? I’m grateful for suggestions - I’ve been chasing this for a week now !
Syndiquer tout le site
