International organisation for standardisation organisation internationale de normalisation

21.4Action Points

22MPEG-V Architecture (23005-1)

22.1Topics

22.1.1ISO/IEC 23005-1 2^nd edition

22.2Contributions

Number	Session	Title	Source		Dispositions
m24722	MPEG-V	Editor's input on SoCD of 23005-1	Jae Joon Han, Sanghyun Joo	refer 3DG report

22.3Summary of discussions

22.4Action Points

23Control Information (23005-2)

23.1Topics

23.1.1ISO/IEC 23005-2 2^nd edition

23.2Contributions

Session	Number	Title	Source		Dispositions
m24776	MPEG-V	Proposal to modify scent capability and preference types (Part 2)	Jeong-Do Kim, Hyung-Gi Byun, Hae-Ryong Lee, Sanghyun Joo	refer 3DG report

23.3Summary of discussions

23.4Action Points

24Sensory Information (23005-3)

24.1Topics

24.1.1ISO/IEC 23005-3 2^nd edition

24.2Contributions

Number	Session	Title		Source		Dispositions
m24775	MPEG-V	Proposal to modify scent effect (Part 3)	Jeong-Do Kim, Hyung-Gi Byun, Hae-Ryong Lee, Sanghyun Joo		refer 3DG report

24.3Summary of discussions

24.4Action Points

25Virtual World Object Characteristics (23005-4)

25.1Topics

25.1.1ISO/IEC 23005-4 2^nd edition

25.2Contributions

Session	Number	Title	Source	Dispositions
m24777	MPEG-V	A technical background of the make-up avatar usage scenario	Sang-Kyun Kim, Yong Soo Joo, In-Su Jang, Jin-Seo Kim, Soon-Young Kwon	refer 3DG report
m24778	MPEG-V	Proposition of make-up avatar schemes for ISO/IEC 23005-4	Sang-Kyun Kim, Yong Soo Joo, In-Su Jang, Jin-Seo Kim, Soon-Young Kwon	refer 3DG report

25.3Summary of discussions

25.4Action Points

26Data formats for interaction devices (23005-5)

26.1Topics

26.1.1ISO/IEC 23005-5 2^nd edition

26.2Contributions

Number	Session	Title	Source	Dispositions
m24779	MPEG-V	Proposition of spectrum camera sensor schemes for ISO/IEC 23005-5	Sang-Kyun Kim, Yong Soo Joo, In-Su Jang, Jin-Seo Kim, Soon-Young Kwon	refer 3DG report
m25090	MPEG-V	Proposal to modify Scent Command type (Part 5)	Jeong-Do Kim, Hyung-Gi Byun, Hae-Ryong Lee, Chung-Hyun Ahn	refer 3DG report

26.3Summary of discussions

26.4Action Points

27Common Types and Tools (23005-6)

27.1Topics

27.1.1ISO/IEC 23005-6 2^nd edition

27.2Contributions

Session	Number	Title	Source	Dispositions
m24258	MPEG-V	Additional Scents for ISO/IEC 23005 - Part 6	Markus Waltl, Benjamin Rainer, Christian Timmerer	refer 3DG report
m25091	MPEG-V	Proposal to add Intensity Category CS with Scent (Part 6)	Jeong-Do Kim, Hyung-Gi Byun, Hae-Ryong Lee, Ji-Hoon Choi	refer 3DG report

27.3Summary of discussions

27.4Action Points

28Conformance and reference software (23005-7)

28.1Topics

28.1.1ISO/IEC 23005-7 2^nd edition

28.2Contributions

Number	Session	Title	Source		Dispositions
m24259	MPEG-V	Proposed Updates for ISO/IEC 23005-7	Markus Waltl, Christian Timmerer	refer 3DG report

28.3Summary of discussions

28.4Action Points

29Exploration

29.1Topics

29.1.1New File Format

29.2Contributions

Number	Session	Title	Source		Dispositions
m24970	MMT & FF	Considerations on an Improved File Format	Thomas Stockhammer	noted
m24980	MMT & FF	Exploring a new MPEG file format	David Singer	noted
m25109	MMT & FF	A New File Format and MMT Encapsulation	Sungryeul Rhyu, Kyungmo Stanley Park, Jeayeon Song	noted

