Comments (20)
That is not what setCodecPreferences does, it only controls receive preferences. [...] and that is what we are doing?
What we're seeing is not being allowed to prefer to receive H264 unless the offerer is preferring to receive it too. This is fine for codecs that work in both directions because you can always swap preference order and use the codec you don't want to use as a fallback, but it makes little sense for unidirectional codecs.
Whether we want to solve this or not is up to us, there are workarounds like modifying SDP (in a legal way) or preferring to receive something you can't receive knowing the other endpoint will swap orders. Just because you can shoot yourself in the foot doesn't mean you will.
from webrtc-pc.
preferring to receive on a send-only codec is kind of silly, so that would be a feature not a bug....
from webrtc-pc.
But the other side will not know what codecs you support...
Yeah this to me is an argument for allowing to "prefer to receive send codecs" and let the transciever.direction
filtering take care of whether or not you're doing nonsense, but still base the a=rtpmap
list based on what you provided to setCodecPreferences
, so that the answerer can always know whether or not the codec is supported.
But while this helps sendonly transceiver with sendonly codec use case, it also adds complexity and confusion, so probably best to keep it simple: setting preference is the same thing as setting receive codecs.
from webrtc-pc.
This is the sentence that I proposed to delete in #2926 because it doesn't make sense when we consider setCodecPreferences just receiver preferences.
In general this needs to stay. The current behavior is not to include recvonly codecs on a sendrecv m-line. We can not and should not change that.
The consequence of doing something foolish is the transceiver being stopped after SLD (I hope... we currently don't get there)
from webrtc-pc.
Doesn't that make more sense somehow?
JSEP says we MUST NOT do that. I assume the reason is that the answerer could interpret such codecs as codecs we are willing to receive.
I've addressed the SLD failure from https://jsfiddle.net/fippo/r63bp8d2/2/ with my change, turned out to be a fairly trivial implementation issue. The new behavior if you set a receive-only codec via sCP and set the direction to sendonly is that the transceiver is stopped by SLD.
from webrtc-pc.
https://www.rfc-editor.org/rfc/rfc8829.html#section-5.3.1 updates this in the bullet points following
Otherwise, each "m=" section in the answer
I do not think those "unidirectional use-cases" are well supported or tested currently and would not push this further without a clear need.
from webrtc-pc.
pc1 should be able to ask for VP8 and pc2 ask for H264 and it should work, but on Chromium the following fiddle results in VP8 in both directions: https://jsfiddle.net/henbos/1vzjybs3/
When we setCodecPreferences, we don't just filter out the preferences, we filter out the codecs, and it doesn't seem to add new codecs either IDK
from webrtc-pc.
Which is expected and how things have been behaving like this for a decade.
And as https://wpt.fyi/results/webrtc/protocol/additional-codecs.html?label=experimental&label=master&aligned shows adding H264 in the answer causes H264 to be sent by pc1 so we have forward compability for whenever implementations feel motivated to implement what JSEP suggested (as an optional thing I believe)
I'm open to the argument that setCodecPreferences should not restrict the codecs pc1 offers but this introduces a compability risk without clear benefits.
from webrtc-pc.
Which is expected and how things have been behaving like this for a decade.
It's good for compat that adding H264 via SDP munging works already. But how do I ask to receive VP8 and have the other endpoint ask to receive H264 using setCodecPreferences
?
You could tweak it to list both [vp8, h264]
and then swap order in answer: https://jsfiddle.net/henbos/jeLav7c3/
But I don't know that this makes sense if the codecs were unidirectional. I don't want to "prefer to receive" something I can't decode if they actually listened to me. (Also the fiddle currently does not work)
from webrtc-pc.
There was a bug in the fiddle (by awaiting replaceTrack
I did setCodecPreferences
too late at pc2
so it missed the answer!).
Fixed and it works for the case of offer [vp8, h264]
and answer [h264, vp8]
: https://jsfiddle.net/henbos/v1rpmfqs/
But it does not work in the case of offering [vp8]
and answering [h264]
: https://jsfiddle.net/henbos/jcgwvf20/
This may be good or it may be bad depending on what we want to do with unidirectional codecs.
from webrtc-pc.
It's good for compat that adding H264 via SDP munging works already.
This isn't munging, this is signaling ;-)
But how do I ask to receive VP8 and have the other endpoint ask to receive H264 using setCodecPreferences?
That is not what setCodecPreferences does, it only controls receive preferences. We have answer handling for additional codecs but we do not have anything in offers. https://www.rfc-editor.org/rfc/rfc8829.html#section-5.2.1 is quite specific:
If codec preferences have been set for the associated transceiver, media formats MUST be generated in the
corresponding order and MUST exclude any codecs not present in the codec preferences.
and that is what we are doing?
from webrtc-pc.
Heeey, we're already dealing with unidirectionality with this filtering:
If transceiver.direction is "sendonly" or "sendrecv", exclude any codecs not included in the list of implemented send codecs for kind.
If transceiver.direction is "recvonly" or "sendrecv", exclude any codecs not included in the list of implemented receive codecs for kind.
This means that if I want to use a sendonly codec WITHOUT having to modify SDP I simply ensure the transceiver is sendonly. And if I want to do sendrecv, then I can always modify SDP, but nobody is forcing me to do this.
I think no changes are needed but we should add more WPTs. Yay.
from webrtc-pc.
Oh but the plot thickens, it's not possible to setCodecPreferences([send-only codec]) if #2926 lands
from webrtc-pc.
preferring to receive on a send-only codec is kind of silly, so that would be a feature not a bug....
If transciever.direction
is sendrecv
or recvonly
, the filtering we have already makes sure you wouldn't prefer to receive a send-only codec, protecting against that which makes no sense.
But if the direction is sendonly
, then we have to list the sendonly codec in order to allow pc2
to answer with this codec.
- Either that or we say that the way to do unidirection is by modifying SDP. It's not illegal, it's just ugly.
from webrtc-pc.
@fippo Explained to me that the fact that we have to SDP munge to add H264 in the setCodecPreferences([h264])
fiddle is an implementation bug, not a spec issue. In that case this mess resolves itself. I'll re-approve fippo's PR
from webrtc-pc.
It is a missing feature in the implementation, in particular the
Any currently available media formats that are not present in the current remote description MUST be added after all existing formats.
from https://www.rfc-editor.org/rfc/rfc8829.html#name-initial-answers
I did tinker with a recv-only codec and setting the transceiver direction to sendonly:
https://jsfiddle.net/fippo/r63bp8d2/1/
Works fine with and without this change. This is fine but the logic is weird... you can only determine the send codec once you have the other side's answer. But the other side will not know what codecs you support...
from webrtc-pc.
[[PreferredCodecs]] should be the single-element list with VP9 profile=2. Since that is not in the list of implemented send codecs it should be excluded. But it is not as the generated offer still contains that codec.
This is the sentence that I proposed to delete in #2926 because it doesn't make sense when we consider setCodecPreferences
just receiver preferences.
If we delete this sentence, then the fact that we don't exclude it is a feature, but if we don't delete it, it is a bug.
from webrtc-pc.
Pilot error previously, deleted that comment. So there is a change of behavior in what I am proposing:
https://jsfiddle.net/fippo/r63bp8d2/2/
currently bails out in sCP because VP9 profile-id=1 is not a codec that can be sent.
With my change it bails out in setLocalDescription. Further splitting this up into createOffer + SLD shows that the offer is created with a rejected m-line. This gets rejected by Chromium because
Failed to set local offer sdp: Failed to set local video description recv parameters for m-section with mid='0'
which I believe to be a bogus error since it is attempting to set receive parameters on a m-line marked as rejected.
from webrtc-pc.
I can argue either way on that one. The sad consequence is it that the receiving endpoint does not know which profiles the sending endpoint supports. So we're designing the API in a way where you have to signal codec capabilities outside of the SDP instead of simply including them in the a=rtpmap
but without including them in the preferences.
This problem goes away if we allow a=rtpmap to not be filtered out while preferences is filtered out. Doesn't that make more sense somehow?
from webrtc-pc.
Perfect, if JSEP forbids, we don't even need to discuss this. sCP is just received codecs, the app picking codecs that works is the app's problem
from webrtc-pc.
Related Issues (20)
- Adding and stopping transceiver before first offer will result in unremovable transceiver HOT 3
- QUIC as Transport for Session Traversal Utilities for NAT (STUN) HOT 3
- Modify the codec description model to ease describing changes HOT 5
- Applying a remote offer with unsupported codecs results in stale transceiver HOT 2
- Should media capabilities influence what is exposed in what is exposed in WebRTC offers and answers HOT 13
- Consider making RTCIceCandidatePair an interface HOT 5
- Update the accessibility section 14 to include RFC 8865 for real-time text in WebRTC data channel HOT 43
- 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
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.