International organisation for standardisation organisation internationale de normalisation

21MPEG-4 AVC File Format (14496-15)

21.114496-15:2004/Amd.2

21.1.1Topics

1. 
   SVC File Format Extensions
   

21.1.215002 (Nokia) On the SVC File Format

Thank you for the very detailed read. The editors should work together to provide an editor’s draft input to the next meeting, dealing with the editorial and consistency issues, and we understand Finland will submit an NB comment supporting such an editor’s draft.

The basic technical changes outlined in the cover note seem acceptable.

21.1.312059 (Nokia) Buffering parameters in the AVC File Format

This was held over from Busan.

“12059 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.”

Editors to incorporate this.

21.1.4In Email

We have some inconsistency with the alignment of extractors in time, in the text. From Karsten Gruenberg:
We found some inconsistency in the definition of the extractors and their alignment with other samples.

In subclause A.6.1 (sample alignment of extractors) of w9283-svc-ff--avc-amd2-fpdam.doc,

there is the following definition:

Samples containing extractors _must_ be temporally aligned (in decoding time) with a sample in the track from which they extract. In contrast to that, Figure F.5 in the informative Annex F illustrates an example of 'overlapped samples' where the extractor at sample no. 1 is not aligned with any sample in the referenced track #0. This case typically shows up if an extractor references a layer representing a subset of the scalable bit stream at a lower frame rate. This may be a typical use case, thus it should not be restricted as done in A.6.1.
We suggest to change the text (paragraph 6. in subclause A.6.1) to:
All the tracks in the group sharing the same scalable base must share the same timescale, and samples that belong to temporal level zero and contain extractors must be temporally aligned (in decoding time) with a sample belonging to temporal level zero in the track from which they extract. Samples belonging to other temporal levels may contain extractors referencing non-aligned samples indicated by the sample_offset field (as defined in subclause B.3).
Accordingly, the second hanging paragraph in B.3.3 (Semantics of the Extractor) should be changed to:
track_ref_index: Specifies the index of the track reference of type 'scal' to use to find the track from which to extract data. The sample in that track from which data is extracted is temporally aligned or nearest preceding in the media decoding timeline, adjusted by an offset given by sample_offset as specified below, with the sample containing the Extractor. The first track reference has the index value 1; the value 0 is reserved.
Editors should also handle this. This is indeed an error.
Technical Work in Progress.

21.214496-15:2004/Amd.3? MVC FF

21.2.1Topics

1. 
   MVC File Format Extensions
   

21.2.214898 (Apple) MVC File Format considerations

This document raises, essentially, the high-level question: what are the specific problems and opportunities for the file-format level of MVC? We welcome more contributions asking questions at this level (and proposing answers).

Discussion of this brought up the following:

a) should the inter_view_dependency flag be reflected in the sample dependency table?

b) would SP and SI pictures enable view switching and view ‘entry’ (random access)?

c) how do we mark viewIDRs?

No changes to the TuC at this meeting.Technical Work in Progress.

22LASeR (14496-20)

22.114496-20/Amd. 2

22.1.1Topics

1. 
   Lightweight Application Scene Representation (SGVT1.2 Support)
   

22.1.2Contributions

M14780 : Ad Hoc Group on Scene Representation. Noted.

M14814 : Summary of Voting on ISO/IEC 14496-20:2006/FPDAM 2. See DoC.

M14852 : FNB comments on LASeR AMD2. See DoC.

M14997 : Editor's study of LASeR FPDAM2. Taken as input to produce final text.

M14941 : Editorial Comments on LASeR 2nd Edition. Taken into account in the 2^nd edition.
Technical Work in Progress.

22.214496-20/Cor 2

22.2.1Topics

1. 
   Profile Removal
   

22.2.2Contributions

M14798 : Summary of Voting on ISO/IEC 14496-20:2006/DCOR 2 [SC 29 N 8704]. See DoC.

M14995 : Editor's study of LASeR DCOR2. Taken as input for the production of the final document.

Technical Work in Progress.

2321000-9 MPEG-21 File Format

23.1MPEG-21 File Format Amendment

23.1.1Topics

1. 
   Mime Type
   

23.1.214799 Summary of voting

All approved. Good work, people!

23.1.314937 Austria NB Comments

Austria is an O-member and cannot submit comments. However, they have some comments, which were well received and incorporated into the next balloted document. We need a 3-letter file extension; “m21” seems to be available, even if it is associated currently with star clusters and assault rifles.

2421000-14 Conformance

24.1MPEG-21 File Format Conformance

24.1.1Topics

1. 
   Conformance
   

24.1.2Contributions

None.

25MPEG-A MAF (23000)

25.123000-4 Musical Slide Show MAF

M14782: Ad Hoc Group on MAF Under Development in Systems. Noted.

M14897: Guidelines for building on the Part 12 ISO Base Media File Format Specification. Noted. The Systems subgroup thanks David Singer for contributing this document which would be used as reference for further using the ISO Base File Format.