Handling of box size fields

[cconcolato]

Reading the BSF, I think there is a need to clarify the general box parsing behavior, specifically with respect to the size field. Let me recap.

In ISOBMFF a Box starts with:

1. a size field on 4 bytes
2. a type field on 4 bytes
3. possibly a largesize field on 8 bytes
4. possible a UUID on 16 bytes
5. possibly version and flags fields on 1+3 bytes if the type is a FullBox

The size field documents the size of the entire box including the type and size itself.

size is an integer that specifies the number of bytes in this box, including all its fields and contained boxes;

So strictly speaking the size value should not be smaller than 8 (or more if UUID and/or FullBox). However, there are 2 special cases:

• a value of 0:

if size is 0, then this box shall be in a top-level container, and be the last box in that container (typically, a file or data object delivered over a protocol), and its payload extends to the end of that container (normally only used for a MediaDataBox)

I don't think it makes sense to tolerate size-0 in MSE context.

Clarification 1: I would like to clearly document that setting the size field to 0 is an error case, i.e. "MUST trigger the append error algorithm".

• a value of 1:

if size is 1 then the actual size is in the field largesize

The simplest clarification we could do is:
Clarification 2: Setting the size field to a value greater or equal to 2 and smaller than 8 is an error.

We could change the value 8 depending on UUID and/or FullBox status if desired, but that's quite complex, see table below:

size == 1	type == 'uuid'	Is FullBox?	Minimum (large)size value (bytes)
false	false	false	8
true	false	false	16
false	true	false	24
true	true	false	32
false	false	true	12
true	false	true	20
false	true	true	28
true	true	true	36

We could also discuss if largesize should be permitted at all. Does MSE support an mdat with a size greater than 4GB?

More generally, we could simply say:
Clarification 3: If the size field of a box indicates a value less than the size of the fields known to the parser, the parser MUST run the append error algorithm.

Another important aspect is the behavior of a parser when the box contains more data than the parser understands. In other words, the parser knows how to parse X bytes but the size field indicates X+Y (Y>0). Such extensibility mechanism has been used in the past. For example, the avcC box has been extended in the past to include more data at the end of the box when an 'old' field has a known value.

Clarification 4: Parsers should discard unknown trailing bytes of a box and not trigger an error.

Finally, a box can contain other boxes so the size of the containing box is constrained.

Clarification 5: If the size of a containing box is less than the sum of the sizes (or largesizes if used) of its child box, plus its own header, it is an error.