Recherche avancée

Médias (1)

Mot : - Tags -/berlin

Autres articles (72)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 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, par

    Par 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 (...)

  • (Dés)Activation de fonctionnalités (plugins)

    18 février 2011, par

    Pour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
    SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
    Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
    MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)

Sur d’autres sites (8644)

  • New FATE Test Coverage System

    10 août 2010, par Multimedia Mike — FATE Server

    I’ve been feeling a bit scattered for the last week since I was fired from my volunteer position as the FFmpeg QA manager, wondering if there is anything I should attempt to do with the project. It can’t be denied that the new system is working well. But one area I’ve wondered about is test coverage.

    Under my old regime I tracked test coverage as a wiki page which was a highly flawed method— tedious and error-prone. There are those 2 adjectives again— tedious and error-prone ; whenever I see those, I search for automation methods. I think that might be more plausible thanks to the new FATE’s tighter integration with the FFmpeg build system.

    I don’t think anyone is working on this problem so I wanted to toss out a brainstorm :

    1. First, run ’ffmpeg -formats’, ’ffmpeg -codecs’, etc. and parse the output to collect a list of all the features (full list : -formats, -codecs, -bsfs, -protocols, -filters, -pix_fmts). Transform these lists into a standardized list of features, e.g., "DEVSD  ffvhuff         Huffyuv FFmpeg variant" represents features ’decode-video-ffvhuff’, ’encode-video-ffvhuff’, ’ffvhuff-horizband’, and ’ffvhuff-dr1’.
    2. Next, tag each individual test spec with the features that it exercises. E.g., test ’fate-vqa-cc’ exercises features ’demux-wsvqa’, ’decode-video-vqavideo’, and ’decode-audio-adpcm_ima_ws’.
    3. Finally, compare the data from parts 1 and 2. Print a list of all the features that are not exercised in FATE.

    I think a lot of this could be implemented at the GNU make level. Then again, I’m no expert on GNU make syntax so I may be overestimating its capabilities. Or there might be simpler ways to automatically track test coverage stats based on the improved testing infrastructure.

  • FFMPEG - Batch convert subfolders

    22 avril 2013, par user2306403

    I am trying to set up a Windows batch file to convert a number of MP4 files using FFMPEG. There are a number of files in multiple subfolders, therefore I need the script to execute on each file in each subfolder.

    I'm afraid I don't have much experience of using batch files but from my research I've got the following command text :

    FOR %%i in (*.mp4) /R DO (ffmpeg32 -i "%%~ni.mp4" -map 0:0 -map 0:1 -map 0:1    -c:v copy   -c:a:0 aac -b:a 128k -ac 2 -strict -2 -cutoff 15000  -c:a:1 copy "%~ni&(2).mp4")

    The script basically needs to add an AAC audio stream to an existing MP4 file, therefore I need to change the output name by adding a (2) at the end of the filename.

    I've tested the ffmpeg command separately so happy that it works - I just need to get the correct batch commands.

    Thanks in advance for any pointers !

    Cheers

  • Hacking the Popcorn Hour C-200

    3 mai 2010, par Mans — Hardware, MIPS

    Update : A new firmware version has been released since the publication of this article. I do not know if the procedure described below will work with the new version.

    The Popcorn Hour C-200 is a Linux-based media player with impressive specifications. At its heart is a Sigma Designs SMP8643 system on chip with a 667MHz MIPS 74Kf as main CPU, several co-processors, and 512MB of DRAM attached. Gigabit Ethernet, SATA, and USB provide connectivity with the world around it. With a modest $299 on the price tag, the temptation to repurpose the unit as a low-power server or cheap development board is hard to resist. This article shows how such a conversion can be achieved.

    Kernel

    The PCH runs a patched Linux 2.6.22.19 kernel. A source tarball is available from the manufacturer. This contains the sources with Sigma support patches, Con Kolivas’ patch set (scheduler tweaks), and assorted unrelated changes. Properly split patches are unfortunately not available. I have created a reduced patch against vanilla 2.6.22.19 with only Sigma-specific changes, available here.

    The installed kernel has a number of features disabled, notably PTY support and oprofile. We will use kexec to load a more friendly one.

    As might be expected, the PCH kernel does not have kexec support enabled. It does however, by virtue of using closed-source components, support module loading. This lets us turn kexec into a module and load it. A patch for this is available here. To build the module, apply the patch to the PCH sources and build using this configuration. This will produce two modules, kexec.ko and mips_kexec.ko. No other products of this build will be needed.

    The replacement kernel can be built from the PCH sources or, if one prefers, from vanilla 2.6.22.19 with the Sigma-only patch. For the latter case, this config provides a minimal starting point suitable for NFS-root.

    When configuring the kernel, make sure CONFIG_TANGOX_IGNORE_CMDLINE is enabled. Otherwise the command line will be overridden by a useless one stored in flash. A good command line can be set with CONFIG_CMDLINE (under “Kernel hacking” in menuconfig) or passed from kexec.

    Taking control

    In order to load our kexec module, we must first gain root privileges on the PCH, and here a few features of the system are working to our advantage :

    1. The PCH allows mounting any NFS export to access media files stored there.
    2. There is an HTTP server running. As root.
    3. This HTTP server can be readily instructed to fetch files from an NFS mount.
    4. Files with a name ending in .cgi are executed. As root.

    All we need do to profit from this is place the kexec modules, the kexec userspace tools, and a simple script on an NFS export. Once this is done, and the mount point configured on the PCH, a simple HTTP request will send the old kernel screaming to /dev/null, our shiny new kernel taking its place.

    The rootfs

    A kernel is mostly useless without a root filesystem containing tools and applications. A number of tools for cross-compiling a full system exist, each with its strengths and weaknesses. The only thing to look out for is the version of kernel headers used (usually a linux-headers package). As we will be running an old kernel, chances are the default version is too recent. Other than this, everything should be by the book.

    Assembling the parts

    Having gathered all the pieces, it is now time to assemble the hack. The following steps are suitable for an NFS-root system. Adaptation to a disk-based system is left as an exercise.

    1. Build a rootfs for MIPS 74Kf little endian. Make sure kernel headers used are no more recent than 2.6.22.x. Include a recent version of the kexec userspace tools.
    2. Fetch and unpack the PCH kernel sources.
    3. Apply the modular kexec patch.
    4. Using this config, build the modules and install them as usual to the rootfs. The version string must be 2.6.22.19-19-4.
    5. From either the same kernel sources or plain 2.6.22.19 with Sigma patches, build a vmlinux and (optionally) modules using this config. Modify the compiled-in command line to point to the correct rootfs. Set the version string to something other than in the previous step.
    6. Copy vmlinux to any directory in the rootfs.
    7. Copy kexec.sh and kexec.cgi to the same directory as vmlinux.
    8. Export the rootfs over NFS with full read/write permissions for the PCH.
    9. Power on the PCH, and update to latest firmware.
    10. Configure an NFS mount of the rootfs.
    11. Navigate to the rootfs in the PCH UI. A directory listing of bin, dev, etc. should be displayed.
    12. On the host system, run the kexec.sh script with the target hostname or IP address as argument.
    13. If all goes well, the new kernel will boot and mount the rootfs.

    Serial console

    A serial console is indispensable for solving boot problems. The PCH board has two UART connectors. We will use the one labeled UART0. The pinout is as follows (not standard PC pinout).

            +-----------+
           2| * * * * * |10
           1| * * * * * |9
            -----------+
              J7 UART0
        /---------------------/ board edge
    
    Pin Function
    1 +5V
    5 Rx
    6 Tx
    10 GND

    The signals are 3.3V so a converter, e.g. MAX202, is required for connecting this to a PC serial port. The default port settings are 115200 bps 8n1.