
Advanced search
Other articles (71)
-
MediaSPIP v0.2
21 June 2013, byMediaSPIP 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 (...) -
MediaSPIP version 0.1 Beta
16 April 2011, byMediaSPIP 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 (...) -
Publier sur MédiaSpip
13 June 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
On other websites (10228)
-
Revisiting the Belco Alpha-400
26 August 2010, by Multimedia Mike — GeneralRelieved of the primary FATE maintenance duties, I decided to dust off my MIPS-based Belco Alpha-400 and try to get it doing FATE cycles. And just as I was about to get FATE running, I saw that Mans already got his MIPS-based Popcorn Hour device to run FATE. But here are my notes anyway.
Getting A Prompt
For my own benefit, I made a PDF to remind me precisely how to get a root prompt on the Alpha-400. The ‘jailbreak’ expression seems a little juvenile to me, but it seems to be in vogue right now.Toolchain
When I last tinkered with the Alpha-400, I was trying to build a toolchain that could build binaries to run on the unit’s MIPS chip, to no avail. Sometime last year, MichaelK put together x86_32-hosted toolchains that are able to build mipsel 32-bit binaries for Linux 2.4 and 2.6. The Alpha-400 uses a 2.4 kernel and the corresponding toolchain works famously for building current FFmpeg (--disable-devices
is necessary for building).FATE Samples
Next problem: Making the FATE suite available to the Alpha-400. I copied all of the FATE suite samples onto a VFAT-formatted SD card. The filename case is not preserved for all files which confounds me since it is preserved in other cases. I tried formatting the card for ext3 but the Alpha-400 would not mount it, even though /proc/filesystems lists ext3 (supporting an older version of ext3?).Alternative: Copy all of the FATE samples to the device’s rootfs. Space will be a little tight, though. Then again, there is over 600 MB of space free; I misread earlier and thought there were only 300 MB free.
Remote Execution
To perform FATE cycles on a remote device, it helps to be able to SSH into that remote device. I don’t even want to know how complicated it would be to build OpenSSH for the device. However, the last time I brought up this topic, I learned about a lighter weight SSH replacement called Dropbear. It turns out that Dropbear runs great on this MIPS computer.Running FATE Remotely
I thought all the pieces would be in place to run FATE at this point. However, there is one more issue: Running FATE on a remote system requires that the host and the target are sharing a filesystem somehow. My personal favorite remote filesystem method is sshfs which is supposed to work wherever there is an SSH server. That’s not entirely true, though– sshfs also requires sftp-server to be installed on the server side, a program that Dropbear does not currently provide.I’m not even going to think about getting Samba or NFS server software installed on the Alpha-400. According to the unit’s /proc/filesystems file, nfs is a supported filesystem. I hate setting up NFS but may see if I can get that working anyway.
Residual Weirdness
The unit comes with the venerable Busybox program (BusyBox v1.4.1 (2007-06-01 20:37:18 CST) multi-call binary
) for most of its standard command line utilities. I noticed a quirk where BusyBox’s md5sum gives weird hex characters. This might be a known/fixed issue.Another item is that the Alpha-400′s /dev/null file only has rwxr-xr-x per default. This caused trouble when I first tried to scp using Dropbear using a newly-created, unprivileged user.
-
FFmpeg destroys my Images
14 September 2015, by dazzafactRightnow iam trying to render a Video reading my image Folder with about 83 Images. Iam using this FFMPEG Snip:
ffmpeg -f image2 -i images/*.jpg -b 450k -r 30 zoom100.avi 2>&1
But iam really frustrated, FFMPEG always replace all my Images with the first Image. And The video it also creates me is about 2 Frames long
Here the FFMPEF Feedbackffmpeg version 0.8.17-4:0.8.17-0ubuntu0.12.04.1, Copyright (c) 2000-2014 the Libav developers
built on Mar 16 2015 13:26:50 with gcc 4.6.3
The ffmpeg program is only provided for script compatibility and will be removed
in a future release. It has been deprecated in the Libav project to allow for
incompatible command line syntax improvements in its replacement called avconv
(see Changelog for details). Please use avconv instead.
Input #0, image2, from 'images/0750.jpg':
Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
Stream #0.0: Video: mjpeg, yuvj420p, 1280x1280 [PAR 72:72 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
[buffer @ 0x24a4220] w:1280 h:1280 pixfmt:yuvj420p
[buffer @ 0x24a4a00] w:1280 h:1280 pixfmt:yuvj420p
[buffer @ 0x24a52c0] w:1280 h:1280 pixfmt:yuvj420p
[buffer @ 0x24a5b20] w:1280 h:1280 pixfmt:yuvj420p
.....
.....
.....
.....
.....
.....
[buffer @ 0x24d4320] w:1280 h:1280 pixfmt:yuvj420p
Incompatible pixel format 'yuvj420p' for codec 'mpeg4', auto-selecting format 'yuv420p'
[buffer @ 0x24d03c0] w:1280 h:1280 pixfmt:yuvj420p
[avsink @ 0x24ceea0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0x24cc460] w:1280 h:1280 fmt:yuvj420p -> w:1280 h:1280 fmt:yuv420p flags:0x4
Output #0, image2, to 'images/0751.jpg':
Metadata:
encoder : Lavf53.21.1
Stream #0.0: Video: mjpeg, yuvj420p, 1280x1280 [PAR 72:72 DAR 1:1], q=2-31, 200 kb/s, 90k tbn, 25 tbc
Output #1, image2, to 'images/0752.jpg':
Metadata:
encoder : Lavf53.21.1
Stream #1.0: Video: mjpeg, yuvj420p, 1280x1280 [PAR 72:72 DAR 1:1], q=2-31, 200 kb/s, 90k tbn, 25 tbc
Output #2, image2, to 'images/0753.jpg':
Metadata:
encoder : Lavf53.21.1
Stream #2.0: Video: mjpeg, yuvj420p, 1280x1280 [PAR 72:72 DAR 1:1], q=2-31, 200 kb/s, 90k tbn, 25 tbc
....
....
....
....
Output #82, image2, to 'images/0833.jpg':
Metadata:
encoder : Lavf53.21.1
Stream #82.0: Video: mjpeg, yuvj420p, 1280x1280 [PAR 72:72 DAR 1:1], q=2-31, 200 kb/s, 90k tbn, 25 tbc
Output #83, avi, to 'zoom100.avi':
Metadata:
ISFT : Lavf53.21.1
Stream #83.0: Video: mpeg4, yuv420p, 1280x1280 [PAR 1:1 DAR 1:1], q=2-31, 450 kb/s, 30 tbn, 30 tbc
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.0 -> #1.0
Stream #0.0 -> #2.0
Stream #0.0 -> #3.0
Stream #0.0 -> #4.0
....
....
Stream #0.0 -> #80.0
Stream #0.0 -> #81.0
Stream #0.0 -> #82.0
Stream #0.0 -> #83.0
Press ctrl-c to stop encoding
frame= 1 fps= 0 q=7.0 Lq=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=7.0 q=6.5 size= -0kB time=0.03 bitrate= -5.3kbits/s
video:16698kB audio:0kB global headers:0kB muxing overhead -100.000129% -
lavu,lavfi,ffmpeg: Remove experimental OpenCL API
14 November 2017, by Mark Thompsonlavu,lavfi,ffmpeg: Remove experimental OpenCL API
This was added in early 2013 and abandoned several months later; as far as
I can tell, there are no external users. Future OpenCL use will be via
hwcontext, which requires neither special OpenCL-only API nor global state
in libavutil.All internal users are also deleted - this is just the unsharp filter
(replaced by unsharp_opencl, which is more flexible) and the deshake filter
(no replacement).- [DH] configure
- [DH] doc/APIchanges
- [DH] doc/filters.texi
- [DH] doc/utils.texi
- [DH] fftools/Makefile
- [DH] fftools/cmdutils.h
- [DH] fftools/cmdutils_opencl.c
- [DH] libavfilter/Makefile
- [DH] libavfilter/allfilters.c
- [DH] libavfilter/deshake.h
- [DH] libavfilter/deshake_opencl.c
- [DH] libavfilter/deshake_opencl.h
- [DH] libavfilter/deshake_opencl_kernel.h
- [DH] libavfilter/opencl_allkernels.c
- [DH] libavfilter/opencl_allkernels.h
- [DH] libavfilter/unsharp.h
- [DH] libavfilter/unsharp_opencl.c
- [DH] libavfilter/unsharp_opencl.h
- [DH] libavfilter/unsharp_opencl_kernel.h
- [DH] libavfilter/vf_deshake.c
- [DH] libavfilter/vf_unsharp.c
- [DH] libavutil/Makefile
- [DH] libavutil/opencl.c
- [DH] libavutil/opencl.h
- [DH] libavutil/opencl_internal.c
- [DH] libavutil/opencl_internal.h