
Recherche avancée
Autres articles (48)
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, 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 (...) -
Mise à disposition des fichiers
14 avril 2011, parPar défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 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 (...)
Sur d’autres sites (7473)
-
What is Behavioural Segmentation and Why is it Important ?
28 septembre 2023, par Erin — Analytics Tips -
A pragmatic strategy to merge multiple video files
19 juin 2021, par sauravI currently am working on recording a multiparty video conference which supports up to 6 participants. I am recording the conference using a media server and storing audio/video streams individually for every participant.


Next, I need to merge those individual recordings into a single video file and upload it to a cloud storage like aws s3. For this I am considering 2 options, either Gstreamer or FFMPEG. I am leaning towards FFMPEG as I have used FFMPEG previously. I currently am playing with FFMPEG things like the hstack and vstack filters etc.


Here is the FFMPEG command I recently used to join 2 webm videos of 2 mins 40sec and 1min 40sec to create a mp4 video file for upload. Both the videos are 1280x720 in this case but I have included the scale part because in real life scenario different participants joining with different cameras produces video files of different resolution which is a problem for the hstack/vstack filter. Therefore, to make the video resolutions of all participant consistent, I have included the scale property.


ffmpeg -i 1.webm -i 2.webm -filter_complex "[0:v]scale=1280:720,setsar=1[l];[1:v]scale=1280:720,setsar=1[r];[l][r]hstack;[0][1]amix" output-1280x720.mp4



Currently I am facing 2 issues with this command.


- 

-
The output mp4 file is very big, in this case 140Mb (approx) for a less than 3 minutes video.


-
How do I add delay to any video before starting to merge ?

Currently the videos are going out of sync if all the participants don't join at the same time which is highly unlikely to happen in a real world scenario.







Any pointer in the right direction will be highly appreciated.


Here is a log sample from FFmpeg (or see the full log link) :


ffmpeg version 4.2.4-1ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers
 built with gcc 9 (Ubuntu 9.3.0-10ubuntu2)
 configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
 libavutil 56. 31.100 / 56. 31.100
 libavcodec 58. 54.100 / 58. 54.100
 libavformat 58. 29.100 / 58. 29.100
 libavdevice 58. 8.100 / 58. 8.100
 libavfilter 7. 57.100 / 7. 57.100
 libavresample 4. 0. 0 / 4. 0. 0
 libswscale 5. 5.100 / 5. 5.100
 libswresample 3. 5.100 / 3. 5.100
 libpostproc 55. 5.100 / 55. 5.100
Input #0, matroska,webm, from '3.webm':
 Metadata:
 title : FFmpeg
 ENCODER : Lavf58.29.100
 Duration: 00:01:39.63, start: 0.000000, bitrate: 707 kb/s
 Stream #0:0: Video: vp8, yuv420p(tv, bt470bg/unknown/unknown, progressive), 1280x720, SAR 1:1 DAR 16:9, 1k tbr, 1k tbn, 1k tbc (default)
 Metadata:
 DURATION : 00:01:39.618000000
 Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)
 Metadata:
 DURATION : 00:01:39.629000000
Input #1, matroska,webm, from '4.webm':
 Metadata:
 title : FFmpeg
 ENCODER : Lavf58.29.100
 Duration: 00:02:39.07, start: 0.000000, bitrate: 708 kb/s
 Stream #1:0: Video: vp8, yuv420p(tv, bt470bg/unknown/unknown, progressive), 1280x720, SAR 1:1 DAR 16:9, 1k tbr, 1k tbn, 1k tbc (default)
 Metadata:
 DURATION : 00:02:39.050000000
 Stream #1:1: Audio: opus, 48000 Hz, stereo, fltp (default)
 Metadata:
 DURATION : 00:02:39.068000000
Stream mapping:
 Stream #0:0 (vp8) -> scale
 Stream #0:1 (opus) -> amix:input0
 Stream #1:0 (vp8) -> scale
 Stream #1:1 (opus) -> amix:input1
 hstack -> Stream #0:0 (libx264)
 amix -> Stream #0:1 (aac)
Press [q] to stop, [?] for help
[libx264 @ 0x562b4842a500] using SAR=1/1
[libx264 @ 0x562b4842a500] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x562b4842a500] profile High, level 6.1
[libx264 @ 0x562b4842a500] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'output-new.mp4':
 Metadata:
 title : FFmpeg
 encoder : Lavf58.29.100
 Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p(progressive), 2560x720 [SAR 1:1 DAR 32:9], q=-1--1, 1k fps, 16k tbn, 1k tbc (default)
 Metadata:
 encoder : Lavc58.54.100 libx264
 Side data:
 cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
 Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
 Metadata:
 encoder : Lavc58.54.100 aac

