moving picture experts groupmpeg.chiariglione.org/sites/default/files/files/standards... · web...

INTERNATIONAL ORGANISATION FOR STANDARDISATION

ORGANISATION INTERNATIONALE DE NORMALISATION

ISO/IEC JTC1/SC29/WG11

CODING OF MOVING PICTURES AND AUDIO

ISO/IEC JTC1/SC29/WG11

MPEG2007/N9164Lausanne, CH, July 2007

Title: MAF Overview

Source: Requirements Group

Editor: Florian Schreiner, Klaus Diepold

Status: Approved

MAF Overview

Table of Contents1 MOTIVATION FOR MULTIMEDIA APPLICATION FORMATS (MAFS).......3

1.1 REQUIREMENTS FOR MAFS..................................................................................31.2 REQUIREMENTS FOR STARTING A NEW MAF.......................................................51.3 TEMPLATE FOR MAF CANDIDATES.....................................................................6

2 MAFS ALREADY SPECIFIED...........................................................................8

2.1 MUSIC PLAYER APPLICATION FORMAT...............................................................82.2 PHOTO-PLAYER APPLICATION FORMAT.............................................................112.3 MUSICAL SLIDE SHOW MAF.............................................................................12

3 MAFS UNDER DEVELOPMENT.....................................................................18

3.1 PROTECTED MUSICAL SLIDE SHOW MAF.........................................................183.2 MEDIA STREAMING PLAYER MAF.....................................................................203.3 PROFESSIONAL ARCHIVAL MAF........................................................................303.4 OPEN RELEASE MAF.........................................................................................393.5 PORTABLE VIDEO PLAYER MAF.......................................................................453.6 MULTIMEDIA APPLICATION FORMAT FOR DIGITAL MULTIMEDIA BROADCASTING..............................................................................................................523.7 VIDEO SURVEILLANCE MAF..............................................................................61

4 MAFS UNDER CONSIDERATION..................................................................67

4.1 ADVANCED SURVEILLANCE MAF......................................................................674.2 DIGITAL VIDEO/CINEMA MAF..........................................................................714.3 PROTECTED PHOTO PLAYER MAF.....................................................................764.4 STEREOSCOPIC MAF..........................................................................................804.5 CROSS-MEDIA INTERACTIVE PRESENTATION MAF...........................................87

REFERENCES..........................................................................................................100

Annex A URN Structure for MAFs.........................................................................101

1 Motivation for Multimedia Application Formats (MAFs)

This document presents an overview of MPEG’s Multimedia Application Formats (MAF), which provide the framework for integration of elements from several MPEG standards into a single specification that is suitable for specific but widely usable applications. Typically, MAFs specify how to combine metadata with timed media information for a presentation in a well-defined format that facilitates interchange, management, editing, and presentation of the media. The presentation may be ‘local’ to the system or may be accessible via a network or other stream delivery mechanism. Selected Multimedia Application Formats are candidates to become parts of the ISO/IEC 23000 (MPEG-A) specification.

The current situation is:

ISO/IEC 23000-1: Purpose of Multimedia Application Formats (TR)

ISO/IEC 23000-2: Music Player (FDIS in April 2007)

ISO/IEC 23000-3: Photo Player (FDIS in October 2006)

ISO/IEC 23000-4: Musical Slide Show (FDIS in April 2007)

ISO/IEC 23000-5: Media Streaming (FCD in April 2007)

ISO/IEC 23000-6: Professional Archival (WD in October 2006)

ISO/IEC 23000-7: Open Release (FCD in April 2007)

ISO/IEC 23000-8: Portable Video Player (FCD in July 2007)

ISO/IEC 23000-9: MAF for Digital Multimedia Broadcasting (FCD in April 2007)

ISO/IEC 23000-10: Video Surveillance (CD in July 2007)

1.1 Requirements for MAFsMAF specifications shall integrate elements from different MPEG standards into a single specification that is useful for specific but very widely used applications. Examples are delivering music, pictures or home videos. MAF specifications may use elements from MPEG-1, MPEG-2, MPEG-4, MPEG-7 and MPEG-21.

Typically, MAF specifications include:

The ISO file format family for storage

MPEG-7 tools for metadata

One or more coding Profiles for representing the media

Tools for encoding metadata in either binary or textual form (XML)

MAFs may specify use of:

MPEG-21 Digital Item Declaration Language for representing the structure of the media and the metadata

Other MPEG-21 tools as they are required

non-MPEG coding tools (e.g., JPEG) for representation of "non-MPEG" media

Elements from non-MPEG standards that are required to achieve full interoperability

MAF Specifications can contain elements from all existing MPEG Standards. MAF specification shall use existing Profiles In exceptional circumstances, non-Profile tool sets may be used.

MAF Specifications shall fully specify the elements that are used from the MPEG standards (and other standards if applicable) with all their constraints, so that full interoperability can be achieved.

MAF Specifications shall specify a core metadata set to be supported by any implementation of that MAF, and may enable private extensions.

Any URNs defined in MAF Specifications shall conform to the structure defined in Annex A. This requirement supplements the general requirements for URNs in the MPEG namespace, as detailed in IETF RFC 3614 and MPEG output N8945.

MAF Specifications shall be made available in the form of text and Reference Software. The Reference SW shall enable a rapid uptake of the MAF in question.

MPEG

-1

MPEG

-2

MPEG

-4

MPEG

-7

MPEG

-21

JPEG

MPEG

-A

Photo Player MAF

Music Player MAF

...

Other MAF

ISO/IEC

11172

ISO/IEC

13818

ISO/IEC

14496

ISO/IEC

21000ISO/IEC 23000

ISO/IEC

15938

...

ISO/IEC

10918

JPEG 2000

ISO/IEC

15444

Figure 1: MAF Conceptual Overview

In Figure 1 the concept for MAFs is illustrated. In [6] a more complete description for the MPEG-A approach is given, which is also reflected in the technical report on MPEG-A to be issued as ISO/IEC 23000-1 [1].

1.2 Requirements for starting a new MAFBefore the work on a new MAF (a part of the MPEG-A Standard) can be started, the following items need to be available:

Documentation of the technologies that the MAF would encompass, and that these technologies are advanced enough in standardization: the base technologies will be certain to be at FDIS stage or beyond, when MAF reaches FDIS stage.

─ This includes MPEG technologies as well as external technologies.

Clear statement of Requirements and Value Proposition,

─ Including an assessment of the relation to any solutions that may already exist, standards-based or proprietary.

It is also requested to clearly explain if there are technically similar MAFs already in existence and in what respect the newly proposed MAF differs from them in terms of requirements

Documentation of enough industry support to successfully complete the work and deploy the format, in the form of registered MPEG input contributions.

Commitments for Reference Software in registered MPEG input contributions. The reference SW should allow a successful launch of the format.

Commitments, in the form of one or more registered input contributions, for exchange and crosscheck of content encoded according to the MAF between multiple parties and multiple independent implementations.

─ The content should exercise/utilize all the tools in the MAF (but not necessarily in all possible combinations).

Commitment, in the form of one or more registered input contributions, to produce relevant marketing materials, including at least one white paper explaining the benefits of the new MAF.

1.3 Template for MAF CandidatesMPEG can start the process for the specification a new part of MPEG-A based on technical contributions which allow the perusal if there is sufficient industry support for such a standardization. The pertaining contribution documents shall be based on a template as specified in this section.

1.3.1 Application Scenario Description

This section shall contain a description of the application scenario under consideration. The application scenario shall guide the requirements process leading into the subsequent specification process. Note that it is not the application that is the subject of standardization.

1.3.2 Requirements

Based on the application scenario described in the previous section technical requirements shall be extracted and specified to a level of detail that allows to identify and quantify the elements from the MPEG body of standards needed to satisfy the requirements. It is conceivable that this process produces requirements for which there exist no appropriate MPEG technologies. This situation may trigger new standardization activities within MPEG if this is considered to be necessary.

1.3.3 List of technologies

MPEG technologies shall be picked in order to match the requirements, which have been compiled in the previous section. Pick fitting profiles from existing MPEG parts or take this information as a guideline to define new profiles as needed.

1.3.4 Comparison with other MAFs

MPEG shall not duplicate its efforts and shall not create a set of MAFs that comprise a large amount of overlap. In order to distinguish the technical scope of a newly proposed MAF, proponents shall provide a comparison of the new MAF with existing or recently proposed MAFs. This exercise could also help to see if there exist MAF proposals which can be merged to produce a more generic MAF that facilitates a wider range of applications.

1.3.5 Issues

MPEG experts need to identify any issues which are essential to facilitate the application scenario but which may lie outside of MPEG’s jurisdiction.

1.3.6 Supporting Companies and Organizations

MPEG standards are asking for reference implementation in terms of reference software. The software is intended to demonstrate and facilitate the use of the specified MPEG technologies in the market place. The necessary software elements may need to include normative and non-normative parts.

2 MAFs Already SpecifiedIn this section MAFs are summarized that have already been standardized or have at least progressed close to the finished standard, i.e. IS status.

2.1 Music Player Application Format

2.1.1 Overview

The Music Player MAF specifies a simple and uniform way to carry MP3 coded audio content in MPEG-4 File Format augmented by simple MPEG-7 metadata and a JPEG image for cover art. Specific MPEG-7 Metadata represents data commonly expressed in ID3 tags as follows:

Song title – title of the song

Album title – title of the album

Artist – artist performing the song

Year – year of the recording

Comment – an account of the content of the resource

Track – CD track number of song

Genre – a category of artistic, musical, or literary composition characterized by a particular style, form, or content.

MPEG-1/2 Audio Layer III, also known as MP3, is one of the most widely used MPEG standards. Currently, the ID3, which was created by appending simple metadata tags such as Artist, Album, Song Title, etc. at the end of the MP3 turned out to be very positive thing to do since they provide useful content description about the music clip.

Since that time MPEG has developed a number of standards, all of which strive to serve the needs of consumers and industry. Among those are MPEG-4, a next-generation suite of standards for media compression, and MPEG-7, a suite of standards for meta-data representation. MPEG-4 specifies the ISO/MPEG-4 File Format, while MPEG-7 specifies not only signal-derived meta-data, but also archival meta-data such as Artist, Album and Song Title. MPEG-21 tools are used to enable album functionality on top of that. It allows to collect several song files in the above described song file format into one album file.

As such, MPEG-4, MPEG-7 and MPEG-21 represent an ideal environment to support the current “MP3 music library” user experience, and, moreover, to extend that experience in new directions.

MPEG has moved one step further to refine Music Player MAF in its second edition by adding protection feature by incorporating AES-128 counter mode encryption as default protection tool and MPEG-21 Intellectual Property Management and Protection (IPMP) and MPEG-21 Rights Expression Language (REL) for flexible and extensible protection and governance description.

2.1.2 Application Scenario for Protection

2.1.2.1 Simple protection scenario with default encryptionProducer Jim records a few new songs storing them in a format as explained in MAF Part-2. To protect his songs against unauthorized copying, he encrypts them as specified in this proposed music player MAF, 2nd edition and sends the files to retailer Tom. Since the content is already protected, transport does not need additional security measures. He puts the access information (encryption keys) in a separate container and delivers these in a secure way to Tom (this may be over the Internet or on a CD or whatever way he chooses). Tom is now able to use the protected content for distribution to the end user without modifying the song format. He just needs to add proper license information.

Advantages for the song producer

Content that is meant to be distributed is protected from the very beginning

If “everyone” uses the same protection (and encoding) format, lots of economically available tools will support this “mastering process”

The producer has the full control over the content

Advantages for the retailer

Needs only one set of well supported tools, since every producer uses a standardized content encoding and protection format

The song can be distributed to the end customer without changing the format (encoding, protection and file format). It is just necessary to add proper license information for the end customer.

The protected content format is directly suitable to be used for concepts like super distribution and subscription models that require the separation of content and license.

The protected content format is slim and efficient and thus suitable for a broad range of customer devices and for various DRM schemes ranging from simple to sophisticated.

2.1.2.2 Flexible Protection Scenario

Distributor applies protection

Producer Peter records songs. He then enters an agreement with Distributor Annie to widely sell the songs online. Peter sends the songs to Annie without any protection because he trusts her.

Upon receiving the songs, Annie takes the following actions:

Protect the songs with the appropriate content protection tool.

Create metadata to describe the protection that she applied to the songs. The description includes the tools (id and/or location to get it), in which part of songs they are applied (if the protection is not applied to entire song).

Express the rights that govern the use of that protected song. The rights expression reflects the business model that is used. The rights expression may describe who has privilege to consume, what is the privilege (rights), on what conditions, etc. Key information to “unprotect” might be included in the rights expression as well.

Package the protected data, metadata that describe the protection, rights expression into the music player MAF format.

Make the package available for download/streaming by the end user. Note the business model may require proof of payment for purchase or a valid subscription.

Producer applies protectionPeter signs a separate agreement with Distributor Bill for some of his live recordings. However, Bill only offers hosting services and does not provide content protection services. Peter applies a simple content protection tool to his songs before uploading them to Bill’s site. Peter also packages timed lyrics and photos as “extras”, and uses protects them as well.

Consumer acquires contentConsumer Charlene sees Peter live at a local pub and approaches him about recordings. He hands her a card with a URL to Bill’s site where she can download some of his songs for free (these are sometimes known as “teasers”.)

Charlene sits in front of her PC at home and downloads the songs from Bill’s website. She uses a Music Player MAF, 2nd edition -compliant player, which parses the file, identifies and applies the content protection tool(s) necessary to play the song. If the player does not have the protection tool that Peter selected, the player can automatically download the tool for a seamless consumer experience.

Charlene likes what she hears, but Peter has not enabled copy to portable players in these free teasers. She connects to her favourite music download site, run by Annie, and finds songs by Peter for sale. Charlene charges her account and downloads the files. She listens to the songs and then transfers them to her portable music player.

The portable music player also is compliant with the Music Player MAF and can process the files downloaded from Annie’s site. The player already supports all the necessary protection tools and can parse the file and play the music payload.


Until its second edition, the following technologies have been identified as necessary for the Music Player MAF:

All technologies needed for ISO/IEC 23000-2, Music Player Application Format

Access Unit header (entry point for decryption) as defined in ISMACryp and OMA2.0 DCF to enable random access to encrypted content

AES128 CTR encryption tool (default encryption)

ProtectedSchemeBox (‘sinf’) of the ISO Base Media File Format 2nd Edition. The ‘sinf’ box is added to the sample description ‘stsd’ to protect the audio track and/or added to the ‘ipro’ box to protect the meta-data. The ‘sinf’ box contains the signalization of the protection format.

Protection format according to the ISMACryp 1.1 specification.

MPEG-21 IPMP Components Base Profile.

MPEG-21 REL MAM Profile.

2.1.4 Conformance Points

There are three conformance points that can be taken by applications and/or devices to implement Music Player MAF.

Unprotected music player.

Protected music player with default protection

Protected music player with flexible protection.

2.2 Photo-Player Application FormatThe Photo-Player MAF enables a new experience in creating, sharing and viewing digital photo albums. It specifies a simple and uniform way to carry JPEG images and their associated MPEG-7 metadata in an MPEG-4 file, providing an interoperable solution for digital photo library applications.

The supported metadata include image-acquisition parameters (such as date, time and camera settings), as well as MPEG-7 visual content descriptions. This allows

conforming devices to support new, content-enhanced functionality, such as intelligent browsing, content-based search or automatic categorization.

MPEG Photo-Player makes it possible to:

Organize photos into categories based on their content – for example, the people and places depicted, or events taking place in photos.

Perform advanced content-based searches, through collections of photos.

Bundle photos and favourite ways to show them, into a single MPEG-4 file.

Link to external resources, such as other images (outside the MPEG-4 file) or web-pages.

The major components of the Photo-Player standard are:

A method to encapsulate a set of JPEG compressed images in an MPEG-4 file

Concise subsets of MPEG-7 metadata, to describe the individual images and the overall collection

A method to embed this binary MPEG-7 metadata in the MPEG-4 file

Digital Cameras are one of the most popular consumer digital devices, with estimates showing over 400 million units sold worldwide (2005). The sales of digital cameras overtook the sales of their analogue counterparts in Japan, US and Europe. JPEG is the common data format used in the great majority of the cameras.

MPEG has developed the MPEG-7 standard, which defines rich meta-data descriptions for audio-visual applications. MPEG also provides the ISO/IEC Media File Format (ISO FF) as a storage container. The Photo Player MAF also takes advantage of the widely supported EXIF meta-data since it has the basic information about picture creation.

As such, Photo Player MAF is an ideal tool to enhance the digital photo library experience.

2.3 Musical Slide Show MAFThe existing Music Player MAF was designed as a simple format for enhanced MP3 players. It contains MP3 audio data, optional MPEG-7 meta-data and JPEG still image for cover art. The Photo Player MAF under development combines JPEG still images with MPEG-7 meta-data.

This Musical Slideshow MAF builds on top of the Music Player and the Photo Player MAF and is meant as a superset of these two MAFs.

The following section describes the applications scenarios and derived requirements for a “Musical Slide Show MAF” format.

2.3.1 Application Scenarios

Foreign language exercise materialsIt is popular to listen the audio contents by using MP3 players. Sometimes, we may want to have more detailed information by some visual contents. For example, students learn and practice foreign languages by lecture materials in MP3 audio by their pocket players. The lecture contents include daily conversation, foreign language cartoon, and problem exercises. A user can see images which show the positions of the tongue in the vocal track to help precise pronunciation of certain words. The dialogue audio contents can also be sounded with pictures that describe the dialogue situation. After the dialogue conversation, some questions are presented on the screen with text overlaid on top of images.

Figure 2 – Exercising a foreign language with extended Music Player MAF contents

Photo-Music album applications

People can better enjoy music by listening the songs with seeing music album images on the display window at the same time in their multimedia devices. The music album pictures of an artist can be synchronized to MP3 song tracks. Also the lyric can be displayed in a synchronized way on the display window so that people can sing the songs by seeing the lyrics of the songs. This will definitely enhance the MP3 experience with improved functionalities.

Figure 2 – a photo-music album application

Storytelling application

The Music Player MAF finds very interesting applications in story telling with multiple JPEG images and text data with synchronization to MP3. Fro example, the story contents in Aesop's Fables can be better understood with associated pictures and text synchronized to MP3 audio tracks. This is definitely beneficial against the current Music Player MAF which does not allow for text and only allow for a single thumbnail image as metadata.

Figure 3 – A story telling application

Personal Slide Show applicationVarious single still images are used as a source in the personal slideshow application scenario. The user arranges the images on a timeline and generates the timing information for the presentation of the still images.

The images may be rescaled in size to optimize the resolution for the target output device: higher resolutions for presentations optimized for computer displays, lower resolutions optimized for mobile devices. Either no transitions between the images are used, or transition effects are applied at the presentation time.

An audio soundtrack and a text track (for sub-titles, annotations or intro text) are used to enrich the presentation. If meta-data describing the images is available, it is stored so that the relationship of the meta-data and the image is maintained.

The timed and optionally rescaled images, the meta-data, the audio soundtrack and the timed text are stored to a file.

Simple Karaoke applicationMary’s favourite song is “Blue” by Leann Rimes. She wishes to listen, as well as sing along to her favourite song. Mary uses the karaoke function (= the device is removing the original voice from the music as a post-processing step) on her mobile phone. She performs the following:

She chooses one of Leann Rimes’ slideshows with animation effects

She hears “Blue” without the voice of Leann Rimes

She sees the lyrics

She reads the lyrics and sings along to the music

Slide Show+Karaoke applicationNow, she wishes to listen, as well as sing along to her favourite song while viewing her images. Mary performs the following:

She visits the mobile service provider’s website

She chooses “Blue” from the service provider’s music selection

She uploads her vacation photos

She chooses the animation effects for the photos

She synchronizes the photos to the music using a web-based tool provided by the service provider

The service provider stores the synchronized photos as in the file together with the music track and the lyrics of the song

She downloads the file to her mobile phone

After the download process, Mary plays the MAF file on her mobile phone. She performs the following:

She listens to “Blue” by Leann Rimes

She watches her slideshow with animation effects

She sees the lyrics

She reads the lyrics and sings along to the music

2.3.2 Derived requirements

The Musical Slide Show MAF should support multiple, timed still images.

The Musical Slide Show MAF should support audio.

The Musical Slide Show MAF should support timed text data.

The Musical Slide Show MAF should support synchronization of multiple images, audio and text.

The Musical Slide Show MAF should support backward compatibility to the Music Player MAF and the Photo Player MAF under development.

The album functionality (= collection of several “Musical Slide Show MAFs” in one single file) of the Music Player MAF should be supported.

The Musical Slide Show MAF should support simple animation technology (like filtering and transition effects) with low computational complexity.


ISO Base Media and MPEG-4 File Format

JPEG ISO Standard

MPEG-7 Meta-data (aligned to Music Player MAF and Photo Player MAF)

MPEG-1/-2 Layer 3 (“mp3”) audio coding

MPEG-4 Part-17 “Streaming Text Format” for timed text

MPEG-21 File Format and DID (aligned to Music Player MAF)

MPEG-4 Part-20 “LASeR” Mini Profile


Music Player MAF

The Music Player MAF is an audio application that provides the file format for combining MP3 audio, MPEG-7 metadata, and an optional JPEG image. There is a similarity in that, both MAFs use MP3, however, the Musical Slide Show MAF contains multiple JPEG images, and the focus is on synchronized image slide show presentation with animation effects.

Photo Player MAF

The Photo Player MAF defines the specification for a file format that carries JPEG images with MPEG-7 Visual and MDS metadata. Both MAFs use multiple images, however, in case of the Musical Slide Show MAF, the images must be synchronized, and supports MP3.

Music Player MAF , 2 nd edition

The Music Player MAF, 2nd edition features the same functionalities as the Music Player MAF with an addition of content protection tools.

Professional Archival MAF

The Professional Archival MAF is an application that focuses on handling of audio files in a single archived file. The target domains of the two MAFs are inherently different.

Media Streaming MAF

The Media Streaming MAF standardizes streaming video content and protocols. The target domains of the two MAFs are inherently different.

Open Release MAF

The Open Release MAF is an application that focuses on publication and delivery of content that is governed in a “light-weight” form. The target domains of the two MAFs are inherently different.

Portable Video Player MAF

The Portable Video Player MAF is an application that focuses on local playback of prepackaged video content. The target domains of the two MAFs are inherently different.

Digital Video/Cinema MAF

The Digital Video/Cinema MAF is an application that concentrates on the distribution of high-resolution video content to professional users with emphasis on color management information. The target domains of the two MAFs are inherently different.

Video Surveillance MAF

The Video Surveillance MAF is an application that is specifically targeted towards the application domain of surveillance. There are similarities in that multiple images are involved in both MAFs, however, the target domain of surveillance has little relevance to the Musical Slide Show MAF.

2.3.5 Issues

It is preferable that the audio track and the synchronized JPEG images can alternatively be used without LASeR scene description (losing the transition effects). It should be investigated if the synchronization of audio and the JPEG images can be aligned with the time line of the LASeR scene description.

If all the JPEG images are stored in a single track, it should be investigated how the JPEG images can be referenced by the LASeR scene description.

The proponents of the Musical Slide Show MAF believe the LASeR mini profile to provide the technology to support the required functionalities for animation and scene representation. However, it is should be investigated if this profile needs to be further limited to an even simpler subset in order to accommodate low complexity requirements.

2.3.6 Supporting Companies and Organization

Information and Communications University (ICU)

LG electronics

Samsung Electronics

Fraunhofer IIS

3 MAFs under DevelopmentThis section described the MAFs under development this means the MAFs that have been under consideration and reached consensus on the value of its specification as a standard.

3.1 Protected Musical Slide Show MAFThe work of ISO/IEC 23000-4 (Musical Slide Show MAF) specifies a file format for packing up MP3 audio data, JPEG images, MPEG-7 Simple Profile metadata, timed text, and MPEG-4 LASeR script. The presentation of Musical Slide Show MAF contents is made by synchronizing all resources with animation defined by MPEG-4 LASeR script. This Musical Slide Show MAF will enrich the user’s experience in consuming different resources together. However, the current Musical Slide Show MAF does not consider any protection and governance mechanism yet which is the essential elements to deploy it into real business.

In this section, protection mechanism to enhance the current Musical Slide Show MAF is considered. The proposed protection mechanism utilized IPMP technology so that it is flexible and extensible to use any protection tools.


The resources inside the Musical Slide Show MAF can be protected as a whole with protection tool chosen by the creator. Before exercising/play backing the resources, the player needs to be able to unprotect them by using the correct protection tool. In the case the required protection tool and key to unprotect the resources are not available and cannot be retrieved, the player should give notification to the user.

Moreover, the protection can be applied selectively. For example, we might want to protect only the MP3 audio data, or combination of audio data along with the slideshow, or protecting the animation for the slideshow. There is also possibility to protect only some segments of the MP3 audio data or several JPEG images in the slide show, or even protecting some region in a JPEG image.

The following are the possible use-cases of protecting the Musical Slide Show MAF:

Protecting the whole resources: MP3 audio, JPEG images, LASeR script animation, timed text, and MPEG-7 metadata at the same time

Protecting the combination of the aforementioned resources. E.g. protecting the MP3 audio and the slideshow, or MP3 audio and the animation, or JPEG images and the animation, etc.

Protecting certain segment of the MP3 audio

Protecting one or more JPEG images

Protecting certain region of the JPEG image

3.1.2 Requirements

The requirements to support the above use-case scenarios are as the following:

The protection mechanism should be able to protect MP3 audio, JPEG images, LASeR script, timed text, and the MPEG-7 metadata one by one and/or all together.

The protection mechanism should be able to accommodate various protection tools flexibly.

The protection mechanism should be able to protect selected JPEG images only.

The protection mechanism should be able to protect certain segment of MPEG3 audio.

The protection mechanism should be able to protect certain region of the JPEG image.


The potential technologies to support implementation of this MAF are the following:

Technologies used in ISO/IEC 23000-4.

MPEG-21 DIDL

MPEG-21 IPMP Base Profile

MPEG-21 REL MAM Profile

MPEG-21 Fragment Identifier


At the current time, only Music Player MAF has protection capability in its specification. Other MAFs may have intention to define protection scheme but they are not mature yet.

3.1.4.1 Protected Music Player MAFCompared to the protected music player MAF, this under consideration MAF has similarity as the following:

Use MPEG-21 DIDL and MPEG-21 IPMP Components Base Profile to signal the resource structure and type of protections and location of protections that are applied to them.

Use MPEG-21 IPMP Components Base Profile to support flexible protection.

Use MPEG-21 REL MAM Profile for the license description.

The differences are as the following:

Both MAFs have difference file structure

o Protected Music Player MAF support two cases of file structure (track in MP4 FF and track(s) in MP21 FF) while (Protected) Musical Slide Show MAF support only MP4 FF.

o The location of protection description for both MAFs is different due to the file structure.

o Protected Music Player MAF support both default protection tool (AES-128 Counter Mode) and flexible protection while the current proposed protection mechanism for Protected Photo Player open the choice of protection tool to the content creator (flexible protection).

3.1.5 Issues

There is no major issue encountered yet.

Note that document M14175 contains a preliminary thought on how the list of technologies listed in sub clause 4.4.3 are used for this under consideration MAF.



Korean Broadcasting Systems (KBS)

LG Electronics

Support by other companies is currently under investigation.

3.2 Media Streaming Player MAFThe Media Streaming Player MAF specifies how to use specific MPEG technologies to build a full-fledged media player for the streaming of governed and ungoverned content. This standard references the data formats exchanged between a number of devices in a media streaming scenario: a Content Provider Device, a License Provider Device, an IPMP Tool Provider Device, a Domain Management Device and a Media Streaming Player. In the most general case a Media Streaming Player obtains streaming content from a Content Provider Device using a Content Access Protocol. In order to use that content, a Media Streaming Player obtains a license from a License Provider Device using a License Access Protocol. Further, to actually process the content, a Media Streaming Player may need to obtain the appropriate IPMP Tools from an IPMP Tool Provider Device using an IPMP Tool Access Protocol, as shown in the figure below.


This MAF is aimed at applications involving the distribution of governed and ungoverned media resources, metadata and related information over streaming channels to Media Streaming Players, possibly members of a domain. In a domain of Media Streaming players, content can be securely distributed once stored in a file. Typical examples of such applications are the IPTV and the Digital Broadcasting without a return channel, Pay TV, internet television, etc. A more detailed list is given in the sections below.

Public broadcasting in the digital worldCarrying over the public broadcasting service from the analogue to the digital world entails a number of adaptations that may be implemented using the proposed MS MAF standard. One way to achieve this is illustrated by the following fictitious case.

Daphnis lives in the island of Lesbos, where the local broadcaster GreenRadioTelevision (GRT) has implemented the following form of Digital Terrestrial Television (DTT)1. GRT broadcasts digital television in clear text2. As long as Daphnis only watches GRT programs, Daphnis’ receiving device

behaves like a regular DTT set top box3. When Daphnis wants to record a program, the receiving device requests an REL

license from GRTa. The license gives Daphnis the right to store and subsequently watch

and distribute the stored program in the island of Lesbosb. The license is stored as part of a Digital Item in the receiving devicec. The actual resources are encrypted and stored together with the

Digital Item.4. When Daphnis uses the stored program, the receiving device performs Daphnis’

commands in accordance to the license.

Commercial broadcasting in the digital worldThe proposed MS MAF standard can be used to address issues of a nature comparable to the case above that exist for commercial television. The following fictitious case illustrates how.

GreenTVToday (GTT) is a commercial broadcaster operating in the island of Lesbos. Each TV program broadcasted by GTT is accompanied by a Digital Item transmitted using the Digital Item Streaming technology. The Digital Item contains a license giving the citizens of the island of Lesbos the right to use the content received using their set top boxes. When Chloe, a citizen of the island of Lesbos, receives a TV program, she is immediately instructed of her rights, e.g. that she may watch and store the program and share with other inhabitants of the island of Lesbos for one week. However, she may also acquire more rights from GTT by requesting an extended license.

Internet streaming via MulticastThe same features described above for broadcasting over MPEG-2 TS can be obtained from a broadcasting system implemented using the IP Multicast technology.

Pay TVPay TV systems have been deployed in many countries mostly based on a business model whereby the set top box is proprietary because the content protection technology has been licensed by the Conditional Access System (CAS) provider to the pay TV operator. This model achieves the goal of allowing a tight control of the pay TV service subscribers but carries the high price of set top box manufacturing and distribution.

The proposed MS MAF standard can be used to support a different model, i.e. one where the set top box can still be used as a means to control the subscriber base but can tap a horizontal market of set top box manufacturers, thereby achieving lower device prices.

IPTVThe deployment of IPTV services is being considered by many and experimented by some Telco and CATV operators. The proposed MS MAF standard can be used to support the implementation of IPTV services in a way that can decrease some cost elements of the total system. One cost element can be the receiving devices but also some components of the back office (e.g. subscriber management systems, play-out centers, etc.) can be positively affected.

Internet TelevisionInternet Television is being considered by some as the mirror of today’s model of web surfing applied to video content. An Internet Television user would be able to surf the web and enjoy paid content that is protected in a way that allows its consumption by “internet set top boxes” that can be purchased from the open

market and therefore enable new forms of pay audio and video services over the web.

Storage and subsequent play of content in a domainThe ability of using content received from a plurality of sources on multiple devices belonging to a home or to its members is a feature that is expected to stimulate new forms of content consumption. The proposed MS MAF standard can be used to support a wide variety of models for domain management.

3.2.2 Requirements

The requirements for the Media Streaming MAF are preceded by the definition of the terms used within the requirements definition.

3.2.2.1 Nomenclature1. Media Streaming Content is digital content produced according to the MS

MAF standard, includinga. Resourcesb. Identifiersc. Metadatad. Licensese. IPMP informationf. IPMP Toolsg. Decryption Keysh. Digital Signature and Hash valuesi. Device Information

2. Use of Media Streaming Content includesa. Decodingb. Presentationc. Storage

3. Media Streaming Player is a device capable of using Media Streaming Content as specified by the rights holder of the content

4. Domain: a set of Devices sharing some common attributes, such as personal or group ownership that is appropriate for various business models

5. Media Streaming Protocol is a protocol used by a Media Streaming Player to exchange data with other devices, namely

a. Content Provider Device, a device capable of interacting with a Media Streaming Player to provide Media Streaming Content

b. License Provider Device, a device capable of interacting with a Media Streaming Player to provide Licenses

c. IPMP Tool Provider Device, a device capable of interacting with a Media Streaming Player to provide IPMP Tools

d. Domain Management Device, a device capable of managing various functions needed for a proper functioning of a domain, e.g.

i. Create domain ii. Renew domain

iii. Delete domain

iv. Add device to domainv. Remove device from domain

6. Media Streaming Device (MSD): any of the following devicesa. Media Streaming Playerb. Content Provider Devicec. License Provider Deviced. IPMP Tool Provider Devicee. Domain Management Device

7. Media Streaming Content Interoperability: the capability of Media Streaming Content to be used by a Media Streaming Device as specified by the MS MAF standard

8. Media Streaming Device Interoperability: the capability of Media Streaming Devices to process the data from other Media Streaming Devices as specified by the MS MAF standard

3.2.2.2 General1. The MS MAF shall standardize

a. The Media Streaming Protocolsb. The Media Streaming Content including its component

elements2. The MS MAF standard shall enable making Media Streaming Content and

Devices so that full interoperability is achieved3. The format shall be flexible and usable to implement a variety of business

models (e.g. those in some of the scenarios described in M13516)4. The standard may need to be structured in profiles targeted to application

areas/business models providing for a degree of interoperability between profiles, e.g. in case of hierarchical profiles

5. The standard shall support the use of a broad range of security technologies, including proprietary ones, without hampering interoperability

6. The standard shall support the use of content ona. A single Media Streaming Playerb. A Media Streaming Player belonging to a domain

7. Use of Media Streaming Content is governed by the associate license8. Media Streaming Content can be moved or copied between Media Streaming

Players as per license terms9. The standard shall support the inclusion of Media Streaming Device

information used fora. Identificationb. Registrationc. Acceptanced. Revocatione. Authentication

10. The standard shall enable services that employ Media Streaming Players without return channel

11. The standards shall support incorporation of external “system specifications” matched to support requirements that are specific to application domains and/or world regions

3.2.2.3 Content1. Rights

a. The standard shall support storage of Media Streaming Content for i. later play on the same Media Streaming Player

ii. transfer to another Media Streaming Playeriii. later play on another Media Streaming Player

b. The standard shall offer different users (rights holders, service providers etc.) the ability to flexibly determine how the content will be used, e.g.

i. Copying Media Streaming Contentii. Moving Media Streaming Content to another Media

Streaming Playeriii. Modifying Media Streaming Content

2. Audio and videoa. The standard shall support the most common video and audio

compression formatsb. The standard shall enable the use of non MS MAF native video and

audio compression formats3. Metadata

a. The standard shall support metadata that are most friendly to media streaming

b. The standard shall support the inclusion of additional application-specific metadata

4. Interaction protocolsa. The standard shall define the protocols for a Media Streaming Player

to obtaini. Media Streaming Content from a Content Provider Device

ii. License from a License Provider Deviceiii. DRM Tool from a DRM Tool Provider Device

b. The standard shall define the protocols for an Media Streaming Player (an Administrator) to

i. Create a domainii. Renew a domain

iii. Delete a domainc. The standard shall define the protocols for a Media Streaming Player

to i. Add itself to a domain

ii. Renew membership of itself to a domainiii. Remove itself from a domain

5. Transport protocolsa. The standard shall support the transport of Media Streaming Content

viai. File

ii. Stream

3.2.2.4 Interaction Protocols:1. The standard shall define the protocols for a Media Streaming Player to obtain

a. Content from a Content Provider Deviceb. Licenses from a License Provider Devicec. IPMP Tools from an IPMP Tool Provider Deviced. Decryption Keys from a Content Provider Device

3.2.2.5 Domains of Media Streaming Players1. The solution shall provide the means to identify Users, Devices and Domains2. The standard shall define the protocols for a Media Streaming Player (an

Administrator) to a. Create a domainb. Renew a domainc. Delete a domain

3. The standard shall define the protocols for a Media Streaming Player to a. Add itself to a domainb. Renew membership of itself to a domainc. Remove itself from a domain

4. The solution shall allow a Domain Administrator to revoke the Membership to a the Domain to a device or a user

5. The solution shall allow a Domain Administrator to revoke a Domain

3.2.2.6 Transport protocolsThe standard shall support the transport of Media Streaming Content via

a. Fileb. Stream

3.2.2.7 Device information1. MPEG-21 IPMP Components shall support expression of information that

enables applications to choose an appropriate tool implementation.The solution shall support the signaling of the IPMP Capabilities of a device that are required to select an appropriate IPMP Tool. A minimum set is the following:

a. Operating Systemi. Vendor

ii. Modeliii. Versioniv. Virtual Machine

b. CPUi. Vendor

ii. Modeliii. Sizeiv. Minimum speed

c. Memoryi. Vendor

ii. Modeliii. Minimum speed

d. Assistant Hardwarei. Smartcard

ii. HardKey

e. Networkf. RPCMechanismg. IPMP Tool Instantiation APIh. IPMP Tool Messaging API

2. The solution shall enable a Media Streaming player to request to other Media Streaming players an appropriate IPMP Tool based on the low level software and hardware characteristics of the Media Streaming player.

3.2.2.8 IPMP Tool package informationThe solution shall enable the signaling of the type of package in which the code of the IPMP Tool is delivered in the DIDL, (e.g. "application/zip"," application/java-archive", etc...)

3.2.2.9 IPMP MessagesThe solution shall support interoperability across IPMP Tools and Media Streaming players.

a. The solution shall provide interoperability in the communication between the Media Streaming player and IPMP Tools from different providers, and between two IPMP Tools

b. A minimum set of interoperable operation must cover the following scenarios:

i. Authentication between Tools an the MS player and among Tools

ii. instantiation of IPMP Toolsiii. IPMP Tool Connection and Disconnectioniv. notification of events to IPMP Tools/playerv. delivery of information to/from IPMP Tools (e.g. keys,

licenses, watermarking information, etc.)vi. User Interaction Messages

3.2.2.10 Tool Agent

1. The solution shall allow the separation between the IPMP algorithms performed by an IPMP Tool (e.g. encryption, watermarking, etc.) and the logic enabling the IPMP Tool to communicate with the other Tools or the Media Player (e.g. the messaging API).

It shall be possible to separate the IPMP algorithm's API from the (standard) IPMP Tool's API.

2. The solution shall allow the instantiation of IPMP Tools in the various control points exposed by the Media Streaming player without requiring the signaling of which IPMP Tool shall be instantiated in each control point.

3.2.3 List of technologies1. The Media Streaming MAF contains elements drawn from existing MPEG

standards, namelya. MPEG-2 and MPEG-4 IPMP-Xb. MPEG-21 DIDc. MPEG-21 DII

d. MPEG-21 IPMP Componentse. MPEG-21 RELf. MPEG-21 File Format and its reference ISO Base Media File

Formatg. MPEG-21 Binary Formath. MPEG-21 DIS

2. The Media Streaming MAF requires the development of appropriate profiles of MPEG standards suitable for the MS MAF, namely

a. MPEG-21 DIDb. MPEG-21 IPMP Components

3. The Media Streaming MAF requires the extension of existing MPEG standards for the purpose of providing the necessary Media Streaming functionalities, for instance

a. The payload of IPMP-X Messages expressed as XML, for reasons of compatibility with the rest of the MPEG-21 standards

b. The IPMP Tool Pack technology that provides additional functionalities to those already provided by the MPEG-2/-4 IPMP-X standards to handle complete IPMP systems

4. The Media Streaming MAF requires the development of new MPEG standard technology to provide the necessary Media Streaming MAF functionality, for instance Management of Domains made up of different types of Devices

3.2.4 Comparison with other MAFs Music Player MAF

The Music Player Application Format specifies the file format for the combination of MP3 files, a subset of MPEG-7 MDS metadata corresponding to ID3 metadata and JPEG pictures.

As the proposed MS MAF requires a file format and this is based on the same technologies, there is a degree of relationship. However, it is believed that the two MAFs can be considered as largely independent.

Photo player MAFThe Photo Player MAF specifies the file format for the combination of JPEG files and a subset of MPEG-7 Visual and MDS metadata.

As the proposed MS MAF requires a file format and this is based on the same technologies, there is a degree of relationship. However, it is believed that the two MAFs can be considered as largely independent.

Music Player MAF, 2nd editionThe general goal of the Music Player MAF, 2nd edition seems to be to support a level of governance information to the Music Player MAF.

As the MS MAF requires governance information there is potentially a relationship for1. The definition of the Digital Item used by the Music Player MAF, 2nd edition2. The IPMP Component Profile used by the Music Player MAF, 2nd editionHowever, it should be borne in mind that this MAF and the proposed MS MAF address very different application domains.

Musical Slide Show MAFThis Musical Slideshow MAF is expected to be a superset of the Music Player and the Photo Player MAF. Additional technologies to be added are streaming text and Laser Mini Profile.

Therefore this MAF can be considered as largely independent from the proposed MS MAF.

Portable Video Player MAFThe Portable Video Player MAF can be considered as the Video equivalent of the Music Player MAF.

As this MAF will require the selection of audio and video coding, metadata for the video program and the file format to store it, there is potentially a relationship with the proposed MS MAF. However, this MAF seems to address the area of devices that are used to play video content acquired as a file from a web site and therefore is driven by different considerations than the MS MAF.

Video Surveillance MAFThe Video Surveillance MAF is targeted to the specific application domain of surveillance.

It cannot be excluded that there will be some technologies required for this MAF that are also required for the proposed MS MAF. However, the application-specific nature of this MAF makes the relationship with the proposed MS MAF rather thin.

Open Release MAFThe Open Release MAF addresses the publication and delivery of governed but unprotected content.

The proposed MS MAF can be considered as a possible vehicle for the distribution of Open Release Content. However, at this stage the relationship appears to be rather thin.

Professional Archival MAFThe Professional Archival MAF seems to be targeted to the specific application domain of professional archival of audio and possibly video information.

There may be some technologies required for this MAF that are also required for the proposed MS MAF. However, the application-specific nature of this MAF makes the relationship with the proposed MS MAF rather thin.

Digital Video/Cinema MAFThe Digital Video/Cinema MAF addresses the high range of video distribution to professional users. One example is the use of metadata for colour management of rendering devices typically in movie theatres.

There may be some technologies required for this MAF that are also required for the proposed MS MAF. However, the application-specific nature of this MAF makes the relationship with the proposed MS MAF rather thin.

3.2.5 Issues

The Media Streaming MAF requires referencing a non-MPEG standard, for Metadata: TV Anytime Metadata (ETSI TS 102 822-5 v1.1.1)


The following list of companies supports the development of the Media Streaming MAF:

ADETTI/ISCTE

CEDEO.net

Enterprise of the Future, Inc.

ETRI

Panasonic

Peking University

SDAE

SpID

Telecom Italia

Telefónica

University of Tokyo

Victor Company of Japan, Ltd.

3.3 Professional Archival MAFWith the standardization of MPEG-4 Audio Lossless Coding (ALS) [1], SLS, and DST [2], the MPEG standard now has efficient lossless encoding tools.

For archival application, users often want to compress audio data files with the whole folder structure. Gnu Zip or WinZip are widely used for such applications, but, unfortunately, the compression performance is not high enough for raw audio data files.

Here, we propose a way to achieve the best compression performance and functionality for handling several files as one archived file. We introduce and define a new Multimedia Application Format (MAF) for archival application, which is called Professional Archival MAF.

MAFs currently under consideration are used for media or digital item based applications. However, there is a strong need for a folder structure based archiving tool that can compress in a lossless manner and archive files with folder structure information.


Digital backup and Direct Delivery of Recorded Music Project

Nashville members of the P&E Wing of The Recording Academy® formed a Delivery Specifications Committee, and the committee has created The Delivery Recommendations for Master Recordings document [3].

In the document, the committee says that they expect that direct delivery (via secure connection on the Internet, etc) will be commonplace in the future, and uploading files to very large-scale Digital Libraries will be recommended.

The preferred delivery of a recorded music project would include "flattened" continuous Broadcast Wave Files (BWF) of every multi-track and two-track element, without processing or automation. All of the audio tracks should be "flattened", which means to convert small recorded segments into a contiguous sound file padded with silence between the recorded segments, and migrated to the Broadcast Wave file format with the maximum of 1 channel per BWF file.

In addition to the BWF files, digitized traditional documentations (tracking sheets, engineer notes, set-up notes, sketches of microphone placement, recording map document, lyrics, charts, orchestral arrangements and parts, mix documentation, and any other data pertinent to the recording project) should be included in the delivery files.

Folder-structure-based archiving is suitable for the direct delivery of a recorded music project. It is natural that all files relative to the recorded music project should be kept in an appropriate folder. Those files in the folder should be compressed and archived together in a single file (see Fig. 1). This may be much safer, since it can prevent users from miss-copying a file during the delivery process. When uploading or downloading a project by FTP, a single archive file is much easier to transmit than transmitting many BWF files individually (see Fig. 2).

Fig. 1: A folder image and an archive file.

Fig. 2: An example of application of the Professional Archival MAF.

Compression and archiving intermediate data generated by sound editing tools

Many professional sound editing tools keep work files in folders (i.e. ProTools from DigiDesign [4], Nuendo from Steinberg [5]). Raw waveform data from separate tracks are stored in separate files with a specific file format, such as .wav or .aiff, and those files are kept in a folder or folders. The set of files in the folder for a song consisting of the waveform files of all tracks is called a “Project”. A project contains the project information file and individual audio track files.

During editing operations, compression and archiving tools that can compress all files in a folder with the folder structure into a single file may be very sufficient for this application. Users can keep a snap-shot of a version of edited files in an archive file, so that they can track back to the previous version of the edits if they want.

Sometimes, a target file may be a non audio data file or already encoded with a lossy compression tool, such as MP3/AAC. In that case, the file should be simply added to an archive file as is.

Preservation/Archiving

As stated in the industry input submitted as document M12688 to the 74th MPEG meeting in October 2005 [6], lossless compression of files is becoming very popular because it reduces the demand on storage media for bitwise-exact copies of digitized masters (see Fig. 3).

All files relative to the content are archived together in a single file. Sometimes, there may be tight relations among the files, but sometimes not. Folder-structure-based archiving is more suitable for archiving these kinds of files since it's too difficult to define a general way to represent relations among the files because the relations highly depend on the content itself.

Fig. 3: Another example of application of the Professional Archival MAF.

Packing file format for non-audio waveforms

In addition to audio data, MPEG-4 ALS can also efficiently compress non-audio multi-channel signals such as bio-medical (e.g. EEG: electroencephalography, MEG:

magnetoencephalography) and seismic data. This MAF would be used for packing such non-audio waveform data with some other relative information.

3.3.2 Requirements

Based on the application scenario described in the previous section, the technical requirements shall be extracted and specified as follows:

The Professional Archival MAF should compress and archive files and folder structures into a single archive file.

The Professional Archival MAF should reduce data size with lossless compression tools, i.e., when a target file contains PCM audio data, the file should be encoded with MPEG-4 ALS for lossless compression. When a target file is already encoded with a lossy compression tool, such as AAC, or when it is a non-audio data file, it should simply be added to an archive file as is. It may be possible to use generic lossless coding tools like ZIP for non-audio data such as text data.

DID shall be used to keep the original file names, attributes, and the folder structure.

It should be possible to un-archive an archived file losslessly, which means complete reconstruction of original files, including the filenames, folder structures, and attributes of those files or folders.

The Professional Archival MAF should support large files exceeding 4GB.

Uncompressed Audio file formats that should be supported are WAV, AIFF, WAVE64 [7], BWF and BWF with RF64 [8].

The Professional Archival MAF should support cross-platform operation, such as Windows, Mac, and Linux platforms.


ISO/IEC 14496-12, ISO Base Media File Format

ISO/IEC 14496-14, MP4 File Format

ISO/IEC 21000-9, MPEG-21 File Format

ISO/IEC 21000-2, MPEG-21 DID

ISO/IEC 21000-3, MPEG-21 DII

ISO/IEC 15938-5, MPEG-7

ISO/IEC 14496-3, MPEG-4 Part-3: Audio Lossless Coding (ALS)

ISO/IEC 14496-3, MPEG-4 Part-3: Lossless coding of oversampled audio (DST)

Proposed file structure for the Professional Archival MAF

Fig. 4 and Fig.5 show an overview of the encoder and the decoder for the Professional Archival MAF.

Fig. 4: An overview of the encoder for the Professional Archival MAF.

Fig. 5: An overview of the decoder for the Professional Archival MAF.

Fig. 6: An example of a proposed file structure for the Professional Archival MAF.

When a target file contains PCM audio data, the file should be encoded with MPEG-4 ALS for lossless compression. When a target file is already encoded with a lossy compression tool, such as AAC, or when it is a non-audio data file, it should simply be added to an archive file as is. In this example, the file2.wav and the file3.aiff were compressed with MPEG-4 ALS.

The file1.txt and the file4.mp4 were simply added into the mdat-box because the file1.txt is a non-audio data file and the file4.mp4 is already encoded with a lossy compression tool such as AAC.

Encoded ALS bit streams and other data files are stored in mdat-box of MPEG-21 file format. Those entries are referenced using the Item Location Box in the MPEG-21 meta-box.

An encoded ALS bit stream can be stored directly in the mdat-box without any container (See itemID=2 of the Item Information Box in the following example).

Or it is also possible to store an encoded ALS bit stream as in the MP4 file format in the mdat-box (See itemID=3 of the Item Information Box in the following example).

A file structure for the previous example in Fig.4 is as follows:ftype box: major-brand = ‘mp21’, compatible-brands = ‘mp21’meta box: (container)

handler box: hdlr = ‘mp21’

’XML box: contains the MPEG-21 DID XML with relative URLs and attributes.ributes.

“./file1.txt”;“./folder2/file2.wav”;“./folder2/file3.aiff”;“./folder2/file4.mp4”;

Item Location: item_count = 4;itemID = 1, data_reference_index = 0, extent_count = 1ference_index = 0, extent_count = 1ndex = 0, extent_count = 1 extent_count = 1ount = 1

, extent_offset = X1, extent_length = Y1, base_offset = X1;itemID = 2, data_reference_index = 0, extent_count = 1index = 0, extent_count = 1, extent_count = 1count = 1

, extent_offset = X2, extent_length = Y2, base_offset = X2;itemID = 3, data_reference_index = 0, extent_count = 1ference_index = 0, extent_count = 1ndex = 0, extent_count = 1 extent_count = 1ount = 1

, extent_offset = X3, extent_length = Y3, base_offset = X3;itemID = 4, data_reference_index = 0, extent_count = 11

, extent_offset = X4, extent_length = Y4, base_offset = X4;Item Information: entry_count = 4;

itemID = 1, item_protection_index = 0 (unused)otection_index = 0 (unused)index = 0 (unused) (unused)

, item_name = “./file1.txt”, content_type = “text/plain”, content_encoding = “” (binary);

itemID = 2, item_protection_index = 0 (unused), item_name = “./folder2/file2.wav”, content_type = “audio/x-wav”, content_encoding = “x-mp4als”(compressed with MPEG-4 ALS and stored without MP4 file format);


, item_name = “./folder2/file3.aiff”, content_type = “audio/x-aiff”, content_encoding = “audio/mp4”(compressed with MPEG-4 ALS and stored in MP4 file format);


, item_name = “./folder2/file4.mp4”, content_type = “audio/mp4”, content_encoding = “” (binary);

media data box:binary data of “file1.txt” (at file offset X1, with length Y1);ALS encoded binary data of “./folder2/file2.wav”(at file offset X2, with length Y2);ALS encoded and mp4 file formatted binary data of “./folder2/file3.aiff”

(at file offset X3, with length Y3);;

binary data of “./folder2/file4.mp4”(at file offset X4, with length Y4);


Music Player MAF

The Music Player MAF is an audio application that provides the file format for combining MP3 audio, MPEG-7 metadata, and an optional JPEG image. The target domains of the two MAFs are inherently different.

Photo Player MAF

The Photo Player MAF defines the specification for a file format that carries JPEG images with MPEG-7 Visual and MDS metadata. The target domains of the two MAFs are inherently different.


The Music Player MAF, 2nd edition features the same functionalities as the Music Player MAF with an addition of content protection tools. The target domains of the two MAFs are inherently different.

Music Slide Show MAF

This Musical Slideshow MAF builds on top of the Music Player and the Photo Player MAF and is meant as a superset of these two MAFs. The target domains of the two MAFs are inherently different.

Media Streaming MAF

The Media Streaming MAF standardizes streaming video content and protocols. The target domains of the two MAFs are inherently different.

Portable Video Player MAF

The Portable Video Player MAF is an application that focuses on local playback of prepackaged video content. The target domains of the two MAFs are inherently different.


The Digital Video/Cinema MAF is an application that concentrates on the distribution of high-resolution video content to professional users with emphasis on color management information. The target domains of the two MAFs are inherently different.


The Video Surveillance MAF is an application that is specifically targeted towards the application domain of surveillance. Professional Archival MAF may be used as the container for the Video Surveillance MAF but Professional Archival MAF does not support a mechanism needs to be in place to provide for the surveillance domain specific demands.

Open Release MAF

The Open Release MAF is an application that focuses on publication and delivery of content that is governed in a “light-weight” form. Professional Archival MAF may be used as the container for the Open Release MAF but Professional Archival MAF does not support a mechanism needs to be in place to provide for the open release specific demands.

3.3.5 Issues

Application scenarios and requirements for more general archiving tasks should be discussed.

Is it better to include a generic lossless compression tool like Zip into this MAF, or is there any appropriate standard for general-purpose compression?

3.3.6 Supporting Companies and Organization

NTT

Technical University of Berlin

Philips

NIST

LG Electronics

3.3.7 References

[1] ISO/IEC 14496-3:2005/Amd.2:2006, Audio Lossless Coding (ALS), new audio profiles and BSAC extensions, July 2005.

[2] ISO/IEC 14496-3:2005, Subpart10: Lossless coding of oversampled audio (DST), July 2006.

[3] " The Delivery Recommendations for Master Recordings," P&E Wing Delivery Recommendations 030609. 31 revision. http://www.grammy.com/PDFs/Recording_ Academy/Producers_And_Engineers/DeliveryRecs.pdf

[4] ProTools: http://www.digidesign.com

[5] Nuendo: http://www.steinberg.net

[6] M12688, "Lossless Compression – Applications & Requirements," October 2005, Nice, France.

[7] A short description of WAVE 64: http://media.vcs.de/download/content/show/04345113457

[8] The latest version of the RF64 draft specification: http://www.sr.se/utveckling/tu/bwf/

[9] ISO/IEC 14496-12, ISO Base Media File Format

[10] ISO/IEC 14496-14, MP4 File Format

[11] ISO/IEC 21000-9, MPEG-21 File Format

3.4 Open Release MAFThere are cases where Users own Rights to a piece of Content and have an interest in releasing it in such a way that other Users can freely access it. However, the users do not want to make the content public domain. Users want to release a piece of content that is governed in a “light-weight” form. This type of release is called “Open Release” and the set of technologies that support it is called Open Release MAF.

Examples of Open Releases are publicity material and teasers. One important set of major potential applications is represented by the BBC’s Creative Archive project.

