This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
MSE requires that media segments use the "default-base-is-moof" flag in the movie fragment. However, conformant ISOBMF parsers require that an ftyp box with a compatible brand 'iso5' be declared to process the flag. While MSE ISO parsers can be modified to assume that a correct ftyp has been declared (or modified to ignore that rule), this can create ISO interoperability problems if MSE byte streams are stored in files. A conformant ISO parser will have no means to tell if the file is the result of storing an MSE byte stream or if it is an ISO v1 file (no ftyp). An ISO validator might also declare the file invalid. To avoid these interoperability problems, MSE should: - define a brand for initialization segments and media segments (e.g. msei, msem) - recommend that an ftyp (with the right brand) be added if an MSE initialization segment byte streams is stored in a file - recommend that if an MSE media segment is stored in a file, and if an styp box is used, that the styp box uses the above brand No change to the MSE parsing behavior is required.
I have no problem making recommendations, although anyone who wants to write an ISO file should know its their responsibility to make the file compliant: they can't just expect to take some arbitrary collection of boxes received over MSE and have it make a compliant file. Why do we need a new brand, though ? Aren't the existing brands sufficient ?
Marking all pre-Last Call bugs
I don't really think we should be specifying a file format. The bytestream specifications were designed to allow the minimal useful subset of existing file format elements to be fed into the UA. It was never designed to act as a storage format. In fact some of the power comes from the fact that you don't need unnecessary stuff like ftype,styp, or indexes. I believe specifying a storage format is out of scope for the MSE spec.
(In reply to comment #1) > I have no problem making recommendations, although anyone who wants to write > an ISO file should know its their responsibility to make the file compliant: > they can't just expect to take some arbitrary collection of boxes received > over MSE and have it make a compliant file. Mark, I agree it's their responsibility but I still think the recommendations are not unnecessary. > > Why do we need a new brand, though ? Aren't the existing brands sufficient ? The new brands may not be necessary. It's more of a good practice and may prove useful in case MSE byte streams diverge from ISOBMF. (In reply to comment #3) > I don't really think we should be specifying a file format. The bytestream > specifications were designed to allow the minimal useful subset of existing > file format elements to be fed into the UA. It was never designed to act as > a storage format. In fact some of the power comes from the fact that you > don't need unnecessary stuff like ftype,styp, or indexes. I believe > specifying a storage format is out of scope for the MSE spec. MPEG-2 TS was never meant to be a file format either, yet you find m2t m2v mpeg2 ... files on servers. I don't want MSE to specify a full-fledged file format, just make some recommendations to avoid creating a format mess. I'm saying people will store MSE byte streams as files. We should be pro-active here to avoid problems in the future.
MSE is about how data is buffered into a media element. Where the data comes from, how it is stored, how it is transferred, and what other purposes people have for the data is out of scope. The only resolution I could see for this bug aside from resolving WORKSFORME is to add a note to the spec that reaffirms that the document does not define a storage format and that readers should not interpret that it does. Personally, I don't think this is necessary.
(In reply to comment #5) > MSE is about how data is buffered into a media element. Where the data comes > from, how it is stored, how it is transferred, and what other purposes > people have for the data is out of scope. > > The only resolution I could see for this bug aside from resolving WORKSFORME > is to add a note to the spec that reaffirms that the document does not > define a storage format and that readers should not interpret that it does. > Personally, I don't think this is necessary. It's easy to add such a note, and since some readers may think otherwise, I'd suggest adding it.
Changes committed https://dvcs.w3.org/hg/html-media/rev/63675668846c Added a note indicating that the byte streams specs are not intended to define a storage format.