I agree. What's important is to make sure that the base-data-offset-present flag is not set. Your text also removes the ambiguous "movie-fragment relative addressing" term. I'm fine with it.

(In reply to Cyril Concolato from comment #1)
> I agree. What's important is to make sure that the base-data-offset-present
> flag is not set. Your text also removes the ambiguous "movie-fragment
> relative addressing" term. I'm fine with it.

(In reply to Aaron Colwell from comment #0)
> I'd like to make the following changes to Section 4 of the ISOBMFF byte
> stream format spec
> (https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/isobmff-
> byte-stream-format.html#iso-media-segments)
> 
> Current text:
> "The Movie Fragment Box does not use movie-fragment relative addressing or
> the flag default-base-is-moof is not set."
> 
> Proposed text:
> "At least one Track Fragment Header Box(tfhd) has the
> base-data-offset-present flag set."

While this is a step in the right direction, I believe this goes too far.

The intent of the default-base-is-moof flag is to keep readers from having to completely parse previous 'traf' boxes in order to determine the offset of subsequent 'traf' boxes.  

If two or more 'traf' boxes are contained within the same 'moof' box, and both have base-data-offset-present = 0 and default-base-is-moof = 0, the first 'traf' will be relative to the enclosing 'moof', but the second 'traf' will be relative to end of the data in the first 'traf'.  IOW, the first 'traf' uses "movie-fragment relative addressing" and the second 'traf' does not.

So loosening up the restrictions from 'must have default-base-is-moof' to 'cannot have base-data-offset-present' goes too far.

Here is my counterproposal:

Current text:
"The Movie Fragment Box does not use movie-fragment relative addressing or the flag default-base-is-moof is not set."

Proposed text:
"The Movie Fragment Box does not use _movie-fragment relative addressing_."

and later:

"A Movie Fragment Box uses _movie-fragment relative addressing_ when either of the following conditions are met:
  * Every Track Fragment Box in the Movie Fragment Box has the ‘default-base-is-moof’ flag set
  * The Movie Fragment Box contains a single Track Fragment Box and that box does not have the 'base-data-offset-present’ flag set."

This makes the definition of "movie-fragment relative addressing" unambiguous, and loosens up the restriction only enough to cover the YouTube case.

I'm fine with Jer's proposal, but I believe it also means that we'll have to require that the data-offset-present flag be set on the first Track Fragment Run ('trun') box in every 'traf' box that is present in the 'moof'. If I understand the spec correctly, the 'moof' relative addressing only comes into play if data-offset-present is set in a 'trun' box. Otherwise if no 'data_offset' fields are present in any 'trun' boxes, the positions are relative to the beginning of the 'mdat' box that follows the 'moof' and each 'trun' requires parsing of the previous 'trun' even if that 'trun' is in a previous 'traf'.

Change committed
https://dvcs.w3.org/hg/html-media/rev/cad94fce3b90