International organisation for standardisation organisation internationale de normalisation

39.3Summary of discussions

39.4Action Points

40.Exploration

40.1Topics

40.1.1Uniform Timeline Alignment

40.2Contributions

Number	Session	Title	Source		Dispositions

40.3Summary of discussions

40.4Action Points

41.Liaison

41.1List of input liaison letters

number	Session	Title	Source	Reponse
m32760	Liaison	IEC CD 60728-101	IEC TC 100 via SC 29 Secretariat	None
m32761	Liaison	IEC NP: Digital Television Accessibility - Functional Specifications	IEC TC 100 via SC 29 Secretariat	None
m32762	Liaison	IEC CDV 62087-1, 62087-2, 62087-3, 62087-4, 62087-5 and 62481-6	IEC TC 100 via SC 29 Secretariat	None
m32764	Liaison	IEC TR 62921 Ed.1	IEC TC 100 via SC 29 Secretariat	None
m32765	Liaison	Liaison Statement from IETF	IETF via SC 29 Secretariat	None
m32766	Liaison	Liaison Statement from 3GPP	3GPP via SC 29 Secretariat	W14368
m32926	Liaison	Liaison Statement from EBU	EBU via SC 29 Secretariat	w14367
m32927	Liaison	Liaison Statement from SC 34	SC 34 via SC 29 Secretariat	W14380
m33096	Liaison	Liaison Statement from EBU	EBU via SC 29 Secretariat	W14373
m33175	Liaison	Liaison Statement on ISO/IEC 13818-1:2013/Amd.6: Delivery of Timeline for External Data	DVB	W14372
m33183	Liaison	Liaison Statement on Uniform Signalling for Timeline Alignment	DVB	W14374
m33290	Liaison	DASH-IF liaison to MPEG	[e-mail], Iraj Sodagar (on behalf of DASH-IF)	W14370
m33373	Liaison	Liaison Statement from DVB	DVB via SC 29 Secretariat	W14369
m33437	Liaison	ATSC Liaison to MPEG on DTS values for MVC	Walt Husak Anthony Vetro	W14375
m33485	Liaison	ATSC Liaison on MMT	Walt Husak	W14376
m33486	Liaison	Liaison Statement from BDA	BDA via SC 29 Secretariat	none

41.1.1m33290 DASH-IF liaison to MPEG

We think defining a track to carry these SEIs and extracting them from the video is the best low-intrusion solution, but converting them to a more modern format should be considered. If the SEIs position needs to be recorded, we would suggest looking at Extractors. The track timing could be copied from the video track (including re-ordering) or simplified to be in presentation order.

We could certainly add to 23001-7 section 11 a part that has a small schema and namespace for representing PSSH boxes in XML. Contributions welcome.

Summary:

• 
  Issue 3: Accuracy of Segment timeline when $Number$ used. No accuracy needed because it is overkill and the client doesn’t need to know the exact duration of the segment.
  
• 
  Issue 5:
  

5.1 Do clients reliably support parsing the emsg and act accordingly? Should it be required in a profile? Is notification of event schemes in an EventStream element in the initial MPD sufficient?

• 
  Response: Yes. It will be added to the new profile. So it’s Amd1 issue.
  

5.2 For DASH events using value=2, there are some open questions. In order to use this box, does the client have to apply the patch operation or can it fall back to value 1? How does the client know to which MPD this patch is the difference?

• 
  Response: Add the MPD publish time as a separate field. Accepted. Alex will provide the text.
  

5.3 We believe that for computing the URL using the $TIME$, a consistent requirement is necessary to either use the segment index or if the tfdt is used, that tfdt is equal to presentation time.

• 
  COR1 clearly indicates how to calculate the timing of each media segment.
  

5.4 Running through all details we identified that it is not clear how the buffering parameters: minBufferTime, suggestedPresentationDelay. We encourage MPEG to clarify their meaning in order to ensure interoperable implementations.

• 
  Response: Agree that the names are not the best choices. We encourage receiving contributions for Part 3 to clarify the use of these parameters.
  

5. 
   There was a very specific question on how Segment Timeline and Segment gaps work for live services. How can the client know when it can restart? We believe some clarification is needed.
   

• 
  Response: Agree. We need to clarify whether Segment Timeline can signal gaps with unknown duration. It will be captured in DuI and will be addressed by contribution.
  

41.1.2m32926 Liaison Statement from EBU

Thank you. The decoder behavior in fault situations (e.g. late arrival of media data) is out of scope of our specification, but your option 2 seems reasonable. We note that MP4Box (among other tools) supports 14496-30. Into the liaison to EBU.

41.1.3m32766 Liaison Statement from 3GPP

Disposition: Accepted. To be included in DuI.

Summary: remove “or more” from the SegmentList in the 23009-1 text (or any place that indicates multiple SegmentList can be used) since the schema only allows one.

41.1.4m33373 Liaison Statement from DVB

Disposition: Partially Accepted.

• 
  Respond to DVB that if p is not used, the t is from the beginning of the MPD.
  
• 
  Add an explanation and two examples to DuI.
  

Summary: The MPD anchor parameter p is not needed and DVB plans to remove it.

Recommendation: Clarify the text by adding example and explanation.