frame= 129 fps=0.0 q=33.0 size= 0kB time=00:00:00.23 bitrate= 1.6kbits/s dup=123 drop=0 speed=0.44x 
frame= 257 fps=228 q=33.0 size= 0kB time=00:00:00.51 bitrate= 0.8kbits/s dup=243 drop=0 speed=0.455x 
frame= 379 fps=224 q=33.0 size= 256kB time=00:00:00.73 bitrate=2855.1kbits/s dup=358 drop=0 speed=0.434x 
frame= 497 fps=222 q=33.0 size= 256kB time=00:00:00.86 bitrate=2431.5kbits/s dup=469 drop=0 speed=0.386x 
 
...
More than 1000 frames duplicated
...
 
frame=158751 fps=196 q=33.0 size= 134656kB time=00:02:39.00 bitrate=6937.4kbits/s dup=151385 drop=0 speed=0.196x 
frame=158851 fps=196 q=33.0 size= 134912kB time=00:02:39.00 bitrate=6950.6kbits/s dup=151482 drop=0 speed=0.196x 
frame=158983 fps=196 q=33.0 size= 134912kB time=00:02:39.00 bitrate=6950.6kbits/s dup=151610 drop=0 speed=0.196x 
frame=159081 fps=196 q=-1.0 Lsize= 137197kB time=00:02:39.07 bitrate=7065.2kbits/s dup=151706 drop=0 speed=0.196x 

video:132693kB audio:2494kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.486001%

[libx264 @ 0x562b4842a500] frame I:637 Avg QP:17.73 size:123895
[libx264 @ 0x562b4842a500] frame P:40088 Avg QP:19.73 size: 1134
[libx264 @ 0x562b4842a500] frame B:118356 Avg QP:27.54 size: 97
[libx264 @ 0x562b4842a500] consecutive B-frames: 0.8% 0.0% 0.0% 99.2%
[libx264 @ 0x562b4842a500] mb I I16..4: 11.1% 67.3% 21.6%
[libx264 @ 0x562b4842a500] mb P I16..4: 0.1% 0.1% 0.0% P16..4: 2.6% 0.4% 0.3% 0.0% 0.0% skip:96.5%
[libx264 @ 0x562b4842a500] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.7% 0.0% 0.0% direct: 0.0% skip:99.3% L0:38.7% L1:61.3% BI: 0.0%
[libx264 @ 0x562b4842a500] 8x8 transform intra:66.8% inter:71.4%
[libx264 @ 0x562b4842a500] coded y,uvDC,uvAC intra: 81.8% 89.5% 72.3% inter: 0.2% 0.4% 0.0%
[libx264 @ 0x562b4842a500] i16 v,h,dc,p: 25% 21% 17% 37%
[libx264 @ 0x562b4842a500] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 22% 12% 4% 5% 6% 6% 6% 6%
[libx264 @ 0x562b4842a500] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 24% 6% 4% 5% 5% 6% 4% 4%
[libx264 @ 0x562b4842a500] i8c dc,h,v,p: 42% 24% 26% 9%
[libx264 @ 0x562b4842a500] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x562b4842a500] ref P L0: 82.4% 11.5% 5.3% 0.8%
[libx264 @ 0x562b4842a500] ref B L0: 83.0% 16.9% 0.1%
[libx264 @ 0x562b4842a500] ref B L1: 94.9% 5.1%
[libx264 @ 0x562b4842a500] kb/s:6833.11
[aac @ 0x562b4842b540] Qavg: 239.393