Open Release is clearly contiguous to other types of commercial release method. While it is understood by MPEG that other MPEG-21 technologies can support these use cases, there is an objectively much higher threshold to overcome to achieve the goal of market place acceptance of this extended set of MPEG-21 technologies, not least because a practical solution is likely to require other technologies that are not part of the MPEG-21 technologies.

By starting from Open Release MPEG would facilitate a first deployment of a limited but still significant set of MPEG-21 technologies on top of which other more sophisticated use cases could be build by simply adding more “heavy-weight” technologies, whether from MPEG-21 or not.


3.4.1.1 Release of a creative workAn author called Leonardo has just finished preparing a PowerPoint presentation. This was intended to be used at a conference that he can no longer attend. So he makes a video of himself while he makes the presentation.

As the conference has an international exposure and he would like to have his presentation accessible by Users in different countries, Leonardo creates:

1) A set of human-readable Creative Commons-like Rights Expressions for a selected range of jurisdictions (of course including the jurisdiction of the place where the conference is held).

2) The corresponding machine-readable Rights Expressions written in the appropriate languages

Leonardo then performs the following steps:

He creates a Digital Item containing

The audio-video file

The PowerPoint file

The human-readable License

The machine-readable License

He packages all contents, licenses and metadata into an Open Release file

Leonardo knows that the Released Digital Item will not deter people from doing what he does not what them to do. However, if he or one of his robots will find Resources taken from the Digital Item on some web site he will have the option of suing the infringers. Also, if his presentation will become a “best seller”, he will have the option to License it at other terms to other Users. These other Users may well decide to Release the same Content, possibly enriched with other elements, in a protected form.

3.4.1.2 Acceptance of the license

When the author creates a MAF with protected content, he can choose what the consumer has to do to get access to the data. Before the user can extract a content out of a Open Release MAF-Container, he normally has to accept the license of the container. Some possibilities for this acknowledgement are e.g. pressing an “Accept” button to some predefined text, sending automatically an email message or accessing a defined website. These mechanisms provide the possibility for the author to get some feedback about the usage of his content. For example the author can see how many people accessed his content or who wants to publish derived works from his content.

3.4.1.3 License ManagementLicense Management today is based on complex software to handle all the different kinds of licenses. With our proposal we want to simplify this process for the content author and the consumer.

License Browser

Imagine you have a large repository with different kinds of licensed files. These files can be of any kind, like images, videos, presentations or documents. In general every file in such a repository has its own license and each of these licenses has specific properties, which allow or restrict the user in different kind of ways. Such a repository can be used in a university, where all exams, theses,

articles, lecture notes and presentations are stored. It can also be in a company for example in an editorial department, where the people need images or videos together with the information how they are allowed to use the specific content.

There exists no simple mechanism to date, which can read all licenses automatically and provide an overview over the available files with their respective licenses. One possible solution is to create a database which organizes the files and associates them with their properties. But this has to be done manually, which can be a very cost-intensive task, because of complicated expression in the licenses.

With the Open Release MAF we try to automate this process by binding the content to a machine-readable license. Such a program can easily read out all attributes of the licenses and save this information in a central storage. From this storage an overview over the whole repository can be generated easily and the user can find the file he needs. The remarkable point is that with such an application, it is also possible to find files, which fulfil specific criteria, i.e. someone wants to find a specific content which can be used for commercial releases or a presentation which can be derived.

The Open Release MAF provides facilities for an automatic license management, which is only possible due to the machine readable licenses.

Automatic generation of new Licenses

Another use case of the Open Release MAF is in software development. Many applications today are based on kinds of different software and contents from third parties. The software can be libraries or plug-ins which are used to accelerate the development process. Even the development environment itself consists of different components and plug-ins from different organisations. Each component may be published under a different license and can constrain the produced software to be used in a restrictive way. The situation gets even more complicated, when we think of the huge number of icons, images or libraries, which modern applications use to improve the performance of the programmer. Every component may have its own license, which has to be respected. For the programmer it is almost impossible to have an overview over all licenses.

In such a case a license management system would be useful, in that it can automatically process the licenses. As a result, a new license can be generated for the whole program, based on all licenses of the used software components and contents. For example all contributing authors would be mentioned automatically.

Additionally the program can advise the user in what way he is allowed to use the content. For example if the user intends to derive a content, but according to the license he isn’t allowed to do that, the program can inform the user about his insincere action.

This can promote the usage of royalty-free content and is corresponding to the basic idea of Creative Commons, where contents can be published in a free way, to be reused by others.

3.4.1.4 Publishing public funded research resultsAs mentioned before, the Open Release MAF would also be greatly appreciated by the academic organizations. The German ministry for example has big interests in publishing research results openly, that were financed by public funds. For that purpose, the ministry started its own project which is called “OpenAccess”, that has the task to provide a platform were the results can be described and offered over the internet. Although the results are publicly available, generally the author wants to retain some specific rights to himself, i.e. the attribution to the author. So there is a need, that results can be published in a standardized way, where different license patterns can be applied.

3.4.1.5 E-Learning Universities and other institution in the tertiary education sector provide documents to the students for teaching purposes. These documents are material like lecture notes and exercises, which the students need during their studies. Open Release gives the possibility for an academic institution to publicise these documents with attached licenses, in a standardized manner.

The Open Release MAF would provide the functionality to package all kinds of materials together in one file and bind it with license information and metadata. The use of Creative Commons Licenses-like licenses provides a variety of licensing conditions to meet the needs of different applications.

3.4.1.6 License SchemesCreative Commons is the first popular license scheme that comes up at the moment. In future other important license schemes can be developed, that have more restrictive properties. It should be possible to incorporate these licenses in the REL at a later date. The REL Framework offers a good basis for this necessity.

3.4.1.7 Feedback by Event ReportingIn this context we can also take a step forward and think of a kind of feedback mechanism for the author. This mechanism provides the author with information about when, who or how often his content has been viewed. Also a statistical analysis could be interesting for the content author.

An Open Release File contains an Event Report Request, which is processed when a content is extracted. The generated Event Report contains several information in a machine readable format, for example at what time or by whom the file was opened. This information will be transmitted back to the author, who can extract the relevant information and process it.

3.4.2 Requirements

File Format

o Open Release MAF is to be derived from the MPEG-21 File Format. Within the file, the following features are to be supported:

Packaging of arbitrary binary files as Digital Items (DI) within the Open Release file, each with an unique associated identifier

Storing of basic information for each DI such as filename (in UTF-8), timestamp

o One or more metadata description can be attached to any DI

o One or more REL-licenses can be attached to any DI, using MPEG-21 Open Release Content (ORC) REL Profile

o One or more Event Report Request (ER-R) can be attached to any DI

Metadata

o Use of MPEG-21 DID to attach licenses

o Use of MPEG-7 to embed Metadata relevant to the content.

o Allow for hierarchical organization of Digital Items within the Open Release file

o Use of DID to allow Metadata, ER and Licenses to be attached to individual or group of Digital Items

Identification

o Every Digital Item needs to be uniquely identified.

o It should be possible to link Digital Items to related items, so as to show the inheritance relation between an item and its adapted version.

License Representation

o All rights and conditions as defined in the Open Release Content (ORC) REL profile are to be supported

o An appropriate human-readable message is to be prompted to the content consumer, when the content is extracted from the Open Release file

Event Reporting

o The Event Report should be sent immediately, when the Extraction operation is carried out on the targeted DI

o The delivery method should include embedding the Event Report in the body of an Email, and by the “POST” method using HTTP and HTTPS.

o Relevant information (such as personal information like name, company name and email), should be reported in the Event Report


To support this MAF the following set of MPEG-21 technologies are needed:

ISO/IEC 21000-2, MPEG-21, Part 2, Digital Item Declaration

ISO/IEC 21000-3, MPEG-21, Part 3, Digital Item Identification

ISO/IEC 21000-3 Amd 1, MPEG-21, Part 3 Amendment 1, Relates identifier types

ISO/IEC 21000-5 Amd 3, MPEG-21, Part 5 Amendment 3, Open Release Content profile

ISO/IEC 21000-9, MPEG-21, Part 9, File Format

ISO/IEC 21000-15, MPEG-21, Part 15, Event Reporting

ISO/IEC15938-5, MPEG-7, Part 5, Multimedia Description Schemes


Open Release is purely a data packaging format, with no support for any multimedia codec. Thus, there is a clear difference compared to Music Player MAF, Video Player MAF, Portable Video Player MAF, Media Streaming MAF, Digital Media Broadcast MAF, Video Surveillance MAF, Musical Slideshow MAF, Professional Archival MAF, etc, because there is no codec for audio, video or other multimedia content in Open Release MAF.

3.4.5 Issues

The following issues have been identified that are key to the successful deployment of the Open Release MAF. It is realized that some of them may not be an issue that MPEG can deal with:

License Identification and Digital Item Identification agencies – To enable Users to get Identifiers agencies must be established. It is realized that there is a number of legal issues that must be resolved to shield agencies from the

responsibilities arising from them Assigning Identifiers to Content for which the Use Requesting the Identifiers may not have Rights.

Cost of Identifiers – The success of the Open Release MAF depends on making available at (virtually) no cost the issuance of MAF Identifiers

Cost of technologies – There should be no cost involved in the use of the IPR required to implement the Open Release MAF.

It is clear that the Open Release MAF has the purpose to “create a market”. All efforts should be made by all affected parties to make this possible by creatively resolving the three issues identified above.


Technische Universität München (TUM)

Digital Media Project

Universitat Pompeu Fabra – Universitat Politècnica de Catalunya

DRM Inside

ETRI

ContentGuard

3.4.7 References

[1] ISO/IEC JTC1/SC29/WG11/MPEG2006/M13118, Towards the interoperability between MPEG-21 REL and Creative Commons licenses. Montreux, April 2006.

3.5 Portable Video Player MAF

Recently, more and more portable music players (mp3 players) are extended to multimedia players capable of displaying images and videos, because the processing power and displays are now available for this kind of devices.

Unfortunately, there is no standard format for mobile, mid-resolution video like there is the DVD format for standard definition. So, devices have to support a wide variety of audio coding (e.g. MP3, AAC), video coding (e.g. MPEG-1, MPEG-4, AVC) and file formats (e.g. AVI, MP4), because a different combination of audio and video codecs and file formats is used for content. But there is still no guarantee that every device can playback all available kinds of content. This uncertainty and in general the lack of interoperability prohibits the market.

So both, industry and users could greatly benefit from a portable video player MAF which would enable interoperability of these mobile multimedia devices.

This section describes application scenarios and derived requirements for a “Portable Video Player MAF”.

3.5.1 Application Scenarios

Portable video players (PVP) today have the ability to play back good quality video on 3-5” size displays at the usual resolutions of 320x240 or 480x272 pixels. Flash memory or hard disk storage can hold many hours of video. Also small-size pre-recorded media like mini-DVD/UMD (1.8 GB capacity) are used in portable devices. As an example, 512MB of total movie file size correspond to 134 min at a bit rate of 500 kbps.

Three different scenarios apply:

Playback of content the users generated on their own for the PVP (downsize and encode), e.g. personal recordings or home video

Playback of content sold on disk media (mini-DVD), comparable to the DVD business

Playback of content sold over the internet, comparable to the online music store business.

In order to enable business of selling content for the PVP devices not only interoperability at the codec level is required but also interoperable digital rights management to protect the rights of the content owners.

Premium content will support advanced features like multiple audio tracks in different languages and subtitles (as known by DVDs). Metadata like the film title or the names of the actors should be included. The movie poster can be included as still image.

Simple past TV program “download & play” applicationJohn’s favourite television show is “Friends.” He decides to download last season’s episodes from the website (owned by the television network) and store it in his portable media player so that he can watch it during his daily commute to work in the subway. John performs the following:

He logs on to the website owned by the television network

He chooses the episodes of “Friends” that he wants to download

He pays for his selections

He downloads the files to his computer

He moves the files to his portable media player for later viewing

On his way to work the next morning, John takes out his portable media player and opens the file “friends01_season8.mp4.” Once the file loads, he sees a visually enhanced, interactive menu screen. He performs the following:

He browses the menu options (“Main feature” and “Extra features”)

He chooses the “Extra features” option and presses the “play” button

He sees another sub-menu screen that has links to “previews” and “behind-the-scene” clips

He presses the “cancel” button and returns to the main menu screen

He chooses the “Main feature” option and presses the “play” button

He begins to watch the episode

Simple playback application utilizing “Usage History Description”John has an appointment with his clients at their office, and he has to take the subway, which is the most reliable means of transportation in the city. He has to make two transfers in order to get to his clients’ office. John takes out his portable media player once again, and opens another file, “friends02_season8.mp4”. He performs the following:

He chooses the “Main feature” option and presses the “play” button

John arrives at a station where he has to make his first transfer. He presses the “stop” button, and he exits the program.

The program saves John’s usage history description onto a separate file. He transfers onto another subway, and then reloads the file “friends02_season8.mp4” on his PMP. The system automatically loads the usage history description.

He chooses the “Continue” option from the menu screen and presses the “play” button

He begins to watch the episode from where he left off previously

Simple playback application utilizing “Hierarchical Summary Description”Susan has missed several episodes of her favourite television newsmagazine program “60 Minutes” while she was away on a business trip. She decides to log on to the TV network’s website and download the past episodes and play them on her portable media player during her commute to work (by using the subway). Susan performs the following:

She logs on to the website owned by the television network.

She chooses the episodes of “60 minutes” that she wants to download.

She pays for her selections.

She downloads the files to her computer.

She moves the files to her portable media player for later viewing.

On her way to work the next day, Susan loads the file “60min_050510.mp4” on her PMP. Among many of the options provided in the menu screen, she chooses the “Summary Segments” option, and presses the “play” button. She notices a sub-menu screen that displays three key frame images with key words/key phrases which represent the three stories that are presented in the episode of “60 minutes” that she has chosen. The key phrases are “Climate change”, “X-treme sports”, and “Violence in television”.

She chooses “Climate change” from the menu and presses the “play” button. She browses a series of key frames related to the “Climate change” story. The

key frames are labelled as “Global warming”, “Water pollution”, and “Rain forest”.

She chooses one of the key frames labelled “Global warming” and presses the “play” button.

She begins to watch a clip on global warming instead of watching the whole story on “Climate change.”

Simple mobile broadcast “save & replay” applicationJohn is a high school student who frequently watches educational programs pertaining to the 10th grade curriculum on television. He used to record them on VHS tapes and watch them again whenever he needed to. But, now that he has a mobile phone capable of receiving DMB signal, he chose his mobile phone over his television set. He performs the following:

John selects the DMB function on his mobile phone He chooses the EBS (Educational Broadcasting System) channel He begins watching a program on 10th grade “Advanced Mathematics” He presses the button that corresponds to the “SAVE” menu on his phone He makes notes using the memo pad function on his phone

After 20 minutes, the program ends, and John performs the following: He presses the button that corresponds to the “END” menu on his phone

The media content is saved as a Portable Video Player MAF file along with the metadata that contains his notes for later viewing. As long as it is saved as a file, John can always watch them later, on any multimedia device that supports this format, and with the metadata, it is easier to browse when there are lots of files.

3.5.2 Derived requirements

3.5.2.1 File Format:

The Portable Video Player MAF should use a file format for the following purposes:

Local playback on devices Web downloads Content storage

Distribution

3.5.2.2 Audio and Video:

The Portable Video Player MAF should support commonly available audio and video coding schemes.

The Portable Video Player MAF should support multiple video tracks for:Extra materials (e.g. movie previews)

The Portable Video Player MAF should support multiple audio tracks for:Multilanguage support (audio dubbing)

3.5.2.3 Textual presentation:

The Portable Video Player MAF should support timed text data.

The Portable Video Player MAF should support multiple text tracks for:Multilanguage support (subtitles)

Textual presentation should be aligned with Musical Slide Show MAF

3.5.2.4 Metadata:

The Portable Video Player MAF should support content creation information description, including:

- Title (title of the movie)- Artist (creator who took the clip/movie)- Clip description (general description of the clip/movie)- User comment (user annotation/text)- File date/time (date/time in which the clip was taken)

The Portable Video Player MAF should support usage history description for:- Profiling user actions on devices

The Portable Video Player MAF should support hierarchical summary description for:

- Video summary- Organizing video clips into chapters

3.5.2.5 Menu scheme

The Portable Video Player MAF should support animated graphics for:- Actual implementation of the menu screen

The Portable Video Player MAF should support still image data for:

- Preview images (to be used with the menu screen)

3.5.2.6 Protection:

The DRM components of the Portable Video Player MAF should be aligned with the “Music Player MAF, 2nd edition.”


3.5.3.1 File format:ISO Base Media/MPEG-4/AVC File Format

3.5.3.2 Audio and Video: MPEG-1/-2 Layer-3 MPEG-4 HE-AAC MPEG-4 BSAC MPEG-4 AVC

3.5.3.3 Textual presentation:MPEG-4 Streaming Text Format

3.5.3.4 Meta data: MPEG-7 Multimedia description scheme, Creation DS MPEG-7 Multimedia description scheme, UsageHistory DS MPEG-7 Multimedia description scheme, HierarchicalSummary DS

3.5.3.5 Menu scheme: JPEG ISO Standard for still images MPEG-4 LASeR

3.5.3.6 Protection:The protection technologies involved in the Portable Video Player MAF should be aligned with the “Music Player MAF, 2nd edition”.


The following MAFs are inherently different from the Portable Video Player MAF in terms of the main technologies that are used to define the characteristics of each MAF:

Music Player MAF

The Music Player MAF is an audio application that provides the file format for combining MP3 audio, MPEG-7 metadata, and an optional JPEG image.

Photo Player MAF

The Photo Player MAF defines the specification for a file format that carries JPEG images with MPEG-7 Visual and MDS metadata.


The Music Player MAF, 2nd edition features the same functionalities as the Music Player MAF with an addition of content protection tools.

Musical Slide Show MAF

The Musical Slide Show MAF is a file format that carries MP3 audio, multiple JPEG images, text, and LASeR for animation.

Professional Archival MAF

The Professional Archival MAF is an application that focuses on handling of audio files in a single archived file.

Open Release MAF

The Open Release MAF is an application that focuses on publication and delivery of content that is governed in a “light-weight” form.

The following MAFs are video applications that involve similar technologies, but are different in terms of target application domain and devices:

Media Streaming MAF

The Media Streaming MAF standardizes streaming content and protocols.


The Video Surveillance MAF is an application that is specifically targeted towards the application domain of surveillance.


The Digital Video/Cinema MAF is an application that concentrates on the distribution of high-resolution video content to professional users with emphasis on color management information.

3.5.5 Issues

