PageSourceSearch

https://postproduction.studio/assets/ImfPackagesArticle-BxfjzOWW.js

js postproduction.studio collected 2026-10-04 03:21:33 UTC 55,606 bytes, 115 lines download raw bytes

1import{u as c,j as e}from"./index-Cnl2vSqt.js";import{S as p}from"./SEOHelmet-DnB_Ebc_.js";import{A as m}from"./AISchemaInjector-C5i6iF3p.js";import{A as h}from"./ArticleTemplate-20AXpUM_.js";import{R as g}from"./RelatedArticles-DEoqSyng.js";import{a as f}from"./seoMetadata-CAiAOw4J.js";import{g as v}from"./articleMetadata-BrJVaAEm.js";import{c as y}from"./schemaGenerator-TDAdNWaa.js";import"./book-open-0f706iRF.js";import"./clock-DOdNlVE-.js";import"./ArticleDiagrams-D7Sd0g7s.js";import"./arrow-right-C8-BmD82.js";const b={en:["IMF (Interoperable Master Format, SMPTE ST 2067) is the standardized delivery format for streaming platforms (Netflix, Amazon, Apple TV+, Disney+) — replaces ProRes deliveries since 2018-2020.",'Core principle: a single set of "essence" files (video tracks, audio tracks, subtitles, captions) composed via CPL (Composition Playlist) — multiple versions reuse the same essences with different CPLs.',"Video format: JPEG 2000 in MXF (or now ProRes IMF profile), 10-12 bit, Rec.709 SDR or Rec.2020 PQ HDR; audio: PCM 24-bit/48kHz, 2.0 / 5.1 / 7.1 / Atmos.","Application profiles: IMF App 2/2E (broadcast/streaming SDR-HDR), IMF App 4 (cinema, JPEG 2000 lossless), IMF App 5 (ACES archival) — Netflix uses App 2E with strict spec validation.","Validation tools: Netflix-provided Photon validator and Hermes captioner; commercial: Marquise, Dalet, Colorfront — required to catch IMF schema and essence errors before submission."],fr:["IMF (Interoperable Master Format, SMPTE ST 2067) est le format de livraison standardisé pour les plateformes de streaming (Netflix, Amazon, Apple TV+, Disney+) — remplace les livraisons ProRes depuis 2018-2020.",'Principe : un seul jeu de fichiers "essence" (pistes vidéo, audio, sous-titres, captions) composé via CPL (Composition Playlist) — plusieurs versions réutilisent les mêmes essences avec des CPL différentes.',"Format vidéo : JPEG 2000 en MXF (ou désormais profil ProRes IMF), 10-12 bit, Rec.709 SDR ou Rec.2020 PQ HDR ; audio : PCM 24-bit/48kHz, 2.0 / 5.1 / 7.1 / Atmos.","Profils applicatifs : IMF App 2/2E (broadcast/streaming SDR-HDR), IMF App 4 (cinéma, JPEG 2000 sans perte), IMF App 5 (archivage ACES) — Netflix utilise App 2E avec validation stricte des specs.","Outils de validation : Photon (fourni par Netflix) et Hermes (captioner) ; commerciaux : Marquise, Dalet, Colorfront — requis pour détecter les erreurs de schéma et d'essence IMF avant soumission."]},M={en:{title:"IMF: interoperable mastering packages",description:"Comprehensive guide to Interoperable Master Format (IMF). Master SMPTE ST 2067, CPL, OPL, versioning, App 2E, and streaming delivery workflows.",intro:`The exponential growth of global streaming platforms like Netflix, Amazon Prime, and Disney+ created a logistical nightmare for post-production facilities. Historically, delivering a television show or feature film to multiple international territories required generating a unique, massive, flattened video file for every single variation. A studio might need to deliver a French dubbed version with forced narrative subtitles, a German version with descriptive text, a 4K HDR master, an HD SDR downmix, and an airline-edited cut—all of which meant exporting, quality controlling, and transmitting dozens of discrete 100-gigabyte ProRes or DNxHR files. This "flattened file" workflow was slow, mathematically redundant, and unsustainably expensive in terms of server storage and network bandwidth. To solve this colossal bottleneck, the Society of Motion Picture and Television Engineers (SMPTE) developed the Interoperable Master Format (IMF), formally defined in the ST 2067 suite of standards. IMF completely revolutionizes the delivery paradigm by adopting a component-based architecture heavily inspired by the Digital Cinema Package (DCP). Instead of baking audio, video, and text into a single monolithic file, IMF keeps them separate, wrapping them in MXF containers and relying on XML playlists to orchestrate their playback. This allows a facility to deliver a single heavy master video file alongside a dozen tiny audio and subtitle payloads, generating infinite versions mathematically rather than physically. This comprehensive guide explores the architecture of the IMF package, the intricacies of the Composition Playlist (CPL) and Output Profile List (OPL), the concept of Supplemental packages, and the rigorous validation processes required to deliver flawless masters to the world's largest streaming networks.`,toc:"Table of Contents",sections:[{title:"1. Definition and origin of IMF",content:`The Interoperable Master Format (IMF) is a global, open standard engineered to provide a single, interchangeable master file format for the distribution of finished audiovisual works across multiple platforms. Developed by SMPTE (Society of Motion Picture and Television Engineers) and ratified under the ST 2067 family of documents, IMF is explicitly not a consumer delivery format. You cannot stream an IMF directly to a living room television. Instead, it is a highly robust Business-to-Business (B2B) mezzanine format—a digital negative from which all consumer deliverables (like H.264 web streams, HEVC HDR files, or broadcast MPEG-2 TS) are ultimately transcoded.
2
3        The origins of IMF lie in the frustrations of the early 2010s digital transition. Prior to IMF, the industry relied heavily on tape formats (like HDCAM SR) or proprietary file formats (like Apple ProRes or Avid DNxHD). The problem with proprietary formats is that they inherently lock a facility into a specific vendor ecosystem. Apple owns ProRes; if Apple changes the codec structure or revokes a license, the archival stability of millions of masters is threatened. Furthermore, these formats are "flattened." If a director decides to fix a single typo in the end credits of a two-hour film, the facility must re-render, re-QC, and re-deliver the entire 200-gigabyte file.
4
5        Recognizing these critical inefficiencies, a consortium of major Hollywood studios, leading post-production facilities, and technology vendors collaborated to build a superior alternative. They looked closely at the resounding success of the Digital Cinema Package (DCP), which had standardized theatrical delivery using an open, component-based, MXF/XML architecture. However, the DCP was too rigid for television and streaming—it only supported XYZ color space and 24fps frame rates. IMF was designed to inherit the brilliant component-based architecture of the DCP while expanding its flexibility to support any frame rate, any resolution, and any color space (including Rec.709, Rec.2020, and HDR formats).`},{title:"2. The principle of the interoperable package",content:`The core philosophy driving the Interoperable Master Format is the transition from a "flattened" workflow to a "component-based" workflow. In a traditional flattened workflow, the video, the 5.1 surround sound audio, the stereo mix
5down, and the burned-in subtitles are irrevocably married together inside a single QuickTime wrapper. If a broadcaster requests a textless version (a version without any graphic overlays) so they can localize the title sequence, the post facility must generate a completely separate, equally massive video file.
6
7        IMF shatters this paradigm by maintaining strict separation of assets. An IMF is not a single file; it is an Interoperable Master Package (IMP)—a rigorously structured directory folder containing multiple discrete files. The video track (the raw, textless imagery) exists as a standalone MXF file. The English audio exists as a standalone MXF file. The French dubbed audio is a separate MXF file. The subtitles are independent XML documents. 
8
9        To assemble these disparate pieces, the IMP utilizes complex XML playlists. When Netflix ingests an IMF package, their automated servers do not look for a flattened video track; they look for a Composition Playlist (CPL). The CPL acts as the master timeline. It contains exact timecode instructions that say: "Play the video MXF from frame 0 to frame 85000. At frame 0, play the English Audio MXF. At frame 1200, overlay this specific text string from the Subtitle XML." 
10
11        This principle of interoperability means that a single, heavy video file can support an infinite number of variations. If the studio needs to censor a violently graphic scene for an airline release, they do not render a new video file. They simply author a new XML Composition Playlist that instructs the playback server to seamlessly skip the offending frames during playback. The heavy media assets remain untouched on the server, while the XML instructions dynamically assemble the required version on the fly.`},{title:"3. Structure: CPL, OPL, and assets",content:`To successfully navigate and author an Interoperable Master Package, post-production engineers must possess a deep understanding of its internal anatomy. The structure of an IMP is highly regulated by SMPTE ST 2067-2. If a single file is misnamed, or if a cryptographic hash fails to match, the receiving server will instantly reject the entire package.
12
13        The foundational elements of the package are the Track Files (the assets). These are the actual media payloads—the video and audio essences. In an IMF, these essences are exclusively wrapped in the AS-02 MXF (Material eXchange Format) container. The video essence is typically compressed using mathematically robust intra-frame codecs like JPEG 2000 (J2K) or, more recently, ProRes (in specific IMF applications). The audio essence must be 24-bit, 48kHz uncompressed PCM audio.
14
15        The structural core of the package is the Composition Playlist (CPL). As previously mentioned, the CPL is the XML document that orchestrates the playback of the Track Files. A single IMP folder can contain multiple CPLs. For example, a single delivery drive might contain one heavy video MXF, but two CPLs: one labeled "Theatrical_Cut_CPL" and one labeled "Director_Extended_Cut_CPL." 
16
17        Equally important, though less frequently discussed, is the Output Profile List (OPL). While the CPL dictates *what* is played, the OPL dictates *how* it should be processed for downstream delivery. An OPL might contain instructions for a transcoder, stating: "When generating the web proxy from this CPL, apply a Rec.709 color space transform, downmix the 5.1 audio to stereo, and permanently burn in the French subtitles." 
18
19        Finally, to ensure data integrity during transmission, the package relies on the Packing List (PKL) and the Asset Map. The PKL is an XML document that lists the file name, the exact byte size, and the SHA-1 cryptographic hash of every single file within the IMP folder. The Asset Map connects the UUIDs (Universally Unique Identifiers) used inside the XML documents to the actual physical file paths on the hard drive. Upon ingestion, the receiving server recalculates the hash of the downloaded files and compares them against the PKL; any discrepancy triggers an immediate critical failure.`},{title:"4. Components: video, audio, and subtitles",content:`The strict rules governing the components within an IMF package are designed to ensure absolute technical fidelity and archival longevity, guaranteeing that the master can survive decades of technological evolution and format shifting.
20
21        The video component is the heaviest asset in the package. In the primary IMF application (App 2E), the video essence is strictly mandated to be JPEG 2000 (J2K). Unlike inter-frame codecs (H.264/HEVC) that estimate motion between frames, J2K is an intra-frame codec, meaning it compresses every single frame as an independent, high-resolution mathematical equation. This eliminates macroblocking and temporal motion artifacts, making it a pristine source for downstream transcoding. The J2K frames can support resolutions from HD up to 8K, frame rates up to 120fps, and color bit depths of 10-bit or 12-bit. Crucially, the video MXF is strictly "textless"—it must not contain any burned-in subtitles, localized title cards, or graphic overlays, ensuring the clean background can be localized globally.
22
23        The audio components are treated with equal rigor. The IMF standard forbids any form of lossy audio compression (like AAC or MP3). All audio must be delivered as 24-bit uncompressed Broadcast Wave Format (BWF) PCM audio, wrapped in MXF. The channel routing is explicitly defined within the XML metadata to prevent mapping errors. A standard delivery might include a 5.1 surround mix, a 2.0 stereo mix
23down, and an M&E (Music and Effects) track. The M&E track is vital for global distribution; it contains all the sound design, foley, and musical score, but zero dialogue, allowing foreign territories to easily record and mix their own localized voice actors over the pristine original soundscape.
24
25        Subtitles and closed captions in an IMF are not video files; they are data files, specifically using the IMSC1 (Internet Media Subtitles and Captions) profile of the W3C TTML standard. An IMSC1 XML file contains the actual text strings, exact timecodes for their appearance, and styling metadata (fonts, colors, background opacity, and screen placement). Because they are text data rather than rasterized images, IMSC1 subtitles can be dynamically rendered sharply on a 4K television or safely scaled down for a mobile phone screen without losing resolution.`},{title:"5. Versioning and supplemental packages",content:`The most powerful economic and logistical advantage of the Interoperable Master Format is its elegant handling of versioning through the use of Supplemental Packages. In traditional post-production, fixing a mistake or localizing a film meant massive data duplication. IMF eliminates this redundancy entirely.
26
27        Consider a scenario where a streaming platform commissions a highly anticipated 4K HDR television series. The post-production facility delivers the Original Version (OV) package. This OV contains the full two-hour 4K J2K video MXF, the English audio MXF, and the English subtitle XML. The total package size is a massive 250 gigabytes. 
28
29        Two weeks later, the studio decides they need to replace a single shot that contained a visible boom microphone, and they also need to deliver the Spanish and German audio dubs. In a traditional workflow, the facility would have to render and upload three entirely new 250GB files (English Fixed, Spanish, German). 
30
31        With IMF, the facility utilizes a Supplemental Package. They render only the three seconds of new video containing the fixed shot, wrapped in a tiny new MXF. They output the Spanish and German audio MXF files. They then author a new Composition Playlist (CPL) XML. This new CPL acts as a set of instructions for the streaming server: "Play the massive 250GB video file you already have from frame 0 to frame 45000. At frame 45001, cut over to this tiny new 3-second video MXF to hide the microphone. Then cut back to the original massive file. Meanwhile, play the Spanish audio track instead of the English one."
32
33        This Supplemental Package might only weigh 3 gigabytes. The facility uploads this tiny package to the streaming network. The network's servers ingest the XML, link the new supplemental assets to the existing Original Version assets on their SAN (Storage Area Network), and instantly generate the corrected and localized versions for global distribution. This non-destructive, delta-based versioning saves millions of dollars in bandwidth and server storage costs annually.`},{title:"6. IMF Applications (App 2, App 2E, App 5...)",content:`Because the television, cinema, and broadcast industries have wildly different technical requirements, a single, rigid IMF specification would fail to accommodate everyone. To solve this, the SMPTE ST 2067 standard utilizes "Applications"—specific, constrained profiles that dictate exactly which codecs, color spaces, and resolutions are permitted within that particular IMF flavor. If you deliver an App 2 package to a broadcaster expecting an App 5 package, the automated ingest will fail.
34
35        IMF Application 2 (App 2) and its successor Application 2E (App 2E) are the undisputed kings of high-end streaming delivery. App 2E was championed heavily by Netflix and has become the global standard for premium episodic television and feature film mastering. It mandates the use of JPEG 2000 (J2K) compression for the video essence. App 2E supports incredibly robust image quality, accommodating resolutions up to 4K (and beyond), frame rates up to 120fps, and crucially, full support for High Dynamic Range (HDR) mastering, including ST 2084 (PQ) color spaces and Rec.2020 color gamuts. If you are delivering a flagship original series to a major SVOD platform, you are delivering an App 2E package.
36
37        IMF Application 5 (App 5) was developed to serve a different c
37onstituency: the archival and established broadcast ecosystem. Many legacy post-production facilities and broadcast networks built their entire infrastructures around the ACES workflow and the Academy Color Encoding System, utilizing the mathematically lossless OpenEXR image sequence format. App 5 allows the IMF wrapper to contain ACES EXR image sequences instead of J2K compressed video. This creates a massive, pristine, mathematically pure archival package, though the resulting file sizes are far too enormous for standard daily television exchange.
38
39        More recently, recognizing the ubiquity of Apple's proprietary codecs in the editorial world, SMPTE introduced Application ProRes (App ProRes). This allows facilities to build standard IMF XML structures (CPLs, OPLs, IMSC1 subtitles) but utilize Apple ProRes 422 HQ or ProRes 4444 as the underlying video essence instead of the computationally heavy J2K. This significantly speeds up rendering times on Mac-based workstations while preserving the component-based versioning benefits of the IMF architecture.`},{title:"7. Creation and validation of an IMF package",content:`The authoring and validation of an Interoperable Master Package require deep technical expertise and specialized software. Unlike exporting a generic H.264 file from Adobe Premiere, creating an IMF is a rigid computational process that offers absolutely zero margin for error. A single misplaced metadata tag will trigger an automated rejection from the receiving network.
40
41        The creation process typically occurs in high-end finishing software such as DaVinci Resolve, Colorfront Transkoder, or Rohde & Schwarz Clipster. The engineer begins by laying out the final graded timeline. The software must be configured to mathematically transform the timeline's color space into the specific targets required by the IMF Application (e.g., transforming a P3-D65 timeline into a Rec.2020 PQ container for an HDR App 2E delivery). The software then encodes the heavy JPEG 2000 video frames, renders the uncompressed audio MXFs, and compiles the complex XML documents (CPL, PKL, AssetMap). Because J2K encoding is incredibly CPU-intensive, rendering a 4K feature film IMF often requires dedicated render farms to complete within a reasonable timeframe.
42
43        However, simply exporting the package is not enough; rigorous validation is strictly required before transmission. Major platforms like Netflix utilize automated, cloud-based QC engines. To prevent facilities from uploading broken 300-gigabyte packages, the industry relies on an open-source validation tool called Photon (originally developed by Netflix). 
44
45        Before shipping, the post facility runs the generated IMP folder through Photon. The software aggressively parses every XML file, verifies the UUID links, recalculates the SHA-1 hashes of every MXF file, checks for illegal characters in the metadata, and ensures the J2K bitrates fall within the mandated ST 2067 limits. Only when Photon returns a "green" validation report can the engineer be confident that the package is structurally sound. Following this technical validation, a human QC operator must still perform a visual spot-check to ensure the IMSC1 subtitles are rendering correctly and that the 5.1 audio channels are routed to the proper speakers.`},{title:"8. IMF versus traditional mezzanine formats",content:`To truly grasp the value of IMF, one must contrast it against the traditional mezzanine formats that have dominated post-production for the past fifteen years, primarily Apple ProRes and Avid DNxHR. 
46
47        ProRes 4444 XQ and DNxHR 444 are undeniably spectacular codecs. They provide robust, 12-bit, visually lossless imagery that perfectly preserves a high-end color grade. They are computationally lightweight, meaning they play back smoothly on almost any modern non-linear editing (NLE) system without requiring dedicated hardware decoders. For a small production company generating a single, final web video, exporting a flattened ProRes master remains the most logical and efficient workflow.
48
49        However, the fundamental weakness of ProRes and DNxHR lies in their monolithic nature. They are "flattened" files. If a global distributor needs to deliver a film with 15 different language dubs and 20 different subtitle languages, a ProRes workflow forces them to either create 15 massive, duplicated video files (one for each audio dub), or rely on chaotic, unstandardized folder structures containing a ProRes video file loosely accompanied by loose WAV files and loose SRT subtitle files. This loose folder approach inevitably leads to synchronization disasters and missing assets when transferred between different vendors.
50
51        IMF solves the chaos. By adopting the component-based architecture of the DCP, IMF provides the strict, standardized "glue" (the XML Composition Playlists) necessary to keep hundreds of disparate localized assets perfectly synchronized with a single, pristine video master. Furthermore, because IMF uses JPEG 2000 (an open ISO standard) rather than a proprietary corporate codec like ProRes, it guarantees archival stability. A studio can be confident that an open-source J2
51K decoder will still be able to mathematically open their IMF packages fifty years from now, long after specific corporate software licenses may have expired.`},{title:"9. Best practices and common pitfalls",content:`Mastering the IMF workflow requires a radical shift in operational mindset, moving away from simple video exporting toward rigid data management. The most common and expensive pitfalls in IMF delivery almost always stem from metadata errors and a failure to respect the strict non-destructive component architecture.
52
53        The most frequent disaster involves subtitle timing. Unlike burned-in text or standard SRT files, IMSC1 subtitles in an IMF are deeply tied to the framerate and the start timecode of the Composition Playlist (CPL). If the video MXF starts at 01:00:00:00, but the subtitle authoring software exported the XML assuming a 00:00:00:00 start time, the text will completely fail to render during playback. Engineers must painstakingly verify that the timecode metadata inside the IMSC1 XML perfectly aligns with the global timeline of the CPL.
54
55        Another massive pitfall is the mishandling of Original Versions (OV) and Supplemental packages. A Supplemental package is entirely useless on its own; it only contains the tiny delta changes (like a 5-second video patch and a Spanish audio track). If a facility accidentally deletes the massive 200GB Original Version from their server to save space, the Supplemental packages instantly "break" because the XML Composition Playlist can no longer find the primary video MXF it references. Facilities must implement rigorous Media Asset Management (MAM) systems to ensure the parent-child relationships between OV and Supplemental IMPs are permanently protected.
56
57        Finally, naming conventions are absolutely critical. An IMF folder is essentially a database. If an operator manually renames an MXF file inside the folder via the operating system to fix a typo (e.g., changing "Audio_Eng.mxf" to "Audio_English.mxf"), the entire package will instantly fail validation. The XML PKL and CPL documents are still looking for the original filename and the original cryptographic hash. Any change to the package must be executed through certified IMF authoring software to ensure the XML databases are correctly updated to reflect the new file identities.`}],conclusion:"In conclusion, the Interoperable Master Format (IMF) represents the ultimate evolutionary step in digital supply chain logistics. By completely dismantling the archaic concept of the flattened video file and replacing it with a rigorous, XML-driven component architecture, IMF has provided the global streaming and broadcast industries with a massively scalable, non-destructive delivery standard. Through the intelligent deployment of Original Versions and Supplemental packages, studios can now localize and version their premium content for dozens of international territories without incurring the crippling storage and bandwidth costs of duplicated video renders. The rigorous nature of SMPTE ST 2067, combined with automated validation tools like Photon, ensures that these colossal data packages remain structurally flawless and archivally stable for decades. For post-production professionals, mastering IMF is no longer optional; it is the absolute prerequisite for delivering high-end content to platforms like Netflix and Amazon. To understand the architectural foundation that inspired IMF, review our deep dive into theatrical delivery in 'The DCP: digital cinema delivery explained'. To explore the underlying video codecs that form the mathematical essence of these packages, consult 'Codecs and containers' and 'Mezzanine formats'. Finally, to grasp how these pristine IMF masters are ultimately compressed for consumer delivery, explore our comprehensive guide on 'Delivery Formats & Standards'."},fr:{title:"IMF : packages d'echange et de livraison",description:"Guide complet sur l'Interoperable Master Format (IMF). Maîtrisez la norme SMPTE ST 2067, CPL, OPL, versionnage, App 2E et les workflows streaming.",intro:`La croissance exponentielle des plateformes mondiales de streaming comme Netflix, Amazon Prime et Disney+ a créé un cauchemar logistique pour les structures de post-production. Historiquement, la livraison d'une émission de télévision ou d'un long métrage à de multiples territoires internationaux nécessitait la génération d'un fichier vidéo aplati, unique et massif pour chaque variation. Un studio pouvait avoir besoin de livrer une version doublée en français avec des sous-titres narratifs forcés, une version allemande avec du texte descriptif, un master 4K HDR, un downmix HD SDR et un montage censuré pour les compagnies aériennes—ce qui impliquait l'exp
57ortation, le contrôle qualité et la transmission de dizaines de fichiers ProRes ou DNxHR discrets de 100 gigaoctets. Ce workflow de "fichiers aplatis" était lent, mathématiquement redondant et d'un coût insoutenable en termes de stockage sur serveur et de bande passante réseau. Pour résoudre ce goulot d'étranglement colossal, la Society of Motion Picture and Television Engineers (SMPTE) a développé l'Interoperable Master Format (IMF), formellement défini dans la suite de normes ST 2067. L'IMF révolutionne complètement le paradigme de livraison en adoptant une architecture basée sur des composants, fortement inspirée du Digital Cinema Package (DCP). Au lieu de figer l'audio, la vidéo et le texte dans un seul fichier monolithique, l'IMF les sépare, les encapsule dans des conteneurs MXF et s'appuie sur des listes de lecture XML pour orchestrer leur lecture. Cela permet à un laboratoire de livrer un seul fichier vidéo maître lourd accompagné d'une douzaine de minuscules charges utiles audio et de sous-titres, générant des versions infinies mathématiquement plutôt que physiquement. Ce guide complet explore l'architecture du package IMF, les subtilités de la Composition Playlist (CPL) et de l'Output Profile List (OPL), le concept de packages supplémentaires (Supplemental), et les processus de validation rigoureux requis pour livrer des masters impeccables aux plus grands réseaux de streaming du monde.`,toc:"Sommaire",sections:[{title:"1. Definition et origine de l'IMF",content:`L'Interoperable Master Format (IMF) est une norme mondiale et ouverte conçue pour fournir un format de fichier maître unique et interchangeable pour la distribution d'œuvres audiovisuelles terminées sur de multiples plateformes. Développé par la SMPTE et ratifié sous la famille de documents ST 2067, l'IMF n'est explicitement pas un format de livraison grand public. Vous ne pouvez pas diffuser un IMF directement sur un téléviseur de salon. Il s'agit plutôt d'un format mezzanine Business-to-Business (B2B) extrêmement robuste—un négatif numérique à partir duquel tous les livrables grand public (comme les flux Web H.264, les fichiers HEVC HDR ou les flux broadcast MPEG-2 TS) sont finalement transcodés.
58
59        Les origines de l'IMF résident dans les frustrations de la transition numérique du début des années 2010. Avant l'IMF, l'industrie s'appuyait fortement sur des formats de bande (comme le HDCAM SR) ou des formats de fichiers propriétaires (comme l'Apple ProRes ou l'Avid DNxHD). Le problème avec les formats propriétaires est qu'ils enferment intrinsèquement une installation dans l'écosystème d'un fournisseur spécifique. Apple possède le ProRes ; si Apple modifie la structure du codec ou révoque une licence, la stabilité archivistique de millions de masters est menacée. De plus, ces formats sont "aplatis". Si un réalisateur décide de corriger une seule faute de frappe dans le générique de fin d'un film de deux heures, le laboratoire doit générer, re-vérifier et re-livrer l'intégralité du fichier de 200 gigaoctets.
60
61        Reconnaissant ces inefficacités critiques, un consortium de grands studios hollywoodiens, de laboratoires de post-production de premier plan et de fournisseurs de technologies a collaboré pour créer une alternative supérieure. Ils ont examiné de près le succès retentissant du Digital Cinema Package (DCP), qui avait standardisé la livraison en salle à l'aide d'une architecture ouverte, basée sur des composants, MXF/XML. Cependant, le DCP était trop rigide pour la télévision et le streaming—il ne prenait en charge que l'espace colorimétrique XYZ et les fréquences d'images de 24 ips. L'IMF a été conçu pour hériter de la brillante architecture basée sur les composants du DCP tout en élargissant sa flexibilité pour prendre en charge n'importe quelle fréquence d'images, n'importe quelle résolution et n'importe quel espace colorimétrique (y compris le Rec.709, le Rec.2020 et les formats HDR).`},{title:"2. Le principe du package interoperable",content:`La philosophie fondamentale de l'Interoperable Master Format est la transition d'un workflow "aplati" à un workflow "basé sur des composants". Dans un flux de travail aplati traditionnel, la vidéo, le son surround 5.1, le mixage stéréo et les sous-titres incrustés sont irrévocablement mariés ensemble à l'intérieur d'un seul encapsuleur QuickTime. Si un diffuseur demande une version sans texte (une version sans aucune incrustation graphique) afin de pouvoir localiser la séquence titre, le laboratoire de post-production doit générer un fichier vidéo complètement séparé et tout aussi massif.
62
63        L'IMF brise ce paradigme en maintenant une séparation stricte des actifs. Un IMF n'est pas un fichier unique ; c'est un Interoperable Master Package (IMP)—un répertoire de dossiers rigoureusement structuré contenant plusieurs fichiers distincts. La piste vidéo (les images brutes et sans texte) existe en tant que fichier MXF autonome. L'audio anglais existe en tant que fichier MXF autonome. L'audio doublé français est un fichier MXF séparé. Les sous-titres sont des documents XML indépendants.
64
65        Pour assembler ces pièces disparates, l'IMP utilise des listes de lecture XML complexes. Lorsque Netflix ingère un package IMF, ses serveurs automatisés ne recherchent pas une piste vidéo aplatie ; ils recherchent une Composition Playlist (CPL). La CPL agit comme la timeline maîtresse. Elle contient des instructions de code temporel exactes qui disent : "Jouer le MXF vidéo de l'image 0 à l'image 85000. À l'image 0, jouer le MXF audio anglais. À l'image 1200, superposer cette chaîne de texte spécifique à partir du XML de sous-titres."
66
67        Ce principe d'interopérabilité signifie qu'un seul fichier vidéo lourd peut prendre en charge un n
67ombre infini de variations. Si le studio doit censurer une scène violemment graphique pour une sortie dans les compagnies aériennes, il ne génère pas de nouveau fichier vidéo. Il crée simplement une nouvelle Composition Playlist XML qui indique au serveur de lecture de sauter de manière transparente les images offensantes pendant la lecture. Les actifs multimédias lourds restent intacts sur le serveur, tandis que les instructions XML assemblent dynamiquement la version requise à la volée.`},{title:"3. La structure : CPL, OPL, assets",content:`Pour naviguer et créer avec succès un Interoperable Master Package, les ingénieurs de post-production doivent posséder une compréhension approfondie de son anatomie interne. La structure d'un IMP est hautement réglementée par la norme SMPTE ST 2067-2. Si un seul fichier est mal nommé, ou si un hachage cryptographique ne correspond pas, le serveur de réception rejettera instantanément le paquet entier.
68
69        Les éléments fondamentaux du package sont les fichiers de pistes (Track Files, les assets). Ce sont les charges utiles multimédias réelles—les essences vidéo et audio. Dans un IMF, ces essences sont exclusivement enveloppées dans le conteneur AS-02 MXF (Material eXchange Format). L'essence vidéo est généralement compressée à l'aide de codecs intra-image mathématiquement robustes comme le JPEG 2000 (J2K) ou, plus récemment, le ProRes (dans des applications IMF spécifiques). L'essence audio doit être un son PCM non compressé 24 bits, 48 kHz.
70
71        Le cœur structurel du package est la Composition Playlist (CPL). Comme mentionné précédemment, la CPL est le document XML qui orchestre la lecture des Track Files. Un seul dossier IMP peut contenir plusieurs CPLs. Par exemple, un seul disque de livraison peut contenir un lourd MXF vidéo, mais deux CPLs : une étiquetée "Theatrical_Cut_CPL" et une étiquetée "Director_Extended_Cut_CPL."
72
73        Tout aussi importante, bien que moins fréquemment discutée, est l'Output Profile List (OPL). Alors que la CPL dicte *ce qui* est lu, l'OPL dicte *comment* cela doit être traité pour la livraison en aval. Une OPL peut contenir des instructions pour un transcodeur, indiquant : "Lors de la génération du proxy Web à partir de cette CPL, appliquez une transformation d'espace colorimétrique Rec.709, réduisez l'audio 5.1 en stéréo et incrustez de manière permanente les sous-titres français."
74
75        Enfin, pour garantir l'intégrité des données pendant la transmission, le package s'appuie sur la Packing List (PKL) et l'Asset Map. La PKL est un document XML qui liste le nom de fichier, la taille exacte en octets et le hachage cryptographique SHA-1 de chaque fichier du dossier IMP. L'Asset Map relie les UUID (Universally Unique Identifiers) utilisés à l'intérieur des documents XML aux chemins de fichiers physiques réels sur le disque dur. Lors de l'ingestion, le serveur de réception recalcule le hachage des fichiers téléchargés et les compare à la PKL ; toute divergence déclenche une défaillance critique immédiate.`},{title:"4. Les composants : video, audio, sous-titres",content:`Les règles strictes régissant les composants au sein d'un package IMF sont conçues pour garantir une fidélité technique absolue et une longévité archivistique, garantissant que le master peut survivre à des décennies d'évolution technologique et de changement de format.
76
77        Le composant vidéo est l'actif le plus lourd du package. Dans l'application IMF principale (App 2E), l'essence vidéo doit strictement être du JPEG 2000 (J2K). Contrairement aux codecs inter-image (H.264/HEVC) qui estiment le mouvement entre les images, le J2K est un codec intra-image, ce qui signifie qu'il compresse chaque image comme une équation mathématique haute résolution indépendante. Cela élimine le macroblocking et les artefacts de mouvement temporel, ce qui en fait une source immaculée pour le transcodage en aval. Les images J2K peuvent prendre en charge des résolutions de la HD jusqu'au 8K, des fréquences d'images jusqu'à 120 ips et des profondeurs de bits de couleur de 10 ou 12 bits. De manière cruciale, le MXF vidéo est strictement "textless" (sans texte)—il ne doit contenir aucun sous-titre incrusté, carton de titre localisé ou superposition graphique, garantissant que l'arrière-plan propre peut être localisé globalement.
78
79        Les composants audio sont traités avec la même rigueur. La norme IMF interdit toute forme de compression audio avec perte (comme AAC ou MP3). Tout l'audio doit être livré sous forme d'audio PCM non compressé au format Broadcast Wave Format (BWF) 24 bits, enveloppé dans du MXF. Le routage des canaux est explicitement défini dans les métadonnées XML pour éviter les erreurs de mappage. Une livraison standard peut inclure un mixage surround 5.1, un downmix stéréo 2.0 et une piste VI (Version Internationale, ou M&E pour Music and Effects). La piste VI est vitale pour la distribution mondiale ; elle contient toute la conception sonore, les bruitages et la partition musicale, mais zéro dialogue, permettant aux territoires étrangers d'enregistrer et de mixer facilement leurs propres acteurs vocaux localisés sur le paysage sonore original vierge.
80
81        Les sous-titres et les sous-titres pour sourds et malentendants dans un IMF ne sont pas des fichiers vidéo ; ce sont des fichiers de données, utilisant spécifiquement le profil IMSC1 (Internet Media Subtitles and Captions) de la norme W3C TTML. Un fichier XML IMSC1 contient les chaînes de texte réelles, les codes temporels exacts de leur apparition et les métadonnées de style (polices, couleurs, opacité de l'arrière-plan et placement à l'écran). Parce qu'il s'agit de données textuelles plutôt que d'images matricielles, les s
81ous-titres IMSC1 peuvent être rendus dynamiquement avec netteté sur un téléviseur 4K ou réduits en toute sécurité pour un écran de téléphone portable sans perdre de résolution.`},{title:"5. La notion de versionning et de supplemental package",content:`L'avantage économique et logistique le plus puissant de l'Interoperable Master Format est sa gestion élégante du versionnage grâce à l'utilisation des Supplemental Packages (Packages Supplémentaires). Dans la post-production traditionnelle, corriger une erreur ou localiser un film signifiait une duplication massive des données. L'IMF élimine entièrement cette redondance.
82
83        Considérons un scénario dans lequel une plateforme de streaming commande une série télévisée 4K HDR très attendue. L'installation de post-production livre le package de la version originale (Original Version ou OV). Cet OV contient le MXF vidéo 4K J2K complet de deux heures, le MXF audio anglais et le XML de sous-titres anglais. La taille totale du package est d'un volume massif de 250 gigaoctets.
84
85        Deux semaines plus tard, le studio décide qu'il doit remplacer un seul plan contenant un microphone à perche visible, et qu'il doit également livrer les doublages audio espagnol et allemand. Dans un flux de travail traditionnel, le laboratoire devrait générer et télécharger trois tout nouveaux fichiers de 250 Go (Anglais corrigé, Espagnol, Allemand).
86
87        Avec l'IMF, l'installation utilise un Supplemental Package. Ils ne rendent que les trois secondes de nouvelle vidéo contenant le plan corrigé, enveloppées dans un minuscule nouveau MXF. Ils génèrent les fichiers MXF audio espagnol et allemand. Ensuite, ils créent un nouveau XML Composition Playlist (CPL). Ce nouveau CPL agit comme un ensemble d'instructions pour le serveur de streaming : "Jouer le fichier vidéo massif de 250 Go que vous avez déjà de l'image 0 à l'image 45000. À l'image 45001, passez à ce minuscule nouveau MXF vidéo de 3 secondes pour cacher le microphone. Revenez ensuite au fichier massif d'origine. Pendant ce temps, jouez la piste audio espagnole au lieu de la piste anglaise."
88
89        Ce Supplemental Package peut ne peser que 3 gigaoctets. Le laboratoire télécharge ce minuscule paquet sur le réseau de streaming. Les serveurs du réseau ingèrent le XML, lient les nouveaux actifs supplémentaires aux actifs de la version originale existants sur leur SAN (Storage Area Network), et génèrent instantanément les versions corrigées et localisées pour une distribution mondiale. Ce versionnage non destructif, basé sur les deltas, permet d'économiser des millions de dollars en bande passante et en coûts de stockage sur serveur chaque année.`},{title:"6. Les applications IMF (App 2, App 2E, App 5...)",content:`Parce que les industries de la télévision, du cinéma et de la diffusion (broadcast) ont des exigences techniques très différentes, une spécification IMF unique et rigide ne parviendrait pas à satisfaire tout le monde. Pour résoudre ce problème, la norme SMPTE ST 2067 utilise des "Applications"—des profils spécifiques et contraints qui dictent exactement quels codecs, espaces colorimétriques et résolutions sont autorisés dans cette saveur IMF particulière. Si vous livrez un paquet App 2 à un diffuseur qui attend un paquet App 5, l'ingestion automatisée échouera.
90
91        L'application IMF 2 (App 2) et son successeur, l'application 2E (App 2E), sont les rois incontestés de la livraison en streaming haut de gamme. L'App 2E a été fortement défendue par Netflix et est devenue la norme mondiale pour le mastering de séries télévisées épisodiques et de longs métrages premium. Elle impose l'utilisation de la compression JPEG 2000 (J2K) pour l'essence vidéo. L'App 2E prend en charge une qualité d'image incroyablement robuste, acceptant des résolutions jusqu'au 4K (et au-delà), des fréquences d'images jusqu'à 120 ips, et surtout, une prise en charge complète du mastering HDR (High Dynamic Range), y compris les espaces colorimétriques ST 2084 (PQ) et les gamuts de couleurs Rec.2020. Si vous livrez une série originale phare à une grande plateforme SVOD, vous livrez un package App 2E.
92
93        L'application IMF 5 (App 5) a été développée pour servir un public différent : l'écosystème d'archivage et de diffusion établi. De nombreux laboratoires de post-production et réseaux de diffusion ont construit l'intégralité de leurs infrastru
93ctures autour du workflow ACES et de l'Academy Color Encoding System, utilisant le format de séquence d'images OpenEXR mathématiquement sans perte. L'App 5 permet à l'encapsuleur IMF de contenir des séquences d'images ACES EXR au lieu de vidéo compressée J2K. Cela crée un paquet d'archives massif, vierge et mathématiquement pur, bien que les tailles de fichiers résultantes soient beaucoup trop énormes pour les échanges télévisés quotidiens standard.
94
95        Plus récemment, reconnaissant l'omniprésence des codecs propriétaires d'Apple dans le monde du montage, la SMPTE a introduit l'Application ProRes (App ProRes). Cela permet aux laboratoires de construire des structures XML IMF standard (CPLs, OPLs, sous-titres IMSC1) mais d'utiliser Apple ProRes 422 HQ ou ProRes 4444 comme essence vidéo sous-jacente au lieu du J2K lourd en calculs. Cela accélère considérablement les temps de rendu sur les stations de travail basées sur Mac tout en préservant les avantages de versionnage basés sur les composants de l'architecture IMF.`},{title:"7. Creation et validation d'un package IMF",content:`L'écriture et la validation d'un Interoperable Master Package nécessitent une expertise technique approfondie et un logiciel spécialisé. Contrairement à l'exportation d'un fichier H.264 générique depuis Adobe Premiere, la création d'un IMF est un processus computationnel rigide qui n'offre absolument aucune marge d'erreur. Une seule balise de métadonnées mal placée déclenchera un rejet automatisé par le réseau récepteur.
96
97        Le processus de création se déroule généralement dans un logiciel de finition haut de gamme tel que DaVinci Resolve, Colorfront Transkoder ou Rohde & Schwarz Clipster. L'ingénieur commence par disposer la timeline finale étalonnée. Le logiciel doit être configuré pour transformer mathématiquement l'espace colorimétrique de la timeline vers les cibles spécifiques requises par l'application IMF (par exemple, transformer une timeline P3-D65 en un conteneur Rec.2020 PQ pour une livraison HDR App 2E). Le logiciel encode ensuite les lourdes images vidéo JPEG 2000, rend les MXF audio non compressés et compile les documents XML complexes (CPL, PKL, AssetMap). Étant donné que l'encodage J2K est extrêmement gourmand en ressources CPU, le rendu d'un film 4K en IMF nécessite souvent des fermes de rendu dédiées pour s'achever dans un délai raisonnable.
98
99        Cependant, il ne suffit pas de simplement exporter le paquet ; une validation rigoureuse est strictement requise avant la transmission. Les principales plateformes comme Netflix utilisent des moteurs de contrôle qualité automatisés basés sur le cloud. Pour éviter que les installations ne téléchargent des packages cassés de 300 gigaoctets, l'industrie s'appuie sur un outil de validation open source appelé Photon (développé à l'origine par Netflix).
100
101        Avant l'expédition, le laboratoire de post-production fait passer le dossier IMP généré via Photon. Le logiciel analyse agressivement chaque fichier XML, vérifie les liens UUID, recalcule les hachages SHA-1 de chaque fichier MXF, recherche les caractères illégaux dans les métadonnées et s'assure que les débits binaires J2K se situent dans les limites obligatoires du ST 2067. Ce n'est que lorsque Photon renvoie un rapport de validation "vert" que l'ingénieur peut être sûr que le package est structurellement sain. Suite à cette validation technique, un opérateur de QC humain doit toujours effectuer un contrôle visuel ponctuel pour s'assurer que les sous-titres IMSC1 s'affichent correctement et que les canaux audio 5.1 sont acheminés vers les bons haut-parleurs.`},{title:"8. IMF face au mezzanine traditionnel",content:`Pour vraiment saisir la valeur de l'IMF, il faut le contraster avec les formats mezzanine traditionnels qui ont dominé la post-production au cours des quinze dernières années, principalement l'Apple ProRes et l'Avid DNxHR.
102
103        Le ProRes 4444 XQ et le DNxHR 444 sont indéniablement des codecs spectaculaires. Ils fournissent des images 12 bits robustes et visuellement sans perte qui préservent parfaitement un étalonnage de haute qualité. Ils sont légers sur le plan des calculs, ce qui signifie qu'ils sont lus de manière fluide sur presque n'importe quel système de montage non linéaire (NLE) moderne sans nécessiter de décodeurs matériels dédiés. Pour une petite société de production générant une seule vidéo Web finale, l'exportation d'un master ProRes aplati reste le flux de travail le plus logique et le plus efficace.
104
105        Cependant, la faiblesse fondamentale du ProRes et du DNxHR réside dans leur nature monolithique. Ce sont des fichiers "aplatis". Si un distributeur mondial doit livrer un film avec 15 doublages de langue différents et 20 langues de sous-titres différentes, un flux de travail ProRes l'oblige soit à créer 15 fichiers vidéo massifs et dupliqués (un pour chaque doublage audio), soit à s'appuyer sur des structures de dossiers chaotiques et non standardisées contenant un fichier vidéo ProRes accompagné de manière lâche de fichiers WAV et de fichiers de sous-titres SRT. Cette approche de dossiers non liés conduit inévitablement à des dé
105sastres de synchronisation et à des actifs manquants lors des transferts entre différents prestataires.
106
107        L'IMF résout ce chaos. En adoptant l'architecture basée sur les composants du DCP, l'IMF fournit la "colle" stricte et standardisée (les Composition Playlists XML) nécessaire pour garder des centaines d'actifs localisés disparates parfaitement synchronisés avec un seul master vidéo immaculé. De plus, parce que l'IMF utilise le JPEG 2000 (une norme ISO ouverte) plutôt qu'un codec d'entreprise propriétaire comme le ProRes, il garantit la stabilité des archives. Un studio peut être certain qu'un décodeur J2K open source sera toujours capable d'ouvrir mathématiquement ses packages IMF dans cinquante ans, bien après l'expiration de licences de logiciels d'entreprise spécifiques.`},{title:"9. Bonnes pratiques et pieges courants",content:`La maîtrise du workflow IMF nécessite un changement radical de mentalité opérationnelle, s'éloignant de la simple exportation vidéo vers une gestion rigoureuse des données. Les pièges les plus courants et les plus coûteux dans la livraison IMF découlent presque toujours d'erreurs de métadonnées et d'un non-respect de l'architecture de composants non destructive stricte.
108
109        Le désastre le plus fréquent concerne la synchronisation des sous-titres. Contrairement au texte incrusté ou aux fichiers SRT standard, les sous-titres IMSC1 dans un IMF sont profondément liés à la fréquence d'images et au code temporel de démarrage de la Composition Playlist (CPL). Si le MXF vidéo commence à 01:00:00:00, mais que le logiciel de création de sous-titres a exporté le XML en supposant une heure de début à 00:00:00:00, le texte ne s'affichera absolument pas pendant la lecture. Les ingénieurs doivent vérifier minutieusement que les métadonnées de timecode à l'intérieur du XML IMSC1 s'alignent parfaitement avec la timeline globale de la CPL.
110
111        Un autre écueil massif est la mauvaise gestion des versions originales (OV) et des packages supplémentaires (Supplemental). Un package supplémentaire est totalement inutile en soi ; il ne contient que les modifications delta infimes (comme un patch vidéo de 5 secondes et une piste audio espagnole). Si une installation supprime accidentellement la version originale massive de 200 Go de son serveur pour économiser de l'espace, les packages supplémentaires se "brisent" instantanément parce que la CPL XML ne peut plus trouver le MXF vidéo principal auquel elle fait référence. Les laboratoires doivent mettre en œuvre des systèmes rigoureux de gestion des actifs multimédias (MAM) pour s'assurer que les relations parent-enfant entre les IMP OV et Supplemental sont protégées de manière permanente.
112
113        Enfin, les conventions de dénomination sont absolument critiques. Un dossier IMF est essentiellement une base de données. Si un opérateur renomme manuellement un fichier MXF à l'intérieur du dossier via le système d'exploitation pour corriger une faute de frappe (par exemple, changer "Audio_Eng.mxf" en "Audio_English.mxf"), l'ensemble du package échouera instantanément à la validation. Les documents XML PKL et CPL recherchent toujours le nom de fichier d'origine et le hachage cryptographique d'origine. Toute modification du package doit être exécutée via un logiciel de création IMF certifié pour garantir que les bases de données XML sont correctement mises à jour pour refléter les nouvelles identités de fichiers.`}],conclusion:"En conclusion, l'Interoperable Master Format (IMF) représente l'étape évolutive ultime dans la logistique de la chaîne d'approvisionnement numérique. En démantelant complètement le concept archaïque du fichier vidéo aplati et en le remplaçant par une architecture de composants rigoureuse pilotée par XML, l'IMF a fourni aux industries mondiales du streaming et de la diffusion un standard de livraison massivement évolutif et non destructif. Grâce au déploiement intelligent des versions originales (OV) et des packages supplémentaires (Supplemental), les studios peuvent désormais localiser et versionner leur contenu premium pour des dizaines de territoires internationaux 
113sans encourir les coûts de stockage et de bande passante paralysants des rendus vidéo dupliqués. La nature rigoureuse de la norme SMPTE ST 2067, combinée à des outils de validation automatisés comme Photon, garantit que ces packages de données colossaux restent structurellement sans faille et stables pour les archives pendant des décennies. Pour les professionnels de la post-production, la maîtrise de l'IMF n'est plus optionnelle ; c'est le prérequis absolu pour livrer du contenu haut de gamme à des plateformes comme Netflix et Amazon. Pour comprendre la fondation architecturale qui a inspiré l'IMF, passez en revue notre analyse approfondie de la livraison en salle dans « Le DCP : la livraison du cinéma numérique ». Pour explorer les codecs vidéo sous-jacents qui forment l'essence mathématique de ces packages, consultez « Codecs et conteneurs » et « Formats mezzanine ». Enfin, pour saisir comment ces masters IMF vierges sont finalement compressés pour la livraison au consommateur, explorez notre guide complet sur les « Formats et standards de livraison »."}},E=()=>{const{currentLanguage:i}=c(),s=M[i],o="imf-packages",t=v(o,i),a=f({title:t.title,description:t.description,path:`/${i}/formats/${o}`,locale:i,publishedTime:t.publishedTime,modifiedTime:t.modifiedTime,section:t.section,tags:t.keywords,keywords:t.keywords}),l=y({title:t.title,description:t.description,publishedTime:t.publishedTime,modifiedTime:t.modifiedTime,section:t.section,url:`https://postproduction.studio/${i}/formats/${o}`,locale:i,keywords:t.keywords});return e.jsxs(e.Fragment,{children:[e.jsx(p,{...a,schemas:[l]}),e.jsx(m,{type:"article",data:{title:a.title,description:a.description,path:a.path,language:i,section:a.section}}),e.jsx(h,{title:s.title,level:i==="fr"?"Avancé":"Advanced",section:i==="fr"?"Formats & Livraison":"Formats & Delivery",readTime:t.readingTime,tldr:b[i],content:e.jsxs(e.Fragment,{children:[e.jsx("p",{className:"lead text-xl text-gray-600 mb-8",children:s.intro}),e.jsxs("div",{className:"bg-gray-50 p-6 rounded-lg mb-8",children:[e.jsx("h2",{className:"text-xl font-bold mb-4",children:s.toc}),e.jsx("ul",{className:"space-y-2",children:s.sections.map((r,n)=>e.jsx("li",{children:e.jsx("a",{href:`#section-${n+1}`,className:"text-blue-600 hover:underline",children:r.title})},n))})]}),s.sections.map((r,n)=>e.jsxs("div",{id:`section-${n+1}`,className:"mb-12",children:[e.jsx("h2",{className:"text-2xl font-bold text-gray-900 mb-4",children:r.title}),e.jsx("div",{className:"text-gray-800 space-y-4",children:r.content.split(`
114
115`).map((d,u)=>e.jsx("p",{children:d},u))})]},n)),e.jsx("div",{className:"mt-12 pt-8 border-t border-gray-200",children:e.jsx("p",{className:"text-lg text-gray-700 italic",children:s.conclusion})}),e.jsx(g,{currentArticleId:"imf-packages",currentSection:"Formats"})]})})]})};export{E as default};

Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.