- From: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Jun 2016 14:07:50 +0000
- To: public-ortc@w3.org
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