Recherche avancée

Médias (1)

Mot : - Tags -/iphone

Autres articles (96)

  • Encodage et transformation en formats lisibles sur Internet

    10 avril 2011

    MediaSPIP transforme et ré-encode les documents mis en ligne afin de les rendre lisibles sur Internet et automatiquement utilisables sans intervention du créateur de contenu.
    Les vidéos sont automatiquement encodées dans les formats supportés par HTML5 : MP4, Ogv et WebM. La version "MP4" est également utilisée pour le lecteur flash de secours nécessaire aux anciens navigateurs.
    Les documents audios sont également ré-encodés dans les deux formats utilisables par HTML5 :MP3 et Ogg. La version "MP3" (...)

  • MediaSPIP Init et Diogène : types de publications de MediaSPIP

    11 novembre 2010, par

    À l’installation d’un site MediaSPIP, le plugin MediaSPIP Init réalise certaines opérations dont la principale consiste à créer quatre rubriques principales dans le site et de créer cinq templates de formulaire pour Diogène.
    Ces quatre rubriques principales (aussi appelées secteurs) sont : Medias ; Sites ; Editos ; Actualités ;
    Pour chacune de ces rubriques est créé un template de formulaire spécifique éponyme. Pour la rubrique "Medias" un second template "catégorie" est créé permettant d’ajouter (...)

  • Dépôt de média et thèmes par FTP

    31 mai 2013, par

    L’outil MédiaSPIP traite aussi les média transférés par la voie FTP. Si vous préférez déposer par cette voie, récupérez les identifiants d’accès vers votre site MédiaSPIP et utilisez votre client FTP favori.
    Vous trouverez dès le départ les dossiers suivants dans votre espace FTP : config/ : dossier de configuration du site IMG/ : dossier des média déjà traités et en ligne sur le site local/ : répertoire cache du site web themes/ : les thèmes ou les feuilles de style personnalisées tmp/ : dossier de travail (...)

