
Recherche avancée
Autres articles (103)
-
À propos des documents
21 juin 2013, parQue faire quand un document ne passe pas en traitement, dont le rendu ne correspond pas aux attentes ?
Document bloqué en file d’attente ?
Voici une liste d’actions ordonnée et empirique possible pour tenter de débloquer la situation : Relancer le traitement du document qui ne passe pas Retenter l’insertion du document sur le site MédiaSPIP Dans le cas d’un média de type video ou audio, retravailler le média produit à l’aide d’un éditeur ou un transcodeur. Convertir le document dans un format (...) -
Modifier la date de publication
21 juin 2013, parComment changer la date de publication d’un média ?
Il faut au préalable rajouter un champ "Date de publication" dans le masque de formulaire adéquat :
Administrer > Configuration des masques de formulaires > Sélectionner "Un média"
Dans la rubrique "Champs à ajouter, cocher "Date de publication "
Cliquer en bas de la page sur Enregistrer -
Emballe médias : à quoi cela sert ?
4 février 2011, parCe plugin vise à gérer des sites de mise en ligne de documents de tous types.
Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;
Sur d’autres sites (7560)
-
flutter : Getting width and height of video using
2 mai 2019, par ebg11I am trying to retrieve the width and height of a video using flutter. I have tried using ffmpeg
_flutterFFmpeg.getMediaInformation(file.path);
but the width and height are occasionally flipped. I have noticed
"rotate" -> "90" and "displaymatrix" -> "rotation of -90.00 degrees" are present in the meta data returned.Is there a bug free method of using the rotate/display matrix to determine the true width/height of the video or is there a better method/library that can help me here ?
Thanks.
-
Anomalie #3419 : balise isolé dans
8 avril 2015, par b bLe problème vient du commit ci-dessous et semble aussi présent dans le modèle audio.html :
http://zone.spip.org/trac/spip-zone/changeset/87681
Pour info, vu que le code est sur la zone tu peux corriger le bug si tu veux Johan ;)
-
avutil/mem : Use max_alloc_size as-is
21 mai 2020, par Andreas Rheinhardtavutil/mem : Use max_alloc_size as-is
The size of a single allocation performed by av_malloc() or av_realloc()
is supposed to be bounded by max_alloc_size, which defaults to INT_MAX
and can be set by the user ; yet currently this is not completely
honoured : The actual value used is max_alloc_size - 32. How this came
to be can only be understood historically :a) 0ecca7a49f8e254c12a3a1de048d738bfbb614c6 disallowed allocations
> INT_MAX. At that time the size parameter of av_malloc() was an
unsigned and the commentary added ("lets disallow possible ambiguous
cases") indicates that this was done as a precaution against calling the
functions with negative int values. Genuinely limiting the size of
allocations to INT_MAX doesn't seem to have been the intention given
that at this time the memalign hack introduced in commit
da9b170c6f06184a5114dc66afb8385cd0ffff83 (which when enabled increased
the size of allocations slightly so that one can return a correctly
aligned pointer that actually does not point to the beginning of the
allocated buffer) was already present.
b) Said memalign hack allocated 17 bytes more than actually desired, yet
allocating 16 bytes more is actually enough and so this was changed in
a9493601638b048c44751956d2360f215918800c ; this commit also replaced
INT_MAX by INT_MAX - 16 (and made the limit therefore a limit on the size
of the allocated buffer), but kept the comment, although there is nothing
ambiguous about allocating (INT_MAX - 16)..INT_MAX.
c) 13dfce3d44f99a2d7df71aba8ae003d58db726f7 then increased 16 to 32 for
AVX, 6b4c0be5586acad3bbafd7d2dd02a8328a5ab632 replaced INT_MAX by
MAX_MALLOC_SIZE (which was of course defined to be INT_MAX) and
5a8e994287d8ef181c0a5eac537547d7059b4524 added max_alloc_size and made
it user-selectable.
d) 4fb311c804098d78e5ce5f527f9a9c37536d3a08 then dropped the memalign
hack, yet it kept the -32 (probably because the comment about ambiguous
cases was still present ?), although it is no longer needed at all after
this commit. Therefore this commit removes it and uses max_alloc_size
directly.Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>