Filter / select across multiple tracks in a namespace

[mzanaty]

Many important use cases can benefit from the ability to filter or select objects across multiple tracks in a namespace. A few examples below.

1. Meetings
   100 person meeting, but subscribers only want to see and hear the last 4 active speakers (voice activity computed by each publisher).

2. Security Cameras
   100 live cameras, but a human viewer can only monitor the top 4 most suspicious activity scores (computed by each camera).

3. Viral Videos
   100 live video feeds, but subscribers only want to see the top 4 most popular (upvotes sent to each publisher).

4. Sensors (or other non-media cases)
   100 temperature sensors, but staff can only monitor the top 4 hottest (computed by each sensor).

5. Feedback Tracks (media or non-media)
   100 subscribers send feedback tracks to a publisher, but the publisher only wants one feedback signal or a count of subscribers.

6. ABR Videos (a different animal which may not be tamed the same way)
   10 resolutions, but the subscriber only wants the one with highest quality within current bandwidth limits.

Today, these require a central server/cloud to receive all tracks from all publishers, filter them, then republish the selected tracks to all subscribers. This floods the ingest relay network and central server with excessive traffic that will be discarded. Traffic not discarded is centrally bottlenecked or hairpinned and incurs higher latency compared to direct relay network routing.

Alternatively, publishers can only publish their computed selection scores as metadata tracks to the central server which then republishes the selected metadata tracks to all subscribers who must rapidly un/subscribe to the real media tracks indicated in the selected metadata tracks. This metadata can still be excessive (consider 100k not 100 pubs), cause a sustained storm of control messages and relay state churn, and add even higher latency to selections.

To address these use cases efficiently and scalably, the relay network can filter or select objects across multiple tracks in a namespace. This can guarantee pruned paths that never exceed the final selected small number of tracks regardless of how many publishers are sending.

Design options for how to achieve this will be presented in the Toronto interim.

[suhasHere]

I fully support us spending some time on the approach for implementing object filtering within and across tracks. This covers real-world use cases and addresses key pain points where MoQ can be effectively leveraged to significantly enhance the end-user experience, reduce bandwidth costs, and achieve substantial improvements in scalability.

[ianswett]

My simple proposal for this is to make the Forward field a uint8 instead of a bool and the publisher forwards any Objects less than the value the subscriber specifies. So 0 still means Forward=false as it does today.

We could special case 255 to mean forward everything, since otherwise you'd never get Objects with priority 255, or we could also just say don't use 255.

This is assuming we add Forward to SUBSCRIBE_NAMESPACE, which we should probably do sooner rather than later.

[suhasHere]

Like the idea of adding forward to subscribers_namespace

Also filtering of forward values is a nice idea to explore further. I would think having a way to match a header field specified in the filter will be good to have.

By match / filter I was largely thinking of integer operations .

[afrind]

Discussed in Toronto:

Plan is to move #1164 forward with along with a Design Team ironing out a concrete proposal and PR that addresses the use cases. @mzanaty to drive.

Marking Parked pending Design Team report.