
Recherche avancée
Autres articles (111)
-
Gestion générale des documents
13 mai 2011, parMédiaSPIP ne modifie jamais le document original mis en ligne.
Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...) -
Use, discuss, criticize
13 avril 2011, parTalk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
A discussion list is available for all exchanges between users. -
Le profil des utilisateurs
12 avril 2011, parChaque 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 (9425)
-
How can ffmpeg concat MP3s with full metadata incl. cover art ?
13 décembre 2022, par TENAudio books inconveniently split into dozens of MP3s (with spaces in their names) should be merged into one MP3 in a subdirectory (in which ffmpeg version 4.2.7-0ubuntu0.1 is invoked), without time-consuming and possibly degrading conversions, reliably preserving all metadata incl. cover art (present and similar in all MP3s of a title, their differences being significant only in lengths and track numbers).


However, rather than picking the latter from the first input MP3, the https://trac.ffmpeg.org/wiki/Concatenate#protocol loses the cover art, the https://trac.ffmpeg.org/wiki/Concatenate#demuxer documented as more flexible even loses all metadata :


ffmpeg -v verbose -f concat -safe 0 -i <(printf "file '$PWD/%s'\n" ../in\ track*.mp3) -c copy "out.mp3"
...
Input #0, concat, from '/dev/fd/63':
Duration: N/A, start: 0.000000, bitrate: 192 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
Stream #0:1: Video: png, 1 reference frame, rgba(pc), 300x300, 90k tbr, 90k tbn, 90k tbc
Metadata:
title : 12ae3b8152eaf255ae0315c59400c540.png
comment : Cover (front)
...
Output #0, mp3, to 'out.mp3':
Metadata:
TSSE : Lavf58.29.100
Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (copy)
...
[AVIOContext @ 0x561459f3dac0] Statistics: 1958050 bytes read, 0 seeks
[mp3 @ 0x561459f3f900] Skipping 0 bytes of junk at 110334.
[mp3 @ 0x561459f3f900] Estimating duration from bitrate, this may be inaccurate
No more output streams to write to, finishing.
size= 75793kB time=00:53:03.12 bitrate= 195.1kbits/s speed= 636x
video:0kB audio:75793kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000865%
Input file #0 (/dev/fd/63):
Input stream #0:0 (audio): 121847 packets read (77611658 bytes);
Input stream #0:1 (video): 40 packets read (4358440 bytes);
Total: 121887 packets (81970098 bytes) demuxed
Output file #0 (out.mp3):
Output stream #0:0 (audio): 121847 packets muxed (77611658 bytes);
Total: 121847 packets (77611658 bytes) muxed
[AVIOContext @ 0x561459ef6700] Statistics: 2 seeks, 298 writeouts
[AVIOContext @ 0x561459f39e40] Statistics: 2006324 bytes read, 0 seeks
[AVIOContext @ 0x561459ee0300] Statistics: 5040 bytes read, 0 seek



The metadata incl. cover PNG as detected (as single-frame "video") should end up in the output MP3, but doesn't (even when adding -movflags use_metadata_tags possibly intended for other formats).


-metadata track="1/1" (or without the /1 ?) may be required as the first input MP3 sometimes wrongly starts at a higher number.


How do I make sure no metadata (incl. image) other than track numbers is lost when concatenating MP3s (by protocol or demuxer, from a set of input files with spaces in their names and a wildcard to match across track numbers) ?


-
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.


-
How do I know if an M3U8 link is from a live transmission or a complete file ?
17 août 2022, par karurosaguThis is my problem


I have a downloader app, and one of it's features is downloading M3U8 links using FFmpeg under the hood

It only supports a selection of sites and platforms, but i don't want to add support for unknown origin links, not just because it's obviously missing the right headers, cookies and user agent and the user would have to put all of that to work, the main reason is that I don't know how to determine if that link leads to a complete file or if it leads to a live transmission

This is what happened :


A user of my app gave me a link to test it manually, i ran the code and I noteiced it was taking a lot of time to finish having a decent speed, the file was getting too big, and when i ask him where did the link came from he said it was from a Live TV stream : I had to cancel the download


So, how do i know in FFmpeg if a given M3U8 link leads to a complete file rather than a live transmission ?