Recherche avancée

Médias (1)

Mot : - Tags -/censure

Autres articles (65)

  • Gestion des droits de création et d’édition des objets

    8 février 2011, par

    Par défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;

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

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

Sur d’autres sites (10116)

  • libav : Store h264 frames in mp4 container

    25 janvier 2024, par ImJustACowLol

    I'm making a C++ application that retrieves frames from a camera and then encodes each frame with a H264 encoder (not using libav). This encoded H264 frame is then kept in memory as a void *mem as I need to do several things with the encoded frame.

    


    One of the things I need to do, is store the frames (so the void *mem pointers) in a .mp4 container using libavcodec/libavformat. I do NOT want to transcode each frame, I just want to store them directly into the mp4 container.

    


    Preferably for each individual frame that I push through, I get the resulting data as a return type from the function (not sure if this is possible ?). If this is not possible, then writing to a file directly is OK as well.

    


    How does one go about doing this with libav ?

    


    The only part I have got so far, and where I'm getting stuck, is this :

    


    /*
some private fields accessible in MP4Muxer:
int frameWidth_, frameHeight_, frameRate_, srcBitRate_;
*/


void MP4Muxer::muxFrame(void *mem, size_t len, int64_t timestamp, bool keyFrame) {
    const AVOutputFormat* outputFormat = av_guess_format("mp4", NULL, NULL);
    AVFormatContext* outputFormatContext = avformat_alloc_context();
    outputFormatContext->oformat = outputFormat;
    AVStream* videoStream = avformat_new_stream(outputFormatContext, NULL);

    videoStream->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
    videoStream->codecpar->codec_id = AV_CODEC_ID_H264;
    videoStream->codecpar->width = frameWidth_;
    videoStream->codecpar->height = frameHeight_;
    videoStream->avg_frame_rate = (AVRational) {frameRate_, 1};
    videoStream->time_base = (AVRational) {1, 90000};

}


    


    How do I continue from here ? Are there any good resources I can follow ? There are some resources I found online, but all of them either write the output directly to a file, read input directly from streams/files etc. so I have a hard time translating them to my needs.

    


  • movenc : Add a flag for indicating a discontinuous fragment

    20 novembre 2014, par Martin Storsjö
    movenc : Add a flag for indicating a discontinuous fragment
    

    This allows creating a later mp4 fragment without sequentially
    writing the earlier ones before (when called from a segmenter).

    Normally when writing a fragmented mp4 file sequentially, the
    first timestamps of a fragment are adjusted to match the
    end of the previous fragment, to make sure the timestamp is the
    same, even if it is calculated as the sum of previous fragment
    durations. (And for the first packet in a file, the offset of
    the first packet is written using an edit list.)

    When writing an individual mp4 fragment discontinuously like this
    (with potentially writing the earlier fragments separately later),
    there’s a risk of getting a gap in the timeline if the duration
    field of the last packet in the previous fragment doesn’t match up
    with the start time of the next fragment.

    Using this requires setting -avoid_negative_ts make_non_negative
    (or -avoid_negative_ts 0).

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

    • [DBH] libavformat/movenc.c
    • [DBH] libavformat/movenc.h
  • movenc : Allow writing a DASH sidx atom at the start of files

    21 octobre 2014, par Martin Storsjö
    movenc : Allow writing a DASH sidx atom at the start of files
    

    This is mapped to the faststart flag (which in this case
    perhaps should be called "shift and write index at the
    start of the file"), which for fragmented files will
    write a sidx index at the start.

    When segmenting DASH into files, there’s usually one sidx
    at the start of each segment (although it’s not clear to me
    whether that actually is necessary). When storing all of it
    in one file, the MPD doesn’t necessarily need to describe
    the individual segments, but the offsets of the fragments can be
    fetched from one large sidx atom at the start of the file. This
    allows creating files for the DASH ISO BMFF on-demand profile.

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

    • [DBH] libavformat/movenc.c
    • [DBH] libavformat/movenc.h