W3C home > Mailing lists > Public > public-html-media@w3.org > January 2014

[Bug 24345] New: Remove "default-base-is-moof is set" requirement and clarify what "movie-fragment relative addressing" means

From: <bugzilla@jessica.w3.org>
Date: Tue, 21 Jan 2014 22:35:25 +0000
To: public-html-media@w3.org
Message-ID: <bug-24345-5436@http.www.w3.org/Bugs/Public/>

            Bug ID: 24345
           Summary: Remove "default-base-is-moof is set" requirement and
                    clarify what "movie-fragment relative addressing"
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: acolwell@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

I'd like to make the following changes to Section 4 of the ISOBMFF byte stream
format spec

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.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 21 January 2014 22:35:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:44 UTC