Recherche avancée
Autres articles (66)
-
Keeping control of your media in your hands
13 avril 2011, parThe 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 (...) -
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
Personnaliser les catégories
21 juin 2013, parFormulaire 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 (12085)
-
avformat/segafilmenc : Don't store packet info in linked list
17 juillet 2020, par Andreas Rheinhardtavformat/segafilmenc : Don't store packet info in linked list
Up until now, the Sega FILM muxer would store some information about
each packet in a linked list. When writing the trailer, the information
in said linked list would be used to write a table in the file header.
Each entry in said table is 16 bytes long, but each entry of the linked
list is 32 bytes long (assuming 64 bit pointer and no padding).
Therefore it makes sense to remove the linked list and write the array
entries directly into a dynamic buffer while writing the packet (this is
possible because the table entries don't depend on any information not
available when writing the packet (the offset is not relative to the
beginning of the file, but to the end of the table). This also
simplifies writing the array at the end (there is no need to traverse a
linked list).Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
FFmpeg - generate x264 CBR video transport stream with C-API
6 juillet 2020, par ZeroDefectUsing various posts sprinkled around the Internet, including this one here on SO, I've been able to understand how to use the FFmpeg cli to generate a CBR video bitrate using the x264 codec (wrapped in an MPEG-2 transport stream). Note : I'm concerned with the video bitrate - nothing else.


ffmpeg -i cbr_test_file_input.mp4 -c:v libx264 -pix_fmt yuv420p -b:v 6000000 -preset fast -tune film -g 25 -x264-params vbv-maxrate=6000:vbv-bufsize=6000:force-cfr=1:nal-hrd=cbr -flags +ildct+ilme x264_cbr_test_output.ts


However, I'm trying to approach this from an FFmpeg C-API point of view. I'm having issues. I've knocked together some code to try do something very similar to what is being done in the FFmpeg CLI. I can generate a transport stream of what I think should be CBR, but the profile of the video bitrate is very different from what I thought was the FFmpeg cli equivalent :


The initialisation of the AVCodecContext looks something like :


av_dict_set(&pDict, "preset", "faster", 0);
 av_dict_set(&pDict, "tune", "film", 0);
 av_dict_set_int(&pDict, "rc-lookahead", 25, 0);

 pCdcCtxOut->width = pCdcCtxIn->width;
 pCdcCtxOut->height = pCdcCtxIn->height;
 pCdcCtxOut->pix_fmt = AV_PIX_FMT_YUV420P;
 pCdcCtxOut->gop_size = 25;

 // Going for 6Mbit/s
 pCdcCtxOut->bit_rate = 6000000;
 //pCdcCtxOut->rc_min_rate = pCdcCtxOut->bit_rate;
 pCdcCtxOut->rc_max_rate = pCdcCtxOut->bit_rate;
 pCdcCtxOut->rc_buffer_size = pCdcCtxOut->bit_rate;
 pCdcCtxOut->rc_initial_buffer_occupancy = static_cast<int>((pCdcCtxOut->bit_rate * 9) / 10);

 std::string strParams = "vbv-maxrate="
 + std::to_string(pCdcCtxOut->bit_rate / 1000)
 + ":vbv-bufsize="
 + std::to_string(pCdcCtxOut->bit_rate / 1000)
 + ":force-cfr=1:nal-hrd=cbr";

 av_dict_set(&pDict, "x264-params", strParams.c_str(), 0);

 pCdcCtxOut->field_order = AV_FIELD_TT;
 pCdcCtxOut->flags = (AV_CODEC_FLAG_INTERLACED_DCT | AV_CODEC_FLAG_INTERLACED_ME | AV_CODEC_FLAG_CLOSED_GOP);

 // WARN: Make some assumptions here!
 pCdcCtxOut->time_base = AVRational{1,25};
 pCdcCtxOut->framerate = AVRational{25,1};
 pCdcCtxOut->sample_aspect_ratio = AVRational{64,45};
</int>

The output graphs appear very different :




Above is the FFmpeg CLI output - video bitrate holds fairly steady.




Above is the output of my sample application - some significant dips in the video bitrate.


I've taken this a step further and created a git repo consisting of :


- 

- Code of sample application
- Test input file (.mp4)
- Outputs (.ts file) of tests
- Graphs of output bitrates.










-
avformat/segafilmenc : Avoid seek when writing header
17 juillet 2020, par Andreas Rheinhardtavformat/segafilmenc : Avoid seek when writing header
Up until now, the Sega FILM muxer would first write all the packet data,
then shift the data (in the muxer's write_trailer function) by the amount
necessary to write the header at the front (which entails a seek to the
front), then seek back to the beginning and actually write the header.This commit changes this : The dynamic buffer that is used to write the
sample table (containing information about each sample in the file) is
now used to write the complete header. This is possible because the size
of everything in the header except the sample table is known in advance.
Said buffer can then be used as one of the two temporary buffers used
for shifting which also reduces the amount one has to allocate for this.
Thereby the header will be written when shifting, so that the second
seek to the beginning is unnecessary.Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Syndiquer tout le site
