Recherche avancée
Médias (1)
-
The Slip - Artworks
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Texte
Autres articles (89)
-
Organiser par catégorie
17 mai 2013, parDans MédiaSPIP, une rubrique a 2 noms : catégorie et rubrique.
Les différents documents stockés dans MédiaSPIP peuvent être rangés dans différentes catégories. On peut créer une catégorie en cliquant sur "publier une catégorie" dans le menu publier en haut à droite ( après authentification ). Une catégorie peut être rangée dans une autre catégorie aussi ce qui fait qu’on peut construire une arborescence de catégories.
Lors de la publication prochaine d’un document, la nouvelle catégorie créée sera proposée (...) -
Récupération d’informations sur le site maître à l’installation d’une instance
26 novembre 2010, parUtilité
Sur le site principal, une instance de mutualisation est définie par plusieurs choses : Les données dans la table spip_mutus ; Son logo ; Son auteur principal (id_admin dans la table spip_mutus correspondant à un id_auteur de la table spip_auteurs)qui sera le seul à pouvoir créer définitivement l’instance de mutualisation ;
Il peut donc être tout à fait judicieux de vouloir récupérer certaines de ces informations afin de compléter l’installation d’une instance pour, par exemple : récupérer le (...) -
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 (10249)
-
How does FFmpeg determine the dispositions of an MP4 track ?
5 mars, par obskyrThe Issue


FFmpeg has a concept of “dispositions” – a property that describes the purpose of a stream in a media file. For example, here are the streams in a file I have lying around, with the dispositions emphasized :


Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo,
fltp, 251 kb/s <strong><em>(default)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Audio
 vendor_id : [0][0][0][0]

 Stream #0:1[0x2](und): Video: mjpeg (Baseline) (jpeg / 0x6765706A),
yuvj420p(pc, bt470bg/unknown/unknown), 1024x1024, 0 kb/s, 0.0006 fps, 3.08 tbr,
600 tbn <strong><em>(default) (attached pic) (timed thumbnails)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Video
 vendor_id : [0][0][0][0]

 Stream #0:2[0x3](und): Data: bin_data (text / 0x74786574)
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Text

 Stream #0:3[0x0]: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/
unknown), 1024x1024 [SAR 144:144 DAR 1:1], 90k tbr, 90k tbn <strong><em>(attached pic)</em></strong>

However, if I make any modification to this file’s chapter markers using the C++ library MP4v2 (even just re-saving the existing ones :
auto f = MP4Modify("test.m4a"); MP4Chapter_t* chapterList; uint32_t chapterCount; MP4GetChapters(f, &chapterList, &chapterCount); MP4SetChapters(f, chapterList, chapterCount); MP4Close(f);), some of these dispositions are removed :

Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo,
fltp, 251 kb/s <strong><em>(default)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Audio
 vendor_id : [0][0][0][0]

 Stream #0:1[0x2](und): Video: mjpeg (Baseline) (jpeg / 0x6765706A),
yuvj420p(pc, bt470bg/unknown/unknown), 1024x1024, 0 kb/s, 0.0006 fps, 3.08 tbr,
600 tbn <strong><em>(default)</em></strong> <kbd>← “attached pic” and “timed thumbnails” removed!</kbd>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Video
 vendor_id : [0][0][0][0]

 Stream #0:2[0x0]: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/
unknown), 1024x1024 [SAR 144:144 DAR 1:1], 90k tbr, 90k tbn <strong><em>(attached pic)</em></strong>

 Stream #0:3[0x4](und): Data: bin_data (text / 0x74786574)
 <kbd>This stream was moved to the end, but that’s intended behavior. It contains chapter titles, and we just edited the chapters.</kbd>
 Metadata:
 creation_time : 2025-03-05T09:56:31.000000Z

It also renders the file unplayable in MPC-HC (but not in VLC !), which is apparently a bug in MP4v2. I’m currently investigating that bug to report and potentially fix it, but that’s a separate issue – in my journey there, I’m wracking my brain trying to understand what it is that MP4v2 changes to make FFmpeg stop reporting the “attached pic” and “timed thumbnails” dispositions. I’ve explored the before-and-afters in MP4 Box, and I can’t for the life of me find which atom it is that differs in a relevant way.


(I’d love to share the files, but unfortunately the contents are under copyright – if anyone knows of a way to remove the audio from an MP4 file without changing anything else, let me know and I’ll upload dummied-out versions. Without them, I can’t really ask about the issue directly. I can at least show you the files’ respective atom trees, but I’m not sure how relevant that is.)


The Question


I thought I’d read FFmpeg’s source code to find out how it determines dispositions for MP4 streams, but of course, FFmpeg is very complex. Could someone who’s more familiar with C and/or FFmpeg’s codebase help me sleuth out how FFmpeg determines dispositions for MP4 files (in particular, “attached pic” and “timed thumbnails”) ?


