
Recherche avancée
Médias (1)
-
Carte de Schillerkiez
13 mai 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Texte
Autres articles (47)
-
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 (...) -
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 -
Les tâches Cron régulières de la ferme
1er décembre 2010, parLa gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
Le super Cron (gestion_mutu_super_cron)
Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)
Sur d’autres sites (7299)
-
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>
-
aarch64 : vp9itxfm : Skip empty slices in the first pass of idct_idct 16x16 and 32x32
18 novembre 2016, par Martin Storsjöaarch64 : vp9itxfm : Skip empty slices in the first pass of idct_idct 16x16 and 32x32
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime :vp9_inv_dct_dct_16x16_sub16_add_neon : 1373.2
vp9_inv_dct_dct_32x32_sub32_add_neon : 8089.0By skipping individual 8x16 or 8x32 pixel slices in the first pass,
we reduce the runtime of these functions like this :vp9_inv_dct_dct_16x16_sub1_add_neon : 235.3
vp9_inv_dct_dct_16x16_sub2_add_neon : 1036.7
vp9_inv_dct_dct_16x16_sub4_add_neon : 1036.7
vp9_inv_dct_dct_16x16_sub8_add_neon : 1036.7
vp9_inv_dct_dct_16x16_sub12_add_neon : 1372.1
vp9_inv_dct_dct_16x16_sub16_add_neon : 1372.1
vp9_inv_dct_dct_32x32_sub1_add_neon : 555.1
vp9_inv_dct_dct_32x32_sub2_add_neon : 5190.2
vp9_inv_dct_dct_32x32_sub4_add_neon : 5180.0
vp9_inv_dct_dct_32x32_sub8_add_neon : 5183.1
vp9_inv_dct_dct_32x32_sub12_add_neon : 6161.5
vp9_inv_dct_dct_32x32_sub16_add_neon : 6155.5
vp9_inv_dct_dct_32x32_sub20_add_neon : 7136.3
vp9_inv_dct_dct_32x32_sub24_add_neon : 7128.4
vp9_inv_dct_dct_32x32_sub28_add_neon : 8098.9
vp9_inv_dct_dct_32x32_sub32_add_neon : 8098.8I.e. in general a very minor overhead for the full subpartition case due
to the additional cmps, but a significant speedup for the cases when we
only need to process a small part of the actual input data.Signed-off-by : Martin Storsjö <martin@martin.st>