International organisation for standardisation organisation internationale de normalisation

Summary of discussions

1. m31207 HEVC file format: A bug fix on sub-parameters for the MIME type ‘Codecs’ parameter

Note that the contribution had an error; the ‘2’ is the flags, and it’s just bit-reversed. But they should be ‘6’ as Main is always Main10 compatible. To DCOR.

2. m31212 HEVC file format: On random access signaling

We will add some guidelines to 8.4.3 in the DCOR. We welcome input on any guidelines for alternative startup sequences. The guidelines will include a note that the leading samples would contain RASL access units.

3. m31213 File format for HEVC multi-layer extensions

This is a nice start; for item 6, we might prefer the MVC+D solution, if equally powerful, for consistency. Contributor to check. Into the WD of amendment with the MVC+D material. Thank you! We need work on sample groups for tiers etc., and inspection of Timed Metadata.

4. m31378 File format extensions for multi-layered HEVC coded sequences 

Excellent, thank you. To the integrated WD mentioned above. (5 week editing period). We go with the sample entries from 31213 for now, rather than a single ‘layered’ sample entry as here. We keep the profile/level etc. in the configuration record, since we want this to work without sample groups etc. and we can if the 4CCs are distinct.

5. m31375 Proposal for a new file format brand name for HEVC coded data

We need a new isoX brand, and notes in earlier brands, to cover whether or not these new features are required. Into a study of DAM3.

6. m31438 ISOBMFF Storage of Tiled HEVC Video

Into the WD. It would be nice to unify this with the storage of layers and multi-view, but we will not do this at this meeting.

7. m31442 On Independent HEVC Slices

This does seem like a problem for the RTP payload format (‘warning, slices may be out of order ahead’). Perhaps we need the same flag in the file format decoder config record, but it’s not obvious. How many decoders would, in fact, need the data re-ordered?

8. m31285 Comments on WD of 14496-15:2013 AMD2

Question: does the dependency flag need to say that this tile (set) can depend on the set with the same ID in the reference frame, or the any of the sets identified in the dependency list in the reference frame? This makes the dependency list and flag orthogonal (one does spatial, one does temporal). We realized, however, that the dependency list is ONLY needed to indicate whether this tile (set) has temporal dependency on other tile sets; the definition of tiles is that in a given frame they are spatially independent. Therefore we don’t think the new FLAG is needed, but the text for the dependency list needs adjusting to say the above – this set has a temporal dependency outside my own tile set.

9. m31395 Improvements to WD AMD2 of HEVC file format (14496-15)

There is a big snag here; maps set up a ‘pattern’ which applies to many samples. The use of byte offsets and sizes here makes that…unlikely. Perhaps sub-sample information, sample aux information, or temporal meta-data (all of which allow per-sample data) may be a better basis for the design?

The bug fix should go into the DCOR of Part 15. Thank you.

10. m31439 Inputs to WD of 14496-15 AMD2

We note that since the tiling is not required to be consistent across layers, we’ll need groupIDs that are fresh with each layer. Since tiles can depend on multiple layers, that means we need multiple dependencyIDs. Do we need something like the dependency_list in the ‘tsif’? It seems like a revised version of this could be included.
We note that the impetus for this work – that the tiling work should look ahead to scalable and multi-view coding, is important. We don’t want to do a re-design when we handle those.

11. m31434 Improved whitepaper for 14496-15

We seem to have lost one-pagers on the SVC and MVC file formats, with the site re-design. We should look for and at those before posting this. Editor to supply the missing diagram.

12. m31377 Constraints signalling in ISOBMFF for image sequences

In general discussion with JPEG over the ownership of work:

1. 
   for image sequences, timed or untimed, with or without audio etc. – ISO BMFF, work at MPEG
   
2. 
   for single still images, the simple case, maybe based on JPX (after much discussion), but there are some issues (no conformance or reference software for JPX per se, but for JP2 there is; new code-points needed); we are particularly interested in the subset of JPX that is also JP2
   
3. 
   there is a lack of EXIF support in JPX (and JP2 etc.) and the ISO BMFF, and it’s clearly needed; JPEG and MPEG both to look at improving this.
   
4. 
   we need to discuss tiling and how to handle that; both composing from multiple tiles, and de-composing into tiles
   
5. 
   MPEG to prepare the documents and intends to start PDAM/CD on at least some at this meeting (part 12/15 amendments, possibly a new part that integrates everything)
   
6. 
   MPEG and JPEG experts to study what conformance and reference software might be needed, and how it might be created
   

ITU-T T.800 is the JP2 spec, see Annex I for the JP2 file format, MPEG to study, JPEG to suggest what changes would be needed to identify the codestream and its profile as HEVC. (Note that there is also a COR; JPEG will supply the amendment for JPEG-XR, as an example. Note also there is a 3^rd edition imminent.)
We would like to explore EXIF storage (a) as a meta-data item and (b) as (possibly additional) timed meta-data tracks. This is overdue.

The options for a normal track with its handler changed (or some other tagging), a track without its timing, and the track outside the move box, possibly renamed sset, are so close we could usefully pick one, and keep the others in mind. We note that some people have wondered about directory-based movies – tracks in separate files. We note an stts with a constant frame duration is compact, and maybe harmless to include, and might document presentation or capture delay (e.g. time-lapse, slide show, or scientific high-speed shoot).

We are concerned over whether we need/want a ‘phase change’ between the single image case, and anything greater than 1. Do we want different structures? What is a track like, with only one sample? Are there ‘wins’ in compactness or functionality for each of the two phases – if not, we’d prefer not to have a phase change.
We are not trying to solve the general image catalog problem – ‘my home photo collection’ or even ‘all the pictures from my vacation’.
We seem to have 3 options for the single image:

• 
  use a track (or a track-like structure) with one sample;
  
• 
  use a Jp2/Jpx-like structure;
  
• 
  use a meta-box item.
  

For the sets of images, we could use:

• 
  a track outside the movie atom (an ‘sset’)
  
• 
  a track inside the movie atom, with a new handler (‘pict’);
  
• 
  a normal video track inside the movie atom, but tagged some other way (e.g. the new box from the third contribution).
  

Dave volunteers to explore (a) EXIF storage and (b) how to use our ‘meta’ box (mpeg-21 like) to store one or more images.

Do we need to do single image in either the same document or at the same time, or can it lag?
We need a document that has sections: storage of image sequences (pict handler, discussion of timing, and the new box(es) in the sample entry); empty section on ‘single’ still image storage; empty section on support for image meta-data (EXIF and maybe XMP). We do WD at this meeting, and fill in at least the meta-data at the next and go to CD/PDAM at the next meeting. The ‘pict’ track would be a part 12 amendment, perhaps? Perhaps ‘The HEVC Image File Format’ is a catchy title rather than a chapter in part 15?

4.