Some Thoughts…


- 

- I figure searching for “attached_pic” might be a good start ?
- Could the MP4 muxer
movenc.cbe helpful ? - I’d imagine what we’d really like to look at is the MP4 demuxing process, as it’s during demuxing that FFmpeg determines dispositions from the data in the file. After poring over the code for hours, however, I’ve been utterly unable to find where that happens.








-
How does FFmpeg determine the “attached pic” and “timed thumbnails” dispositions of an MP4 track ?
6 mars, par obskyrThe Issue


FFmpeg has a concept of “dispositions” – a property that describes the purpose of a stream in a media file. For example, here are the streams in a file I have lying around, with the dispositions emphasized :


Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo,
fltp, 251 kb/s <strong><em>(default)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Audio
 vendor_id : [0][0][0][0]

 Stream #0:1[0x2](und): Video: mjpeg (Baseline) (jpeg / 0x6765706A),
yuvj420p(pc, bt470bg/unknown/unknown), 1024x1024, 0 kb/s, 0.0006 fps, 3.08 tbr,
600 tbn <strong><em>(default) (attached pic) (timed thumbnails)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Video
 vendor_id : [0][0][0][0]

 Stream #0:2[0x3](und): Data: bin_data (text / 0x74786574)
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Text

 Stream #0:3[0x0]: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/
unknown), 1024x1024 [SAR 144:144 DAR 1:1], 90k tbr, 90k tbn <strong><em>(attached pic)</em></strong>

However, if I make any modification to this file’s chapter markers using the C++ library MP4v2 (even just re-saving the existing ones :
auto f = MP4Modify("test.m4a"); MP4Chapter_t* chapterList; uint32_t chapterCount; MP4GetChapters(f, &chapterList, &chapterCount); MP4SetChapters(f, chapterList, chapterCount); MP4Close(f);), some of these dispositions are removed :

Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo,
fltp, 251 kb/s <strong><em>(default)</em></strong>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Audio
 vendor_id : [0][0][0][0]

 Stream #0:1[0x2](und): Video: mjpeg (Baseline) (jpeg / 0x6765706A),
yuvj420p(pc, bt470bg/unknown/unknown), 1024x1024, 0 kb/s, 0.0006 fps, 3.08 tbr,
600 tbn <strong><em>(default)</em></strong> <kbd>← “attached pic” and “timed thumbnails” removed!</kbd>
 Metadata:
 creation_time : 2021-11-10T20:14:06.000000Z
 handler_name : Core Media Video
 vendor_id : [0][0][0][0]

 Stream #0:2[0x0]: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/
unknown), 1024x1024 [SAR 144:144 DAR 1:1], 90k tbr, 90k tbn <strong><em>(attached pic)</em></strong>

 Stream #0:3[0x4](und): Data: bin_data (text / 0x74786574)
 <kbd>This stream was moved to the end, but that’s intended behavior. It contains chapter titles, and we just edited the chapters.</kbd>
 Metadata:
 creation_time : 2025-03-05T09:56:31.000000Z

It also renders the file unplayable in MPC-HC (but not in VLC !), which is apparently a bug in MP4v2. I’m currently investigating that bug to report and potentially fix it, but that’s a separate issue – in my journey there, I’m wracking my brain trying to understand what it is that MP4v2 changes to make FFmpeg stop reporting the “attached pic” and “timed thumbnails” dispositions. I’ve explored the before-and-afters in MP4 Box, and I can’t for the life of me find which atom it is that differs in a relevant way.


(I’d love to share the files, but unfortunately the contents are under copyright – if anyone knows of a way to remove the audio from an MP4 file without changing anything else, let me know and I’ll upload dummied-out versions. Without them, I can’t really ask about the issue directly. I can at least show you the files’ respective atom trees, but I’m not sure how relevant that is.)


The Question


I thought I’d read FFmpeg’s source code to find out how it determines dispositions for MP4 streams, but of course, FFmpeg is very complex. Could someone who’s more familiar with C and/or FFmpeg’s codebase help me sleuth out how FFmpeg determines dispositions for MP4 files (in particular, “attached pic” and “timed thumbnails”) ?


Some Thoughts…


- 

- I figure searching for “attached_pic” might be a good start ?
- Could the MP4 muxer
movenc.cbe helpful ? - I’d imagine what we’d really like to look at is the MP4 demuxing process, as it’s during demuxing that FFmpeg determines dispositions from the data in the file. After poring over the code for hours, however, I’ve been utterly unable to find where that happens.








-
Revision 36945 : au final pas grand chose passe dans les fichiers de presets ... On ...
5 avril 2010, par kent1@… — Logau final pas grand chose passe dans les fichiers de presets ...
On repasse les codec et les bitrates dans la ligne de commande
On commence à améliorer grandement la conf
Syndiquer tout le site
