Recherche avancée

Médias (16)

Mot : - Tags -/mp3

Autres articles (33)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

  • Ajouter notes et légendes aux images

    7 février 2011, par

    Pour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
    Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
    Modification lors de l’ajout d’un média
    Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)

Sur d’autres sites (6261)

  • avformat/ttaenc : Defer freeing dynamic buffer

    20 mai 2020, par Andreas Rheinhardt
    avformat/ttaenc : Defer freeing dynamic buffer
    

    The TTA muxer writes a seektable in a dynamic buffer as it receives
    packets and when writing the trailer, closes the dynamic buffer using
    avio_close_dyn_buf(), writes the seektable and frees the buffer. But
    the TTA muxer already has a deinit function which unconditionally
    calls ffio_free_dyn_buf() on the dynamic buffer, so switching to
    avio_get_dyn_buf() means that one can remove the code to free the
    buffer ; furthermore, it also might save an allocation if the seektable
    is so small that it fits into the dynamic buffer's write buffer or if
    adding the padding that avio_close_dyn_buf() adds necessitated
    reallocating of the underlying buffer.

    Reviewed-by : James Almer <jamrial@gmail.com>
    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

    • [DH] libavformat/ttaenc.c
  • Can ffprobe consume piped ffmpeg output ?

    19 mai 2020, par slifty

    The Situation

    &#xA;&#xA;

    I'm writing a NodeJS script that takes a video stream (or file), pipes it to ffmpeg to standardize the format, and then sends it to various ETL processes to extract data from the video.

    &#xA;&#xA;

    I want my node-level data stream to have awareness of how far into the video it is, and it seems the best (only ?) way to do this is to use ffprobe to extract times from the stream packets.

    &#xA;&#xA;

    The Problem

    &#xA;&#xA;

    Before I actually start spawning ffmpeg commands, I'm trying to test at the CLI level. When I pipe ffmpeg's output directly to ffprobe, I receive a complaint :

    &#xA;&#xA;

    av_interleaved_write_frame(): Broken pipe&#xA;Error writing trailer of pipe:: Broken pipe&#xA;

    &#xA;&#xA;

    The command in question :

    &#xA;&#xA;

    ffmpeg -i /path/to/in.mp4 -f mpegts - | ffprobe -i - -print_format json&#xA;

    &#xA;&#xA;

    The Question

    &#xA;&#xA;

    Am I misunderstanding something about what ffprobe accepts ? I haven't found a single example of ffmpeg piping to ffprobe, which makes me nervous.

    &#xA;&#xA;

    Is it possible to pipe ffmpeg data directly to ffprobe ?

    &#xA;&#xA;

    Bonus points : if you have a better way of extracting timing information from the ffmpeg stream, take a look at this question

    &#xA;

  • avformat/matroskaenc : Allow a custom destination for writing Tags

    29 avril 2020, par Andreas Rheinhardt
    avformat/matroskaenc : Allow a custom destination for writing Tags
    

    Up until now, the Matroska muxer writes only one Tags level 1 element
    and therefore using a certain place to store the dynamic buffer used for
    writing it was hardcoded ; yet the Matroska specifications allow an
    unlimited amount of Tags elements and we have reason to write a second
    one : If chapters are provided after writing the header, they are written
    when writing the trailer ; yet the corresponding tags are ignored. This
    can be fixed by writing them in a second Tags element.

    Also use a MatroskaMuxContext * instead of an AVFormatContext * as
    parameter in mkv_write_tag() and mkv_write_tag_targets() as that is all
    these functions use.

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

    • [DH] libavformat/matroskaenc.c