24345 2014-01-21 22:35:25 +0000 Remove "default-base-is-moof is set" requirement and clarify what "movie-fragment relative addressing" means 2014-03-03 23:46:59 +0000 1 1 1 Unclassified HTML WG Media Source Extensions unspecified PC All RESOLVED FIXED P2 normal CR 1 acolwell adrianba cyril.concolato jer.noble mike public-html-media public-html-bugzilla oldest_to_newest 98851 0 acolwell 2014-01-21 22:35:25 +0000 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." I believe this will more clearly indicates "does not use movie-fragment relative addressing" and allows MSE to accept files that use relative addressing, but don't specify the default-base-is-moof flag. Chrome has never enforced the "default-base-is-moof is set" requirement and a large amount of YouTube content does not have this flag set. Requiring this flag be set only marginally reduces implementation complexity and existing MP4 implementations likely handle the "default-base-is-moof not set" case anyways. FWIW, I also believe making this change will also allow certain legacy SmoothStreaming content to work now with MSE. 99145 1 cyril.concolato 2014-01-27 10:34:29 +0000 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. 100023 2 jer.noble 2014-02-07 17:18:48 +0000 (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. 100084 3 acolwell 2014-02-08 16:58:18 +0000 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'. 101800 4 acolwell 2014-03-03 23:46:59 +0000 Change committed https://dvcs.w3.org/hg/html-media/rev/cad94fce3b90