Organisation internationale de normalisation

ISO/IEC 14496-15:2013 AMD 2 Carriage of AVC based 3D video excluding MVC

This amendment provides file format support for AVC based 3D video excluding MVC, e.g., MVC+D, 3DV-AVC, MFC, and MFC+D.

2. Contributions

Number	Session	Title	Source	Dispositions
m36473	File Format	Layered HEVC file format design for ISO/IEC 14496-15	V. K. Malamal Vadakital, M. M. Hannuksela (Nokia)	Accepted N15480
m36474	File Format	Support of 3D-AVC in ISO/IEC 14496-15	M. M. Hannuksela (Nokia)	Accepted N15480
m36547	File Format	On the use of AVC and HEVC "unspecified" NAL unit types in file formats and systems	Ye-Kui Wang, David Singer, Gary J. Sullivan	Noted
m36549	File Format	Comments on layered HEVC file format	Hendry, Ye-Kui Wang	Accepted N15480
m36558	File Format	Fixing the oinf box in the Layered HEVC file format	Cyril Concolato, Jean Le Feuvre, Franck Denoual, Frédéric Mazé, Naël Ouedraogo, Eric Nassor,	Accepted N15480
m36560	File Format	Simplifications of the L-HEVC File Format	Cyril Concolato, Jean Le Feuvre, Franck Denoual, Frédéric Mazé, Naël Ouedraogo, Eric Nassor,	Accepted N15480
m36557	File Format	Clarification on the use of HEVC BLA and CRA Pictures in MPEG File Formats	Cyril Concolato, Jean Le Feuvre, Franck Denoual, Frédéric Mazé, Naël Ouedraogo, Eric Nassor,	Accepted N15881
m36170	File Format	Signalling DRAPs in the ISOBMFF	Richard Mitic	Noted

3. Summary of discussions

1. m36364 Comments on partial file storage

Disposition:noted

Thank you. We note that if files are ‘fixed up’, that may be at either or both at the ISO BMFF level, or at the encryption or coding level. Also when an ISO BMFF file is segmented, we like to be able to concatenate the segments; if one segment is damaged, it would be nice if it were still possible to concatenate the damaged and undamaged pieces, and have that be a ‘legal’ file that still documents the loss/damage.

2. m36611 Partial File Delivery - Status Update

Disposition: noted

Thank you for bringing in this information from 3GPP and IETF. This looks as if it handles the question of how HTTP can be used to transfer partial/damaged files. We may still have the question of how that is represented/stored (at either end). Note that this assumes that, given a partial file, we may need to serve it again over a protocol (in this case, HTTP). Is this a requirement?

3. m36584 Error Handling in File Format

Disposition: noted

Many questions about whether it’s better to alter box types or to encapsulate damaged structures, and adding hint tracks at reception time may be a complex operation. We also need to check whether a file that is missing e.g. fragments is formally compatible with current brands, and if not, it may be that we need to move some/all existing brands into an alternative location.

We note that though reception hint tracks worked in RTP, because we were receiving an RTP stream and constructing a new MP4 file at reception, it’s a little more tangled here – we are receiving an MP4 file and effectively transforming it at reception to insert a new (reception hint) track (if one needs to store or forward an MP4 file).

4.