Re: SDP renegotiation with same msid but different ssrc (video becomes frozen)

2016-03-11 18:57 GMT+01:00 Taylor Brandstetter <deadbeef@google.com>:
> Chrome's WebRTC implementation treats changing the SSRC as removing a track
> with the old SSRC and adding a track with the new one. This probably isn't
> the right thing to do (especially when we go to Unified Plan SDP) but it's
> the way it's worked for a while.
>
> And, due to the bug you linked
> (https://bugs.chromium.org/p/chromium/issues/detail?id=415501), adding a
> track to a MediaStream does not update the video element.
>
> I'm not sure why this bug is closed though. It's caused me a good deal of
> frustration personally.
>
> The current Media Capture and Streams last call working draft says:
>
> For each MediaStreamTrack in the MediaStream , including those that are
> added after the User Agent enters the media element load algorithm, the User
> Agent must create a corresponding AudioTrack or VideoTrack as defined in
> [HTML5].
>
>
> The more recent editor's draft instead references HTML51. And although it's
> a bit difficult (at least for me) to sift through the algorithm in HTML51,
> my interpretation is that it works the same way in regards to adding tracks.
> The key excerpts being:
>
> Whenever new data for the current media resource becomes available, queue a
> task to run the first appropriate steps from the media data processing steps
> list below.
> ...
> The media data processing steps list is as follows:
> ...
> If the media resource is found to have a video track
>
> Create a VideoTrack object to represent the video track.
>
> So... Can we reopen this bug? Harald, Peter, your thoughts?

Very useful text. Do you mind adding it into the bug report?
It is currently marked as WONTFIX due the deprecation of MediaStream
usage in WebRTC, but indeed, I expect the same problem will arise
when, instead of MediaStream, we take MediaStreamTracks from the
PeerConnection and add them into a MediaStream being rendered by a
video element.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 11 March 2016 20:07:53 UTC