29.3Summary of discussions

29.3.1m24970 Considerations on an Improved File Format

Thank you for this nice overview of our existing formats and their strengths and weaknesses. Are we talking ‘file format’ or is it more a packaging/encapsulation – yes, the latter. DASH is an example of a manifest-file-based approach; do we need a manifest? Some discussion of the drawbacks of the ISO BMFF. Should we have bi-directional convertibility, or only forward? Many workflows will want convertibility. The figure shows a real need for self-describing segments, that can carry all the information needed for time, key, overlap, etc. handling. How do you handle piece-to-whole mapping (e.g. time zero in ad 0, ad 1, and the main program), and the availability indicators (how much timeline can be played), and so on?

29.3.2m25109 New File Format and MMT Encapsulation

Thank you for this careful look at the MMT requirements and the ‘clean-up’ opportunities in ISO BMFF.

MMT MPU ≈ Fragment

MMT Asset ≈ Track/Segment

We explored naming/labeling, and the nature of these terms, and concepts, and what they hope to achieve, and the needs to package etc. for long-term and complete storage. MMT is mostly concerned about transport characteristics and presentation description. The MPU concept means that there is at least one random-access point in an MPU, and it has some timing that maps it into a global asset.

29.3.3m24980 Exploring a new MPEG file format

This contribution helped raise a lot of questions, and helped us identify ‘requirements’ as we asked “how does X work?”, and so on. Does this format need a manifest?

There were a number of areas that could use more thought (some detailed below as general questions):

• 
  we need to handle discontinuities (where either the program is continuous but the sequence numbers and/or timestamps are not, or the program material has gaps); do we need a ‘null’ codec?
  
• 
  handling stream splicing in general
  
• 
  do we need three orderings (storage, decode, and presentation), to handle layered scalable coding?
  
• 
  can we move some of the higher-level indexing etc. into side files?
  
• 
  do segments/fragments need better linking (link-back to initialization, or claiming to be part of the same presentation)?
  

29.3.4Moving ahead

We welcome contributions in the following areas:

• 
  how does X work, how do you do Y, and how do they compare across formats?
  
  • 
    manage recording, particularly with discontinuities?
    
  • 
    manage a simple locally playable file?
    
  • 
    dynamically add tracks (e.g. new bitrates, languages, etc.)?
    
  • 
    convert M2TS, MP4 and other existing content;
    
  • 
    integrate with the W3C MediaSource API?
    
  • 
    integrate with DASH as a media format under it?
    
  • 
    how do we handle layered, scalable, multi-view coding etc.?
    
  • 
    how do we handle the AAC and particularly USAC pre-roll and sync requirements (e.g. is the edit list really the right way to express the timing adjustment)?
    
  • 
    can we get closer to M2TS latencies, when needed, than the typical MP4 latencies?
    
• 
  can we meet the MMT use cases and requirements for encapsulation (or highlight where they need adjustment)?
  
• 
  analysis against the old MP4 requirements (1997)?
  
• 
  how does this compare to MP2TS, MP4, WebM/Matroska, MXF?
  
• 
  what do we need to DO with this? (record, local playback, network playback, DASH integration, MMT integration, FLUTE delivery, etc.)
  
• 
  can we extend/profile MP4, rather than invent something new? What is intrinsically ‘wrong’ with MP4? Perhaps we can make some (perhaps non-compatible) MP4 profiles?
  
• 
  what robustness requirements do we have (bit/byte/frame/fragment/segment…?)
  
• 
  how much better can we make a strawman (either starting from the one presented, or from some new ideas)?
  
• 
  in the strawman, how much of the tabular data can be delivered (a) ‘late’ (after the media) or (b) in s side-file or stream?
  

Options on the table seem to be:

1. 
   live with what we have, maybe compatibly enhanced; (maybe adding guidelines etc. for various use-cases);
   
2. 
   enhance what we have, profile it, maybe have some incompatibility;
   
3. 
   invent something new.
   

By investigating the questions above, and using the strawman as a ‘could be not worse than this’, we need to answer which of these three options we take (in the next meeting).