-
-
Long Overdue MediaWiki Upgrade
5 février 2014, par Multimedia Mike — GeneralWhat do I do ? What I do ? This library book is 42 years overdue !
I admit that it’s mine, yet I can’t pay the fine,
Should I turn it in or should I hide it again ?
What do I do ? What do I do ?I internalized the forgoing paean to the perils of procrastination by Shel Silverstein in my formative years. It’s probably why I’ve never paid a single cent in late fees in my entire life.
However, I have been woefully negligent as the steward of the MediaWiki software that drives the world famous MultimediaWiki, the internet’s central repository of obscure technical knowledge related to multimedia. It is currently running of version 1.6 software. The latest version is 1.22.
The Story So Far
According to my records, I first set up the wiki late in 2005. I don’t know which MediaWiki release I was using at the time. I probably conducted a few upgrades in the early days, but that went by the wayside perhaps in 2007. My web host stopped allowing shell access and the MediaWiki upgrade process pretty much requires running a PHP script from a command line. Upgrade time came around and I put off the project. Weeks turned into months turned into years until, according to some notes, the wiki abruptly stopped working in July, 2011. Suddenly, there were PHP errors about “Namespace” being a reserved word.While I finally laid out a plan to upgrade the wiki after all these years, I eventually found that the problem had been caused when my webhost upgraded from PHP 5.2 -> 5.3. I also learned of a small number of code changes that caused the problem to go away, thus kicking the can down the road once more.
Then a new problem showed up last week. I think it might be related to a new version of PHP again. This time, a few other things on my site broke, and I learned that my webhost now allows me to select a PHP version to use (with the version then set to “auto”, which didn’t yield much information). Rolling back to an earlier version of PHP might have solved the problem easily.
But NO ! I made the determination that this goes no further. I want this wiki upgraded.
The Arduous Upgrade Path
There are 2 general upgrade paths I can think of :
- Upgrade in place on the server
- Upgrade offline and put the site back on the server
Approach #1 is problematic since I don’t have direct shell access, though I considered using something like PHP Shell. Approach #2 involves getting the entire set of wiki files and a backup of the MySQL tables. This is workable since I keep automated backups of these items anyway.
In fairly short order, I was able to set up a working copy of the MultimediaWiki hosted on a local Linux machine. Now what’s the move ? The MediaWiki software I’m running is 1.6.10. The very latest, as of this upgrade project is 1.22.2. I suppose it’s way too much to hope that the software will upgrade cleanly from 1.6.x straight to 1.22.x, but I guess it’s worth a shot…
HA ! No chance. Okay, next idea is to march through the various versions and upgrade each in turn. MediaWiki has all their historic releases online, all the way back to the 1.3 lineage. I decided that the latest of each lineage should upgrade cleanly from anything in the previous version of lineage. E.g., 1.6.10 should upgrade cleanly to 1.7.3 (last in the 1.7 series). This seemed to be a workable strategy. So I downloaded the latest of each series, unpacked, and copied all the wiki files over the working installation and ran ‘php update.php’ in the maintenance/ directory.
The process is tedious and not without its obstacles. I consider this penance for my years of wiki neglect. First, I run into the “PHP Parse error : syntax error, unexpected T_NAMESPACE, expecting T_STRING” issue, the same that I saw years ago after the webhost transitioned from PHP 5.2 -> 5.3. I could solve this by editing assorted files and changing “Namespace” -> “MWNamespace” (which is what MediaWiki did by version 1.13). But I would prefer not to.
Instead, I downloaded the source for PHP 5.2 and compiled it in a separate directory, then called ‘/path/to/php/5.2/bin/php update.php’. Problem solved.
The next problem is that a bunch of the database update scripts are specifying “Type=InnoDB”. This isn’t supported by modern MySQL databases. Now, it’s “Engine=InnoDB”. A quick search & replace at the command line fixes this for 1.6.x… and 1.7.x… and 1.8 through 1.12. Finally, at 1.13, it was no longer necessary. As a bonus, at 1.13, I was able to test the installation since Namespace had been renamed to MWNamespace. I would later learn that the table type modifications probably could have been simplified in by changing “$wgDBmysql4 = true ;” to “$wgDBmysql5 = true ;” somewhere in LocalSettings.php.
Command line upgrading worked smoothly up through 1.18 series when I got a new syntax error :
<br />
PHP Fatal error: Call to a member function addMessages() on a non-object in /mnt/sdb1/archive/wiki/extensions/Cite.php on line 68<br />Best I could do was comment out that line. I hope that doesn’t break anything important.
In the home stretch, the very last transition (1.21 -> 1.22) failed :
PHP Fatal error : Cannot redeclare wfProfileIn() (previously declared in /mnt/sdb1/archive/wiki/includes/profiler/Profiler.php:33) in /mnt/sdb1/archive/wiki/includes/ProfilerStub.php on line 25
Apparently, this problem arises occasionally since 1.18. I found a way around it thanks to this page : Deleted the file StartProfiler.php. Who am I to argue ?
Upon completing the transition to 1.22, the wiki doesn’t look correct– the pictures aren’t showing up. The solution was to fix the temporary directory via LocalSettings.php.
Back To Production
Okay, it all works again ! Locally, that is. How to get it back to the server ? My first idea was that, knowing that this upgrade process can succeed, try stepping through the upgrade process again, but tell the update.php scripts to access the database tables on multimedia.cx. This seemed to be working for awhile, even though the database update phase often took 4-5 minutes. However, the transition from 1.8.5 -> 1.9.6 took 75 minutes and then timed out. According to my notes, “This isn’t going to work.”The new process :
- Dump the database tables from the local database.
- Create a new database remotely (melanson_wiki_ng).
- Dump the database table into melanson_wiki_ng.
- Move the index.php file out of the wiki files directory temporarily (or rename).
- Modify the LocalSettings.php to talk to the new database.
- Perform a lftp mirror operation in order to send all the files up to the server.
- Send the index.php file and hope beyond hope that everything magically works.
And that’s the story of how the updated MultimediaWiki came back online. Despite the database dump file being over 110 MB, it only tool MySQL 1m45s to transmit it all to the remote server (let’s hear it for the ‘–compress’ option). For comparison, inserting the tables back into a fresh local database took 1m07s.
When the MultimediaWiki was first live again, it loaded, but ever so slowly. This is when I finally looked into optimization and found that I was lacking any caching. So as a bonus, the MultimediaWiki should be much faster now.
Going Forward
For all I know, I did everything described here in the hardest way possible. But at least I got it done. Unless I learn of a better process, future upgrades will probably look similar to this.Additionally, I should probably take some time to figure out what new features are part of the standard MediaWiki distribution nowadays.