Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section 3.2.2: Clarify Use Case #123

Merged
merged 11 commits into from
Dec 8, 2023
Merged

Section 3.2.2: Clarify Use Case #123

merged 11 commits into from
Dec 8, 2023

Conversation

aboba
Copy link
Collaborator

@aboba aboba commented Sep 8, 2023

Partial fix for #103


Preview | Diff

@youennf
Copy link

youennf commented Sep 12, 2023

Questions about the use case:

Is RTP used both before and after fanout, or is RTP only used before fanout (but data channel after), or does it cover both?
During fanout, is it important to add almost no latency (hence forwarding packets) or is it fine to buffer enough packets to build a frame and forward the frame?
Maybe we can answer this by looking at what |pipe| and Dolby are doing.

@aboba
Copy link
Collaborator Author

aboba commented Sep 12, 2023

Since this is for critical applications like auctions or betting, RTP is used before fanout (e.g. WHEP distribution), rather than a streaming protocol (e.g. HLS, LL-HLS) that transports CMAF. To remove latency, the fanout also uses RTP, rather than using CMAF over data channel to move them around. While unreliable/unordered data channel with application FEC could be used to transport the frames, the low-latency congestion control of RTP (e.g. gcc) will be preferred to data channel's NewReno.

@youennf
Copy link

youennf commented Sep 13, 2023

In that case, I wonder whether we could make the use case more precise according your description.

N39 could tell it wants to do forwarding at the packet level (to not require assembling frames). Currently it is vague, maybe intentionally.

Another requirement might be that the forwarding UA needs to expose RTCP info like PLI or FIR that it receives from its end clients so that the web page can trigger some recovery mechanism like asking for a key frame to the media source, as quickly as possible. This really is the SFU in a browser use case.

Also, in parallel to forwarding, the user agent should be able to consume the incoming media for local playback. I am not sure how much a technical requirement that is. But this could somehow influence the API design so that consumption be easy to do with no/as little JS as possible.

@dontcallmedom-bot
Copy link

@alvestrand
Copy link
Contributor

The notes from TPAC were "Continue discussing with intent to merge".

index.html Outdated Show resolved Hide resolved
@youennf
Copy link

youennf commented Sep 28, 2023

Additional point: the use case is really about stringent latency and also ensuring that all peers render media at precisely the same time.
Does it mean that a forwarding peer should delay rendering so that end peers render at the same time as forwarding peers?

index.html Outdated
and data is sent to thousands (or even millions) of recipients. Limited interactivity
may be supported, such as capturing audio/video from auction bidders. Both the media
sender and receivers may be behind a NAT. Peer-to-peer relays may be used to improve
scalability, with ingestion, distribution and fanout utilizing RTP.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer use cases that do not prescribe a solution, so I'd prefer removing mention of RTP. I think we should trust the "less than 300ms" requirement to already cover this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we seem to be having the debate about "but you should consider whether or not datachannels are an equally good solution" at every juncture where we propose extensions that assume the use of RTP, I wonder if it would make sense to add sub-use cases where one is "RTP is used for media transport", and one is "non-RTP protocols are used for media transport in some or all parts of the solution".

That would give us some clean identifiers to point to when saying "THIS extension is applicable to THAT use case".

But I think we should merge this PR and take that up later.

Copy link
Collaborator Author

@aboba aboba Oct 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This use case is focused on non-datachannel approaches because:

  • The requirement for low latency congestion control cannot be met by datachannel.
  • Datachannel-related requirements are already covered in Section 3.1 File Sharing.

@aboba aboba added December 5 VI For Discussion at November 2023 Virtual Interim and removed TPAC 2023 labels Oct 19, 2023
@aboba aboba requested a review from fippo October 19, 2023 20:56
index.html Outdated Show resolved Hide resolved
@dontcallmedom-bot
Copy link

@aboba aboba merged commit 6b0574f into main Dec 8, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
December 5 VI For Discussion at November 2023 Virtual Interim
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants