[Moq] Re: Knowing the start of a Subgroup

["Mo Zanaty (mzanaty)" <[e-mail]>]

Hi Ian,

For 3. the minor wrinkle of a same-priority tie break between a subgroup and datagram in the same group of a track, we can simply specify subgroup wins. Why? If a track uses both subgroups and datagrams with the same priority in the same group, it is reasonable to assume the datagrams are disposable and therefore lower priority than reliable subgroups.

For the main issue, subgroups were added for video layers as the primary use case. The subgroup ID has specific semantics in this case as the layer ID. When we added subgroups, LOC removed its separate layer IDs and used subgroup ID directly.

To understand why layer / subgroup ID = object ID is a bad constraint, see the first example in the AV1 spec.
https://aomediacodec.github.io/av1-rtp-spec/v1.0.0.html#a1021

This shows temporal layers without spatial layers, the dominant encoding of most video today, not a rare or future thing, hence why it's first. (Even "linear" video actually has this structure.)

0 1 2 3 4 5 <- Frame number = object ID
0 2 1 2 0 2 <- Layer number = subgroup ID

Notice how this violates the proposed constraint, which would misnumber layer 2 as 1 and 1 as 2. This would require explicit priorities as it breaks the default priorities of subgroups. And it's a footgun for devs to screw up this inversion of some (not all!) specific layer / subgroup IDs. If our WG and editors already fell into this pit, there is no chance the average dev can escape it.

For the solution, I favor explicit mandatory indicators for the first object in a subgroup and group (maybe even track as Cullen suggested, although I'm unsure how that would be used).

Thanks,
Mo

________________________________
From: Ian Swett <ianswett=[e-mail]>

Thanks for clarifying.  Using subgroup IDs in the catalog is an interesting usecase I hadn't considered. I'm not sure this would cause practical problems, but I need more time to think about it.

Regarding consistency, today we indicate the end of the Subgroup with a stream FIN, not a bitflag on the Object. So I actually think using Subgroup ID==Object ID is more consistent, but that's my opinion.

When we originally created Subgroups, we needed an ID to stitch them together in case they were split apart.  I'm not sure anyone intended this be exposed to the application, but it sounds like you want to?  QUIC doesn't expose Stream IDs as part of its API, which was an intentional choice and mostly a good one.

If we go with the bitflag approach (#1618), are people ok with requiring it be set on the first Object in the Subgroup?  Requiring it gives the feature a lot more value IMO.

Also, do people want to resolve the undefined prioritization between Subgroups and datagrams in some way?
"3. If two objects in response to the same request have the same subscriber
   and publisher priority and belong to the same group of the same track, the
   one with **the lowest Subgroup ID** (for objects with forwarding preference
   Subgroup), or **the lowest Object ID** (for objects with forwarding preference
   Datagram) is scheduled to be sent first.  If the two objects have
   different Forwarding Preferences the order is implementation dependent."


Thanks, Ian

On Thu, Apr 30, 2026 at 5:22 AM Magnus Westerlund <magnus.westerlund=[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Date: Thursday, 30 April 2026 at 07:08
To: Ian Swett <ianswett=[e-mail]<mailto:[e-mail]>>
Cc: MOQ Mailing List <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

--
Moq mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>