Organisation internationale de normalisation

Contributions

Number	Session	Title	Source	Dispositions
m35248	File Format	Summary of Voting on ISO/IEC 14496-15:2014/DCOR 1	SC 29 Secretariat	Refer 14832
m35046	File Format	Optional codecs MIME parameter for L-HEVC in 14496-15	M. M. Hannuksela, V. K. Malamal Vadakital (Nokia)	noted
m35099	File Format	Suggested update to AVC/HEVC file format 14496-15	David Singer	Accepted 14839

3. Summary of discussions

   1. m35046 Optional codecs MIME parameter for L-HEVC in 14496-15

This is a complex problem; HEVC profile/level indications for layered coding document only the layer, not the closure of the necessary lower layers. The RFC implies (but doesn’t say) that the list is over all tracks (and all sample entries, if multiple in a track?). It does say that all sample entries must be listed. The RFC doesn’t say if the same codec is used twice in two tracks, is it listed twice?

There are questions on what happens when the enhancement is delivered separately, also (e.g. in DASH representations).

This raises lots of questions over corners of the RFC syntax, of course.

The base layer gets repeated, it seems.

The first 4CC should be the 4CC of the sample entry; subsequent ones would then document what else you need to do to decode an output layer set of that sample entry.

Do we need to repeat the capability requirement for each layer (even if already implied) or do we need to say explicitly “you need to be able to operate decoders at these layers simultaneously?”.

We do think that the syntax should start with the actual 4CC of each sample entry, i.e. be the other way around.

In summary, the syntax essentially says “to decode you also need , ” but those other streams may be in other tracks or even other files. And the might be repeated for different output layer sets from the same bitstream.

(Ideally someone defines a profile/brand for the file that establishes the ‘envelope’ requirement.)

We need to study whether we could use a new parameter to identify the rendering combinations for HEVC, rather than trying to overload the codecs parameter. Such a parameter would be in the MIME type in DASH (the codecs parameter is split out so it can be used for transport streams as well).

Note that canplaytype in HTML takes a qualified MIME string, so having this in some parameter is useful beyond DASH.

Can we explore a new parameter to express layered coding, and not overload “codecs”?

(Aside, have we documented the codecs parameter for encrypted content??) [Into the part 12 Defect Report! Though we need DECE input as they have considered this – Dave].

Can we explore a new parameter (with a suitable syntax)? Contributions welcome, and we would hope to go into the part 15 amendment at the next stage.

2.