A Digital Broadcast Item (DBI) enabling metadata repository for digital interactive television (digiTV) feedback channel networks Artur Lugmayr, Anurag Mailaparampil, Florina Tico, Seppo Kalli, and Reiner Creutzburg Digital Media Institute, Tampere University of Technology, Tampere, Finland ABSTRACT Digital television (digiTV) is an additional multimedia environment, where metadata is one key element for the description of arbitrary content. This implies adequate structures for content description, which is provided by XML metadata schemes (e.g. MPEG-7, MPEG-21). Content and metadata management is the task of a multimedia repository, from which digiTV clients - equipped with an Internet connection - can access rich additional multimedia types over an “All-HTTP” protocol layer. Within this research work, we focus on conceptual design issues of a metadata repository for the storage of metadata, accessible from the feedback channel of a local set-top box. Our concept describes the whole heterogeneous life-cycle chain of XML metadata from the service provider to the digiTV equipment, device independent representation of content, accessing and querying the metadata repository, management of metadata related to digiTV, and interconnection of basic system components (http front-end, relational database system, and servlet container). We present our conceptual test configuration of a metadata repository that is aimed at a real-world deployment, done within the scope of the future interaction (fiTV) project at the Digital Media Institute (DMI) Tampere (www.futureinteraction.tv). Keywords: Multimedia asset repository, digiTV, metadata, XML, XML database, MPEG-21, digital broadcast object
1. INTRODUCTION AND RELATED WORK The Multimedia Home Platform (MHP) has been introduced by the Digital Video Broadcasting (DVB) initiative and published by the European Telecommunications Standards Institute (ETSI)6. It is a world wide opened standard covering the broadcast of digital interactive television (digiTV) services, relying on high-bit-rate MPEG-2 Transport Stream (TS), as standardized by the Motion Picture Expert Group (MPEG). Definitions, such as profiled broadcast, application programming interfaces, transporting of arbitrary content types, multiple video quality levels, data broadcasting, and multiplexing of “all-IP” protocols are part of the standard family and shall guarantee future operability between consumer- and broadcast devices. A digital television broadcast within Scandinavia (Europe) is based on a subset of ETSI’s recommendations, and is called NORDIG7. As digiTV is a multimedia environment, common definitions can be utilized: a multimedia asset convolves either content or metadata descriptions in form of audio, video, applications, XML files, applications, etc. 1.1. Interaction Modes In principal five participants in the value chain are present in the digital television broadcast value chain. The Programand Service Author provides multimedia assets to be broadcasted in arbitrary form (e.g. applications, movies, audio files, etc.). Putting multimedia assets into context means to invoke a Service Provider (SP), who would like “add-on” services during a broadcast (e.g. travel agency is announcing his new web-site for buying cheap flights). The actual playout is done by one or more Broadcast Service Provider (BSP)’s facilities. Thus the BSP provides the broadcast technology and acts as transmitter of multimedia assets. The Consumer requires contemporary hardware for video/audio decoding, and performing the life-cycle of multimedia applications, called Xlet’s based on Java technology2,3,17 in the world of digiTV. He might be connected to a home-network and home entertainment centre enabling technologies. In digiTV standards three different profiles of interactivity are defined to enable the consumer to “interact with multimedia assets”:
Further author information: (Send correspondence to Artur Lugmayr) A.L., A.M., F.T. SK.: email:
[email protected], Tel.: +358 (0)40 821 0558, Digital Media Institute, Tampere University of Technology, POB. 553, FIN-33101, Tampere, Finland. R.C.: email:
[email protected], Tel.: +49(0)3381 355 442, Digital and Computer Systems, Tampere University of Technology, POB. 553, FIN-33101 Tampere, Finalnd; and FH Brandenburg, Dept. Computer Science, POB. 2132, D-14737 Brandenburg, Germany.
•
•
•
Semi-interactive broadcast: data-only, high-bit-rate channels deliver the content to the consumer. Local interactivity is only enabled. Capability of data screens, thus pass-through to service provider is given. Example scenarios are information services, such as the Electronic Program Guide (EPG), weather-, news-, stock- market ticker. Another significant issue is the dealing of copyright law restricted materials. Interactive broadcast: the combination of several video-, audio-, and data-channels unsynchronized and synchronized is available. Unsynchronized video and data requires a very loose topical relation between data channels (e.g. news ticker during a news broadcast). Synchronization requires a more tight topical relation, and service authoring for a synchronized feedback (e.g. lottery application with a telephone as feedback line). Feedback enabled broadcast: complete Internet connection over an all-IP layer enables full network capabilities over wireless or wired Interaction Service Provider (ISP). The ISP usually provides typical Internet front-end capabilities over Internet protocol types, such as HTML, DVB-HTML, XML, etc.
1.2. The idea of this paper Within the scope of this paper we base our ideas of designing a feedback architecture for digiTV on a MPEG-21 based Digital Broadcast Item (DBI), which is a configurable, uniquely identified, described by a descriptor language, logical unit for structuring relationships among elements of broadcasted content by referencing to concrete resources of individual broadcast related assets. The end-user perceives it as one entity and as access point to a distributed service pool. DBIs are MPEG-21 based digital items that are especially configured for broadcast use4. We focus on the development of a Digital Broadcast Feedback Item (DBFI) enabled metadata repository. A DBFI is a sub-item of a DBI and covers feedback channel only requirements, where a Digital Broadcast TV Item (DBTVI) is mainly relevant for broadcasting content. Fig. 1 shows the basic idea for structuring these item types. Following topics are covered within the scope of this paper: • Brief introduction to the Digital Broadcast Item Methodology (DBIM) • Description of the overall logical feedback architecture • Explanation of the Digital Broadcast Feedback Item (DBFI) as metadata description of deploying services • Communication models and protocols between our DBI enabling feedback architecture and the consumer • Presentation of sample service deployed by this methodology
Figure 1. Root items utilized within the Digital Broadcast Item Methodology (DBIM) and their mapping to a distribution timeline.
1.3. Introducing the Digital Broadcast Item Methodology (DBIM) The Digital Broadcast Item Methodology (DBIM) shall unify several metadata structures under the umbrella of a digital item. Metadata is commonly used as term for “data about data”. Metadata consists of schemas, describing data structures, and instantiated files. The process of instantiating metadata schemas filling schema data structures with concrete data. Currently a well accepted metadata language is the eXtensible Markup Language (XML). It shall reference to multimedia content assets, control the broadcast- and feedback channel processes, contain information about the dynamic and static behaviour, complete digitalization of the value chain processes, provide consistency throughout each process, unify production and distribution, and enable platform independent service design at consumer side. The DBFI
shall only provide a general configurable service framework structure for a later concrete configuration of each item’s parameters during run-time of the system. Its character is more based on templates for future reference, where interoperability shall be guaranteed across multiple feedback network-, and consumer device architectures. The underlying principle is, information that is exchanged is based on a digital item, consisting of a unique identification, item description, and references to other multimedia assets. 1.4. Related work The basic framework for metadata based services is provided by the introduction of XHTML12, enabling the definition of XML1. On top of other different metadata languages are several other description schemes, such as MPEG-7 9, MPEG21 7, TV-Anytime10, etc. for different purposes, whose relevant key features get explained within the scope of this paper. Other multimedia asset types are MPEG-2, MPEG-4, java based applications2,3,17 etc. The architectural concepts for the deployment of web based services are exhaustively described within the documentation of the Apache Software Foundation’s projects18. For communication protocols between web service portal and clients we refer to SOAP5, IP, UDP, TCP/IP, HTTP, and binary XML streams11. Our own research works done within this field can be found in 23-27.
2. LOGICAL SERVICE ARCHITECTURE The principle of designing abstract logical service architecture for the digiTV feedback channel is relying on current solutions of web based portals. We designed a four tier model: • The Service Front End Tier establishes the service front-end visible to end-user devices, therefore is directly addressed and localized. Its major task is to perform user management, such as access control, and performing billing and accounting tasks. Service and usage monitoring capabilities enable the service provider to obtain server statistics and user profiles. Distinct service server (e.g. game server) is accessed through the front portal, which forwards requests upon access control. • The Service Control Tier pipelines user-requests upon rights clearing and transforms request as such, that back-end architectures are capable of their syntax. Advanced technologies provide emerging application scenarios for content manipulation, invoking of narrative structures and personalization efforts, metadata extraction etc. • The Multimedia Asset Tier establishes the back-end of the feedback service architecture. Its purpose is mainly the provision of large data storage for various content types. The access is controlled by a media compiler, that synchronizes accesses and forwards requested data in a useful manner. • The Consumer Tier’s purpose is to enable the consumer actually to interact with content, by providing an application run-time environment, metadata parsers, middleware software, system software, protocol stack implementation for network access, etc.
Figure 2. Three level multimedia asset feedback channel architecture for a digiTV environment.
In the value chain the service front end tier belongs to the delivery plane. The whole business logic is part of the first layer of the feedback architecture, thus user management, access control management, user-identification, right-clearing,
play-out and streaming facilities, billing and accounting, service distribution, performing calculations based on the interactions from the consumer, etc. Upon successful performing service access, play-out and interaction over multiple protocol types is enabled, such as e.g. IP, HTTP, SOAP, MPEG-2, binary metadata streams (e.g. MPEG-7 BiM), RTP. Service servers are available for performing concrete service tasks, such as acting as streaming solution, virtual gaming, chatting, etc. The service control tier covers more tasks in post-production, manly focusing on content packaging, and combination of different services to unique packages, thus digital items. By combining consumer’s interaction strategies and raw data stored in the multimedia asset repository, they group each multimedia asset type to a useful package together, that are adapted to the consumer hardware capabilities, and needs by a resource management system. Intelligent storage management and controlling multimedia asset repository access is the major purpose of this tier. A special focus is given to the back-end of this system, responsible for the storage of raw multimedia asset data. Raw data can be video, audio, services, etc. In our approach we mostly rely on a metadata repository, capable of storing native XML data or filling relational database data into predefined XML schemas. Multimedia content is stored in a content repository and can be referenced for future use within either a RDBS, or metadata repository.
3. MULTIMEDIA METADATA TYPES LINKING AND PACKAGING Different media description schemes are currently under investigation by MPEG. Two standards are currently emerging: MPEG-7 for managing content access and retrieval, and MPEG-21 for unifying the life-cycle of digital objects. MPEG-7 was formerly named “Multimedia Content Description Interface” and is primary utilized to describe multimedia contents in such a way, that they can be interpreted, accessed or passed by to other devices or program code7. In order to describe multimedia objects, MPEG-7 defines methods and tools for content description. Technical activities within MPEG-7 range from standardization of descriptors, description schemes, a Description Definition Language (DDL), to the binary encoding of descriptions. MPEG-7 DDL7 adopted the XML schema language for its design. MPEG-21 provides an abstract framework for Digital Item (DI) life cycle performance. DIs are defined as structured digital objects, including a standard representation and identification, and metadata7. The standard emphasizes digital rights management, content authentication, history of use, adaptation to multiple end-user devices, etc. W3C defined XML schemas are the basis for the MPEG-21 standard. DIs can be either exchanged between consumers or service providers. Multiple other multimedia descriptor schemes exist, but we rather focus on the two previous mentioned in our research work. 3.1. Linking and referencing multimedia metadata asset types Especially for a metadata based feedback architecture following XML based standards are relevant: • XPath: The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and boole. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values14. The syntax required to address parts and sub-parts of an XML document is provided due to the logical tree representation of each XML document, consisting of attributes, namespaces, and processing instructions. • XLink: The XML Linking Language (XLink), which allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of today's HTML, as well as more sophisticated links20. • XPointer: XPointer, which is based on XPath, supports addressing into the internal structures of XML documents and external parsed entities. It allows for examination of a hierarchical document structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position21. The correlation between XPointer and XPath standards is easy explained: if XPath is referenced to with an URI, then it is represented by an XPointer. This provides access to sub-parts and attributes of XML documents. However, XPointer defines additional features such as explicit and implicit search, defines search ranges and enhanced search attribute definitions. • XQuery: XML files shall be addressed like databases, therefore recommendations for adding such an XML based capability are in process by the W3C. The XML Query Language (XQuery) 22 enables to query information between web based documents and database. Expressions are either abbreviated syntax of XPath clauses or FWLR (FOR, WHERE, LET, RETURN) constructs. They are compatible with SQL queries for database access.
Figure 3. A Digital Broadcast Feedback Item (DBFI) metadata schema. It shall provide a basic framework for service deployment and aligning it to a timeline.
3.2. Digital Broadcast Feedback Item (DBFI) The DBFI shall structure services, configurations, dynamic- and static behavior of a deployed feedback channel service. The service definition is based on an extended MPEG-21 digital item declaration. The root element groups one or multiple services together to one object. Each DBFI consists of a description, sub-container, and sub-items for grouping different services together to one entity. The recursive characteristics of this item guarantee a consistent and unique identification of each sub-element throughout the deployment process. Descriptors for sub-elements can be based on other metadata languages, such as e.g. MPEG-7 or TV-Anytime. References to multimedia content assets maintain the requirement of a separation of metadata and content flows. Thus, the item itself represents a heterogeneous structure characterizing services, and defining an optional behavior description by mapping each sub-item on a timeline. This timeline can be synchronized either synchronized to broadcasted content, or other feedback services. Unique identification is implemented via a feedback architecture internal service identifier. To obtain interoperability to other identification schemes, a lookup table mechanism allows identifier transformation. The overall feedback architecture is capable of managing a DBFI throughout the whole deployment process. New services can be simply added by creating a new type containing configuration information into the overall architecture. For e.g. a simple chat server requires parameters such as port, IP-address, etc.
Figure 4. Flow diagram of a struts based front-end tier implementation.
Instanciated Digital Broadcast Feedback Item Within this service two video streams are streamed to the same client at different ports. Streaming of two pre-ordered video streams.
Figure 5. Programme listing of an instanciated DBFI.
4. MULTIMEDIA ASSET REPOSITORY TIER Designing a multimedia asset repository is a rather complex task. Metadata from multiple sources an in any form shall be stored there for future referencing. Also content and legacy database information requires to be dealt with. The metadata repository works entirely as catalyst in interconnecting different entities within the multimedia asset repository. Multimedia content and multimedia descriptions are stored separately, due to the separation of descriptive and content data (e.g. video, audio, graphic objects). 4.1. Basic requirements The design and implementation of an advanced multimedia asset repository has to fulfill the following requirements: • Fulfilling needs of services in a special context: each database system, either metadata- or relational based requires data structures fulfilling the needs of the special service type, determining the characteristics of the storage system. Examples are tables in a relational database containing information about customers, order lists, serial number, etc. • Internal and external database management: metadata servers provide capability for storing native and non-native XML objects. This enables utilizing those facilities also for content management, even though functionality might be restricted to simple ftp or http solutions. In our solution the metadata repository acts as bounding catalyst, between a content repositories based on HTML, and relational database system. • Metadata schema creation, instantiation, instance population, and storage of both (XML Schema, XML file): editing environments shall provide assistance in metadata schema creation, metadata instantiation, and metadata transformation. • Performing metadata transformations: transformation of one metadata format into another one, commonly referred to as XSLT in the world of XML, is entire requirement. This enables e.g. the transformation of an XML file into HTML for viewing.
• •
Provision of a query service: querying XML documents and its contents can only be realized by an effective interactive interface based on XPath or XQuery support for automatic or semi-automatic metadata asset resolution. Integration into existing database systems: support for invoking existing database system and content repositories.
4.2. Functionality of a metadata repository The basic functions of a metadata or XML enabled server is storing and referencing metadata instances and schemas for later publishing. Publishing is enabled via an HTTP connection to the public over the Internet or to other entities in the feedback architecture. Graphical statistics analysis tools support statistical evaluation and can be forwarded to the business logic of the service provider for further investigation. Persistent storage devices are a convenient form of transportation or long-term storage. A metadata repository offers a platform for maintaining the overall life-cycle of XML based metadata objects, and supports the building process of metadata based applications. The back end of each metadata repository consists of a relational database system, of any arbitrary type (e.g. relational- or object oriented database) for populating metadata schema’s data structures. The significant part is the correct building of database queries.
Figure 6 (left): Schematic overview of the integration of a relational database system. (right): Functional elements of a metadata repository.
4.3. Relational database system A relational database system represents an organized collection of data, represented in form of fields, records, and files. Each file is made up from multiple tables describing data types and data format. The actual data is stored within records, which can be related to each other with a common table identifier. The overall system is maintained via a Relational Database Management System (RDBMS), enabling data access, transformation, organization, selection, extraction, creation, and updating. To access database data, a common and very widely used query language is the Structured Query Language (SQL), defined by the American National Standards Institute (ANSI). SQL is our main query language utilized for providing access to data from each entity in the feedback architecture.
Figure 7. Snapshot of our database table list, consumer table fields, and relations between different tables.
During the design of our feedback architecture, we firstly defined the context and purpose of the database as back-end of the metadata repository, and solution for pass-through to the front end of the system for data access. Required tables for each developed service have been determined, where Fig. 7 shows a screenshot of our customer tables. Each table field,
holding information that should be kept in the database system has been filled with concrete data. A significant step was the determination of relationships between tables, and which new tables have been created for later investigation.
5. SERVICE ARCHITECTURE CONFIGURATION The entire feedback architecture implementation consists of mainly three completely realized tiers: consumer tier, service front end tier, and multimedia asset repository. During the realization we added service control functionality to the service front end tier, to avoid the involvement of more complex application server structures. Thus, by utilizing Apache’s struts framework18 and Java’s Servlet technology3 for the implementation of service front end, and service control functionality, we could achieve a heterogeneous solution to provide a sophisticated end-to-end service delivery. Fig. 4 showed the flow diagram of our struts based front-end implementation. Each service that is deployed within this framework is pre-defined in a DBFI. Based on pre-stored configuration of a DBFI and consumer interactions new services and configurations are added dynamically. To avoid the configuration of different feedback architectures for different consumer groups, we provided access for the following groups: Consumers, Broadcast Service Provider, Interaction Service Provider, Multimedia Home Network Server, and Service Provider. Each login leaded to different menus, as e.g. Fig. 10 shows the management screen for our broadcast architecture, and Fig. 9 the service access point page for consumers. Fig. 8 shows the principal blocks of the client implementation on a digiTV receiver box.
Content Repository
Metadata Repository
DEMULTIPLEXER MULTIMEDIA REPOSITORY CONTROL MODULE
ACTIVE CONTENT MODULE DEMULTIPLEXER
INTERACTION CH.
MULTIMEDIA MODULE
GFX MODULE
Figure 8. Functional overview of the intended client implementation.
SYNCHRONIZATION MODULE
ISP Internet Multimedia - HTML - Multimedia Content - MPEG-2 Stream - etc.
BSP MPEG-2 Multiplex - Video/Audio/Data - Metadata - Multimedia Content - etc.
MULTIMEDIA REPOSITORY
CONTENT BROWSER MODULE
INTERACTION MODULE
INTERACTION DEVICES
RENDERING SYSTEM
DISPLAY DEVICES
Table 2. Configuration of the overall feedback architecture.
Functionality Service Front End
Technology Apache HTTP Server V1.3.23 15 Apache Tomcat V4.0.2 15 Apache Struts V1.0.2 15
Service Control Servlet technology Multimedia Asset Repository
Tamino XML Server13 MySQL V3.23.52
Communication Protocols
SOAP V2.3.1 XML Binarizer V0.9 (own development of a MPEG-7 Systems subset) UDP, TCP, IP, HTTP, RTP
XML Editing Environment
XMLSpy IDE14
Figure 9. Screenshot of the consumer’s menu web-page.
Comments Web-server Servlet container deployment applications Tag library for providing a servlet deployment environment Library for servlet implementations for different services, and a generic general deployment framework Metadata native storage system Open source relational database system Communication in XML between front-end and consumer own development of a MPEG-7 system subset Standard deployment protocols for webbased services; RTP is used for video streaming, others depend on the deployed service
Figure 10. Screenshots of the BSP login management page.
ACKNOWLEDGEMENTS We would like to thank all the project team members of the fiTV project at the Tampere University of Technology, Hypermedia Laboratory at the Tampere University, and the Helsinki University of Technology. We thank them for all their help, discussions, and research materials.
REFERENCES 1. World Wide Web Consortium (W3C). Extensible Markup Language (XML). http://www.w3c.org/XML/ 2. SUN Microsystems, Java TV API 1.0, April 2000. Release Candidate D. 3. SUN Microsystems, Java APIs, http://java.sun.com/ 4. Lugmayr, A., Niiranen, S., Mailaparampil, A., Rautavirta, P., Oksanen, M., Tico, F. & Kalli, Applying mpeg-21 in digital television - example use scenarios: epostcard, egame, and eticket, 2002 IEEE International Conference on Multimedia and Expo, August 26-29, 2002, Lausanne, Switzerland. 5. W3C, Simple Object Access Protocol (SOAP), http://www.w3c.org/2000/xp/Group/. 6. Digital Video Broadcasting (DVB), TS101812 MHP: Multimedia Home Platform Specification 1.0. European Broadcasting Union, July 2000. Vers. 1.1.1. 7. ISO/IEC JTC 1/SC 29/ WG 11, MPEG-21, Information Technology – Multimedia Framework – Part 3: Digital Item Identification and Description. Sidney, July, 2001. 8. NORDIG, Nordig II Digital Integrated Receiver Specification for use in cable, satellite and terrestrial networks, Version 0.9, 2000. www.nordig.se. 9. ISO/IEC JTC 1/SC 29/WG 11, MPEG-7 Standard and Recommendations, Pattaya, December, 2001. 10. TV-Anytime Forum, TV-Anytime Standards and Recommendations, http://www.tv-anytime.org.
11. O. Avaro, and P. Salembier, “MPEG-7 Systems: Overview,” IEEE Transactions on circuits and systems for video technology, Vol. 11, No. 6, June, 2001. 12. W3C, XHTML 1.0: The Extensible HyperText Markup Language, http://www.w3.org/TR/xhtml1/ 13. Software AG, Tamino XML server, http://www.softwareag.com/ 14. XMLSpy IDE, http://www.xmlspy.com/ 15. http://www.apache.org/ 16. Connolly, T. M., and Begg, C. E: Database Systems: A Practical Approach to Design, Implementation and Management, 3 rd edition. Addison Wesley (2002). 17. J. Gosling, B. Joy, and G. Steele, The Java Language Specification, Sun Microsystems, second ed., 1996. 18. The Apache Software Foundation Project, Jakarta, HTTP-Server, Tomcat, Struts, http://www.apache.org/. 19. W3C, XML Path Language (XPath), Version 1.0. W3C Recommendation (1999). http://www.w3c.org/TR/xpath. 20. W3C, XML Linking Language (XLink), Version 1.0. W3C Recommendation (2001). http://www.w3c.org/TR/xlink. 21. W3C, XML Pointer Language (XPointer), Version 1.0. W3C Recommendation (2001). http://www.w3c.org/TR/xptr/ 22. W3C, XML Query Working Group (XQuery), http://www.w3c.org/XML/Query. 23. Lugmayr, A.R., Creutzburg, R., Kalli, S. & Tsoumanis, A. 2002. Face customization in a real-time digiTV stream. In: Kehtarnavaz, N. (ed.). Real-Time Imaging VI, 23-24 January 2002, San Jose, USA, Proceedings of SPIE. 4666. s. 18-29. 24. Lugmayr, A., Lyytinen, J., Mailaparampil, A., Tico, F., Maijala, S., Tuominen, S., Pihlajamäki, T., Rautavirta, P., Oksanen, M., Spieker, J., Niiranen, S. & Kalli, S. 2002. The future interaction tv project developing diet - digital interaction environment for tv. Proceedings of the 5th Nordic Signal Processing Symposium, NORSIG 2002, October 47, 2002, on board Hurtigruten, Norway. 6 s. 25. Niiranen, S., Lugmayr, A. & Kalli, S. 2002. Agent-based personalization in digital television. Proceedings of the 5th Nordic Signal Processing Symposium, NORSIG 2002, October 4-7, 2002, on board Hurtigruten, Norway. 6 s. 26. Lugmayr A., Creutzburg R., Seppo K., and Tsoumanis A. Manipulating premarked rectangular areas in a real-time digiTV stream utilizing MPEG-7 metadata descriptors. In Proc. SPIE Vol. 4862, p. 30-39. Internet Multimedia Management Systems III. John R. Smith, Sethuraman Panchanathan, and Tong Zhang, Eds. Boston, 2002. 27. A. Lugmayr, S. Kalli, R. Creutzburg. Synchronization of MPEG-7 metadata with a broadband MPEG-2 digiTV stream by utilizing a digital broadcast item approach. Real Time Imaging and System Components. SPIE. Seattle,2002.
