[Moq] Re: Knowing the start of a Subgroup

[Magnus Westerlund <[e-mail]>]

Hi,

My worry is exactly related to that one would like to bind sub-group IDs to catalog info making clear what improvement a particular subgroup contains. I think this matters in two ways. First related to end subscriber processing it during decoding operations. This also matters if one want to use the sub group filter as the subscriber need to know that the publisher uses the subgroup IDs consistently.

With the proposal in place I think it limits the possibility to apply additional constraints on the object IDs. For example if one want the object IDs in decoding order without gaps across a full tree of different sub-groups then one have a constraint that may be difficult to fulfil if one need to reconfigure the encoder between groups to handle bandwidth limitation between the original publisher and the relay. The reconfiguration could mean skipping a sub group completely in this group. This will require a gap in the object ID to skip over the object ID = sub group ID.

Yes clearly if one assign no additional semantics and accept gaps in object IDs the idea in #1608 can work. However, I think it is limitation that people with more advanced use cases in the future will be annoyed with and may result in significantly more additional signalling about gaps etc than an explicit start of sub-group indicator would require.

Cheers

Magnus



From: Cullen Fluffy Jennings <[e-mail]>
Date: Thursday, 30 April 2026 at 07:08
To: Ian Swett <ianswett=[e-mail]>
Cc: MOQ Mailing List <[e-mail]>
Subject: [Moq] Re: Knowing the start of a Subgroup


Three thoughts ….

1) I don’t deeply care about this one way or the other but I think we should make it mirror the end marker bits. If the original publisher knows it is the start, or knows it is the end, it should add the marker. I think we should deal with start of track, start of group, at the same time as subgroup as it is the same issue.

2) Imagine a case where you want to refer to the SubGroup ID in the catalog to explain what layer of a codec is in that subgroup. And assume you want  the object ID to increment by 1 in the group. I'm just not seeing how it works in this case.

3) Mostly I don’t worry about how we spell it on the wire but FWIW … My gut feel is we are pinning to very weird implicit signaling by taking two things that have nothing to do with each other, the subgroup id and the object id, then saying if they are equal, it means some third thing. I’d rather just explicitly signal the third thing and not have it be some implicit convention on how to use the first two things.



> On Apr 29, 2026, at 3:10 PM, Ian Swett <ianswett=[e-mail]> wrote:
>
> In Monday's interim, there was strong interest in knowing what the starting Object Id of a Subgroup is, just like we know the end today.
>
> My proposal (#1608) was to require the Subgroup ID equal the Object ID of the first Object of the Subgroup. The original publisher would do this, and it would naturally be preserved downstream, just like Subgroup ID and Object ID are today. Some people had concerns with this, but I don't think I fully understood them?  If anyone wants to spell them out in more detail, that would be great.
>
> To clarify, this retains the ability to stitch together a Subgroup that arrived on two separate streams for whatever reason.  That is a core requirement for Subgroups.
>
> I'm not set on my particular design, but I reviewed #1618 (which uses a bitflag) and I think #1608 has two important advantages:
> 1) It's required
> 2) If you receive some Objects from a Subgroup, you know if the first one is the first Object in the subgroup.
>
> Thoughts?
>
> Thanks, Ian
> --
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

--
Moq mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]