It should be investigated if adding animated graphic technologies like MPEG-4 Part-20 (LASER) to this MAF would

add a big complexity burden to this MAF or not

help to broaden the application scenarios if the additional complexity is no burden.


Fraunhofer -IIS

LG Electronics

MediaLive

Samsung

Streamezzo

3.6 Multimedia Application Format for Digital Multimedia Broadcasting


Digital Multimedia Broadcasting (DMB) is the first global mobile TV service based on a digital radio transmission system. DMB provides people with crystal-clear video, theatre-quality audio, and other data services on the move via in-vehicle terminals or hand-held gadgets like mobile phones so that it makes possible the information acquisition and consumption anywhere.

Due to the availability of multiple DMB broadcasting services, the DMB users have many mobile TV programs available on their terminals and they may want to watch their preferred DMB program contents. However, it is not easy for users to consume the DMB programs at their convenient time. Therefore, it is required that the DMB program contents could be stored and play backed at anytime. The stored DMB contents are also expected to be exchanged between different DMB terminals. Thus, a

standardized DMB file format needs to be specified to guarantee the interoperability across the DMB terminals from different vendors.

DMB Multimedia Application Format (MAF) specify how to combine the variety of DMB contents with associated information for a presentation in a well-defined format that facilitates interchange, management, editing, and presentation of the DMB contents.

Internet

InternetIP Network

(wired/wireless,fixed/mobile)

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

DMB-HE

IP-HE

InternetDMB Network

(terrestrial/satellite)

Contents,Metadata,Data,License

DMB-MAF Terminals

Interchange

IP-net.DMB DataServer InternetInternet

InternetInternetIP Network

(wired/wireless,fixed/mobile)

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

<XML>

</XML>

DMB-HE

IP-HE

InternetInternetDMB Network

(terrestrial/satellite)

Contents,Metadata,Data,License

DMB-MAF Terminals

Interchange

IP-net.DMB DataServer

Figure 1: A DMB Service Architecture

3.6.1.1 Storage of Mobile Broadcasting ContentsMajor application area of DMB MAF is for storage of mobile broadcasting contents. In the DMB services, DMB-HE (Head End) broadcasts the digital contents through satellite and terrestrial DMB network. A user can watch the live contents though a DMB player and can store them in a unified form (DMB MAF file) for a next-time usage. He can also search and select some scheduled contents using EPG metadata and make a reservation for recording on a local or remote storage.

In addition to the main audio-visual contents, various contents can be acquired through DMB data services such as BWS (broadcasting website), slide show, and TTI (traffic and travel information), or can be signaled by metadata describing the locator (e.g. URI (uniform resource identifier)) of the contents. A user can not only consume the additional contents, he can also select and store them in a packaged form (with or without the main contents) for a next-time usage.

These stored DMB MAF contents can be managed and re-accessed by a DMB-MAF browser which can display the contained item list and description for each DMB MAF content. A user can play, edit, or export the DMB MAF contents on a file basis, an item basis, or a stream segment basis.

In DMB services, the multimedia contents can be governed or protected using some protected or governed mechanisms such as IPMP. The stored DMB MAF content shall keep the governance with the originally transferred one.

3.6.1.2 IP Media ServicesDMB MAF contents can also be stored to and/or acquired from a network storage such as a PDR (personal digital recorder), an NDR (network digital recorder), or a DMB Portal. For example, a user can search and select some DMB contents on a DMB Portal, record them on network storage, and watches them through Internet streaming or just download them for next-time usage.

Not only on the DMB-receivable terminals, DMB MAF can be created and played on DMB terminals without RF-module through the IP media services and/or removable storage media.

3.6.1.3 Interchange between TerminalsDMB MAF contents can be stored to and interchanged through a remote storage or a removable storage media. For example, a user can transfer and consume DMB MAF contents between the DMB MAF terminals through a CD, an USB drive, or a memory card. Partial and whole items contained in a DMB MAF content can be exported. Proper right management and protection scheme should be involved in this case.

3.6.1.4 User-Creative DMB contentsIf they are interpretable on DMB terminals, a user can freely add his own contents or data to an existing DMB MAF content. For example, he can add an image, verbal or textual comments, secondary audio or video, or graphical annotation, and can make some of them spatially and temporally synchronized with the existing contents.

A user can also add his usage history and bookmark for next-time usage. For example, if information describing which contents/items/segments are already watched is stored with the contents, he can start to consume the contents from the point of last consumption at any time. More over, if bookmark information is stored with the contents, he can selectively consume the contents by just navigating his favorite bookmarked items or segments. The marked items or segments over multiple DMB MAF contents can be gathered and reformatted to a new MAF and can be shared to other users. For example, sports highlight content can be easily generated by this mechanism.

3.6.1.5 Metadata Applications with DMB MAF Since there can be a large amount of DMB MAF contents on the Internet, search and select process may need to be personalized by some filtering or recommendation services. This kind of services requires the DMB MAF to include content description metadata and targeting information.

When the DMB video channel bandwidth is insufficient, EPG or ECG metadata should be transferred to each DMB terminals in alternative ways, e.g. through a DMB

data channel or IP network. In this case, a unified and interoperable file format that can carry EPG or ECG information should be supported.

3.6.2 Requirements

3.6.2.1 General RequirementsThe DMB MAF specification shall support:

The functionalities and components of T-DMB, S-DMB, and IP based DMB services.

Protection and governance of DMB MAF contents for creation, delivery, and consumption.

Interoperability among DMB MAF compliant services.

The DMB MAF compliant terminals shall support the followings:

DMB MAF Player is a device or terminal capable of using DMB MAF Contents as specified by the rights holder of the content. If the player which has functionality to transfer internal digital contents onto other DMB players, the protection information should be persistently associated with the transferred protected contents and trustfully applied to the target players.

The DMB MAF terminal should provide the functionality of storing DMB contents in DMB MAF format.

Basic and enhanced functionalities: the basic functionality includes the main A/V data (IOD/OD, BIFS, H.264/AVC, MPEG-4 ER-BSAC, MPEG-2 AAC+, MPEG-4 HE-AAC); and the enhanced functionality may encompass the IPMP, metadata, and user data, etc.

3.6.2.2 File Format RequirementsFor storing and transferring the DMB MAF contents, DMB MAF shall support the following functionalities:

The file format shall provide unified storage and interchange of audio-visual data and metadata.

o The file format shall support the media data such as text, image, audio, video, and metadata. The media data can be obtained from DMB broadcast services or can be retrieved and downloaded through communication networks.

o The file format shall support synchronization of multiple media.

o The file format shall support editing functionality of the included contents on item basis, or stream segment basis.

o The file format shall support access to the whole or part of the contained data.

o The file format shall allow for multiple DMB programs in a single DMB MAF file.

The file format shall provide the protection for audio-visual data and metadata

o The file format shall provide the method to carry encrypted/governed resources (audio, video, metadata, digital item, and etc).

The file format shall support random access to the media data.

The file format shall allow for easy provisions for streaming and media adaptation.

The file format shall support the inclusion of private contents such as an image, verbal or textual comments, secondary audio or video, or graphical annotation, as long as they can be processed on DMB terminals.

The file format should provide metadata for fast search and preview without parsing all the details, e.g., title, keyword, genre, grade, simple descriptions for embedded digital items, representative image.

The file format should allow for easy access to the information about the playability of the file or individual media data, codec types, media data types, versions, etc.

The file format shall allow for DMB MAF player’s operations such as Play, Store, Edit, Copy, and Adapt.

3.6.2.3 Requirements for MetadataThe DMB MAF shall support the following functionalities with regard to metadata:

Identification and location resolution of contents

Description of video and audio resources and usage information:

o Content description such as Title, Grade, Genre, Recorded time, Station, Broadcast schedule, URL, synopsis, etc.

o Usage history and user profile

o Segment metadata

o ECG (Electronic Content Guide) and EPG (Electronic Program Guide)

Description of additional DMB data services

o MOT (multimedia object transfer) slide show, BWS (broadcasting website), TTI (traffic and travel information), etc.

Description of related contents, consumption condition, and targeting information.

3.6.2.4 Requirements for Intellectual Property Management and Protection (IPMP)

The DMB MAF shall support the following functionalities with regard to IPMP:

Protection of audio, video and metadata

o Carriage of protected resources

o Detection of protection and/or governance

o Granularity of IPMP signaling such as multi-level protection and partial/ whole protection

Governed use of protected resource

o Various usage rules over governed resources such as valid period, maximum usage count, etc.

o Usage control over protected/governed resources

The standard methods for authentication of users/devices/domains/IPMP tools

Carriage of protection information such as Rights Expression and IPMP Information

Accessing protection information with secured ways.

Renew ability of IPMP capabilities and tools

o Update or upgrade of protection mechanism.

Management of copyright of DMB MAF Contents

o License association with DMB MAF

License within DMB MAF/License referenced within DMB MAF/License service referenced within DMB MAF

o License access and retrieval

Location from which the applicable license may be retrieved

method or process for acquiring the applicable license

o Supporting the standard handling process for digital contents without licence

IPMP Tools and capability management

Flexibility and extensibility of IPMP Tools

Management of private information such as usage history, user preference data, etc.


The DMB MAF will be based on the following technologies:

ISO Base Media File Format DMB Video: MPEG-4 AVC Baseline Profile Level 1.3 DMB Audio: MPEG-2 AAC+, MPEG-4 ER-BSAC MPEG-4 HE-AAC

System: IOD/OD, BIFS, MPEG-4 File format, AVC File format

DMB Data Services: BWS, MOT slide show, TTI

Content description and user metadata: TV-Anytime

Protection and Governance information: MPEG-21 IPMP, REL, etc.

Further details of the specification are currently in progress.


Music slide show MAF, Photo Player MAF, Music Player MAF, Open Release MAF, and Professional Archival MAF show different target applications compared with MAF for DMB, that is, those are not for video applications. Therefore, it is reasonable to inspect Portable Video Player MAF, Video Surveillance MAF, Digital Video/Cinema MAF, and Media Streaming MAF. Comparison with Media Streaming MAF and Portable Video Player MAF

MS MAF PVP MAF MAF for DMB

Target market

Application scenario address on DTV Settop, IPTV Settop, etc.(not specifically targeted)

-Mini-DVD-Portal service

-DMB Application Terminals only.

Application scenario

Wide application scenario related to governance.-Public broadcasting,-Commercial broadcasting,-Internet streaming-Pay TV,

A possible standard format for portable applications that utilize mid-resolution video:-mini-DVD/UMD-portable video player (PMP)-DMB recording

DMB specific services:-Storage of DMB contents only with associated metadata -IP Media Services with DMB contents-Exchange of DMB contents

-IPTV,-Internet Television-Storage and subsequent play of content in a domain

(main video and audios only, no DMB data contents, not MPEG-4 IOD/OD/BIFS)

accros DMB MAF Terminals -User-Creative DMB contents-Metadata Applications with DMB MAF

File format MPEG-21 File Format(not specified in detail)

-ISO Base Media / MPEG-4 / AVC File Format-MPEG-21 File Format-Only specified with ftyp, moov, meta, mdat boxes -Use xml box to contain MPEG-4 LASeR-Content information is carried in xml box inside trak box

Derived MPEG-4 File Format with extension and restrictions(extend AVC File Format)-Use meta box to carry MPEG-21 IPMP & DID- Content information is carried in MPEG-21 DID

Video resources

-MPEG-2 Video Main Profile -MPEG-4 Visual Advanced Simple Profile-MPEG-4 Advanced Video Coding Main Profile

-MPEG-4 AVC Baseline Profile, Level 1.2 for a resolution of 320x240 (4:3) -MPEG-4 AVC Baseline Profile, Level 2.1 for a resolution of 480x272 (16:9) -MPEG-4 Part2 Visual

-MPEG-4 AVC Baseline profile level 1.3 only

Audio resource

-MPEG-1 Audio Layer-2-MPEG-4 Advanced Audio Coding-MPEG-4 High Efficiency-AAC

-MPEG-1/-2 Layer-3-MPEG-4 AAC/AAC+/HE-AAC/BSAC Audio

-MPEG-2 AAC+, MPEG-4 ER-BSAC MPEG-4 HE-AAC

Systems support

Not defined Use MPEG-4 LASeR to represent menu to select content (video, audio, text)

MPEG-4 OD/IOD/BIFS are used for scene descriptions, interactions, and synchronizations of multiple objects

Data service resources

Not defined Not defined BWS, TTI, MOT Slideshow, Java midlet

Metadata - MPEG-21 DID- TV-Antime Phase 1 metadata (a limited set of elements to include only the Copyright, Classification and ProgramDescription elements)

-MPEG-7 MDS1) Creation DS2) UsageHistory DS3) HierarchicalSummary DS

-MPEG-21 DID to organize DMB contents, metadata, and IPMP- TV-Anytime Phase 1 Phase 2 Metadata (Part 3)

Streaming framework

MPEG-21 DIS not defined not defined

IPMP -MPEG-21 REL DAC Profile-MPEG-21 IPMP Componenents Media Streaming Profile -MPEG-21 IPMP Message Extentions-Media Streaming Technologies (access protocol, domain

-Protection technologies to be aligned with the Music Player MAF, 2nd edition

-MPEG-21 REL DAC Profile-MPEG-21 IPMP Components Media Streaming Profile

management protocol)

Comparison with Video Surveillance MAF The purpose of Video Surveillance MAF is to make standard of the CCTV

(Closed Circuit TV), and provide compatibility between surveillance videos from different CCTV. Consequently, the application domain of Surveillance MAF is different from that of MAF for DMB.

Comparison with Digital Video/Cinema MAF Digital Video/Cinema MAF proposed for keeping color information which

can be changed by circumstance with metadata. With that, a user can consume digital video with color information which is created when digital video is created in the studio. MAF for DMB and Digital Video/Cinema MAF have independent application domains.

3.6.5 Issues

MPEG experts need to identify any issues which are essential to facilitate the application scenario but which may lie outside of MPEG’s jurisdiction.


Broadcasters

o KBS (Korea Broadcasting System)

o MBC (Munhwa Broadcasting Company)

o SBS (Seoul Broadcasting System)

Telcos

o KT (Korea Telecom)

o LG TeleCom

Solution & Terminal Vendors

o Samsung Electronics

o LG Electronics

o Pixtree

o onTimetek

o DRM Inside

o ContentGaurd

o KAI MEDIA

o OnionTech

Institute & Universities

o ETRI (Electronics and Telecommunications Research Institute)

o UOS (University of Seoul)

o ICU (Information and Communications University)

3.7 Video Surveillance MAFIn this section, video surveillance is introduced as an application domain that will benefit from a MAF that introduces a small number of key improvements to interoperability in the CCTV industry.

The abbreviation CCTV stands for Closed Circuit Television, which indicates that standards are not considered to be essential since this type of TV takes place in a hitherto closed environment with no need for interoperability with systems offered by other companies. On the other hand the video surveillance industry is subject to a changing environment, and MPEG standards can offer interoperability between different systems, as well as to have access to mature and cost effective multimedia components to be integrated.

The proposed Video Surveillance (VS) MAF is not intended to directly accommodate the legacy content and components. Rather, it is intended to provide a lightweight and useful wrapper to the video content from the MPEG technologies that are the best fit for purpose at the date of expected finalisation. However, the description of any relation existing between VS MAF content and other video content will need to be addressed. Currently, JPEG and MPEG-4 Part-2 are arguably the most commonly deployed digital video standards. However, in due course it is expected that AVC will be more commonly deployed, not least because it is understood to be the most ‘fit-for-purpose’ of the available video technologies.

The CCTV application domain undoubtedly has many requirements in the areas of auditing, data integrity and protection. However, this is not included in the VS MAF Application Scenario. Indeed, it is expected that a MAF that did address these requirements would bear a close and hierarchical relationship with the proposed VS MAF.

A further design requirement for the proposed MAF is that it has a small group of key features that will provide tangible benefit to the manufacturer, installer or user. Even

though the MPEG standards can provide many more features of possible benefit, there are several reasons why this design is preferred, including the need to constrain the scope of the MAF to sizeable proportions and the idiosyncrasies of the CCTV market.


In many countries, notably the USA, U.K. and other European and East Asian countries, video surveillance in public places is increasingly used for crime prevention and for the detection of similar incidents. Examples for public places being observed are streets, squares, railway and subway stations.

More and more cameras are being in place forming huge surveillance systems. Within those systems required basic functionalities are identical. The video stream needs to be transmitted from the site to an appropriate place where it will be archived. The video might be looked at by a number of persons and in case of an incident it could be exported to the appropriate authorities.

In order to identify a requested stream it would be necessary to enhance the pure video stream by appropriate metadata. Here, the information about recording time and place as well as camera parameters used for recording would be sufficient to achieve basic interoperability.

For efficient archival a packaging of the video and metadata information into a file format should be supported. That file format should also provide for the inclusion of user data and possibly additional MPEG-7 metadata. This metadata should provide key functionality to support the activities of the CCTV manufacturers, installers and users.

Recording of audio signals in the context of surveillance is not commonly used, and is therefore not included in this application scenario. Companies in this space have indicated their interest to include such functionality in the future.

General RequirementsThe Video Surveillance MAF shall support:

Packaging of visual data and associated metadata

Selective access to visual data and metadata

File Format Requirements (to Support Packaging)1) The file format should support all existing transport networks (transport

agnostic).

2) The file format should support storage of visual data and metadata, and the information necessary to enable these elements to be synchronized.

3) The file format should support visual content coded by AVC.

4) The file format should provide a means for referencing an arbitrary external source of digital video content.

Video Requirements1) It is required to support the AVC video compression standard.

2) Sampling Formats and Bitrates:a. Scanning Formats: progressive scan, only 4:2:0 chroma-sampling,

only 8 bits per pixel. b. The video compression shall support up to 4CIF image resolution. c. The video compression shall support temporal resolutions of 25 Hz

and 30 Hz and also lower resolutions. d. The video compression shall support a bit-rate of up to 2 Mbps

(4CIF).

3) Video Functionalities:a. Low latency coding (less than 500 ms).b. Temporal scalability.c. Random access and trick modes (e.g. fast forward, fast reverse).

Requirements for MetadataThe file format shall support the following metadata. For ‘required’ items, the file is only valid if the item is present. For ‘optional’ items, the file is valid with or without the item. The format should support efficient mechanisms to allow devices to ignore unused optional items. Unless otherwise stated, all items are optional.

A mechanism should be supported to allow the values and labels of user-entered metadata to conform to a user-supplied taxonomy, specific to a particular application scenario, e.g. train station, airport, shopping centre; convention for labeling cameras; or lexicon for describing events.

