Recherche avancée

Médias (0)

Mot : - Tags -/organisation

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (35)

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (9522)

  • FFmpeg -bash : ffmpeg : command not found

    12 février 2015, par Daniel Khajehpour

    OK, so I have gone up and down the internet trying to figure out what it is I am doing wrong ... and yet I’m in the middle of nowhere.
    I am basically trying to install the FFmpeg on my CENTOS 6.6 dedicated server by following the instructions here : https://trac.ffmpeg.org/wiki/CompilationGuide/Centos

    Everything seems to go just fine throughout the process. When it’s all done, I type in "ffmpeg" hit the enter and keep on getting this extremely ugly error :

    -bash : -bash: : command not found

    I’m not much of a shell guy, but working with it all day today, I can say that this means that it’s not installed correctly. So, I tried re-installing it, and it tells me all the packages already exist now ... . Here is a copy if what I am doing and what I am getting :

    root@server1 [~]# ffmpeg -version
    
-bash: ffmpeg: command not found
    

    
root@server1 [~]# yum install autoconf automake gcc gcc-c++ git libtool make nasm pkgconfig zlib-devel
    
Loaded plugins: fastestmirror, priorities, security
    
Setting up Install Process
    
Loading mirror speeds from cached hostfile
    
 * base: centos.mirror.ndchost.com
    
 * extras: centos-distro.cavecreek.net
    
 * updates: mirrors.easynews.com
    
Package autoconf-2.63-5.1.el6.noarch already installed and latest version
    
Package automake-1.11.1-4.el6.noarch already installed and latest version
    
Package gcc-4.4.7-11.el6.x86_64 already installed and latest version
    
Package gcc-c++-4.4.7-11.el6.x86_64 already installed and latest version
    
Package git-1.7.1-3.el6_4.1.x86_64 already installed and latest version
    
Package libtool-2.2.6-15.5.el6.x86_64 already installed and latest version
    
Package 1:make-3.81-20.el6.x86_64 already installed and latest version
    
Package nasm-2.07-7.el6.x86_64 already installed and latest version
    
Package 1:pkgconfig-0.23-9.1.el6.x86_64 already installed and latest version
    
Package zlib-devel-1.2.3-29.el6.x86_64 already installed and latest version
    
Nothing to do

    Any ideas or help is greatly appreciated !

  • avformat/matroskadec : Accept more unknown-length elements

    17 mai 2019, par Andreas Rheinhardt
    avformat/matroskadec : Accept more unknown-length elements

    The current Matroska specifications mandate that only two elements may
    
use an unknown-length length : Segments and clusters. But this was not
    
always so : For the greater part of Matroska's existence, all master
    
elements were allowed to make use of the unknown-length feature.
    

    And there were muxers creating such files : For several years
    
libavformat's Matroska muxer used unknown-length for all master
    
elements when the output wasn't seekable. This only stopped in March
    
2010 with 2529bb30. And even afterwards it was possible (albeit
    
unlikely) for libavformat to create unknown-length master elements
    
that are in violation of today's specifications, namely if the master
    
element was so big that the seek backwards to update the size could
    
no longer be performed inside the AVIOContext's write buffer. This
    
has only been fixed in October 2016 (with the patches that introduced
    
support for writing CRC-32 elements).
    

    Libavformat's Matroska demuxer meanwhile has never really supported
    
unknown-length elements besides segments and clusters. Support for the
    
latter was hardcoded. This commit changes this : Now all master elements
    
for which a syntax to parse them is available are supported. This
    
includes the files produced by old versions of libavformat's muxer.
    

    More precisely, master elements that have unknown length and are about
    
to be parsed (not skipped) are supported ; only a warning is emitted for
    
them. For normal files, this means that level 1 elements after the
    
clusters that are encountered after the clusters have been parsed (i.e.
    
not because they are referenced by the seekhead at the beginning of the
    
file) are still unsupported (they would be skipped at this point if
    
their length were known).
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    • [DH] libavformat/matroskadec.c

  • lavu/hwcontext_vulkan : support mapping VUYX, P012, and XV36

    20 août 2022, par Philip Langdale
    lavu/hwcontext_vulkan : support mapping VUYX, P012, and XV36

    If we want to be able to map between VAAPI and Vulkan (to do Vulkan
    
filtering), we need to have matching formats on each side.
    

    The mappings here are not exact. In the same way that P010 is still
    
mapped to full 16 bit formats, P012 has to be mapped that way as well.
    

    Similarly, VUYX has to be mapped to an alpha-equipped format, and XV36
    
has to be mapped to a fully 16bit alpha-equipped format.
    

    While Vulkan seems to fundamentally lack formats with an undefined,
    
but physically present, alpha channel, it has have 10X6 and 12X4
    
formats that you could imagine using for P010, P012 and XV36, but these
    
formats don't support the STORAGE usage flag. Today, hwcontext_vulkan
    
requires all formats to be storable because it wants to be able to use
    
them to create writable images. Until that changes, which might happen,
    
we have to restrict the set of formats we use.
    

    Finally, when mapping a Vulkan image back to vaapi, I observed that
    
the VK_FORMAT_R16G16B16A16_UNORM format we have to use for XV36 going
    
to Vulkan is mapped to Y416 when going to vaapi (which makes sense as
    
it's the exact matching format) so I had to add an entry for it even
    
though we don't use it directly.
    • [DH] libavutil/hwcontext_vulkan.c
    • [DH] libavutil/version.h

Navigation