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:
a size field on 4 bytes
a type field on 4 bytes
possibly a largesize field on 8 bytes
possible a UUID on 16 bytes
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.
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
Boxstarts with:sizefield on 4 bytestypefield on 4 byteslargesizefield on 8 bytesversionandflagsfields on 1+3 bytes if the type is a FullBoxThe
sizefield documents the size of the entire box including thetypeandsizeitself.So strictly speaking the
sizevalue should not be smaller than 8 (or more if UUID and/or FullBox). However, there are 2 special cases: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
sizefield to 0 is an error case, i.e. "MUST trigger the append error algorithm".The simplest clarification we could do is: Clarification 2: Setting the
sizefield to a value greater or equal to 2 and smaller than 8 is an error.We could also discuss if
largesizeshould be permitted at all. Does MSE support anmdatwith 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
sizefield indicates X+Y (Y>0). Such extensibility mechanism has been used in the past. For example, theavcCbox 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.