1) Information associated with captured data:a. Time and date of capture of visual data in a standard unambiguous

interoperable format (required).b. Identification of the equipment:

i. Identification tag for the camera (required).ii. Identification tag for the cluster to which the camera belongs.

iii. Identification tags for each of the multiple streams from a single camera.

c. Description of equipment used and equipment settings:i. Camera make and model.

ii. Camera settings such as the aperture and shutter-speed values, peak-to-peak voltage etc.

2) Metadata for content:a. The format should provide a means of annotating events (usually depicted

in the video content).i. In a free text format, along with an event ID (unique in the file

only) and a timestamp.ii. In a semantically structured format.

b. The format should provide a means of representing the location of an object of interest in one or more frames of video data, in image co-ordinates.

c. The format should provide a means of representing the colour appearance of an object of interest, in order to enable retrieval of observations of that object from multiple video sources.

d. The format should provide a means of storing the identity of objects observed in one or more video sources, to enable cross-referencing.


AVC

MPEG-7 simple meta data profile and visual descriptors

ISO Media File Format, AVC File Format

3.7.3 Comparison with other MAFsAdvanced Surveillance MAF (under consideration)The Advanced Surveillance MAF addresses a broad range of Application Scenarios. The Video Surveillance MAF targets a specific application scenario. The successful development of the latter may help to factor this range of Application Scenarios into a set of more focused requirements for further consideration.

Music Player MAFThe Video Surveillance MAF does not include audio. Also, the VS MAF does not include requirements for protection, so there is no close relation with the 2nd Edition of the Music Player MAF.

Photo player MAFThe Photo Player MAF specifies the file format for the combination of JPEG files and a subset of MPEG-7 Visual and MDS metadata. As the proposed VS MAF requires a file format and this is based on the same technologies, there is a degree of relationship, and it may be useful to consider the PP MAF structures for re-use. However, it is believed that the two MAFs can be considered as largely independent due to the differences in required video content and metadata.

Musical Slide Show MAFThe Video Surveillance MAF does not include audio. However, there may be some benefit in examining if the structures for representing video and metadata content will be of use in the case of the VS MAF.

Professional Archival MAF There is a sense in which CCTV activity includes the archiving of observations made about the scene under surveillance. However, the details of the Professional Archival MAF address a substantially different application domain, such as lossless archiving of directory structures. It is thought that the procedures for archiving used by the CCTV operators will lie outside the scope of the proposed VS MAF.

Media Streaming MAFThe Media Streaming MAF includes extensive requirements for Digital Rights Management, which is not included in the proposed VS MAF. Also, the requirements for video and metadata are substantially different. Therefore, there is no close relation with the MS MAF.

Portable Video Player MAF The Media Streaming MAF includes extensive requirements for Digital Rights Management. This is not included in the VS MAF, therefore there is no close relation with the MS MAF.

Open Release MAF The Open Release MAF addresses substantially different requirements than the proposed VS MAF.

MAF for Digital Media BroadcastingThe MAF for DMB includes requirements for Digital Rights Management, and the requirements for video content and metadata are significantly different. Therefore, there is no close relation with the MAF for DMB.

Digital Video/Cinema MAF (under consideration)The DMB MAF includes requirements for Digital Rights Management, and the requirements for video content and metadata are significantly different. Therefore, there is no close relation with the DMB MAF.

3.7.4 Issues

The question of which video compression standards to include in the proposed VS MAF is an important issue. There are many competing standards (and non-standards) in use in the surveillance industry today, and there is a cost (in terms of decoder complexity and MAF manageability) associated with the inclusion of each additional standard. Therefore the approach adopts a strategy of only including a single video standard. The facility for allowing external references to arbitrary video content will support cases in which the video content is coded in other standards.

Two areas of metadata were excluded from the list of requirements: information about the locality of the camera and its relation to the scene; and more sophisticated surveillance requirements such as support for automatic face recognition systems. These areas were excluded because they were not regarded as sufficiently mature (in terms of standardization and real-world experimental performance, respectively).


Cognitive Video Technologies (CoVi) (US)

Ecole Polytechnique Federal Lausanne (EPFL) (CH)

EMITALL Surveillance (CH)

Mitsubishi (JP)

Nine Tiles (UK)

QinetiQ (UK)

Siemens AG (D)

Technische Universität München (TUM) (D)

Effective Pictures (UK)

Thales (F)

4 MAFs Under ConsiderationThis section presents several candidate MAFs, which are described in terms of the template given in section 1.3. The candidate MAFs are subject to further analysis and study before they can progress to the next stage. The proposals must meet the “InFigure 1 the concept for MAFs is illustrated. In [6] a more complete description forthe MPEG-A approach is given, which is also reflected in the technical report onMPEG-A to be issued as ISO/IEC 23000-1 [1].” outlined above (section 1.2). In particular, if an application scenario does not receive sufficient support, it may be dropped from further consideration.

The description of the MAFs under Consideration expresses the opinion and approaches of the supporting companies and organizations.

4.1 Advanced Surveillance MAFIn this section video surveillance is introduced as an application domain that will benefit from a MAF that integrates a wide range of audio-visual technologies from MPEG-4, MPEG-7 and MPEG-21. The video surveillance industry is subject to a change to embrace MPEG standards as a means to offer interoperability between different systems as well as to have access to mature and cost effective multimedia components to be integrated.


Video Surveillance has been named several times as a prime field of application for MPEG-4 scalable video coding. In addition to this, MPEG-21 IPMP Components offers tools for content protection and authentication. Both elements are essential technologies for the development of coming video surveillance systems.

One of the major questions that come to mind is if video surveillance comprises an industry that is in favour of standardization. The abbreviation CCTV stands for Closed Circuit Television, which indicates that standards are not considered to be essential since this type of TV takes place in an closed environment with no need for interoperability with systems offered by other companies.

For example, the international fight against terrorism has clearly shown the deficits of running proprietary video surveillance systems. Neighbouring counties, cities or regions were not able to exchange data and recorded video footage due to a lack of interoperability between the respective surveillance systems. This is a most undesirable situation. The experience gathered during those instances leads to the requirement for interoperable video surveillance systems, which shall be operated by the police or other public organizations to facilitate the exchange of data between different systems operated by different organizations.

Video surveillance systems need security mechanisms to protect the integrity of the images, to authenticate the source and the sink in a networked environment and to encrypt and scramble the audio-visual recordings (e.g. see [4], [6]). The suite of MPEG-21 standards offer mature candidate technologies to address most of the data security and integrity issues associated with surveillance video.

In many countries, notably the USA, U.K. and other European and East Asian countries, video surveillance in public places is increasingly used for crime prevention and for the detection of similar incidents. The increasing number of surveillance recordings can only be mastered if there are automatic tools to analyse the video and audio signals for particular events. While these analysis tasks (e.g. face detection, identification of intruders, etc.) are not a topic for MPEG standardization, the data formats to store the content-based meta information including manually or automatically added annotations can be provided by various parts of the MPEG-7 standard. This way it is possible to browse through the recorded material searching for particular events. The audio-visual recordings can be automatically annotated by

appropriate analysis processes generating the corresponding meta data. Locating specific events in stored video is very labour intensive. Rapid search of archived data for events of interest. Automatic triggering of alarms when pre-defined activity is observed. For example: Find the scene where a person of 5’ 4” and blue colour clothing climbs into a yellow car and drives off. The system would return a list of all scene indexes that matched these criteria

Even though today recording of audio signals in the context of surveillance is not commonly used, companies in this space have indicated their interest to include such a functionality in the future. This also calls for audio compression, and MPEG-7 audio descriptors.

It is necessary to have a file format for storing the recorded and annotated audio-visual data that also facilitates streaming services.

4.1.2 Requirements

General RequirementsThe Advanced Surveillance MAF shall support:

Packaging of audio-visual data and associated metadata

Selective access to audio-visual data and metadata

An audit trail of interactions with audio-visual data and metadata, in the case that these are stored

Stand in a close and hierarchical relationship to other MAF’s in the surveillance application domain

File Format Requirements (to Support Packaging)1) The file format shall support all existing transport networks (transport

agnostic).

2) The file format shall support storage of audio-visual data and metadata

3) The file format shall support audio-visual content coded by compression standards such as JPEG, MPEG-4 (part 2) and AVC/SVC.

Video RequirementsThe file format shall support

1) A variety of sampling formats and bitrates

2) The following video functionalities:

a. Low latency coding

b. Temporal scalability

c. Random access and trick modes (e.g. fast forward, fast reverse)

d. Error resilience

Audio RequirementsThe file format shall support

1) A variety of sampling formats and bitrates

2) The following audio functionalities:

a. Low latency coding

b. Random access

c. Error resilience

Requirements for MetadataThe file format shall support the following metadata:

1) Information associated with captured data

a. Time and date of capture of audio-visual data

b. Camera/microphone identification or location

c. User (CCTV system owner/controller)

d. Equipment used and equipment settings (e.g. camera parameters)

e. Unique identification of the images/frames/slices

2) Metadata for audio-visual event generation

a. Visual descriptors such as motion, color, etc.

b. Audio descriptors such as loudness

3) Metadata for annotation of audio-visual events

4) Metadata associated with an audit trail to track

a. Access to audio-visual data

5) Modification of audio-visual data, such as reducing frame rate to make room on a storage device for more video/audio

Requirements for Data Integrity and Protection

The file format shall support:

1) Information to enable synchronization of audio, visual, and metadata

2) Support of MPEG content protection mechanisms


MPEG-4 Visual (Part 2), AVC / SVC, JPEG 2000, JPEG

MPEG Audio Coding, such as mp3, AAC

MPEG-7 simple meta data profile, visual and audio descriptors

MPEG-21 DIx, IPMP Components, MPEG-21 Event Reporting

ISO Media File Format, MPEG-4 File Format, MPEG-21 File Format

4.1.4 Comparison with other MAFsProfessional Archival MAFThe Professional Archival MAF seems to be targeted to the specific application domain of professional archival of audio information.

If transformed into a more general archival MAF a closer relationship with the Video Surveillance MAF could be developed. Additionally, a mechanism needs to be in place to provide for the surveillance domain specific demands.

Photo player MAFThe Photo Player MAF specifies the file format for the combination of JPEG files and a subset of MPEG-7 Visual and MDS metadata.

As the proposed SMAF requires a file format and this is based on the same technologies, there is a degree of relationship. However, it is believed that the two MAFs can be considered as largely independent.

4.1.5 Issues

The elements of trust management and key management as well as security elements that are bound to contractual conditions are outside of the scope for such a MAF, even though they will be essential for the final development and deployment of such video surveillance systems.

The wish for the inclusion of audio processing tools in such a MAF may be in contradiction with several national regulations and laws to protect privacy. The resolution of this issue is beyond the scope of MPEG, but may require the input from knowledgeable persons or organizations.


Cognitive Video Technologies (CoVi) (US)

Robert Bosch GmbH (D)

DynaPel Systems (US)

Ecole Polytechnique Federal Lausanne (EPFL) (CH)

EMITALL Surveillance (CH)

HiSilicon Technologies (CN)

Medialive (FR)

Mitsubishi (JP)

Nine Tiles (UK)

Panasonic (SG)

QinetiQ (UK)

Siemens AG (D)

Technische Universität München (TUM) (D)

Visiowave (General Electric Security) (CH) Effective Pictures (UK)

4.2 Digital Video/Cinema MAF


There are many processing steps in the Digital Video/Cinema value chain. Normally, content creators use video camera to capture video. Afterwards the obtained visual image data is edited according to predetermined scenarios, and DRM information is attached. This audio visual data are stored in storage media using an appropriate coding format. Finally, such audio visual data is transferred to the end user terminal and displayed on the display device.

To keep the perceived image colors identical throughout the different steps of the digital video production and delivery chain, color management information is used to control display equipment. In addition, it is necessary to be able to associate DRM information with such high value digital video data. As a consequence, there is a growing demand for an interoperable format for storing, transmitting and consuming digital video/cinema while retaining original color information and incorporating DRM information.

The figure below shows how the MAF could potentially work:

Image Capturing

Digital Video/Cinema Content Distribution

Content ArchivesStorage

Authoring Signal Processing Signal

Processing

Content Creation Processing Processing ProjectionDistribution/Storage

MPEG-7 META Data of Color management

DRM SsytemMeta Data Digital Video/Cinema

Common Specification

DisplayColor Image

Original colorMETA Data

Fig3 ; Conception Image of Digital Video/Cinema MAF


ReuseStore

Terminal

MPEG-21 REL RDDMPEG21-IPMP

Content Creation Display Facilities

MEDIA

The content creator shoots movie by using his video camera system.

The content related camera equipments data, shooting environment data and colour management related META data are captured and stored at the camera equipment system together with content itself.

During the content editing process and authoring stage this metadata is combined together with attribute base META data and DRM like cipher or water mark tool information and then transfer the file to the next process.

Next, this content adapt to the Digital Video/Cinema File Format.

Digital Video/Cinema file is constructed from audio visual data plus various META data sets e.g. colour management metadata, DRM metadata, can be stored to the content archives storage.

After processing, original content distribute to the end-user.

Due to the added DRM information on the header, distribution system can realize in a secure way.

Finally, the end-user consumes the content and the consuming device can use the colour management information to reconstruct the original colour.

4.2.2 Requirements

4.2.2.1 General RequirementsThe Digital Video/Cinema MAF specification shall support:

Distribution of Digital Video/Cinema content with Audio, Video, and various metadata to maintain end to end compatibility.

Distribution method of both streaming and file transfer.

Display devices to represent color same as the one captured from camera.

Metadata from creation to projection of Digital Video/Cinema content linked, referred, or attached to the content

Digital Video/Cinema content including the form of intra coding with 4:4:4 color sampling

Scalable video coding of Digital Video/Cinema content so the content can be represented with various devices.

Scalable DRM in connection with scalable video coding

4.2.2.2 File Format RequirementsDigital Video/Cinema MAF shall support the following functionalities with regard to file format:

The file format shall provide unified storage and distribution of audio-visual data and above-mentioned metadata.

Distribution method of both streaming and file transfer.

4.2.2.3 Requirements for MetadataThe Digital Video/Cinema MAF shall support the following functionalities with regard to metadata:

Description from creation to projection of Digital Video/Cinema. The processes to be described in the above-mentioned metadata are as follows:

o Preproduction

o Production

o Postproduction

o Mediation

o Presentation/Projection

Description of color management. The elements are as follows:

o Input color space data

o Conversion algorithm

o Display manufacturer

o Display model

o Presentation/Projection environment

o Color component preset

o Color Correction parameter

4.2.2.4 Requirements for Video The Digital Video/Cinema MAF shall support the following functionalities with regard to Video:

Scalable video coding of Digital Video/Cinema content so the content can be represented with devices capable of representing below coding types and color sampling format:

o Coding types

All intra

Inter frame coding

Scalable coding (both spatial and temporal)

o Color sampling format

4:4:4

4:2:2

4:2:0

4.2.2.5 Requirements for Digital Rights Management (DRM)The Digital Video/Cinema MAF shall support the following functionalities with regard to DRM:

Scalable DRM in connection with scalable video coding


MPEG provides the ISO/IEC Media File Format (ISO FF) as a storage container. This MPEG-21 FF uses the MPEG-21 DID as a container for expressing the relationship between audio visual assets and their metadata.

By using MPEG-7 Visual descriptors, and possibly color management information can be expressed

MPEG-21 DIA, color management information can be expressed. This metadata can be used throughout the content delivery and consumption chain to retain original color information.

To express the scalable A/V content MPEG-2 and MPEG-4 has defined different formats.

Finally, everything can be protected and licensed using MPEG-21 REL, RDD, and IPMP technologies. DII technologies can be used to identify resources in the Digital Video/Cinema MAF.

Therefore, the Digital Video/Cinema MAF will be based on the following technologies:

MPEG-2 video coding standard (main profile).

MPEG-4 AVC/SVC.

MPEG audio codecs

MPEG-7 Visual Description Tools plus potential extensions

MPEG-21 File format

MPEG-21 DID

MPEG-21 DII

MPEG-21 IPMP

MPEG-21REL

MPEG-21 RDD

MPEG-21 DIA


Unique characteristics of Digital Video/Cinema MAF are as follows:

(1) metadata to maintain end to end compatibility to achieve color management

(2) scalable video representation

(3) scalable DRM in connection with scalable video

4.2.5 Issues

Media Streaming MAF function, following functions need for Digital Video/Cinema Content Filing. Also some tools are needed for

Color space management metadata and its name space

Scalable DRM for scalable video coding


Mitsubishi Electric Corporation

Tokyo Institute of Technology

Tokyo University of technology

National Institute of Informatics

The University of Tokyo

Matsushita Electric Industrial Co.,Ltd.


4.3 Protected Photo Player MAFThe work of ISO/IEC 23000-3 (Photo Player MAF) has been finalized with focus on utilizing many of MPEG-7 functionalities to the collection of photos in JPEG format and encapsulating them in MPEG-4 file format. The current specification of Photo Player MAF offer very good functionalities because users can put their photos and associated them with information to make it easy to exchange with friends, browse, search, categorize, many other actions. However, since it does not consider any protection mechanism to protect its content, it may not be complete for the deployment into real business.

In this section, protected mechanism to enhance the current Photo Player MAF is considered. The proposed protection mechanism utilized IPMP technology so that it is flexible and extensible to use any protection tools.


4.3.1.1 Protected Photo AlbumA collection of photos can be protected as a whole with protection tool chosen by the creator. Before playing/displaying the photos, a photo player needs to be able to unprotect it by using the correct protection tool. In the case the required protection tool and key to unprotect the photos are not available and cannot be retrieved, the player should give notification to the user.

Moreover, the protection can be applied selectively. For example, a collection of photos consists of several different scenes and we want to protect only certain scenes and left the rest free to be viewed. If the player can unprotect all the protected photos, it will be played normally; but if it cannot, only unprotected photos are displayed while the protected ones are skipped so that unauthorized user will not realize that.

Note that there is a thought/idea that this Protected Photo Album MAF may be considered as the Version 2 of Photo Player MAF which in this sub section will be referred as Version 1.

4.3.1.2 Privacy Protected PhotoContribution M12659 has proposed that a Photo Player MAF (was called as Photo Album MAF) should be able to protect certain object in a photo. For this functionality, we can apply weak protection such as pixel scrambling or masking. In this way, for unknown people, certain object(s) in the photo will cannot be viewed clearly while for familiar people can see it normally as shown in the following figure.

Privacy protected MAF

Unknown people Familiar people

Figure x – Protecting selected object in photo