Sur d’autres sites (9682)

  • avcodec/aaccoder : Add minimal bias in search_for_ms()

    31 mai 2021, par Michael Niedermayer
    avcodec/aaccoder : Add minimal bias in search_for_ms()
    

    Fixes : floating point division by 0
    Fixes : Ticket8218

    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>

    • [DH] libavcodec/aaccoder.c
  • avcodec/videotoolbox : Fix undefined symbol with minimal configuration

    4 janvier 2022, par Limin Wang
    avcodec/videotoolbox : Fix undefined symbol with minimal configuration
    

    Please reproduced with the following minimal configure command :
    ./configure —enable-shared —disable-all —enable-avcodec —enable-decoder=h264 —enable-hwaccel=h264_videotoolbox

    You'll get below error :

    Undefined symbols for architecture x86_64 :
    "_ff_videotoolbox_vpcc_extradata_create", referenced from :
    _videotoolbox_start in videotoolbox.o
    ld : symbol(s) not found for architecture x86_64
    clang : error : linker command failed with exit code 1 (use -v to see invocation)

    Reported-by : Cameron Gutman <aicommander@gmail.com>
    Tested-by : Cameron Gutman <aicommander@gmail.com>
    Signed-off-by : Limin Wang <lance.lmwang@gmail.com>

    • [DH] libavcodec/videotoolbox.c
  • Why is ffmpeg faster than this minimal example ?

    23 juillet 2022, par Dave Ceddia

    I'm wanting to read the audio out of a video file as fast as possible, using the libav libraries. It's all working fine, but it seems like it could be faster.

    &#xA;

    To get a performance baseline, I ran this ffmpeg command and timed it :

    &#xA;

    time ffmpeg -threads 1 -i file -map 0:a:0 -f null -&#xA;

    &#xA;

    On a test file (a 2.5gb 2hr .MOV with pcm_s16be audio) this comes out to about 1.35 seconds on my M1 Macbook Pro.

    &#xA;

    On the other hand, this minimal C code (based on FFmpeg's "Demuxing and decoding" example) is consistently around 0.3 seconds slower.

    &#xA;

    #include <libavcodec></libavcodec>avcodec.h>&#xA;#include <libavformat></libavformat>avformat.h>&#xA;&#xA;static int decode_packet(AVCodecContext *dec, const AVPacket *pkt, AVFrame *frame)&#xA;{&#xA;    int ret = 0;&#xA;&#xA;    // submit the packet to the decoder&#xA;    ret = avcodec_send_packet(dec, pkt);&#xA;&#xA;    // get all the available frames from the decoder&#xA;    while (ret >= 0) {&#xA;        ret = avcodec_receive_frame(dec, frame);&#xA;        av_frame_unref(frame);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;&#xA;int main (int argc, char **argv)&#xA;{&#xA;    int ret = 0;&#xA;    AVFormatContext *fmt_ctx = NULL;&#xA;    AVCodecContext  *dec_ctx = NULL;&#xA;    AVFrame *frame = NULL;&#xA;    AVPacket *pkt = NULL;&#xA;&#xA;    if (argc != 3) {&#xA;        exit(1);&#xA;    }&#xA;&#xA;    int stream_idx = atoi(argv[2]);&#xA;&#xA;    /* open input file, and allocate format context */&#xA;    avformat_open_input(&amp;fmt_ctx, argv[1], NULL, NULL);&#xA;&#xA;    /* get the stream */&#xA;    AVStream *st = fmt_ctx->streams[stream_idx];&#xA;&#xA;    /* find a decoder for the stream */&#xA;    AVCodec *dec = avcodec_find_decoder(st->codecpar->codec_id);&#xA;&#xA;    /* allocate a codec context for the decoder */&#xA;    dec_ctx = avcodec_alloc_context3(dec);&#xA;&#xA;    /* copy codec parameters from input stream to output codec context */&#xA;    avcodec_parameters_to_context(dec_ctx, st->codecpar);&#xA;&#xA;    /* init the decoder */&#xA;    avcodec_open2(dec_ctx, dec, NULL);&#xA;&#xA;    /* allocate frame and packet structs */&#xA;    frame = av_frame_alloc();&#xA;    pkt = av_packet_alloc();&#xA;&#xA;    /* read frames from the specified stream */&#xA;    while (av_read_frame(fmt_ctx, pkt) >= 0) {&#xA;        if (pkt->stream_index == stream_idx)&#xA;            ret = decode_packet(dec_ctx, pkt, frame);&#xA;&#xA;        av_packet_unref(pkt);&#xA;        if (ret &lt; 0)&#xA;            break;&#xA;    }&#xA;&#xA;    /* flush the decoders */&#xA;    decode_packet(dec_ctx, NULL, frame);&#xA;&#xA;    return ret &lt; 0;&#xA;}&#xA;

    &#xA;

    I tried measuring parts of this program to see if it was spending a lot of time in the setup, but it's not – at least 1.5 seconds of the runtime is the loop where it's reading frames.

    &#xA;

    So I took some flamegraph recordings (using cargo-flamegraph) and ran each a few times to make sure the timing was consistent. There's probably some overhead since both were consistently higher than running normally, but they still have the 0.3 second delta.

    &#xA;

    # 1.812 total&#xA;time sudo flamegraph ./minimal file 1&#xA;&#xA;# 1.542 total&#xA;time sudo flamegraph ffmpeg -threads 1 -i file -map 0:a:0 -f null - 2>&amp;1&#xA;

    &#xA;

    Here are the flamegraphs stacked up, scaled so that the faster one is only 85% as wide as the slower one. (click for larger)

    &#xA;

    ffmpeg versus a minimal example, audio from the same file

    &#xA;

    The interesting thing that stands out to me is how long is spent on read in the minimal example vs. ffmpeg :

    &#xA;

    time spent on read call, ffmpeg vs minimal example

    &#xA;

    The time spent on lseek is also a lot longer in the minimal program – it's plainly visible in that flamegraph, but in the ffmpeg flamegraph, lseek is a single pixel wide.

    &#xA;

    What's causing this discrepancy ? Is ffmpeg actually doing less work than I think it is here ? Is the minimal code doing something naive ? Is there some buffering or other I/O optimizations that ffmpeg has enabled ?

    &#xA;

    How can I shave 0.3 seconds off of the minimal example's runtime ?

    &#xA;