International organisation for standardisation organisation internationale de normalisation
Download 3.13 Mb.
|
- Navigate this page:
- 8.1.2Contributions
- 8.214496-15:2004/Cor.1
7.214496-12/Cor.27.2.1Topics
7.2.2ContributionsTechnical Work in Progress. 8MPEG-4 AVC File Format (14496-15)8.114496-15:2004 Amd.18.1.1Topics
8.1.2ContributionsM12043: ISO/MP4 File Format for Storage of Scalable Video. Thomas Rathgen. Peter Amon. Andreas Hutter M12057: Storage of scalability information in file format. Ye-Kui Wang, Miska M. Hannuksela M12062: Proposal to support the storage of SVC streams in the AVC File Format.Mohammed Z Visharam, Ali Tabatabai. These three documents received extensive discussion both here and in the joint session with the video group (for which see the video minutes). First we considered the requirements in W6880 and made comments on them: Requirement 1: The file format should support maintaining the maximum scalability flexibility (easy addressability of all possible “scalability subsets”). Example: In some application cases the full adaptation flexibility must be preserved along the transmission path. In other applications a layered representation of the transmitted bitstream provides simpler adaptation mechanisms (e.g. on a network node). Comments: Not all the proposals support FGS and ROI scalability (partly because these are still being developed), but further work on them might. We need contributions on the level of support that is appropriate in the file format for FGS and ROI, and then contributions that show how to provide that support (if any). Requirement 2: The file format should support both the efficient transmission of fully scalable SVC stream as well as the efficient mapping from a fully scalable representation to a layered representation (e.g. hierarchical hint tracks). Note: The term ‘fully scalable representation’ refers to a description of multi-dimensional scalability points of the scalable video format, where all scalability axes (temporal, spatial, SNR) are accessible independently of each other, preserving maximum scalability flexibility (combined scalability) of the scalable video format. The term ‘layered representation’ refers to a description of a pre-defined sub-set of scalability points on a one-dimensional extraction/adaptation path. Comments: No proposals currently explicitly address hinting, the formation of multiple hint tracks for scalability, possible hint track extensions to support scalability, or the labeling of hint tracks to declare what layers etc. they contain. Hinting is, of course, not required for transmission, and it is possible to construct delivery systems that do not require hint tracks. Contributions on the transformation of file format data to streams, and that interaction with adaptation, might help clarify this area. There are at least partial solutions in some of the contributions, but some verification may be appropriate. Requirement 3: The file format should be backward compatible with the AVC file format. Example: It should be possible to access and to decode the AVC compatible base layer without knowing about the file format extensions for SVC. Comments: All proposals intend to achieve this. Some verification may be appropriate. We read this as meaning that a ‘classic’ AVC reader can read the track. There is some concern that if all the data is within one track (stream), the AVC reader will ‘see’ all access units, some of which might contain no base-layer data. Similarly the overall declarations on the track (e.g. its width and height) would have to be backwards-compatible (i.e. describe the base layer). There is possibly a difference between structurally compatible and functionally compatible. Requirement 4: The file format should support efficient extraction of the desired portion from the SVC bitstream (“linear storage”). Example: When accessing a scalable media file, probably a large amount of the data in the file is not necessary for the desired quality. Unnecessary read operations should be kept at a minimum. Comments: The current approach of all contributions is to store all the data in one track (stream), so declarative data might help readers skip un-needed data. However, this is at best on an AU-by-AU, NALu-by-NALu basis, and may not be very efficient. Certainly any reader that reads whole samples (AUs) or chunks from the track would read all data for all layers. The group decided to form an outline of the desired specification text, without any body text. We recognize that much of the text in the three contributions is suitable for use in the body and welcome contributions based on the supplied outline, that build on these contributions, synthesizing from them, to make a working draft. We expect to adopt a WD at the next meeting, and to decide whether the SVC file format is a new part or an amendment to 14496-15 (AVC File Format) (or something else). We also recognize that the high-level SVC syntax (e.g. of NAL Unit headers) is still under discussion and this impacts our work. (Note that there are also comments on these contributions in the video report as a result of the joint session.) Output document: Skeleton of SVC File Format specification Other AVC File Format Issues M12059: Storage of AVC buffering parameters in AVC file format. Ye-Kui Wang. Miska M. Hannuksela Held over to next meeting to manage with the SVC file format, if that is an amendment. Align with 3GPP so we don’t have two slightly different ways to do the same thing in the industry. Technical Work in Progress. 8.214496-15:2004/Cor.18.2.1Topics
8.2.2ContributionsM12055: Corrigenda items to AVC file format. Ye-Kui Wang. Miska M. Hannuksela. David Singe. Most of these corrigendum items were accepted. The editor was asked to make a study of corrigendum as an output document, request corrigendums for both documents. Experts are asked to contribute any other corrigendum items at the next meeting, when DCORs are expected to be produced. Technical Work in Progress. Directory: sc29 -> open -> 29view 29view -> International organisation for standardisation organisation internationale de normalisation 29view -> International organisation for standardisation organisation internationale de normalisation Download 3.13 Mb. Share with your friends:
|