[ortc] What should rtpReceiver.receive() with two (switched) encodings produce?

ibc has just created a new issue for https://github.com/openpeer/ortc:

== What should rtpReceiver.receive() with two (switched) encodings 
produce? ==
Somehow we call `rtpReceiver.receive()` with these parameters:

```js
{
        codecs :
        [
                {
                        name        : 'video/VP8',
                        payloadType : 101
                },
                {
                        name        : 'video/VP9',
                        payloadType : 102
                }
        ],
        encodings :
        [
                {
                        codecPayloadType : 101,
                        ssrc             : 111111
                },
                {
                        codecPayloadType : 102,
                        ssrc             : 222222
                }
        ]
}
```

Let's assume that such a parameters come from a server or SFU and it 
guarantees that just a single encoding would be sent at the same time.

* The receiver associated `MediaStreamTrack` is attached into a 
`MediaStream` being played in a `<video>` element. 

* Initially VP8 (ssrc 111111) is received and its video routed to the 
generated `MediaStreamTrack`, so we have visible video. Yeah.

* Later the server switches to VP9 (ssrc 222222).

What would happen in the receiver? In a happy world I would expect 
that the receiver would properly decode the VP9 stream and pass the 
output to the `MediaStreamTrack`, and if the world is full of 
unicorns, the `<video>` element would automatically render the new VP9
 video stream.

But in the real world in happens that Chrome is tiled to Plan-B (in 
which different media SSRCs identify different `MediaStreamTrack` 
instances, there is `MediaStream.onaddtrack`, etc etc).

Anyhow, what should happen in the receiver side in the above scenario?

Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/558 using your GitHub account

Received on Wednesday, 1 June 2016 14:07:58 UTC