search

MPEGGroup / CMAF

Official MPEG repository to discuss public issues on CMAF (ISO/IEC 23000-19)
2 stars 0 forks source link

CMAF fragment with no samples intended for presentation #28

Closed RufaelDev closed 2 years ago

RufaelDev commented 3 years ago

In some low latency cases short fragments may exist. In case an edit list is used to remove samples from the presentation timeline there are two issues

  1. if the edit is applied no samples may be available for rendering/presentation
  2. the earliest presentation time in sidx cannot be negative ?

Does it make sense to have restrictions on presentable samples in a cmaf chunk/fragment ? Does it make sense to document this corner case ?

cconcolato commented 3 years ago

Low latency and sidx are not typically used together. Can you elaborate on the use case?

But I agree that generally if the edit list removes media for a duration longer than the first segment you have a problem to write the sidx box as the spec says:

earliest_presentation_time is the earliest presentation time of any content in the reference stream in the first subsegment, in the timescale indicated in the timescale field; the earliest presentation time is derived from media in access units, or parts of access units, that are not omitted by an edit list (if any);

but is it really a technical problem or simply editorial. For example, saying that it is the earliest presentation in the first subsegment that has presentable information could suffice? Is there really a problem if a segment contains no presentable samples? a) it's rare, edge cases as you say and b) I would assume that the player will receive the next segments with presentable samples.

RufaelDev commented 3 years ago

Yes when using DVB-DASH the sidx can be present at the beginning of a segment, also there may be VoD presentations with larger edits (surpassing the fragment duration) resulting in a negative ept, potentially crashing implementations of sidx box. Documenting the recommended value of ept in such cases may help avoid this. Perhaps this issue should go to ISOBMFF instead ?

cconcolato commented 3 years ago

Yes, I would suggest closing this issue and opening a new one on ISOBMFF.

cconcolato commented 2 years ago

I think this problem is being discussed in https://github.com/MPEGGroup/FileFormat/issues/30

RufaelDev commented 2 years ago

@cconcolato makes sense to close it here

cconcolato commented 2 years ago

Closing it now, we might reopen an issue after the discussion in ISOBMFF concludes.