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

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
<https://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStreamTrack> in
the MediaStream
<https://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStream> ,
including those that are added after the User Agent enters the media
element load algorithm
<http://www.w3.org/TR/html5/embedded-content-0.html#media-element-load-algorithm>,
the User Agent must create a corresponding AudioTrack
<http://www.w3.org/TR/html5/embedded-content-0.html#audiotrack> or
VideoTrack <http://www.w3.org/TR/html5/embedded-content-0.html#videotrack> as
defined in [HTML5 <https://www.w3.org/TR/mediacapture-streams/#bib-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 <https://www.w3.org/TR/html51/webappapis.html#queuing> to run the
first appropriate steps from the media data processing steps list
<https://www.w3.org/TR/html51/semantics-embedded-content.html#media-data-processing-steps-list>
 below.
...
The media data processing steps list is as follows:
...
If the media resource
<https://www.w3.org/TR/html51/semantics-embedded-content.html#media-resource>
 is found to have a video track

   1. Create a VideoTrack
   <https://www.w3.org/TR/html51/semantics-embedded-content.html#videotrack-videotrack>
object
   to represent the video track.

So... Can we reopen this bug? Harald, Peter, your thoughts?

On Fri, Mar 11, 2016 at 5:55 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2016-03-11 14:48 GMT+01:00 Harald Alvestrand <harald@alvestrand.no>:
> > I am not at all surprised it does not work. I think it should, but I'm
> > not sure exactly how.
>
> I'm strongly sure that this is 100% related:
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=415501
>
> Basically, when something changes in a MediaStream (added/removed
> tracks) the video element rendering it is not updated. Setting again
> video.src = URL.ObjectCreateURL(stream) updates it.
>
>
> > Question: When does the sender change its SSRC to the new value? When
> > sending the offer in the negotiation, or when getting the answer back
> > that it's accepted?
>
> Chrome sends a SDP re-offer. The SDP answer from the server contains
> different ssrc than before the renegotiation.
>
>
> > And what does it send inbetween those two times? Nothing, old SSRC or
> > new SSRC?
>
> Once the server receives the SDP re-offer from Chrome, the server
> changes its sending ssrc and sends RTP packets with the new SSRC
> value.
>
>
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
>