4.3.1.3 Protecting MPEG-7 MetadataMPEG-7 metadata is obviously an important component of Photo Player MAF because it makes functionalities such as searching and categorizing become possible. If the MPEG-7 metadata is not present of inaccessible, Photo Player MAF would be just an ordinary collection of photos without revealing any sensitive information about it.

The reason for protecting MPEG-7 metadata can be as the following:

We want to require an ordinary user to view the entire photo collection one by one, not only just specific photos. Without MPEG-7 metadata, the user cannot use the searching functionality so that he cannot find specific photos unless he/she view the entire photos.

We want to hide information about the photos such as who creates the photo, where and when it was taken, etc.

4.3.2 Requirements

To implement the above use-case scenarios, the Protected Photo Player MAF should support the following requirements:

The Protected Photo Player MAF should be able to protect the JPEG images and the MPEG-7 metadata, either individually or concurrently.

The Protected Photo Player MAF should be able to accommodate various protection tools flexibly.

Internal resources shall be protected by a single default protection tool.

The Protected Photo Player MAF should support protection to the complete set of photos.

The Protected Photo Player MAF should support protection to selected photos.

The Protected Photo Player MAF should support protection to selected regions of the photos.

Unprotected image resources and metadata in a Protected Photo Player file shall be playable by the Version 1 Photo Player.

Unprotected parts of image resources with protected regions shall be playable by the Version 1 Photo Player.

The Protected Photo Player MAF should have licensing mechanism.

The overall complexity of the Protected Photo Player shall not be significantly greater than that of the Version 1 Photo Player.



Technologies used in ISO/IEC 23000-3.

MPEG-21 DIDL

MPEG-21 IPMP Base Profile

MPEG-21 REL MAM Profile

MPEG-21 Fragment Identifier


At the current time, only Music Player MAF has protection capability in its specification. Other MAFs may have intention to define protection scheme but they are not mature yet.

4.3.4.1 Protected Music Player MAFCompared to the protected music player MAF, this under consideration MAF has similarities as the following:

Use MPEG-21 DIDL and MPEG-21 IPMP Components Base Profile to signal the resource structure and type of protections and location of protections that are applied to them.

Use MPEG-21 IPMP Components Base Profile to support flexible protection.

Use MPEG-21 REL MAM Profile for the license description.

The differences are as the following:

Both MAFs have difference file structure

o Protected Music Player MAF support two cases of file structure (track in MP4 FF and track(s) in MP21 FF).

o The location of protection description for both MAFs is different due to the file structure.

o Protected Music Player MAF support both default protection tool (AES-128 Counter Mode) and flexible protection while the current proposed protection mechanism for Protected Photo Player open the choice of protection tool to the content creator (flexible protection).

4.3.5 Issues

The following issues are identified during discussion with experts in the MPEG Requirements group:

There is concern about the additional complexity that this protection mechanism would bring for the Version 1. One of possible solution to deal with this complexity issue is by having multiple compatibilities/conformances as described as the following:

o Implements only default protection tool with no licensing support.

Only for internal resources (type A).

Suitable for not device with limited capability & no network connection.

o Implements only default protection tool with licensing support.

o Implements flexible protection mechanism.

Note that document M14174 contains a preliminary thought on how the list of technologies listed in sub clause 4.3.3 are used for this under consideration MAF.



Korean Broadcasting Systems (KBS)

Mitsubishi Electric.


4.4 Stereoscopic MAFIn today’s technological arena, there is an abundance of digital contents for digital image machinery such as cell-phone, digital camera, DVD and PMP. Stereoscopic contents provide natural three-dimensional scenes which are displayed using solved acquisition/generator techniques. The market for applying stereoscopic contents on respective devices is fully formed and is ready for deployment. Consequently, there is a need for standard data for acquisition/creation, storage, transmission and playing of stereoscopic contents. This document introduces the application scenario, which uses Stereoscopic MAF contents, while defining the requirement for consumption techniques.

Stereoscopic contents include still images and motion pictures. Stereoscopic MAF contents define stereoscopic contents which adhere to the requirements defined in the documentation.


Figure 2 Service architecture of stereoscopic contents.

Acquiring stereoscopic contents using dual cameras and share them with other users

Using the dual cameras on the device, a user can create his own contents and he can share them with other users.

Rendering Stereoscopic User Created files

Using the dual cameras on the device, a user can create his own contents and he can also keep the usage history for the next-time playing

Downloading and Rendering Stereoscopic Music Video files

From various networks(wireless, wired, ptp, and broadcasting), the terminal receives stereoscopic Music video files. Compared with the mono-scopic Music video, the user can feel more natural video quality.

Downloading and Rendering Stereoscopic Advertisements

In case that the original stereoscopic images/videos are the same as monoscopic ones, due to the stereoscopic effect, a user can be expected to experience different feeling. Consequently, advertisement is very good application example.

Downloading Preview contents of Movies or Movie files

Similar to the advertisement scenario, preview contents of Movies and movie files can be provided as stereoscopic contents. After viewing stereoscopic preview video clips of a movie, a user will have more interests on that movie compared with mono-scopic version of it.

Random access of stereoscopic video contents

In both cases of downloaded files and user created files, a user can keep the information related with accessing. Thus, the user can find the accessing point randomly. And the user can see the accessing point after the previous consumption.

4.4.1.1 Creation of the Stereoscopic MAF ContentsStereoscopic content can be created from a stereoscopic camera. This content will contain stereoscopic still images and/or motion pictures. Stereoscopic content can also be created using CG animation authoring tools to output still images and/or motion pictures. Stereoscopic MAF content can be created combining acquisition/creation information with stereoscopic still images and motion pictures.

4.4.1.2 Storage of the Stereoscopic MAF ContentsStereoscopic MAF content is stored using a combination of media data and Meta data to create a single file format. Thus, Stereoscopic MAF content will contain stereoscopic acquisition/creation system along with stereoscopic still images and moving images.

Managing the Stereoscopic MAF content can be done using a Stereoscopic MAF browser. This browser will allow Stereoscopic MAF content to be viewed and played.

4.4.1.3 Transmission of the Stereoscopic MAF ContentsThe user will be able to Upload/Download Stereoscopic MAF content via a wireless or wired network.

If compatibility exists, the network allows multiple data channels to receive and transmit Stereoscopic MAF content. After the content is received, the Stereoscopic MAF player will be able to re-compose and play the corresponding content.

4.4.1.4 Player for the Stereoscopic MAF ContentsThe Stereoscopic MAF content player will be able to play transmitted files or stored files. The player will also be able to play mono-scopic content as well. The user will be given the option to play stereoscopic MAF content from the following modes: Mono-scopic mode, Stereoscopic mode.

4.4.2 Requirements

General Requirements

The Stereoscopic MAF must support:

the necessary functionalities and the construction for a Stereoscopic still image and motion pictures service. The audio service support is optional.

the Stereoscopic MAF contents are an expansion of Mono-scopic contents. production, copyright protection, delivery and usage. the functionality and the construction of composition methods.

Acquisition/Creation Requirements

The Stereoscopic MAF contents must include Stereoscopic still images and motion pictures acquisition /creation information from the Stereoscopic acquisition/creation system.

The information may include some of the following: distance between two cameras, crossed-eye view, parallel-eye view, viewing distance versus use/validity depth ratio and kinds of camera.

File Format Requirements

The file format with stereoscopic media data must provide the storage structure in the Meta data. The file format must include Stereoscopic still images, Stereoscopic motion

pictures and audio data, and Meta data. The Meta data is required for Stereoscopic contents re-composition. The media data can be acquired by using the Stereoscopic acquisition/creation system.

The file format must support multiple media synchronization. The file format must support access to part of the data or the whole data. The file format must support compatibility with existing mono-scopic

contents. The file format must provide protection of content, contents encryption and

copyright protection methods and random access of media data. The file format must allow the user to search and manage data via keyword input.

Requirements for Protection and Governance

The Stereoscopic MAF contents must support the following for copyright protection of Stereoscopic MAF contents: The Stereoscopic MAF must provide content encryption for stored and

transmitted Stereoscopic MAF contents. It must provide various levels of encryption depending on the user access

authority and application service. The Stereoscopic MAF contents must provide encryption, user authority, period

of usage of playing license, and copyright protection. It must provide conditions from the receiver for various Stereoscopic MAF

content services. It must provide manufacturer information and usage history. And, in order to use Stereoscopic MAF contents from various terminals the user

must provide conversion of encrypted content.

Requirements for Metadata

The stereoscopic MAF must provide the following for the storage, playing, and transmission of Meta data. The Stereoscopic MAF contents must include Stereoscopic still images and

motion pictures acquisition/creation information from the Stereoscopic acquisition/creation system This may include distance between two cameras, crossed-eye view, parallel-eye view, viewing distance versus use/validity depth ratio and kinds of camera.

It must provide identifiable information for transmitted or stored media data of the stereoscopic MAF content. This content may be stereoscopic media data, existing mono-scopic media data.

It must provide the composition information for the ES (elementary stream) of the stereoscopic still image or the motion pictures. It must have information on the number of elementary streams. This value

will either be one or two. In the case that there is only one ES, there must be information on how to

compose the right and left images. It must provide information on the restoration of the right and left image.

The existing formats are: Parallax Barrier format, Top-down format, Side-by-side format, Field sequential format, and Frame sequential format

In the case that there are two ES, it must provide detail information of media data type for stereoscopic still images and motion pictures. The stereoscopic still images and motion pictures are composed with the ES

to create Main media data and Sub media data. The Main media data contains Mono-scopic still images and motion pictures. The Sub media data contains the composition information of the stereoscopic still images and motion pictures. The Sub media data has the image and depth map. It also contains the composition information which is used to combine the image and depth map.

In the case where two ES are prevalent, the Sub media data must provide image size information from stereoscopic MAF contents. Depending on the display method of the stereoscopic MAF content, it will

allow the user to display 1/2 of the data from the original left and right images. To reduce the Sub media data size, the user can reduce the image sizes.


The Stereoscopic MAF will be based on the following technologies: ISO Base Media File Format Video: MPEG4 Visual Advanced Simple profile Still Image: JPEG Audio: MPEG-4 -AAC Meta Data:

Content description metadata: MPEG-7, TV-Anytime etc.

User metadata: MPEG-7, TV-Anytime, etc Terminal targeting metadata MPEG7 or TVA(acquisition/creation metadata)

Protection and Governance information: MPEG IPMP, REL, etc.

Further details of the specification are currently in progress.


Music Player MAF, Music slide show MAF, Photo Player MAF, Open Release MAF, and Professional Archival MAF have different goals than Stereoscopic MAF in that the former MAFs are not used in video applications. Therefore, it is more reasonable to compare it with Portable Video Player MAF, Video Surveillance MAF, Digital Video/Cinema MAF, Digital Multimedia Broadcasting MAF and Media Streaming MAF.

PVP MAF MAF for DMB Stereoscopic MAF

Target market Mini-DVD Portal service

DMB Application Terminals only.

Stereoscopic File download service, stereoscopic UCC

Application scenario A possible standard format for portable applications that utilize mid-resolution video: mini-DVD/UMD portable video player

(PMP)

DMB specific services: Storage of DMB contents

only with associated metadata

IP Media Services with DMB contents

Exchange of DMB contents accros DMB MAF Terminals

User-Creative DMB contents Metadata Applications with

DMB MAF

File format of wide application : Creation of the Stereoscopic

MAF Contents Storage of the Stereoscopic

MAF Contents Transmission of the Stereoscopic MAF Contents Player of the Stereoscopic MAF Contents

File format ISO Base Media / MPEG-4 / AVC File Format

MPEG-21 File Format Only specified with ftyp,

moov, meta, mdat boxes Use xml box to contain

MPEG-4 LASeR Content information is

carried in xml box inside trak box

Derived MPEG-4 File Format with extension and restrictions(extend AVC File Format) Use meta box to carry

MPEG-21 IPMP & DID- Content information is carried in MPEG-21 DID

ISO Base Media file format

Video resources MPEG-4 AVC Baseline Profile, Level 1.2 for a resolution of 320x240 (4:3)

MPEG-4 AVC Baseline Profile, Level 2.1 for a resolution of 480x272 (16:9)

MPEG-4 Part2 Visual

MPEG-4 AVC Baseline profile level 1.3 only

MPEG4 Visual Advanced Simple Profile

Audio resource MPEG-1/-2 Layer-3 MPEG-4 AAC/AAC+/HE-

AAC/BSAC Audio

MPEG-2 AAC+, MPEG-4 ER-BSAC MPEG-4 HE-AAC

MPEG4 AAC

Systems support Use MPEG-4 LASeR to represent menu to select content (video, audio, text)

MPEG-4 OD/IOD/BIFS are used for scene descriptions, interactions, and synchronizations of multiple objects

Not required currently

Data service resources

Not defined BWS, TTI, MOT Slideshow, Java midlet

Not defined

Metadata MPEG-7 MDS1) Creation DS2) UsageHistory DS3) HierarchicalSummary DS

MPEG-21 DID to organize DMB contents, metadata, and IPMP

TV-Anytime Phase 1 Phase 2 Metadata (Part 3)

MPEG7 or TVA

Streaming framework

not defined not defined not defined

IPMP Protection technologies to be aligned with the Music Player MAF, 2nd edition

MPEG-21 REL DAC Profile MPEG-21 IPMP

Components Media Streaming Profile

MPEG-21 REL DAC Profile MPEG-21 IPMP Components

Media Streaming Profile

Comparison with Portable Video Player MAF (PVP MAF)o Stereoscopic MAF has a concrete application domain, which is

Stereoscopic image. PVP MAF does not. Therefore two MAFs have different application domains and type of video codecs.

o PVP MAF does not specify the supported profiles of audio and video compression standards, whereas Stereoscopic MAF specifies the exact set of supported audio and video profiles.

Comparison with Media Streaming MAF (MS MAF)o MS MAF focuses on DRM of contents for streaming service. Stereoscopic

MAF is mainly concerned with storing and interchanging Stereoscopic contents. Therefore two MAFs have different application domains.

Comparison with MAF for Digital Multimedia Broadcasting

o MAF for DMB focuses on contents for DMB service. Stereoscopic MAF is mainly concerned with storing and interchanging Stereoscopic contents. Therefore two MAFs have different application domains and type of video codecs.

Comparison with Video Surveillance MAFo The purpose of Video Surveillance MAF is to make a standard for CCTV

(Closed Circuit TV), and provide compatibility between surveillance videos from different CCTVs. Thus, the application domain of Video Surveillance MAF is different from that of Stereoscopic MAF.

Comparison with Digital Video/Cinema MAFo Digital Video/Cinema MAF’s purpose is to keep colour information which

can be changed by the metadata. A user can consume digital video with colour information which is created when digital video is created in the studio. Stereoscopic MAF and Digital Video/Cinema MAF have independent application domains.

4.4.5 Issues

Stereoscopic MAF is motivated from the industry’s needs. The current market already has its related products, thus Stereoscopic MAF file format will boost up the market.

Thus, basically, the current technology set should consider the current implementation considering standardization progress and time-to-market requirement.

However, generally, in the future, it should be investigated that adding technologies makes bigger complexity to the terminal or help to broaden the application spread out further considering the market requirement and standardization process.


SK Telecom

Samsung Electronics co., Ltd

LG Electronics

Samsung Electro-Mechanics co., Ltd

MBC(Munhwa Broadcasting Corp.)

ETRI(Electronics and Telecommunications Research Institute)

KETI(Korea Electronics Technology Institute)

KIST(Korea Institute of Science and Technology)

Samsung SDI co., Ltd

Samsung Techwin co., Ltd

ECT(Enhanced Chip Technology Inc.)

KWU (Kwangwoon University)

TU Media Corp.

3D Project

4.5 Cross-Media Interactive Presentation MAFThe Cross-Media Content based on HTML and/or SMIL and/or SVG/LASeR and/or SCORM/IMS and related styles and referred digital resources and similar content has a huge potential market both in the educational and informative fields and it is especially suitable for infotainment, edutainment, etc, as well as for the distribution of cultural material, and data in applications such as those as proposed by AXMEDIS, in WEDELMUSIC (www.wedelmusic.org), by the MUSICNETWORK international association, in VARIAZIONI project and service (www.variazioniproject.org), for the Electronics School Bags project and AXMEDIS/MEPG-21 player of SEJER, POLYMNIA project and tool, I-MAESTRO project (www.i-maestro.org ), TISCALI AXMEDIS/MPEG-21 players, etc.

HTMLSMIL

SCORM

Text

layout, synchronization,

interactive behaviour

...

StyleSheets(formatting instructions)

LASeR

Figure - Structure of Cross-Media Content

The Cross-Media content document organizes the digital resources by configuring the layout. For example, for creating a presentation (e.g. HTML textual pages with images and animations, scripts, SMIL based menus, SMIL based active animations, etc.), it may be necessary to include the synchronization among resource rendering and interactive behaviour (e.g. SMIL-based interactive game with sound effects, SMIL sequence of video with transition effects, MPEG4 LASeR Presentation). The Cross-Media content typically refers to digital resources with a URI indicating the path to locate the resource files.


The main scenarios are:

Distribution and usage of Cross-Media Content,

Production and B2B Distribution of Cross-Media Content,

Storage and resale of Cross-Media Content.

The value-chain of Cross-Media Content

In the above mentioned B2B context, cross-media content can be created by using tools for combining third party cross-media content (as DIs) and digital resources according to the rights provided on the basis of some licenses. In this case, both the player and the authoring tool (tool to create compounded DIs) are de facto players of content according to some rights provided on the basis of some licenses. The process of composition enables the creation of more complex and valuable contents.

4.5.1.1 Distribution and usage of Cross-Media ContentThe Distributors of Cross-Media Content are interested to distribute the above mentioned Cross-Media Content in a protected form. Currently, they do not have this possibility since the above mentioned formats (also considering the links among them and nesting levels among the different resources referred) are not supported by any integrated solution for the protection of information.

protectedcross-media

content

cross-media content

License

Distribution site

1. authoring

2. protecting

3. publishing 4. downloading5. asking for a license

6. producing license

protectedcross-media

content

7. playing

Authorization Server

7a. asking for grant authorization

Paolo(producer/distributor)

Piero(end-user)

Figure – Distribution and usage of Cross-Media content

A possible representative scenario could be described as follows:1. Paolo is a Distributor/Producer and prepares the above mentioned Cross-Media

Content:a. the Cross-Media Content includes informative metadata and descriptors

for cataloguing and identification, including business related metadata (e.g. commercial offer about the content) and resource specific metadata for the included digital resources;

b. the Cross-Media Content includes LASeR, SMIL, HTML, SCORM, etc., documents and related digital resources organised according to the nested levels/directory and with references to internal/external resources.

