DASH-IF-IOP
DASH-IF-IOP copied to clipboard
Dash-Industry-Forum
Deprecate startsWithSAP
Based on the comments in #235 it appears to me that determining the SAP type of a representation is nontrivial, requiring the packager to inspect the sample structure in order to determine the right value.
This required effort needs to be weighed against the benefits it provides.
As far as I can tell, it provides no benefits at all.
Everyone uses SAP=1/2 for all interoperable content. Indeed, all our codec chapters say this is mandatory. So why have this value present at all? Let's get rid of it. Can we? Yes.
DASH allows it to be omitted, default to value 0 the meaning of which is undefined. It also says "can be ignored" value is not 1/2, which is fine as this ignoring is not a hard requirement and upon a review of open source players, I found exactly zero that care about startsWithSAP whatsoever.
I propose that in IOP v5 we state that startsWithSAP SHOULD NOT be emitted by services and SHALL NOT be used by clients.
In IOP v4 and DASH there is no hard requirement to include this but the "may be ignored" could be read to be one. What I propose is taking a stance that this "may" should not be applied for interoperable services and clients, relieving them of the effort of having to determine the right value (for no reason other than spec conformance).
To be clear, IOP would still say "use SAP type 1/2" because that is important but there is no need for packagers to emit this useless information in the MPD.
Deriving the SAP type is not very difficult for a packager, if follows straight from the decode and presentation timelines. I am wondering what would be the benefit of deprecating this and eventually breaking backward compatibility as there is already a lot of content out there and some players may use this. Also for other codecs not yet considered it might still be relevant. Therefore, I would recommend to be carefull with removing this.
Deriving the SAP type is not very difficult for a packager
There are different types of packagers, some of which operate on already segmented content and potentially never need to look inside the ISOBMFF structures. Parsing the sample timestamps just to determine SAP type 1 or 2, for this information to then be ignored by players, seems like a waste of time.
some players may use this
Do you have specific examples? I was unable to find any but I only inspected the popular open source players.
If you use CMAF, then you can always set it blindly to 2 as 2 is the superset. Should you know more, you may use 1. That's it. We can write this down.
If we can always hardcode 2 then this attribute is pointless and should not be used, hence my proposal here.
Does anyone know of clients that care whether the MPD says 1 or 2? That is, clients that act differently based on the value of this attribute?
(IOP - 19/05/14) Review this together with the CMAF profile at f2f meeting
SAP=2 is needed. It is a good encoder optimization for scene changes, used by some well-known commercial H.264 implementations. Figuring out whether something is type 1 or 2 is trivial. I doubt a client cares whether something is 1 or 2.
I doubt a client cares whether something is 1 or 2.
Exactly. This is why this attribute is irrelevant. I propose we take whatever are the necessary steps to get rid of this needless burden in the MPD.