Recherche avancée
Médias (1)
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (54)
-
Le plugin : Podcasts.
14 juillet 2010, parLe problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
Types de fichiers supportés dans les flux
Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...) -
Gestion générale des documents
13 mai 2011, parMédiaSPIP ne modifie jamais le document original mis en ligne.
Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...) -
Taille des images et des logos définissables
9 février 2011, parDans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)
Sur d’autres sites (3287)
-
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.








-
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.








-
HlS playlist skip files with ffmpeg
29 janvier, par tamirgI simply downloaded 5 mp3 files from here :
https://samplelib.com/sample-mp3.html


which means i have :


sample-3s.mp3
sample-6s.mp3
sample-9s.mp3
sample-12s.mp3
sample-15s.mp3


and then i create a simple hls playlist sample.m3u8 :


#EXTM3U
#EXT-X-TARGETDURATION:20
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:3.0,
sample-3s.mp3
#EXTINF:6.0,
sample-6s.mp3
#EXTINF:9.0,
sample-9s.mp3
#EXTINF:12.0,
sample-12s.mp3
#EXTINF:15.0,
sample-15s.mp3


But when i play this playlist :


ffplay sample.m3u8


i get :


[hls @ 0x13703b4d0] Opening 'sample-9s.mp3' for reading
[mp3 @ 0x13703b740] invalid concatenated file detected - using bitrate for duration
Input #0, hls, from 'playlist2.m3u8':
 Duration: N/A, start: 0.000000, bitrate: 128 kb/s
 Program 0
 Metadata:
 variant_bitrate : 0
 Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 128 kb/s
 Metadata:
 variant_bitrate : 0
 encoder : Lavc57.10
2025-01-29 10:57:46.957 ffplay[17029:696588] +[IMKClient subclass]: chose IMKClient_Modern
2025-01-29 10:57:46.957 ffplay[17029:696588] +[IMKInputSession subclass]: chose IMKInputSession_Modern
[hls @ 0x13703b4d0] Opening 'sample-12s.mp3' for reading 0B
[mp3float @ 0x13703c710] Header missingvq= 0KB sq= 0B
[hls @ 0x13703b4d0] Opening 'sample-15s.mp3' for reading 0B


It starts playing from the file sample-9s, and not sample-3s. So it skips the first two files.
Why does it happen ?


Syndiquer tout le site
