International organisation for standardisation organisation internationale de normalisation

17.3Summary of discussions

17.3.1m32944 Conformance bitstreams for MPEG-4 File Format

Into the pending update for conformance, for cross-check. Maybe we could have a file that uses both restriction and encryption? Thank you!

17.3.2m33256 WD Text of 14496-12 Amd 4

For channel position, the bits need labeling and associating with the layout, and we need to link to the new position table, and also allow for explicit azimuth/elevation (and alas, 0 means left front, not reserved).

We need to look at extended language codes and supplementary audio tags as well (as defined by DVB 300-468), and possibly whether the track is coded in such a way as to support interaction. Contributions welcome.

17.3.3m32745 Summary of Voting on ISO/IEC 14496-12:2012/DCOR 2 and ISO/IEC 15444-12:2012/DCOR 2

All approved, thank you. (The Danish ‘comment’ is that they are abstaining.)

17.3.4m33084 Comment on 14496-12 4th Edition

Into an output Defect Report on 14496-12. We also have a bug in the ctts box, that says version=0 and then has an if (version==1) later.

17.3.5m33220 Considerations for TEMI in ISOBMFF

Seems like an interesting problem. We had documents on this subject before (uniform timeline alignment), and we’ll put this in the ad-hoc charter. Logically we have two problems: (optionally) labeling the times in this MP4 file, and then saying what the matching times are in the other stream (and maybe what it is).

17.3.6m33222 Tile Information in ISOBMFF

For now, into the amendment WD for part 15, but marked as intended for part 12. We clarify the width/height relationships when re-sampling occurs.

17.3.7m33081 Study of ISOBMFF Sample Variants

We discussed the requirements in the requirements session. It seems that this could document ‘the sample aux info for this 4CC is ’ and not need to define a new box for it. We are concerned with the new offsets, especially encrypted ones, and we hypothesize that the possible sources of variant sample bytes for a given sample are either the original sample or a pool of bytes specific to this sample. We wonder whether the variant information could be in a separate track, with time-parallel samples (some of which are empty, and some contain variant construction information). We note that this works for any encryption system, or indeed any system, where you can work out “I cannot handle the original sample as presented” (e.g. because I don’t have the key). We note that sample groups are good for ‘marking’ samples that have a characteristic (e.g. they have variant information), but the instructions are not re-used between samples, so the variant construction can’t be a sample group description. The variant-construction information is encrypted in order to obfuscate what a reader might do; it’s not easy to work out what will happen even if you know the keyIDs a reader has keys for.

We’d like to understand roughly what the ‘scale’ is (how many variants should we cope with, how many samples in a track might have variants, and so on).

We note that this should work in a DASH context but study is welcome.

Into a TuC output, to accompany the draft requirements.

17.3.8m33260 Carriage of Time Variant Encryption and Signature information in ISOBMFF and its Signaling in DASH

On signing tracks, there is no doubt we could work to define a signature metadata track, but we are concerned we don’t understand the use-cases well enough to do the definition so that it meets them.

On signing parts of files, we note that the CD of image carriage has some hash/signature provisions. But this is a general provision for box-structured files. The use of box-relative offsets is attractive, but it means that if someone fiddles with unsigned bytes such that the distance changes, but in fact the ‘important’ signed bytes have not changed. We may need to work more on the addressing/linking of signature to the signed data. We think that we’d go with just 64-bit support at this point, or use a flag rather than version if variation is really needed. Into the TuC for part 12.

17.3.9m33297 Partial ISO BMFF Structures

We are interested in working out why a standard would help here – where is the interop point? One possible is when files are partially received over multicast and then handed on or stored. Could this be abstracted from the format of the file itself, and just represent a ‘sparse file’, a file with pieces missing? Does it need to be tied to the (box) structure of the ISO BMFF? Maybe add this to the mandate of the Ad-hoc group to study?

17.3.10m33217 Relaxing Movie Fragment Sequence Number

We are looking at four possible solutions:

1. 
   brand, as suggested; this stops many players that could the file;
   
2. 
   make the box optional; players may well complain
   
3. 
   version or flag the box; the same players may well complain
   
4. 
   we could change the text; we could say that this can be used to check ordering or put fragments in order in environments where re-ordering might occur, and provide guidance on setting it, and let decoders decide whether they need to use it.
   

We tend to the 4^th, and put it into the defect report for study.

17.3.11m33219 Codec parameters for metadata and subtitle tracks

We make this into a liaison that outlines the problems, and who owns them, and suggest that the file format group stop at the level of identifying the format, and those formats own further sub-parameters. Liaison to W3C, SMPTE, EBU, DVB, DECE, DASH-IF. Authors to draft. Also a TuC to capture the decision on text tracks.

17.4Action Points / Ballots

ISO/IEC 14496-12:2012/DAM 3 (SC 29 N 13726)

Part 12: ISO base media file format AMENDMENT 3: Font streams and other improvements to file format

DAM (2014-04-13)