International organisation for standardisation

5.1.2ISO/IEC 14496-12:2008/AMD 3 DASH support and RTP reception hint track processing

5.1.3ISO/IEC 14496-12:2008/AMD 4 MP4 files as a playlist using file tracks

5.2Contributions

Session	Number	Title	Source	Dispositions
File	m19532	Summary of Voting on ISO/IEC 14496-12:2008/FPDAM 2 and ISO/IEC 15444-12:2008/FPDAM 2	SC 29 Secretariat	Finland, Japan, Sweden, UK Accepted (N11919)
File	m20099	Comments on 14496-12:2008 DAM3	Miska M. Hannuksela	Accepted (N11920)
File	m20109	Random Access in 14496-12, the ISO Base Media File Format	David Singer	Accepted (N11922)
File	m20110	File Tracks (TuC) in 14496-12, the ISO Base Media File Format	David Singer	Accepted (N11922)
File	m19537	File Format-Support for Key Rotation	Sanjeev Verma, Bogyeong Kang	Accepted (N11921)
File	m20169	Study on ISO/IEC 14496-12 DAM3	Takehiko Nakano, Mitsuhiro Hirabayashi	Accepted (N11921)
File	m20186	Comments on Annex I in 14496-12:2008 DAM 3	Kevin Murray, Eyal Farkash, Eli Hibshoosh	Accepted (N11921)

5.3Summary of discussions

m19532

Thank you for the fine and detailed comments.

On the restricted-video coding comments from Finland, we agree:

1. 
   That the SEI box should be in Part 15; we will move it to the amendment of part 15, final ballot, when we issue that text. It has been reviewed here.
   
2. 
   That we introduce the frame packing restricted scheme here, but we re-issue the comment ballot on this amendment, to allow both review of this technology and review of its alignment with the Stereo MAF (23000-11).
   
3. 
   That we not do the file-format changes suggested that are not related to the restricted scheme (the documentation of the handling of frame-packed video when transformation is not mentioned).
   

With the documentation of the frame-packed scheme, we document that if it is used:

• 
  track header width and height are after unpacking and sample scaling, for a single view
  
• 
  frame_count is 1
  
• 
  width and height in the sample entry are for the packed frame (because this is what comes out of the decoder)
  
• 
  the pixel aspect ratio box should document pixels which are ‘wide’ or ‘high’ for side-by-side or top-bottom packing (inside the scheme information?)
  

m19537

Thank you. Accepted in principle, but without the extra data (which, if needed, could and should be in a new sample group with an identifying group type). Editors to incorporate into the study text.

m20099

Thank you for the nice C.8 material, which is much appreciated. Editors to check and incorporate.

Accepted to do the sample aux information typing, but we need a 4CC for common encryption (‘cenc’).
Yes, we introduce 8.16, with an introduction, for segments, and mention segments in the introduction (if appropriate). We also need an annex for the MIME registration of a segment. The actual mime type should be discussed at the co-located ad-hoc.
We will do a request for sub-division, common encryption, part of MPEG-B, with the support of Finland, Sweden, US, Israel, Germany, Japan, UK, Korea. File format editors to do the split after making the study, and supply as input to Torino.
m20169

On sample auxiliary information, we should allow it anywhere it would be legal; for data references, that really is anywhere. For same-file, yes, we say ‘typically’ within a media-data box or box defined by a derived spec.

Yes, we should follow the sample groups in movie fragments and add the appropriate boxes to the appropriate headers.
Yes, we will change “counter block” to “cipher block” and make sure that we use counter, etc. correctly.
We don't think we can change the way that AES-CTR is applied without alignment with DECE, who use this scheme. But there are issues – this would cycle the blocks faster, which increases the decryption cost.
m20186

Yes, we will document what other algorithm ID values mean, as suggested.

A number of people would like to work on partial encryption of other formats, and the signaling of partial encryption, before July. Co-ordination using the mp4-sys reflector is suggested.
20218 new SSIX

Accepted with minor textual fixes. (ranges_size -> range_size, etc.).

m20109 Random Access in 14496-12, the ISO Base Media File Format

The team really needs to analyze this further; did you miss a definition in amendment 3? We need good, file-format level, definitions, as indicated in the WD of Cor. More study, please.

m20110 File Tracks (TuC) in 14496-12, the ISO Base Media File Format

More support and thought are still desired on this TuC, but thank you for these comments.