Refactor spec to introduce media thread #107
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alvestrand
reviewed
May 20, 2021
| @@ -91,37 +91,44 @@ argument, ensure that the codec is disabled and produces no output. | |||
|
|
|||
| ### Stream creation ### {#stream-creation} | |||
|
|
|||
| Each {{RTCRtpSender}} or {{RTCRtpReceiver}} has its own <dfn>media thread</dfn> on which media flows, | |||
| from a source on which to read encoded data to a sink on which to write encoded data. | |||
| The source is the packetizer for {{RTCRtpSender}} and the decoder for {{RTCRtpReceiver}}. | |||
There was a problem hiding this comment.
This seems backwards. For Sender, media comes from the encoder and goes to the packetizer; for the Receiver, media comes from the depacketizer and goes to the decoder.
Either I am misunderstanding line 95 or I'm misunderstanding lines 96+98.
There was a problem hiding this comment.
Right, it needs to be reversed.
alvestrand
reviewed
May 20, 2021
| @@ -91,37 +91,44 @@ argument, ensure that the codec is disabled and produces no output. | |||
|
|
|||
| ### Stream creation ### {#stream-creation} | |||
|
|
|||
| Each {{RTCRtpSender}} or {{RTCRtpReceiver}} has its own <dfn>media thread</dfn> on which media flows, | |||
There was a problem hiding this comment.
I think this is not right; in the non-transform case, the media thread on which media flows is not the thread that is visible to JS.
I'll suggest alternate wording (after the meeting).
|
Alternative to this PR:
|
jan-ivar
reviewed
May 20, 2021
| 1. [=Queue a task=] to run the following step: | ||
| 1. [=Queue a task=] on [=this=]'s media thread to run the following steps: | ||
| 1. If [=this=].`[[pipeToController]]` is not null, abort these steps. | ||
| 1. Set [=this=].`[[pipeToController]]` to a new {{AbortController}}. |
There was a problem hiding this comment.
This creates a WebIDL interface on a background thread, which we shouldn't do.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to clarify the threading model, without changing much of the functionality.
For SFrameTransform, the transform happens as if in the media thread, though implementations may decide to do it however they want.
For RTCRtpScriptTransform, the streams are transferred from the media thread directly to the worker thread.
Preview | Diff