ISO/IEC JTC 1/SC 29

Projekta Nr.ISO/IEC 16500-6:1999
Nosaukums<p>This part of ISO/IEC 16500 takes a practical approach to the specification of Information Representation. Just the</p> <p>information types that cannot be dispensed with in producing the set of DAVIC applications (viz. broadcast, movies</p> <p>on demand, home shopping, etc.) are specified. The approach taken in this part of ISO/IEC 16500 starts by defining</p> <p>the various monomedia information types. They include character, text, fonts, service information, audio, video, and</p> <p>graphics. Consistent with DAVIC principles, one tool is selected for the encoding of each information type.</p> <p>Multimedia components comprise one or more monomedia components. This part of ISO/IEC 16500 defines the way</p> <p>in which multimedia information is coded and exchanged. This includes the definition of a virtual machine and a set</p> <p>of APIs to support interoperable exchange of program code. Finally, this part of ISO/IEC 16500 defines a Reference</p> <p>Decoder Model for contents decoding which provides constraints on content. The major problem addressed by the</p> <p>model is to ensure interoperability of applications by specifying memory and behaviour constraints for contents</p> <p>decoding by a hypothetical STU, without specifying the internal design of an STU. An application built according to</p> <p>the reference decoder model will be an "ISO/IEC 16500 conforming application" and will successfully execute on a</p> <p>STU that is compliant to ISO/IEC 16500.</p> <p>For each monomedia and multimedia component the coding format is specified, as well as applicable constraints for</p> <p>coding of the components. Three types of monomedia components are distinguished. Monomedia components which</p> <p>are included within other monomedia components, such as characters within text, are of type implied. Non-implied</p> <p>monomedia components that do not require synchronization with a time base at play back, are of type stand-alone.</p> <p>Finally, non-implied monomedia components of which the presentation may require synchronization with a time base</p> <p>are of type stream. This part of ISO/IEC 16500 defines which type each DAVIC defined monomedia component may</p> <p>take, and specifies that the coded representation of monomedia components of type stream are packetized in PES</p> <p>packets (for definition of PES packets refer to ISO/IEC 13818-1). PES packets permit (1) to include time stamps to</p> <p>support mutual synchronisation of multiple monomedia components in reference to a common time base and (2) to</p> <p>define timing and buffer behaviour in a common reference model for contents decoding. While there are various</p> <p>ways to deliver the monomedia and multimedia components to the STU, This part of ISO/IEC 16500 defines how the</p> <p>components are carried in an MPEG-2 Transport Stream.</p> <p>DAVIC specifies a number of different profiles. In a specific profile there may be support of a subset of the</p> <p>monomedia components. Each STU that complies to a specific profile of DAVIC shall be capable of decoding and</p> <p>presenting each monomedia and multimedia component permitted within that profile.</p> <p>This part of ISO/IEC 16500 also specifies methods for packaging of contents and metadata. The way in which</p> <p>content is packaged for delivery is independent of the way in which content data is delivered to the SPS (it may be</p> <p>delivered to a Service Provider either on physical media or over a transmission system). All programming content is</p> <p>represented in the DAVIC system as multimedia components. Multimedia components comprise one or more</p> <p>monomedia components coupled with the logical relationships between the monomedia components. The multimedia</p> <p>components will be created by content providers for input to the servers.</p>
Reģistrācijas numurs (WIID)31014
Darbības sfēra<p>This part of ISO/IEC 16500 takes a practical approach to the specification of Information Representation. Just the</p> <p>information types that cannot be dispensed with in producing the set of DAVIC applications (viz. broadcast, movies</p> <p>on demand, home shopping, etc.) are specified. The approach taken in this part of ISO/IEC 16500 starts by defining</p> <p>the various monomedia information types. They include character, text, fonts, service information, audio, video, and</p> <p>graphics. Consistent with DAVIC principles, one tool is selected for the encoding of each information type.</p> <p>Multimedia components comprise one or more monomedia components. This part of ISO/IEC 16500 defines the way</p> <p>in which multimedia information is coded and exchanged. This includes the definition of a virtual machine and a set</p> <p>of APIs to support interoperable exchange of program code. Finally, this part of ISO/IEC 16500 defines a Reference</p> <p>Decoder Model for contents decoding which provides constraints on content. The major problem addressed by the</p> <p>model is to ensure interoperability of applications by specifying memory and behaviour constraints for contents</p> <p>decoding by a hypothetical STU, without specifying the internal design of an STU. An application built according to</p> <p>the reference decoder model will be an "ISO/IEC 16500 conforming application" and will successfully execute on a</p> <p>STU that is compliant to ISO/IEC 16500.</p> <p>For each monomedia and multimedia component the coding format is specified, as well as applicable constraints for</p> <p>coding of the components. Three types of monomedia components are distinguished. Monomedia components which</p> <p>are included within other monomedia components, such as characters within text, are of type implied. Non-implied</p> <p>monomedia components that do not require synchronization with a time base at play back, are of type stand-alone.</p> <p>Finally, non-implied monomedia components of which the presentation may require synchronization with a time base</p> <p>are of type stream. This part of ISO/IEC 16500 defines which type each DAVIC defined monomedia component may</p> <p>take, and specifies that the coded representation of monomedia components of type stream are packetized in PES</p> <p>packets (for definition of PES packets refer to ISO/IEC 13818-1). PES packets permit (1) to include time stamps to</p> <p>support mutual synchronisation of multiple monomedia components in reference to a common time base and (2) to</p> <p>define timing and buffer behaviour in a common reference model for contents decoding. While there are various</p> <p>ways to deliver the monomedia and multimedia components to the STU, This part of ISO/IEC 16500 defines how the</p> <p>components are carried in an MPEG-2 Transport Stream.</p> <p>DAVIC specifies a number of different profiles. In a specific profile there may be support of a subset of the</p> <p>monomedia components. Each STU that complies to a specific profile of DAVIC shall be capable of decoding and</p> <p>presenting each monomedia and multimedia component permitted within that profile.</p> <p>This part of ISO/IEC 16500 also specifies methods for packaging of contents and metadata. The way in which</p> <p>content is packaged for delivery is independent of the way in which content data is delivered to the SPS (it may be</p> <p>delivered to a Service Provider either on physical media or over a transmission system). All programming content is</p> <p>represented in the DAVIC system as multimedia components. Multimedia components comprise one or more</p> <p>monomedia components coupled with the logical relationships between the monomedia components. The multimedia</p> <p>components will be created by content providers for input to the servers.</p>
StatussStandarts spēkā
ICS grupa35.040
35.040.40