Summary of discussions m31462
Summary of CE: The usecase and inputs were discussed. We beleive that the CE must focus on solving the main usecase descriobed in m31464.
Recommendations:
-
limit the CE in the following usecase:
-
How to signal info needed for client authentication and access authroziation.
-
Rename the core experiment to above and update the CE description:
“DASH Client Authentication and content access authorization”
m31603
Report of CE, summarizing the above contributions. It provides two method of identifying the tiles: pixel and grid coordinates.
Disposition: Noted.
Recommendation:
-
After evaluation, we recommend to use only pixel number which is also a logical expression of relative location and size of tiles.
-
To signal the tiling, we have two options:
-
Essential/Supplementary property or profile
-
For profile, the question is which new profile or how to tie it with existing profile, i.e live+SRD, or on-demand+SRD.
-
If a new profile defined, still required client resources (i.e how many decoders) is not clear.
Therefore, we recommend using the Essential/Supplementary property descriptors in the following way:
-
Require at least one adaptation set that does not have the essential property, i.e a legacy player still have a valid result MPD after validating the MPD (independent to this CE, add to conformance).
-
The @value also include a parameter showing source id.
-
Clarification on the fact that for each element, the client has to process at least one essential property descriptor (independent to this CE, add to conformance).
-
The adaptation set that represents the full video, can use supplementary property to tie to other SRD adaptation sets.
-
The advantage is that this method is orthogonal to all profiles.
-
This means that the presentation can be augmented with tiles, but does not require the client to stream all tiles or capable of decoding multiple video streams.
We also recommend:
-
The above solution to be added to TuC.
-
To update the CE scope and description to cover the followings (m31705):
-
HEVC tiling vs SRD, how to signal HEVC tiles in DASH.
-
Additional parameters for signalling default and priority tiles.
m31673
Summary: Report of the CE.
Disposition: Noted.
Recommendations:
-
Close the CE.
-
After reviewing the proposed solution, we recommend using a specific @codec parameter per metadata track/adaptation set in conjunction with @dependencyId flag indicating the association from metadata tracks to media tracks would be adequate solution. Investigate if we need to clarify/extend the definition of @depencenyId, or define a different signalling mechanism.
-
We recommend such solution to be explored and also make sure that it won’t break its usage for scalable codecs (by contribution to the next meeting).
m31304
Summary: Propose a new element (replacement for adaptation set only for metadata) and tie Representation id to sync the content and metadata tracks.
Disposition: Noted.
m31320
Summary: Introduces @association ID for Rep.
Disposition: Noted.
m31501
Summary: Implementation guidelines for m31320.
Disposition: Noted. We will consider the implementation guidelines after a solution is finalized for this CE.
m31458
Summary of all input contributions on SAND.
Disposition: Noted. Recommendation are accepted with revision. Please see the end of this section.
m31084
Summary: Proposes the propose a cross-layer interface(CLI) between DASH and underlying layers to utilize the information from MAC and PHY layers to improve adaptation by the DASH client. The CLI includes semantics and syntaxes for abstracted QoS parameters of underlying channel for parameters such as available bitrate, queuing delay, frame error rate and frame size.
Disposition: Noted.
m31085
Summary: proposes defining tools for providing end-to-end seamless guaranteed service by 1) define a set of abstracted QoS parameters 2) define a reservation mechanisms, exchanging messages and their corresponding process 3) flow identification: every DASH packet included in the flow whose resource for delivery is reserved shall be identified by the entities which provide reserved resources. Proposes to identify which items are to be standardized in DASH and which items are just implementation issues.
Disposition: Noted.
M31301
Summary: proposes requirements for
-
Use Case 3 (Network-Assisted DASH)
-
DASH shall support communication of service subscription levels between DASH applications and the underlying network, and
-
DASH shall support a standard cross-layer interface between DASH applications and underlying networks on generating GBR requests and responses; with reference to m31305.
-
Use Case 6 (Server-Controlled DASH).
-
DASH shall provide a URL query parameter insertion mechanism, e.g., currently in the DASH TuC, to ensure that it can provide flexible support for the server-managed DASH approach, and
-
DASH shall define a set of DASH URL query parameters that can be used for the purpose of supporting server-managed DASH.
Disposition: Noted.
m31305
Summary: Provides simulation results for DASH over the GBR bearer and demonstrated advantage of GBR over the non-GBR bearer:
-
User’s quality of experience can be guaranteed, and
-
radio resources can be managed more efficiently to exactly match application layer’s requirements.
Therefore, it proposes:
-
Use a cross-layer interface, either newly defined or refined from existing ones, to enable GBR related information exchange among the DASH client, network and DASH server.
-
Add support for these cross-layer interfaces and work flows to regulate GBR request/response and authorization, and
-
Add support mechanisms to assist/control streaming adaptation based on GBR information provided by the network.
Disposition: Noted.
m31412
Summary: proposes to include QoS signalling in order to assist the DASH client in making smart decisions for the following use case scenarios:
-
start-up delay over managed network
-
heterogeneity of DASH clients, which can individually adapt their playout buffer
-
Variety of QoS in a LAN: Two clients may receive the same information from the MPD, the wireless DASH player should have a longer buffer time in order to absorb the perturbations occurring in the local network.
Also proposes to define a new XML element for QoS parameters, but leaves the transport of the data open, e.g. using the MPD, XMPP, web sockets or other means. Demonstrates experimental results that a better quality of experience can be offered when signaling QoS information to a DASH client.
Disposition: Noted.
m31415
Summary: proposes the client to use HTTP HEAD messages to re-resolve MDP entries a bit ahead of time. The CDN interprets these HTTP HEAD requests as a hint of the future segments to be requested- similar to “Next segment signaling through HTTP GET extension for CDNs” described in the TuC, but offers other advantages. This contribution presents two benefits of using HTTP HEAD requests with segment URLs. Along the way the various CDNs can interpret these requests as hints for pre-caching the segments. Plus the DASH client is able to resolve the URLs in the MPD a bit ahead of time so that no request-routing delay is introduced when the client sends the actual HTTP GET request.
Disposition: Noted.
m31417
Summary: proposes
-
Possible messages from the server to the client that would improve the efficiency of a DASH delivery system, namely:
-
QoS Signaling
-
Server capability, e.g.
-
CDN change
-
Possible messages from the client to the server that would improve the efficiency of a DASH delivery system, namely:
-
Quality metrics reporting
Recommends to analyze more examples of such messages in order to define a reference message model.
Disposition: Noted.
m31459
Summary: provides two addition use cases, namely operational support for DASH live service and Session Establishment. Also provides a simple architecture to classify the different potential control message flows as follows:
Figure 3 Simplified media distribution and control architecture
Based on this architecture, different use cases and message flows are assigned to different flows and based on this, requirements are derived for the different interfaces.
The contribution also discusses the role of the MPD
-
Does it describe the content authoring on the server?
-
Does it describe the operational instructions on the content?
-
Can MPDs be updated for operational purposes?
-
To what extent can it be used for client-specific issues?
According to the existing data model, 2 and 3 are not included in the MPD context, but some deployments attempt to use it. The ambiguity should be resolved and clear statements on this aspect should be considered. A detailed revisit of MPD updates for live services and the use of MPD updates for On-Demand services are necessary.
Disposition: Noted.
m31465
Summary: The document provides LTE-based evaluation results for justification on the value of signaling and/or exposing network QoS parameters to the DASH client, e.g., in the MPD, through suitable APIs or via other means, toward optimally managing limited network resources, enhancing network capacity utilization and providing better QoE to the end user. In particular, the availability of QoS information on the GBR and MBR is shown to lead to significant enhancements in service capacity and user’s QoE. It is therefore proposed to consider the derived QoS-based DASH client adaptation guidelines developed from the evaluations in Section 3 based on the availability of GBR and MBR information. To summarize some of these guidelines:
-
DASH client can take the available network QoS information into consideration in its adaptation logic when requesting representations such that the consumed content bandwidth remains within the limits established by the signaled QoS information (i.e., GBR and MBR values).
-
DASH client can use network QoS information (i.e., MBR) to reduce its requested rate and switch to a lower DASH representation in response to a radio congestion event
-
DASH client can use network QoS information (i.e., GBR) to request a higher quality representation during start-up
In the potential absence of alternate signaling mechanisms to convey QoS information to the client (e.g., via PCC-level signaling, etc.), it would be beneficial to enable such signaling in DASH. In addition to our proposal from MPEG#105, we observe that there are already two proposals on signaling of QoS parameters in the DASH MPD from TNO and Huawei (in addition to those presentations at the MPEG workshop), which is quite encouraging toward the consideration of this feature.
Disposition: Noted.
m31624
Summary: proposes that DASH standardizes a set of commands for SAND that can be delivered through different communication channels, including:
-
A representation is temporarily not available for consumption. The message data contains the representation identifier “Representation@id” or it may refer to the current representation.
-
A representation is permanently made unavailable and the DASH client should avoid using this representation in the future. The message data may contain the representation identifier or it may refer to the current representation.
-
A representation is available again after it has been made temporarily unavailable. The message data may contain the representation identifier.
-
A representation is recommended to the DASH client over other representations of the same AdaptationSet. The message data carries the representation identifier.
-
The network estimates or guarantees a certain bandwidth for the DASH client and expects the client to perform rate adaptation in accordance with this recommendation. The message data may contain the available bandwidth or throughput in bits per second or in some other unit.
-
The origin or proxy server prefers to serve data from a particular CDN and recommends to the client to use the corresponding base URL to resolve the actual addresses of the DASH segments. The message data may contain one or more base URLs that represent the base URLs for the recommended CDN.
In addition, on the SAND control channel, MPEG DASH should limit the scope of the SAND CE to the definition of the commands that may be delivered via any suitable communication channel. For this purpose, we propose that the commands are defined in a portable and channel independent format such as XML.
Disposition: Noted.
m31665
Summary: This document discusses the necessity of assisting the DASH clients for operational purposes. For this purpose two additional use cases are defined:
-
Bi-Directional Hinting between Servers, Clients and the Network
-
Monitoring, Diagnostics and Fault Isolation
The contribution recommends rather than trying to enforce a certain action on the client, providing assistance and letting the client make the decisions is better.
The following requirements are stated:
-
There should be a signaling plane (separate than the media delivery plane) to provide a means for bi-directional communication between server(s), client(s) and other network elements (where applicable) to exchange a variety of information about network, server and client conditions. The information provided to the clients can carry useful (but not binding) information. The clients may use this information or simply ignore it.
-
It is optional to implement this signaling plane. A client unaware of this signaling plane or that does not understand what the information means can safely ignore it and continue to perform as usual.
-
The signaling plane should support carrying both public and private messages. Public messages are those that need to be implemented and understood by every vendor that supports this signaling plane. Private messages are vendor-specific and need to be defined in a non-colliding way to avoid interop issues. Unique vendor IDs can be be used to identify these messages.
-
The signaling plane should be separate from the media delivery plane. That is, while it can use the same transport, signaling messages should not be as part of the media.
-
The signaling plane should be scalable and CDN-friendly.
Disposition: Noted.
CE Recommendations:
-
The CE should have an scope including the following items:
-
SAND parameters: Providing a set of network assisted parameters, downlink, from the delivery network element to the DASH client.
-
DASH metrics: Parameters from DASH client to network, uplink: review and improvement of them including adding new metrics.
-
Paramenters for enhancing delivery by DANE (PED): generated by the content author, provided from media server to DASH Aware Network Element (DANE).
-
Define the signalling mechanism (Protocol) requirements at the first stage.
-
Parameters selection criteria:
-
Each parameter has a clear definition including unit
-
The usefulness of the metric must be provided before it get accepted.
-
Frequency of each parameter should be defined.
-
How the parameter can be generated/calculated.
-
How scalable is the parameter.
-
Liaison to external organization to collect input on parameters: 3GPP, IETF CDNi, DASH-IF, EBU, HbbTV, SCTE.
m31300
Summary: Updates the TuC section on URL query including the mpd element, its parameters and also includes examples of how to use it. It proposes the mandatory option meaning that the client which can understand and insert the query can play the MPD.
We identified the following issues, need to be resolved:
-
Order of byte range and query string
-
Check the consistency with Annex E (embedded byte range)
-
How it works with hashing and signatures.
-
MPD updates rules
-
How to process of resolution in xlink case.
-
May need to define a new profile or essential property to support this feature.
Disposition: Partially accepted. Update the TuC. Include the above issues in the TuC, to be resolved by inputs at the next meeting, and include the above issue list.
Dostları ilə paylaş: |