2. Paolo protects and package the new content: the Cross-Media Content has to be protected, encrypted and stored together within the Digital Item;

3. Paolo makes available the new content on a distribution channel (e.g. a web site): the Cross-Media Content can be distributed by means of download or other means.

4. Piero is a final user who is interested in receiving and playing the Cross-Media content on different players on different devices, e.g. PC, PDA, mobiles. He accesses to the distribution site where he can get the Cross-Media content;

5. Piero is ready to accept to buy the content. He asks for a MPEG-21 REL license that allows him to play the Cross-Media content;

6. Paolo produces a license that gives Piero the rights to play, print, etc., for the required Cross-Media content and its digital resources (Paolo has the license to issue, since is the right owner)

a. the license is stored into some authorization server that is capable to respond to queries on user grants, thus providing the grant authorization.

b. the license can be revoked; if this happens the related Cross-Media content will become unusable for Piero.

7. Piero is now authorized to use the downloaded Cross-Media content and uses some players in order to exploit the acquired rights;

a. while Piero is playing/printing his Cross-Media content, the player is contacting the authorization server in order to verify that the Piero owns the appropriate rights.

4.5.1.2 Production and B2B Distribution of Cross-Media ContentThe Producers of Cross-Media Content are interested in producing and distributing the above mentioned Cross-Media Content with some protection support to Distributors in order to establish a B2B distribution. Currently, they do not have this possibility since the above mentioned formats are not supported by any integrated solution (formats and authoring tools for compounding objects, and related players) to protect the information, also considering the links among them and nested levels among the different resources referred.

License

B2B Distribution site




6. publishing new content

5. creating new content by embedding

2. downloading exisiting content

Paolo(producer)

3. establish business agreement


Davide(producer)

Figure – B2B Distribution and usage of Cross-Media content

A possible representative scenario could be described as follows:1. Davide is a Producer and he would like to distribute the above mentioned Cross-

Media Content with some protection support towards one or more Distributors/Producers (such as Paolo) as a DI which:

a. can be obtained through download or other channels;b. includes informative metadata and descriptors for cataloguing and

identification, including also business related metadata of all included DIs as public metadata of the whole object;

c. includes Cross-Media Content and related digital resources organised according to nested levels (as DIs) and references to internal and/or external resources.

2. Paolo and/or Davide are interested a. in receiving and reusing the DIs for creating more valuable DIs, and alsob. in distributing the DI according to the scenario as discussed in Section 2.1.

3. Davide and Paolo establish a business agreement on how Paolo can use the new Cross-Media content produced by Davide.

4. Davide produces a REL license that gives Paolo the required rights on the basis of the agreement (e.g., embed Davide’s Cross-Media content in another one produced by Paolo)

a. the license is stored into some authorization server that is capable to responds to query on user grants, thus providing the grant authorization. The grant can be for producing other more complex objects and for distributing the cross-media content to other Distributors and/or final users;

b. the license can be revoked; if this happens the related content will become unusable for Paolo.

5. Paolo is now authorized to embed (it is just the example for this scenario) Davide’s content in a new Cross-Media content: he uses a suitable tool to perform such operation and to finalize his new content.

a. while performing the embed operation the authoring tool is contacting the authorization server in order to ensure that Paolo owns the proper rights.

Step 4 of the proposed scenario can be varied on the basis of the produced license. The license could grant to Paolo the right of using Davide’s Cross-Media content for adaptation (e.g., adjusting layout in order to fit in a small screen) to create a new Cross-Media content.

4.5.1.3 Storage and resale of Cross-Media ContentThe Scenario (as discussed in Section 2.1) is supported by a business model in which some Distributors provide the content to the final users via Kiosks towards PDA and mobile players.

License

B2B Distribution site



2. downloading exisiting content

3. establish business agreement


Davide(producer)

Piero(end-user)

End-user Distribution site



License

6. downloading content

9. playing

7. asking for a license


Paolo(distributor)

Figure – B2B Distribution and usage of Cross-Media content

The scenario consists of:1. Davide is a Producer and he distributes the above mentioned Cross-Media content

with some protection support toward one or more Distributors (such as Paolo) in the form of a DI which:

a. can be obtained through downloading or other channels;b. includes informative metadata and descriptors for cataloguing and

identification, including also business related metadata of all included DIs as public metadata of the whole object;

c. includes Cross-Media Content and related digital resources organised according to nested levels (as DIs) and references to internal and/or external resources.

2. Paolo, the Distributor, downloads the new Cross-Media content, since he is interested in distributing the DI to his own customers.

3. Davide and Paolo establish a business agreement on how Paolo can distribute to his customers the new Cross-Media content produced by Davide.

4. Davide produces a REL license that gives Paolo the required rights on the basis of the agreement (e.g. issue end-user licenses for Davide’s Cross-Media content)

a. the license is stored into some authorization server that is capable of replying to queries on user grants, thus providing the grant authorization.

b. the license can be revoked; if this happens the related content will not be usable because the end-user licenses that depend on the revoked license would be consequently invalidated.

5. Paolo is now authorized to redistribute/resale Davide’s content and he makes the content available to a distribution site that is reachable by his customers.

6. Piero is a customer of Paolo and he would like to download the new cross-media content from the distribution site.

7. Piero wants to buy this Cross-Media content and asks for a suitable license.8. Paolo produces a license that grants Piero the right to play

a. the license is the same of what has been produced in the Scenario in Section 2.1

b. Paolo is acting as a Distributor. Hence the production of Piero’s license is bounded to the authorization included in the licence that Davide has produced for him;

c. the produced license is stored in the Authorization Server and can be revoked.9. Piero plays his Cross-Media content by using a suitable player as in the Scenario in

Section 2.1a. while Piero is playing the Cross-Media content, the player is contacting the

Authorizaion Server in order to ensure that Piero owns the proper rights.the authorization involves the two licenses that have been produced: the one produced by Davide granting Paolo the right to issue licenses (distributing the content, and also compounding the content if needed) and the one produced by Paolo granting Piero the right to play the Cross-Media content.

4.5.1.4 The value-chain of Cross-Media ContentThe different scenarios are parts of a unique path that the content follows, starting from the providers, ending with the end-users.

In the following diagram a two-steps value chain has been depicted in order to resume the main task of this MAF: the production of integrated content in an open market respecting DRM in both B2B and B2C distribution.

In fact the diagram in the following Figure starts with a video resource that is provided to the value-chain as a file that is compliant with the CMIP-MAF. This file is initially distributed to B2B partners and then one of them uses the same file in order to produce a new refined and augmented version. The action is still modelled as a consumption of the first CMIP-MAF file. To allow this usage of the content, the Producer has granted a specific right to the Integrator and this information has been located in a well-known

Authorization Server. The chain could have many steps, but the most important one is the distribution to the end-user. Also in this case the latter receives a CMIP-MAF compliant file; the usage of the content is controlled by the rights the distributor has granted to him.

Actor 1(e.g. Producer)

Actor 2(e.g. Integrator)

Actor N-1(e.g. Distributor)

Actor N(e.g. end-user)

AuthorizationServer

issue licenses ask to embed issue licenses ask to play

Layout/Syncro data

video

image

1.

2.

3.4.

5.

6.

9.

7.

10.

8.

Figure – Example of a complete path for a CMIP-MAF compliant file.

4.5.2 Requirements

To implement the above use-case scenarios, the Cross-Media Interactive Presentation MAF should support the following requirements:

The CMIP-MAF shall support the use of a broad range of security technologies, including but not limited to proprietary ones, without hampering interoperability Internal resources shall be protected by a single default protection tool.

The CMIP-MAF shall support compliant files can be moved, reused or copied among devices according to license terms;

The CMIP-MAF shall support the inclusion of metadata to describe content for classification and search;

The CMIP-MAF shall support the inclusion of existing metadata technologies presently used in the market for the interested business area;

The CMIP-MAF shall support the notification of B2B relevant information such as: content creators, content distributors and business opportunities regarding the packaged content

The CMIP-MAF shall support the inclusion of any kind of media resource

The CMIP-MAF shall support the inclusion of cross-media presentation specific resources

The CMIP-MAF shall enable presentation resource to retrieve components (metadata, media resources, other presentations resources) inside the package by means of URI

The CMIP-MAF shall support the hierarchical organization of content

The CMIP-MAF shall support the local playback of presentations on devices

The CMIP-MAF shall support acceptable performance when rendering the presentation

The CMIP-MAF shall support the download of compliant file

The CMIP-MAF shall support the storage on fixed or removable media

The CMIP-MAF shall support the composition of the existing CMIP-MAF compliant file in a new CMIP-MAF compliant file

The CMIP-MAF shall support interactivity of the presentation (e.g. menu, buttons, links, etc.)

The CMIP-MAF shall support the protection of any sub-tree of the hierarchy and this protection as to affect all the components and sub-trees

The CMIP-MAF shall support the signaling of which protection mechanism has been used in order to protect any part of a file

the CMIP-MAF shall support any user exploits packaged content on the basis of the following rights with has to be enforced by the devices:

o play (entire Cross-Media Content or parts of it – in this case adequate information on what is accessible should be available in the metadata in order to avoid the incurrence of eviction, thus providing proper warranty against eviction)

o print (entire Cross-Media Content or parts of it – also in this case adequate information on what is accessible should be available in the metadata in order to avoid the incurrence of eviction, thus providing proper warranty against eviction)

o transfer among Cross-Media Content Players and/or Cross-Media Content Provider Devices;

o embed Cross-Media Content in another one by means of Cross-Media Content Provider Device;

o adapt existing Cross-Media Content to produce another one by means of Cross-Media Content Provider Device;

o issue grants for Cross-Media Content from those specified above;



ISO Base Media File Format, (MPEG-21 File Format)

MPEG-21 DID

MPEG-21 DIDL

MPEG-21 IPMP

MPEG-4 LASeR

MPEG-7

Dublin Core


4.5.4.1 Music Player MAF and Music Player MAF, 2nd editionThe Music Player Application Format specifies the file format for the combination of MP3 files, a subset of MPEG-7 MDS metadata corresponding to ID3 metadata and JPEG pictures.

The general goal of the Music Player MAF, 2nd edition seems to be to support a level of governance information to the Music Player MAF.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. In CMIP-MAF DIs can be nested and protected preserving metadata access, composition ability, etc. The governance includes also exploitation of typical B2B rights where authorization is granted for content adaptation/embedding in new content.

4.5.4.2 Photo player MAFThe Photo Player MAF specifies the file format for the combination of JPEG files and a subset of MPEG-7 Visual and MDS metadata.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. In CMIP-MAF, DIs can be nested and protected preserving metadata access, composition ability, etc.

4.5.4.3 Musical Slide show MAFThis Musical Slideshow MAF is expected to be a superset of the Music Player and the Photo Player MAF. Additional technologies to be added are streaming text and Laser Mini Profile.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. The CMIP-MAF aims to distribute content in a protected form and more important it covers application scenarios where produced content is adapted/embedded, under governance, to create new content.

4.5.4.4 Professional Archival MAFThe Audio Archival MAF seems to be targeted to the specific application domain of professional archival of audio and possibly video information. The Professional Archival MAF introduces a structured set of digital resources. The objective the Professional Archival MAF is to package for archival.

In CMIP-MAF content is structured because is the result of the composition/adaptation of several elementary/raw content. Also in this case, the application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. The application domains of the two MAFs are inherently different.

4.5.4.5 Media Streaming MAFThe Media Streaming MAF standardizes streaming video content and protocols.

The proposed CMIP-MAF is based on file downloading.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. In CMIP-MAF DIs can be nested and protected preserving metadata access, and composition ability, etc. The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content. The application domains of the two MAFs are inherently different.

4.5.4.6 Portable Video Player MAFThe Portable Video Player MAF is an application that focuses on local playback of packaged video content. Portable Video Player MAF includes animation, text.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. In CMIP-MAF DIs can be nested and protected preserving metadata access, and composition ability, etc. The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content. The application domains of the two MAFs are inherently different.

4.5.4.7 Open Release MAFThe Open Release MAF addresses the publication and delivery of governed but unprotected content (content is governed in a “light-weight” form).

The proposed CMIP-MAF cannot consider Open Release Content as a possible vehicle for the distribution, since B2B/B2C relationships have to be modelled and this requires “strong governance” (preventing unauthorized access/manipulation). The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content. Thus the two MAFs are independent.

4.5.4.8 Digital Media Broadcasting MAFDigital Media Broadcasting MAF specifies how to combine the variety of DMB contents with associated information for a presentation in a well-defined format that facilitates interchange, management, editing, and presentation of the DMB contents.

CMIP-MAF is targeting to completely different application scenarios where cross media content is downloaded. CMIP-MAF requires protection to be applied at different levels and by different users along content lifecycle. The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content.

4.5.4.9 Video Surveillance MAF, Advanced Surveillance MAFThe Video / Advanced Surveillance MAF is an application that is specifically targeted towards the application domain of surveillance. Thus, it has no relevance to the CMIP-MAF.

4.5.4.10 Digital Video/Cinema MAFThe Digital Video/Cinema MAF addresses the high range of video distribution to professional users. One example is the use of metadata for colour management of rendering devices typically in movie theatres. The application domains of the two MAFs are inherently different.

4.5.4.11 Protected Photo Player MAFThe goal of the Protected Photo Player MAF, is to support a level of governance information to the Photo Player MAF.

CMIP-MAF aims to distribute cross media content in protected form; governance requires protection to be applied at different levels and by different users along the content lifecycle. The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content. The application domains of the two MAFs are inherently different.

4.5.4.12 Protected Musical Slide Show MAFThe goal of the Protected Musical Slide Show MAF is to support a level of governance information to the Musical Slide Show MAF.

The application domains are very different, since CMIP-MAF introduces usage of cross media content for creating new cross media content. In CMIP-MAF DIs can be nested and protected preserving metadata access, and composition ability, etc. The governance includes also exploitation of typical B2B rights where authorization is granted for content adapting/embedding in new content.

4.5.4.13 Stereoscopic MAFThe Stereoscopic MAF is an application that is specifically targeted towards the application domain of display stereoscopic video. Thus, it has no relevance to the CMIP-MAF.

4.5.5 Issues

The Cross-Media Interactive Presentation MAF requires referencing to non-MPEG standard, for informative metadata, presentation documents and related style sheets:

Dublin Core (ISO Standard 15836-2003 02-2003))

When the Cross-Media is distributed as a DI the references could target resources that are internal (packaged in the same DI) or external. When the resources are within the DI, the URI should locate resources that have to be streamed from the DI. Additional resources can be referred in order to provide formatting style such as style sheets (e.g. CSS); these resources have to be uniquely identified at presentation loading.

In hierarchical cross-media content, it may happen that multiple resources with the same name may exist. For example two “index.html” resources (in two different DI included in a third DI) related to two different presentations (in different Items) that need to be linked from a top html page (the third DI). Content creators need an easy way to manage this situation and to structure the content, possibly by using a solution that is similar to what they use in their everyday work and possibly with little or no modifications to the content itself (e.g., the HTML pages and related resources). The nesting can be even performed by compounding protected DI (components) and thus the change of the resource name is impossible.

The issue of creating unambiguous URI-based references to locate resource inside the hierarchy of components.

Currently in the DIDL specification the resource element does not contain the resource name (the localPath attribute was present in the 1st edition of DIDL specification but it was removed in 2nd edition). Hence, this information is missing when the resources are embedded (encoded in base64) within the XML file representing the DI. The resource name may be present when the DI is represented using the MPEG-21 file format. In this case the resource name (called item name) can be stored in the iinf box. In this case, a viable solution is needed to manage the uniqueness of names.

Another similar problem can be present with XML IDs when two Digital Items using the same XML IDs (possibly protected) are compounded in another Digital Item.


TISCALI, Italy;

GIUNTI Labs, Italy;

SEJER, France;

EXITECH SrL, Italy;

GERMINUS, Spain;

Universitat Politècnica de Catalunya, Barcelona, Spain;

University of Florence, Department of Systems and Informatics, Distributed Systems and Internet Technology Lab (DSI-DISIT), Italy;

ICSRiM - University of Leeds, Leeds, UK;

Accademia Nazionale di Santa Cecilia, Rome, Italy;

XIM Ltd., UK;


References[1] ISO/IEC JTC1/SC29/WG11/N7069, Draft PDTR ISO/IEC 23000-2, Purpose of

Multimedia Application Formats, Busan, Korea, April 2005.

[2] ISO/IEC 23000-2, Music Player Application Format, FDIS.

[3] ISO/IEC JTC1/SC29/WG11/N7564, Committee Draft 23000-3 Photo Player Multimedia Application Format, Nice, France, October 2005.

[4] ISO/IEC 21000-4 IPMP Components FCD, ISO/IEC JTC1/SC29 WG11 MPEG68/N7196, Busan, Korea, April 2005.

[5] ISO/IEC 14496-12 & 15444-12: ISO Base media File Format, Amendment 1, ISO/IEC JTC1/SC29/WG11/N6596, Redmond, USA, June 2004.

[6] K.Diepold, F.Pereira, W.Chang. MPEG-A: Multimedia Application Formats. IEEE Multimedia, Vol. 12, No.4, 2005, p.34-41.

[7] Exchangeable Image File Format for Digital Still Cameras: EXIF Version 2.2, JEITA CP-3451, Standard of Japan Electronics and Information Technology Industries Assoc., Apr. 2002.

[8] House of Lords, Digital Images as Evidence, Government Response, Select Committee on Science and Technology, Eighth Report, June 1998.

[9] M. Pramateftakis, T.Oelbaum, K.Diepold: Authentication of MPEG-4 based Surveillance Video. International Conference on Image Processing (ICIP), Singapore, 2004.

Annex A

URN Structure for MAFs

urn:mpeg:maf:{usage}:{maf-identifier}:{name-string}:{year}

where

{usage} is regulated by MPEG N8945

{maf-identifer} is one of the terms listed in Table A.1, identifying the relevant part of ISO/IEC 23000

{name-string} is an optional US-ASCII string, unique within a given MAF, to describe the function of this URN, as necessary

{year} is regulated by MPEG N8945

Table A.1 – List of MAF identifiers

Specification {maf-identifier}

ISO/IEC 23000-2 musicplayer

ISO/IEC 23000-3 photoplayer

ISO/IEC 23000-5 mediastreaming

EXAMPLE 1 urn:mpeg:maf:schema:photoplayer:collection:2006

EXAMPLE 2 urn:mpeg:maf:cs:musicplayer:CollectionElementsCS:2007

EXAMPLE 3 urn:mpeg:maf:schema:mediastreaming:tva:2006

moving picture experts groupmpeg.chiariglione.org/sites/default/files/files/standards... · web...

Documents