
Recherche avancée
Autres articles (39)
-
La file d’attente de SPIPmotion
28 novembre 2010, parUne file d’attente stockée dans la base de donnée
Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...) -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir -
Demande de création d’un canal
12 mars 2010, parEn fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)
Sur d’autres sites (5401)
-
libav : Store h264 frames in mp4 container
25 janvier 2024, par ImJustACowLolI'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 usinglibavcodec
/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>
-
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>