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

IDL changes for setMetadata for 3.2.2 webrtc nv use case #202

Closed
wants to merge 13 commits into from

Conversation

palak8669
Copy link
Contributor

@palak8669 palak8669 commented Sep 5, 2023

@dontcallmedom-bot
Copy link

This issue was mentioned in WEBRTCWG-2023-09-12 (Page 50)

@youennf
Copy link
Collaborator

youennf commented Sep 29, 2023

As discussed during yesterday editor's call, here is some feedback for this issue.

As expressed in #201 (comment), WebRTC encoded transform is a very specific tool. It does not seem to be the most appropriate tool for 3.2.2 webrtc nv use cases. Given alternative APIs have been proposed for this use case, we should take the time to evaluate them and pick the best one.

Also 3.2.2 use case definition is being refined in w3c/webrtc-nv-use-cases#123, the target seems to be ultra low latency.

For 3.2.2 ultra low latency use case, doing processing at packet level (both for forwarding from first to second link and for processing the second link feedback) would probably be more appropriate, like what SFUs are doing. WebRTC encoded transform is only handling frames, not packets, which is one example of the potential mismatch.
Another mismatch is that WebRTC encoded transform does not deal with packet loss.

When some additional latency is ok, which seems to be the use case behind this PR, using RTCPeerConnection for the first link (limited bandwidth) and data channel for the second link (corporate network) is already feasible and should provide good results. I would be interested in understanding the end user benefits of the proposed new approach with this already feasible implementation strategy.

@palak8669
Copy link
Contributor Author

We want to solve the use case first mentioned in WebRTC July 2023 meeting – (SetMetadata for redundant relay PCs.). Though using Data channels for this use case is possible, it adds more latency than RTP would using the proposed encoded transforms approach. In addition to this, using data channels here would require the app to write, tune and maintain its own custom jitter buffer along with defining a system to smoothly render vide from JS, which can be difficult due to timing restrictions.

Though encoded transforms do not allow handling packets, we think the added latency on waiting to assemble packets to a frame is still much less than data channels and something that our use case can handle.

In regards to the concern about packet loss management, this is being addressed in Congestion control API proposal

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
Co-authored-by: Dominique Hazael-Massieux <[email protected]>
@dontcallmedom
Copy link
Member

the CI is still failing because the parameter to setMetadata() is a dictionary, so should be optional or have a required field; I suspect the right solution would be to make the rtpTimestamp field required (but I'm not entirely sure why this is doing setMetadata vs setRtpTimestamp since that's the only field that can be updated from what I understand)

@palak8669
Copy link
Contributor Author

The change is for allowing modifications to RTPTimestamp(for audio and video) and frameID and dependencies(for video) as proposed in the July WG meeting.

@dontcallmedom
Copy link
Member

(sorry, I had missed that setMetadata changes more than rtpTimestamp for video frames)

@dontcallmedom-bot
Copy link

This issue had an associated resolution in WebRTC April 23 2024 meeting – 23 April 2024 (Custom Codecs):

RESOLUTION: Consensus on on #186, discussion to continue on #202

@alvestrand
Copy link
Contributor

For use cases where copying the data is not natural (like E2EE encryption), supporting setMetadata seems more natural than the copy constructor.

Constructor language and setMetadata language should be as parallel as possible.

@guidou
Copy link
Collaborator

guidou commented Jul 18, 2024

Closing in favor of #223
Will reopen the discussion with a new PR in the future if necessary.

@guidou guidou closed this Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants