Re: Summary of replace track status

On 26/05/15 22:50, Bernard Aboba wrote:
> Stefan said:
>
> "after the dance there is a replaceTrack with a video source that
> does not encode to h265."
>
> [BA] Looking through the Media Capture specification, I do not see
> mention of a track having an encoding constraint or codec attribute.
> Can you point out to me where this is described?

It is not described. I tried to clarify the use case described by Adam 
in https://lists.w3.org/Archives/Public/public-webrtc/2015May/0130.html

I think it is valid, don't you agree?

>
> This leads me to one conclusion and one question.
>
> Conclusion: replaceTrack should always fail (throw) if the signaling
> state is not stable (this was probably apparent to everyone else
> already).
>
> [BA] Sure.
>
> Question: what would the sender's RtpParameters read out during the
> different stages of the dance if the app for some reason decides to
> check?
>
> [BA] So far, I believe that the assumption is that RtpParameters are
> not changed (e.g. they remain as they were set).   If the
> RtpParameters are illegal, then an exception would result, but having
> the browser guess what was intended and change the value to match
> "what I think you meant" is problematic.  Plus, changing
> RtpParameters would probably imply the need for an event when they
> are changed.  So probably best not to go down that road unless it is
> absolutely necessary.

I agree. But what was unclear to me is what the RtpParameter should read 
out if never set by the application. I.e., if the application does

var sender = pc.addTrack(trackX);
[.....]
var rtp_params = sender.RtpParameters;

(put in any number of the createOffer/setLocal/setRemote or 
setRemote/createAnswer/setLocal steps - including nothing - in place of 
[.....])

what would rtp-params be? Would it depend on how far you've come in the 
create/set... chain?

Received on Wednesday, 27 May 2015 10:28:57 UTC