New SUBSCRIBE limitations

[afrind]

As currently defined, you can SUBSCRIBE starting from the following points:

1. The latest group and latest object
2. An absolute group and latest object
3. 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 TRACK_STATUS_REQUEST, so perhaps this is an optimization we can tackle later.

[kixelated]

As currently defined, you can SUBSCRIBE starting from the following points:

1. The latest group and latest object
2. An absolute group and latest object
3. 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

It's currently ambiguous if case 1 or case b happens. When start_group=0, then start_object is not present but doesn't have a specified default. If default=0 then case 1 occurs, and if default=1 then case b occurs. The correct behavior is case b IMO since groups are intended to be sync points.

+1 to removing case 2.

[kixelated]

And I don't think we should support case c 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 TRACK_STATUS_REQUEST, which primarily eats into time that would have been spent waiting for the next group to start anyway.

[kixelated]

437 means you can only start at:

b. The latest group from the beginning

3. An absolute group and absolute object

Everything else is accomplished with TRACK_STATUS_REQUEST, forcing the subscriber to converts relative values to absolute. I think we should eventually bring back Locations so the publisher can do this conversion too without an additional RTT, but the desire was to simplify start/end ranges.

[ianswett]

FWIW, I thought/intended start_group=0 to correspond to b.

Also +1 to removing case 2.

[fluffy]

Thanks for summary.

+1 to remove case 2 (abs/latest).

I also thought we had b. today but we need case b so lets update to make it clear we have b (latest/0).

I don't think we have a use case for a (latest/abs), +1 on remove.

I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group. If there was not enough bandwidth to do this, then there is probably not enough bandwidth for the next group when it arrives.

If we get a bunch of code running and can show that (latest/latest) is not good enough and we really need (next/0), then I will change my mind but for now, I think we can live without (next/0).

And +1 to point that TRACK_STATUS_REQUEST solves most problems.

[wilaw]

A +1 to all these points

I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group.

TRACK_STATUS_REQUEST solves most problems.

to remove case 2 (abs/latest).

Regarding starting at the latest group at the beginning, this seems like the default starting use case for many players. Therefore per Luke's comment - The correct behavior is case b IMO since groups are intended to be sync points.

[ianswett]

Fixed by #439