Table 1 : Identification of requirements satisfied
-
Offer access to selected individual MPEG and related technologies through standard APIs
|
Y
| -
Offer APIs to
|
| -
Access
|
| -
Media encoders/decoders
|
| -
Audio
|
Y
| -
Video
|
Y
| -
3DG
|
Y
| -
Binary XML
|
N
| -
Audio/Video/3DG players
|
Y
| -
Presentation Engine
|
| -
BIFS
|
N
| -
LASeR
|
Y
| -
HTML
|
N
| -
IPMP functionality
|
| -
IPMP components
|
Y
| -
Create/edit/parse
|
| -
Digital Items
|
Y
| -
Metadata
|
| -
MPEG-7
|
Y
| -
MPEG-21
|
Y
| -
TVA
|
N
| -
Licences
|
Y
| -
File Formats
|
Y
| -
Stream/consume content
|
| -
Audio
|
Y
| -
Video
|
Y
| -
Scene
|
Y
| -
Metadata
|
Y
| -
Digital Items
|
Y
| -
Store/consume content in distributed environments
|
| -
Peer-to-peer (P2P) infrastructure based on e.g. Distributed Hash Tables (DHT)
|
Y
| -
Search for content
|
Y
| -
Communicate between devices
|
| -
Player with Licence server etc.
|
Y
| -
Support interfacing with security elements in devices such as those provided by ISO/IEC 11889 Trusted Platform Module
|
Y
| -
Be documented in at least one Programming Language (APIs)
|
Y
| -
A Programming Language independent version of the APIs may be supported as well by MXM
|
Y
| -
Be modular to enable easy customisation for specific needs and to form various media value-chain easily
|
Y
| -
Be designed to be re-usable in complete environments such as the M3W Framework
|
Y
|
Table 2: Identification of requirements not satisfied and suggested ways by which MPEG could obtain the corresponding technology/ies
Requirements not satisfied
|
Reasons/How requirements could be satisfied
|
Binary XML
|
The proponents could not devote resources to satisfy this requirement. As MPEG has identified several application for Binary XML, it could easily extend the current proposal to support this requirement using it internal expertise
|
BIFS and HTML Presentation
|
The proponents could not devote resources to satisfy these requirements. However, the BIFS and HTML specificities can be easily accommodated with the material contained in the submission
|
Visual description
|
The proponents have provided support to Visual descriptors used in the Photo Player Application Format. More Visual descriptors can be supported using the same procedure highlighted in the proposal
|
Audio description
|
The proponents could not devote resources to satisfy this requirement. As MPEG has identified several application for audio description, it could easily extend the current proposal to support this requirement using it internal expertise
|
TVA metadata
|
The proponents could not devote resources to satisfy this requirement. However, there exists enough openly accessible significant material that can be used to develop the TVA Metadata part of the MXM API
|
In addition, new requirements were satisfied by the proposal (even they were not called for):
-
Content identification (APIs and protocol)
-
Content upload (APIs and protocol)
-
License upload (APIs and protocol)
-
Access to Video output /Audio output / Event APIs (APIs)
They are detailed in the table below and new CfP was issued (Cf. Req. report):
Table 3: Identification of additional requirements satisfied
New requirement
|
How it is handled
|
API to remote store a content item (Digital Item + resources)
|
Proposal of API and of specific technology provided. If accepted this could be added to ISO/IEC 29116
|
API to remote store a licence
|
Supported by the proposed solution.
|
API to identify a Digital Item or elements thereof
|
Supported by the proposed solution.
|
API to authenticate a Digital Item or elements thereof
|
Supported by the proposed solution.
|
API to verify a role
|
Document m15689 proposes a specific API to verify a role, but there is no Media Value Chain Ontology (MVCO) technology proposal in m15688. We believe that the proposed API is MVCO-technology agnostic. If MPEG will develop its own MVCO technology there may be a need to make fine adjustments as the MVCO standardisation progresses
|
Resource rendering
|
Proposal of API provided
|
Digital Item Presentation
|
Document m15689 proposes a specific API to present digital items, but there is no Presentation of Structured Information (PSI) technology proposal in m15688. We believe that the proposed API is PSI-technology agnostic. If MPEG will develop its own PSI technology there may be a need to make fine adjustments as the PSI standardisation progresses
|
A process for developing the standard was discussed and approved by MPEG:
-
MXM use cases definition
-
MXM API requirements definition
-
MXM API specification
-
MXM technologies specification
The inputs contribution was taken as the basis to produce the 2 output WD:
-
Architecture and Technologies
-
APIs
Technical Work in Progress.
Dostları ilə paylaş: |
