Transcript
IMF CORE APPLICATION AND EXTENSIONS CONCEPT CURRENT APPROACH: MULTIPLE IMF APPLICATIONS AND COMMON CORE CONSTRAINTS •
• • •
Create a series of applications that satisfy specific use cases. Examples: • Picture Codec (Uncompressed, J2K, SSTP, H.264, Cineform) • Audio Codec (LPCM, AC3, AAC, Dolby E, DTS-HD. AES3 bitstream has been discussed as well Redact the items which are common from these applications into a set of “core constraints”. 1 Applications would refer to the core constraints and add to them or constrain them further to suit the application. An IMF device may support any of these applications (one or more). For example, a company could advertise that a certain piece of equipment supports “IMF Applications 2 and 5” and another company could advertise that its device supports “IMF Applications 3 and 4” and both would be considered IMF devices.
ISSUES WITH CURRENT APPROACH: • •
There is not one application that all IMF devices must support, which hampers interoperability. A given IMF is only usable on devices that support the application under which it was created.
SPE PROPOSED APPROACH: IMF CORE APPLICATION AND EXTENSIONS • •
•
1
Create an IMF Core Application that all IMF devices must support at a minimum. • Ideally, this requires that all IMF devices be able to read and write a core IMF Create a series of “Application Extensions” that add additional functionality to the IMF Core Application. Examples may include: • Add picture codecs • Add audio codecs • Add support for text/data not included in core IMF Devices must support the IMF core and may optionally support one or more of the application extensions.
IMF core currently has CPL/OPL, wrapping, packaging, security, data essence and some audio. There is currently no image in the core.
IMPACTS ON CURRENT APPROACH • • • •
Changes slant on the current concept of core to be a complete application rather than only some common pieces Adds Image Essence and Image File Formats to core Requires that IMF equipment support at least the core application at a minimum rather than choosing what it will support from a list. Can still support additional applications past the core application as desired. Changes slant on the current concept of “applications” to be application extensions rather than full applications or application constraints. • Note that items in the IMF Core that cannot be supported using a particular application extension would be constrained in that application by nature. An example may be a raster size that a particular codec does not support that is supported in the IMF core.
SPE PROPOSAL FOR THE IMF CORE APPLICATION (The following is a possible preface, please comment) Sony Pictures believes that there needs to be a core IMF application that all IMF equipment must support at a minimum in order to make the Interoperable Master Format interoperable. Additional extension applications are a welcome addition to the functionality and may be added over time as proponents bring them forward. Sony Pictures’ position is that the IMF Core Application should be based on the concepts that the original proponents brought forward into SMPTE coupled with the excellent work that is currently underway. The exact specifications of the IMF Core Application should be the current focus of the IMF effort. Extension applications can be brought forward by their proponents at any time but should be done so in parallel and should not in any way dilute the initial effort to standardize the IMF Core Application. In short, the IMF Core Application should solve the problem that the original proponents intended to solve. Proponents desiring additional solutions should write extensions to the IMF Core Application.
The below are basic bullet points and are not intended to be exhaustive PLEASE ADD to/CORRECT THE BELOW, esp RESOLUTIONS The current work in CPL/OPL, wrapping, security, packaging and data essence should continue as is. Audio should continue as is with the caveats noted in the bullet points below. • •
•
•
Frame Rates • 23.976, 24.00, 25.00, 29.97, 30, 48, 50, 59.94, 60 Image Essence Parameters • UHD, HD and SD (We could eliminate UHD but I think there is a push for it) • Resolutions up to < 7680x4320 > • Bit Depth-10 bits • Colorimetry Rec.709, Y’C’bC’r, R’G’B’ , Rec 601 Y’C’bC’r • Component Sampling: 4:2:2, 4:4:4 • Progressive and Interlace • (Should we comment on active pixals only versus the container concept? This was discussed at length in the WG meeting. Maybe should just leave this alone for now.) Image file formats • Uncompressed: Generic Container, DPX • JPEG 2000 part one, Levels 2-5 Audio • 2’s complement LPCM • 24 bit data word • 47.952K, 48K, 95.904K, 96K sampling rate • All other constraints currently in IMF audio documents • Audio MXF track labeling per the MCA Structure
IMPLEMENTATION CONSIDERATIONS (may not include this ultimately but please comment) • • • •
A compromise could be that an IMF device must be able to read a core IMF but does not have to be able to author/write a core IMF It may be that in general the industry will have some devices that can read IMF and other devices that can author an IMF, and some that can do both. Application extensions may be realized in practice as a “plug-in” architecture concept In practice, as more application extensions are standardized, if IMF devices want to stay competitive they will issue revisions to their software
or hardware to accommodate. SUGGESTED APPLICATION EXTENSIONS • • •
SSTP extension Dolby E extension Others?
