Code change:
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </del> <ins> Filter Type: Identifies the type of filter, which also indicates whether the StartGroup/StartObject and EndGroup/EndObject fields will be present.  See (sub-filter). StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </del> <ins> StartObject: The start Object ID within the StartGroup.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </del> <ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. </ins> EndObject: The end Object ID, plus 1.  A value of 0 means the <del> entire group is requested.  This field is not present when End Group is 0. </del> <ins> entire group is requested.  Only present for the "AbsoluteRange" filter type. </ins> Track Request Parameters: The parameters are defined in

Related discussion:
text: I took a stab at another rewrite of Subscribe message which attempts to not use special group and object values. Also add support for multiple subscription flows that have been discussed. As this is a control message, we should be Ok to be elaborate in describing the subscriber needs. This leaves 0 as a special value for the StartObject and EndObject.
NAME updated the PR .. please let me know .. thanks
I like that this would move us away from stealing special values from obejct id / group id space.
This looks good NAME .. thanks for the update
As currently defined, you can SUBSCRIBE starting from the following points: The latest group and latest object An absolute group and latest object An absolute group and absolute object You cannot SUBSCRIBE to a. The latest group with an absolute object b. The latest group from the beginning c. The next group after latest, from the beginning I'd like to remove 2) (absolute group, latest object). If this group is in the past, then likely the group is complete and no new objects will come in that group, so it's equivalent to (absolute group + 1, object 0). If this group is in the future, then it's equivalent to (absolute group, object 0). If the group is current, it's equivalent to latest/latest. Does anyone have a use case that requires this mode? I'd also like to add b) (latest group, first object) and c) (next group, object 0). This can be done now with an extra round trip via TRACKSTATUSREQUEST, so perhaps this is an optimization we can tackle later.
It's currently ambiguous if or happens. When , then is not present but doesn't have a specified default. If then occurs, and if then occurs. The correct behavior is IMO since groups are intended to be sync points. +1 to removing .
And I don't think we should support without a good use-case. It's too racey for ABR and too delayed for initial playback. It's also barely an optimization since the alternative is making the TRACKSTATUSREQUEST, which primarily eats into time that would have been spent waiting for the next group to start anyway.
means you can only start at: b. The latest group from the beginning An absolute group and absolute object Everything else is accomplished with , forcing the subscriber to converts relative values to absolute.