search

Dash-Industry-Forum / DASH-IF-IOP

DASH-IF Interoperability Points issue tracker and document source code
33 stars 8 forks source link

Unique period IDs for xlink-resolved periods #121

Open waqarz opened 7 years ago

waqarz commented 7 years ago

Being discussed here: https://github.com/Dash-Industry-Forum/Test-Vectors/issues/55

2 possible approaches; both have some issues:

  1. Make sure xlink resolved period provides unique IDs (e.g. using a server-side scripting based implementation; its probably a complex solution)
  2. Do not provide ID in remote element, use the one in the main MPD: does not work in general, only works for a single remote period.

Clarification needed!

waqarz commented 7 years ago

Option 1 has been currently implemented in DASH-IF test vectors

ZmGorynych commented 7 years ago

The most reasonable solution is unique period IDs in remote entities. Easiest implementation -- just use a UUID.

waqarz commented 7 years ago

The most reasonable solution is unique period IDs in remote entities. Easiest implementation -- just use a UUID.

A static UUID does not work in some cases, because the same xlink entity may be resolved more than once in the same MPD; in this case this unique ID will not remain unique anymore.

ZmGorynych commented 7 years ago

If we are resolving it differently, then dynamically generated UUID should suffice. If you need 1:1 uniqueness, you can use a hash (e.g. SHA or MD5) of the canonicalized Period element w/o the @id attribute, and use it as the @id value.

On Jan 31, 2017 1:33 PM, "waqarz" notifications@github.com wrote:

The most reasonable solution is unique period IDs in remote entities. Easiest implementation -- just use a UUID.

A static UUID does not work in some cases, because the same xlink entity may be resolved more than once in the same MPD; in this case this unique ID will not remain unique anymore.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/121#issuecomment-276450039, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxMZVHrZMRs0ydDSwCtsL0OLJUnkPo1ks5rX35egaJpZM4LoRVy .

acbegen commented 7 years ago

Was there a resolution on this?

waqarz commented 6 years ago

3rd edition Section 5.5.3 now says:

1) Only a single top-level element type of the same type as the MPD element shall be obtained from a remote element entity. However, multiple top-level elements of the same type may be obtained from a remote element entity unless explicitly restricted. All these elements shall have the same type as the element of the MPD containing xlink. If multiple top-level elements are obtained from the remote element entity, the elements shall be in appropriate order and the first element shall replace the element of the MPD containing the xlink. All additional top-level elements shall be inserted immediately after this element in the order in which they appear. Note: The remote element entity may be a non-valid XML document, when containing multiple top-level elements.

What are the implication on test content and conformance? not clear currently.