More explicit handling for end-of-group bit

[afrind]

The previous "implicit" end of group handling both created additional malformed track cases, and was challenging to integrate into existing MoQ APIs. Change the interpretation to mean it's the same as receiving an End of Group Object with ID + 1.

Fixes: #1093

[fluffy]

I'm OK with this but it seems like a really weird way to specify what happens. I'd rather just see it say what happens when you get a UDP packet like than put it in terms of a UDP packet but don't really care.

[martinduke]

This implies that if I want extensions for my EndOfGroup object, I need to send that object explicitly. That's fine, I suppose, but it is a little different from when a single object had payload, extensions, and EoG status.

I don't understand many of the use cases for extensions, so I don't know if this is a problem.

This gets thorny if the relay decides to add an extension to an EoG object. If it's concerned it might do this, it can never initiate a stream with the EndOfGroup flag.

I am not sure compressing away the EndOfGroup object is well-conceived. It's already opened up a series of logical problems for what is a minor savings.

[afrind]

This implies that if I want extensions for my EndOfGroup object, I need to send that object explicitly. That's fine, I suppose, but it is a little different from when a single object had payload, extensions, and EoG status.

Yes, this is correct.

I don't understand many of the use cases for extensions, so I don't know if this is a problem.

This gets thorny if the relay decides to add an extension to an EoG object. If it's concerned it might do this, it can never initiate a stream with the EndOfGroup flag.

I can conceive of use cases for extensions in EOG -- metrics covering the entire group or something.

For a relay that might add extensions to EOG objects, it should be clear it can't use this flag.

I am not sure compressing away the EndOfGroup object is well-conceived. It's already opened up a series of logical problems for what is a minor savings.

It was not well conceived in the first instance as revealed by implementation experience. I was hoping this fixed it, but as you point out, it's a little fuzzy around extension handling. Do you think we should remove the feature or try to fix-forward?

[martinduke]

What if Object ID is VARINT62_MAX? I can't express the implied EOG object in a FETCH stream.

[afrind]

What if Object ID is VARINT62_MAX? I can't express the implied EOG object in a FETCH stream.

Wait for #1016 ?

[martinduke]

What if Object ID is VARINT62_MAX? I can't express the implied EOG object in a FETCH stream.

Wait for #1016 ?

That just moves the problem to a different integer.

[martinduke]

Having now implemented the existing spec (not this PR), and realized that this is saving 3 bytes per group under a narrow set of applicability conditions, I believe that all of this superstructure is not worth the lines of spec, lines of code, and ~dozen test cases it spawns. I propose we revert the whole thing.

[fluffy]

For me, low bandwidth audio is the case that drives this being worth doing.

[afrind]

@vasilvv will address this after making a separate PR for #1223 and #1224

[afrind]

#1342 will address this in a more complete way