search

MPEGGroup / FileFormat

MPEG file format discussions
24 stars 0 forks source link

movie-fragment relative addressing #38

Closed cconcolato closed 1 year ago

cconcolato commented 3 years ago

While reading the 6th edition, I found the following issues:

It is not clear to me what the "Otherwise" corresponds to given the complexity of cases before. Then, what is the "file" when the movie is split into multiple files: moov in one file; moof in another one? What happens if the file containing the moof does not start with the moof, but contains an styp for example?

dwsinger commented 3 years ago

so

data_offset is added to the implicit or explicit data_offset established in the track fragment header.

should be

data_offset is added to the implicit or explicit base_data_offset established in the track fragment header.

as indeed the field in TrackFragmentBox is base_data_offset

?

dwsinger commented 3 years ago

While reading the 6th edition, I found the following issues:

  • Editorial issues:

    • To understand what it means, the text is spread out in multiple places (terms and definitions, tfhd definition, tfhd semantics, trun definition, trun semantics).

    • There are typos:

    • "The data origin that the base data offset is relative and the value of base_data_offset, when not present, are inferred as follows" is missing "to" after "relative"

    • In the trun semantics, the second occurrence of data_offset should be base_data_offset

    • Some formatting makes it hard to understand: e.g. the last paragraph of the tfhd definition should be split into 2 (and maybe expanded) as it talks about two different concepts; or the bulleted list in the tfhd definition should use multiple levels of indentation, one per if-level.

  • Technical issue: The last bullet point in the tfhd definition says:

Otherwise, the base data offset is relative to the file identified by the referenced data reference entry.

It is not clear to me what the "Otherwise" corresponds to given the complexity of cases before. Then, what is the "file" when the movie is split into multiple files: moov in one file; moof in another one? What happens if the file containing the moof does not start with the moof, but contains an styp for example?

When this was written there was no such thing as a segment file; fragments were in the same file as the moov box and addressed either recording or HTTP fast-start. The 'file' here is the concatenation of the file that contained the moov box and everything since, just as if the offset were in a chunk offsets box.

We need a name for this thing (the concatenation).

jeanlf commented 3 years ago

should be

data_offset is added to the implicit or explicit @base_data_offset` established in the track fragment header.

as indeed the field in TrackFragmentBox is base_data_offset

Yes I would say so. Additionally in tfhd definition we should change:

the base data offset is relative to the first byte of the payload of the IdentifiedMediaDataBox

to

the base_data_offset is relative to the first byte of the payload of the IdentifiedMediaDataBox

and change (independently of Cyril's remark)

Otherwise, the base data offset is relative to the file identified by the referenced data reference entry

to

Otherwise, the base_data_offset is relative to the first byte of the file identified by the referenced data reference entry

jeanlf commented 3 years ago

Then, what is the "file" when the movie is split into multiple files: moov in one file; moof in another one? What happens if the file containing the moof does not start with the moof, but contains an styp for example?

The issue is what is the "self" data reference for the following cases:

And the question is whether we want segment files to be processed as files and keep the base data offset relative to that file, or do we expect we will always use concatenation, and keep the base data offset relative to the file containing the moof (and this only makes sense if you always concatenate the same amount of bytes).

I would suggest we simply say that "If base-data-offset-present flag is set and the referenced data reference entry is the movie, the movie fragment and MovieBox shall be in the same resource (file, URN)." If one needs to deal with movie segment in dedicated files, use default-base-is-moof for the first fragment of each track.

dwsinger commented 3 years ago

I think we need to mark 'file relative' as only applying to single-file cases (notably recording), indeed. It's archaic, and not relevant otherwise.

mhannuksela commented 2 years ago

I agree on most things discussed above, but here are some detailed comments.

First, on Cyril's initial comment https://github.com/MPEGGroup/FileFormat/issues/38#issue-983181331:

To understand what it means, the text is spread out in multiple places (terms and definitions, tfhd definition, tfhd semantics, trun definition, trun semantics).

A new informative subclause under clause 6 could be added to clarify movie-fragment relative and other addressing modes in ISOBMFF.

Otherwise, the base data offset is relative to the file identified by the referenced data reference entry.

It is not clear to me what the "Otherwise" corresponds to given the complexity of cases before.

It corresponds to base-data-offset-present flag equal to 1 and the referenced data reference entry being neither DataEntryImdaBox nor DataEntrySeqNumImdaBox. This could be clarified in the text.

Then, on David's comment https://github.com/MPEGGroup/FileFormat/issues/38#issuecomment-962036316:

I think we need to mark 'file relative' as only applying to single-file cases (notably recording), indeed. It's archaic, and not relevant otherwise.

File-relative could also be useful when media data is stored in a separate file compared to the meta data. I'd propose to add after the otherwise condition:

NOTE: base-data-offset-present flag is advised to be set equal to 1 only if the file identified by the reference data reference entry is not transmitted movie-fragment-wise or the data reference entry is DataEntryImdaBox or DataEntrySeqNumImdaBox.

dwsinger commented 2 years ago

we draft text for the amendment

mhannuksela commented 2 years ago

Just uploaded a suggested draft text for amendment, see https://dms.mpeg.expert/doc_end_user/current_document.php?id=81237&id_meeting=189 (access to MPEG members only).

RufaelDev commented 2 years ago

I appreciate the contribution and I think it is correct, just a question on the current text in 6th edition compared to the 2015 edition, the 2015 edition states:

0x000001 base-data-offset-present: indicates the presence of the base-data-offset field. This
provides an explicit anchor for the data offsets in each track run (see below). If not provided and if the default-base-is-moof flag is not set, the base-data-offset for the first track in the movie
fragment is the position of the first byte of the enclosing Movie Fragment Box , and for second
and subsequent track fragments, the default is the end of the data defined by the preceding
track fragment. Fragments 'inheriting' their offset in this way must all use the same data-reference (i.e., the data for these tracks must be in the same file)

in the current text the case of the first fragment seems not to be handled anymore when base-data-offset and default-base-is-moof are 0 i.e. see the text below i could not find the condition of using default base is moof and base data offset to zero for the first fragment, see the current text below, i think this affects some smooth streaming implementations that use this. Was this condition removed intentionally ?

text from the 6th edition:

The data origin that the base data offset is relative and the value of base_data_offset, when not present, are inferred as follows:

So in the case of first segment and 0 for both flags i end up at the last condition which is different from what is written in the 2015 edition.

cconcolato commented 1 year ago

Closing as the 8th edition has lots of improvements around this text. Reopen if necessary.