Internet-Draft | moq-track-switching | July 2024 |
Gurel & Begen | Expires 8 January 2025 | [Page] |
This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document outlines a solution for switching tracks in media delivery over Media Over QUIC Transport (MOQT) [MoQTransport]. Switching tracks is necessary for a variety of reasons, such as changing the quality, the language of the media, or the type of the media (e.g., switching from a video to an audio track). The solution described in this document ensures that there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The party initiating a MoQ transport session.¶
The party accepting an incoming transport session.¶
A Client or Server.¶
An endpoint sending media over the network.¶
An endpoint receiving media over the network.¶
A raw QUIC connection or a WebTransport session.¶
Packet loss and queuing caused by degraded or overloaded networks.¶
A temporal sequence of objects. A group represents a join point in a track.¶
An object is an addressable unit whose payload is a sequence of bytes.¶
An encoded bitstream. Tracks contain a sequential series of one or more groups and are the subscribable entity with MOQT.¶
This document uses the conventions detailed in ([RFC9000], Section 1.3) when describing the binary encoding.¶
As a quick reference, the following list provides a non-normative summary of the parts of RFC9000 field syntax that are used in this specification.¶
Indicates that x is L bits long¶
Indicates that x holds an integer value using the variable-length encoding as described in ([RFC9000], Section 16)¶
Indicates that x can be any length including zero bits long. Values in this format always end on a byte boundary.¶
Indicates that x is repeated zero or more times and that each instance has a length of L¶
This document extends the RFC9000 syntax and with the additional field types:¶
Indicates that x consists of a variable length integer encoding as described in ([RFC9000], Section 16), followed by that many bytes of binary data¶
To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value.¶
In MOQT communications, the publisher announces the availability of multiple encodings of a media content in different tracks, which are alternatives of each other and indicated so in the catalog [CommonCatalogFormat]. The subscriber subscribes to one of the tracks from an altGroup in the catalog. During the session, the subscriber may switch from a currently consumed track to any other alternate track from the catalog due to, for example, changes in available bandwidth. To do this, the subscriber can subscribe to a new track and unsubscribe from the old track. Such an action is done by sending a SUBSCRIBE message to the relay. An example of the different tracks indicated in the catalog is shown below.¶
Relays do not have access/visibility to the catalog. Therefore, they are unaware when two tracks are alternates. An example of the existing SUBSCRIBE message format is shown below.¶
Existing SUBSCRIBE message that the subscriber transmits to the relay only contains information of the current track and does not indicate that the client is switching to a new track for the same media content. Therefore, when receiving a SUBSCRIBE message from the subscriber for switching to the new track, the relay may download and transmit both the new track and the old track of the same media content, which can create a bitrate spike and in turn can aggravate an already congested link. Additionally, the player/client application on the subscriber will have to process (e.g., parse and decode) the same media content in overlapping times, which is a waste of computational power.¶
A new parameter altTrackGroup can be added to every SUBSCRIBE message. altTrackGroup is the identifier for a group of alternative tracks within the scope of a track namespace. The value of the altTrackGroup identifier may be the same as the altGroup identifier used in the catalog or a different one. An example of a SUBSCRIBE message that includes the identifier altTrackGroup is shown below.¶
The SUBSCRIBE message can contain an identifier Switch Track Alias such that the Switch Track Alias = Track Alias of the active subscription. This way, this ID in the SUBSCRIBE message can indicate to the relay that this switching request is for an alternative track of the same media content of the current track and assists the relay in seamless switching. An example of a SUBSCRIBE message that includes the identifier Switch Track Alias is shown below.¶
TODO: Expand this section.¶
TODO: Expand this section.¶