Comments (10)
I think it is trying to say that duplicates are removed from the end of the list, not the beginning. So removing duplicates from [A, B, C, A₁, B₁]
results in [A, B, C]
not [C, A₁, B₁]
. But the index of first occurrennce doesn't always remain the same. Removing duplicates from [A, B, B₁, A₁, C]
results in [A, B, C]
, which changes the index of the first occurrence of C.
Removing the duplicates seems preferable to throwing. I'd prefer not to link "duplicate" to the codec match algorithm because the match algorithm has issues:
- The advertised level-id/profile may not reflect what can actually be decoded (e.g. by FFMPEG). So sending a higher level-id/profile than the receiver indicated it could handle might not result in a decode failure.
- Because of problem 1, mismatches detected by the "match algorithm" may be imaginary.
- level-assymetry-allowed is currently not taken into account in determining negotiation faliure. Although differing values of level-assymetry-allowed are treated as distinct profiles, there are some practical problems with declaring negotiation failure if the values don't match. What is sent is not coupled to what is received, due to congestion control. Also, limiting the sender based on a pessimistic receiver advertisement can be too restrictive. So in practice differing settings of
level-assymetry-allowed
doesn't currently lead to negotiation faliure. Presumably this means that two profiles differing only in the value oflevel-assymetry-allowed
can interoperate...
from webrtc-pc.
Agree we only need to remove "the index of the first occurrence of a codec within the list is the same before and after this step."
Removing the duplicates seems preferable to throwing.
Why? Where would duplicates come from?
from webrtc-pc.
I'd prefer not to link "duplicate" to the codec match algorithm because the match algorithm has issues:
If we don't link to it then what does "duplicate" mean (these are dictionaries after all)? We need to fix those issues in the match algorithm then I think (or disallow duplicates).
In my mind, the starting point for this API seems to be:
const {codecs} = RTCRtpReceiver.getCapabilities("video");
// sort codecs by e.g. mimeTypes like "video/H264", "video/VP9"
videoTransceiver.setCodecPreferences(codecs);
And in this model, any duplicate would appear to be a programming error. When would it not be?
from webrtc-pc.
@jan-ivar Does "duplicate" imply a match on codec, level-id/profile and level-assymetry-allowed
? Since distinct values result in treatment as a separate format, there is some logic to that approach. But requiring an exact match on each parameter in a universal "match algorithm" is problematic if level-assymetry-allowed
isn't taken into account in other matching applications, such as determining negotiation faliures.
from webrtc-pc.
In my mind, the following needs to hold regardless of domain details:
- the match algorithm needs to distinguish all entries returned from
RTCRtpReceiver.getCapabilities()
- IOW it by definition contains no "duplicates"
- The following must be valid/succeed
videoTransceiver.setCodecPreferences(RTCRtpReceiver.getCapabilities("video"));
audioTransceiver.setCodecPreferences(RTCRtpReceiver.getCapabilities("audio"));
Those seem to be the APIs the match algorithm are in service of.
A quick dump of getCapabilities() reveal:
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f"
},
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f"
},
This suggests they are distinct codecs to me. Does that match your understanding?
from webrtc-pc.
Oh I see, I appear to have left out another possible input source for setCodecPreferences:
transceiver.setCodecPreferences(receiver.getParameters().codecs);
Is that right? If so, please see my questions in #2956.
from webrtc-pc.
Since there are multiple input sources then I also see where duplicates may come from, so I concede that point.
from webrtc-pc.
I agree that
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f"
},
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f"
},
Are distinct codecs, because packetization-mode
differs between them. What I am not sure about is when these profiles are considered to "match":
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f"
},
{
"clockRate": 90000,
"mimeType": "video/H264",
"sdpFmtpLine": "level-asymmetry-allowed=0;packetization-mode=1;profile-level-id=42001f"
},
from webrtc-pc.
But requiring an exact match on each parameter in a universal "match algorithm" is problematic if level-assymetry-allowed isn't taken into account in other matching applications, such as determining negotiation faliures.
This seems like a naming problem, since algorithms need to be excplicitly invoked and aren't universal. Let's just call it the "codec dictionary match" algorithm for now.
The codec dictionary match algorithm was added in #2847 because codecs aren't exposed as platform objects, and thus A == previousReadOfA
fails in both JS and c++ (solving only c++ btw; folks in #2845 didn't want to go the interface route. E.g. the interface route would have allowed us to modify properties like A.sdpFmtpLine
over time without affecting the identity of A
, if that is interesting. Just mentioning it. It was dismissed for legit compat concerns).
What I am not sure about is when these profiles are considered to "match":
The spec says the two dictionaries are distinct codec inputs to setCodecPreferences()
, which makes sense to me as them also being distinct in either getCapabilities or getParameters is a precondition.
I don't read anything in the spec that says the "codec dictionary match" algorithm affects negotiation, as it does not appear to be called from there AFAICT. If there is implicit language somewhere that suggests it, we should identify and clarify it.
from webrtc-pc.
Happy to discuss this at next meeting but since I've conceded that we probably need to tolerate duplicates given the two possible input sources, I'll also try to put up a PR to see if clarify things is all we need.
from webrtc-pc.
Related Issues (20)
- Existing setCodecPreferences NOTE is wrong and should be deleted HOT 8
- Specify what should happen if filtering [[PreferredCodecs]] on direction results in empty list HOT 7
- setCodecPreferences, sendonly codecs and dummy codecs HOT 21
- If a preferred codec is filtered out, does it still get assigned a PT? HOT 16
- Proposing setCodecPreferences to deal with both send and recv codecs HOT 6
- RTCSessionDescriptionInit vs "local" RTCLocalSessionDescriptionInit HOT 2
- Review mute/unmute/ended and constraints on RTCRtpReceiver's track. HOT 2
- Alternative storage for RTCCertificates needed HOT 6
- simple webrtc connection and manual signaling (QR, JSON, Carrier pigeon) - consent time out prevents connection HOT 3
- RTCIceCandidate's relayProtocol and url members can be null but not absent
- Missing tests for candidate amendments
- Incorporate jitterBufferTarget
- receiver.getParameters().codecs is broken (regression) HOT 4
- setCodecPreferences should take sequence<RTCRtpCodec>
- setCodecPreferences should trigger negotiationneeded HOT 3
- Implementations only update getParameters().codecs when negotiation has finished HOT 3
- Comparison rules for RTCRtpCodec needs clarification on how mimeType is compared HOT 10
- Promises on the operations chain may never settle HOT 3
- RTCRtpCodecCapability is superfluous and should be deleted from the spec. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webrtc-pc.