Recherche avancée

Médias (2)

Mot : - Tags -/documentation

Autres articles (78)

  • Problèmes fréquents

    10 mars 2010, par

    PHP et safe_mode activé
    Une des principales sources de problèmes relève de la configuration de PHP et notamment de l’activation du safe_mode
    La solution consiterait à soit désactiver le safe_mode soit placer le script dans un répertoire accessible par apache pour le site

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • Personnaliser les catégories

    21 juin 2013, par

    Formulaire de création d’une catégorie
    Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
    Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
    On peut modifier ce formulaire dans la partie :
    Administration > Configuration des masques de formulaire.
    Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
    Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)

Sur d’autres sites (12594)

  • FFmpeg remuxing parts of an audio file

    22 décembre 2022, par zorleone

    I'm trying to remux individual tracks from a FLAC file using the FFmpeg libraries.
I get the starting timestamps from a Cue sheet, I seek to the timestamps using avformat_seek_file. However after writing the packets to output files, they only have data from the beginning of the input file.

    


    This is the code snippet which opens the input FLAC and also creates an output AVFormatContext for each track. I'm guessing the issue is avformat_seek_file, it doesn't seem to do anything, since even though I seek to the beginning of a track, the output file contains data from the beginning of the input.

    


        for(int i = 0; i <= sheet.ntracks; i++) {
        sheet.avfmtctx = avformat_alloc_context();
        if(avformat_open_input(&sheet.avfmtctx, sheet.file, NULL, NULL) < 0) {
            fprintf(stderr,
                    "avformat_open_input(): failed to open %s\n",
                    sheet.file);
            return 1;
        }
        int audio_stream_idx = -1;
        for(int i = 0; i < sheet.avfmtctx->nb_streams; i++) {
            if(sheet.avfmtctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
                audio_stream_idx = i;
                break;
            }
        }
        avformat_find_stream_info(sheet.avfmtctx, NULL);
        AVFormatContext *output;
        char *filepath = title_to_filepath(&sheet.tracks[i], sheet.file);
        avformat_alloc_output_context2(&output, NULL, NULL, filepath);
        AVStream *out_audio_stream = avformat_new_stream(output, NULL);
        avcodec_parameters_copy(out_audio_stream->codecpar,
                                sheet.avfmtctx->streams[audio_stream_idx]->codecpar);

        if(avio_open(&output->pb, filepath, AVIO_FLAG_WRITE) < 0) {
            fprintf(stderr, "Failed to open %s for writing\n", filepath);
            return 1;
        }
        if(avformat_write_header(output, NULL) < 0) {
            fprintf(stderr, "avformat_write_header() failed\n");
            return 1;
        }
        int64_t current_frame = sheet.tracks[i].index;
        int64_t next_track_index = (i < sheet.ntracks) ?
                                   sheet.tracks[i + 1].index :
                                   INT64_MAX;
        if(avformat_seek_file(sheet.avfmtctx,
                           -1,
                           INT64_MIN,
                           current_frame,
                           current_frame,
                           0) < 0) {
            fprintf(stderr, "Failed to seek to the index of track %d\n", i);
            avformat_free_context(sheet.avfmtctx);
            sheet.avfmtctx = NULL;
            av_write_trailer(output);
            avio_closep(&output->pb);
            avformat_free_context(output);
            free(filepath);
            continue;
        }
        AVPacket *pkt = av_packet_alloc();
        int64_t pts_diff = AV_NOPTS_VALUE, dts_diff = AV_NOPTS_VALUE;
        while(current_frame < next_track_index && !avio_feof(output->pb)) {
            int ret;
            if((ret = av_read_frame(sheet.avfmtctx, pkt)) < 0) {
                if(ret != AVERROR_EOF)
                    fprintf(stderr, "av_read_frame() failed: %s\n", av_err2str(ret));
                break;
            }
            if(pkt->stream_index != audio_stream_idx)
                continue;
            // runs only once
            if(pts_diff == AV_NOPTS_VALUE && dts_diff == AV_NOPTS_VALUE) {
                pts_diff = pkt->pts;
                dts_diff = pkt->dts;
            }

            pkt->stream_index = 0; // first and only stream
            pkt->pts -= pts_diff;
            pkt->dts -= dts_diff;
            pkt->pos = -1;
            av_interleaved_write_frame(output, pkt);

            current_frame++;
        }

        avformat_free_context(sheet.avfmtctx);
        sheet.avfmtctx = NULL;

        av_write_trailer(output);
        av_packet_free(&pkt);
        avio_closep(&output->pb);
        avformat_free_context(output);

        free(filepath);
    }



    


    current_frame and next_track_index are calculated from the INDEX lines in the Cue sheet : MM * 60 * 75 + SS * 75 + FF.
Can someone tell me what I'm doing wrong, and how to get the data I need from the input ?

    


  • aarch64 : vp9 : Implement NEON loop filters

    13 novembre 2016, par Martin Storsjö
    aarch64 : vp9 : Implement NEON loop filters
    

    This work is sponsored by, and copyright, Google.

    These are ported from the ARM version ; thanks to the larger
    amount of registers available, we can do the loop filters with
    16 pixels at a time. The implementation is fully templated, with
    a single macro which can generate versions for both 8 and
    16 pixels wide, for both 4, 8 and 16 pixels loop filters
    (and the 4/8 mixed versions as well).

    For the 8 pixel wide versions, it is pretty close in speed (the
    v_4_8 and v_8_8 filters are the best examples of this ; the h_4_8
    and h_8_8 filters seem to get some gain in the load/transpose/store
    part). For the 16 pixels wide ones, we get a speedup of around
    1.2-1.4x compared to the 32 bit version.

    Examples of runtimes vs the 32 bit version, on a Cortex A53 :
    ARM AArch64
    vp9_loop_filter_h_4_8_neon : 144.0 127.2
    vp9_loop_filter_h_8_8_neon : 207.0 182.5
    vp9_loop_filter_h_16_8_neon : 415.0 328.7
    vp9_loop_filter_h_16_16_neon : 672.0 558.6
    vp9_loop_filter_mix2_h_44_16_neon : 302.0 203.5
    vp9_loop_filter_mix2_h_48_16_neon : 365.0 305.2
    vp9_loop_filter_mix2_h_84_16_neon : 365.0 305.2
    vp9_loop_filter_mix2_h_88_16_neon : 376.0 305.2
    vp9_loop_filter_mix2_v_44_16_neon : 193.2 128.2
    vp9_loop_filter_mix2_v_48_16_neon : 246.7 218.4
    vp9_loop_filter_mix2_v_84_16_neon : 248.0 218.5
    vp9_loop_filter_mix2_v_88_16_neon : 302.0 218.2
    vp9_loop_filter_v_4_8_neon : 89.0 88.7
    vp9_loop_filter_v_8_8_neon : 141.0 137.7
    vp9_loop_filter_v_16_8_neon : 295.0 272.7
    vp9_loop_filter_v_16_16_neon : 546.0 453.7

    The speedup vs C code in checkasm tests is around 2-7x, which is
    pretty much the same as for the 32 bit version. Even if these functions
    are faster than their 32 bit equivalent, the C version that we compare
    to also became around 1.3-1.7x faster than the C version in 32 bit.

    Based on START_TIMER/STOP_TIMER wrapping around a few individual
    functions, the speedup vs C code is around 4-5x.

    Examples of runtimes vs C on a Cortex A57 (for a slightly older version
    of the patch) :
    A57 gcc-5.3 neon
    loop_filter_h_4_8_neon : 256.6 93.4
    loop_filter_h_8_8_neon : 307.3 139.1
    loop_filter_h_16_8_neon : 340.1 254.1
    loop_filter_h_16_16_neon : 827.0 407.9
    loop_filter_mix2_h_44_16_neon : 524.5 155.4
    loop_filter_mix2_h_48_16_neon : 644.5 173.3
    loop_filter_mix2_h_84_16_neon : 630.5 222.0
    loop_filter_mix2_h_88_16_neon : 697.3 222.0
    loop_filter_mix2_v_44_16_neon : 598.5 100.6
    loop_filter_mix2_v_48_16_neon : 651.5 127.0
    loop_filter_mix2_v_84_16_neon : 591.5 167.1
    loop_filter_mix2_v_88_16_neon : 855.1 166.7
    loop_filter_v_4_8_neon : 271.7 65.3
    loop_filter_v_8_8_neon : 312.5 106.9
    loop_filter_v_16_8_neon : 473.3 206.5
    loop_filter_v_16_16_neon : 976.1 327.8

    The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
    is again 30-50% faster than the cortex-a53.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DBH] libavcodec/aarch64/Makefile
    • [DBH] libavcodec/aarch64/vp9dsp_init_aarch64.c
    • [DBH] libavcodec/aarch64/vp9lpf_neon.S
  • rtpdec : Don’t pass non-const pointers to fmtp attribute parsing functions

    24 février 2015, par Martin Storsjö
    rtpdec : Don’t pass non-const pointers to fmtp attribute parsing functions
    

    This makes it clear that the individual parsing functions can’t
    touch the parsed out value.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DBH] libavformat/rtpdec.c
    • [DBH] libavformat/rtpdec.h
    • [DBH] libavformat/rtpdec_amr.c
    • [DBH] libavformat/rtpdec_dv.c
    • [DBH] libavformat/rtpdec_h264.c
    • [DBH] libavformat/rtpdec_hevc.c
    • [DBH] libavformat/rtpdec_ilbc.c
    • [DBH] libavformat/rtpdec_latm.c
    • [DBH] libavformat/rtpdec_mpeg4.c
    • [DBH] libavformat/rtpdec_xiph.c