
Recherche avancée
Médias (1)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
Autres articles (86)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...) -
Le profil des utilisateurs
12 avril 2011, parChaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...)
Sur d’autres sites (11017)
-
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>