Re: [MMUSIC] Remove msid-semantic

[Magnus Westerlund <[e-mail]>]

Hi Harald,


Harald Alvestrand skrev den 2015-04-15 15:41:
> OK, here is how the section on handing unsignalled tracks looks when
> I've removed msid-semantic.
> 
> Note that depending on exactly how we do early media, this may cause
> trouble in delivering it.
> 
> 3.1.  Handling of non-signalled tracks
> 
>    Entities that do not use msid will not send msid.  This means that
>    there will be some incoming RTP packets that the recipient has no
>    predefined MediaStream id value for.
> 
>    Note that this handling is triggered by incoming RTP packets, not by
>    SDP negotiation.
> 
>    When MSID is used, the only time this can happen is when, at a time
>    subsequent to the initial negotiation, a negotiation is performed
>    where the answerer adds a MediaStreamTrack to an already established
>    connection and starts sending data before the answer is received by
>    the offerer.  For initial negotiation, packets won't flow until the
>    ICE candidates and fingerprints have been exchanged, so this is not
>    an issue.
> 
>    The recipient of those packets will perform the following steps:
> 
>    o  When RTP packets are initially received, it will create an
>       appropriate MediaStreamTrack based on the type of the media
>       (carried in PayloadType), and use the mid RTP attribute (if
>       present) to associate the RTP packets with a specific media
>       section.  If the connection is not in the RTCSignalingState
>       "stable", it will wait at this point.
> 
>    o  When the connection is in the RTCSignalingState "stable", it will
>       look at the relevant media section to find the msid attribute.
> 
>    o  If there is an msid attribute, it will use that attribute to
>       populate the "id" field of the MediaStreamTrack and associated
>       MediaStreams, as described above.
> 
>    o  If there is no msid attribute, the identifier of the
>       MediaStreamTrack will be set to a randomly generated string, and
>       it will be signalled as being part of a MediaStream with the
>       WebIDL "label" attribute set to "Non-WebRTC stream".
> 
>    o  After deciding on the "id" field to be applied to the
>       MediaStreamTrack, the track will be signalled to the user.
> 
>    The process above may involve a considerable amount of buffering
>    before the stable state is entered, If the implementation wishes to
>    limit this buffering, it MUST send a "mediadiscarded" event to the
>    user, as described in [????].

I think there are two aspects of the buffering here that may need a bit
more discussion. So one buffers to ensure that one have a good media
encoding entry point. However, in most cases one can't really play out
all the buffered media, unless one can play it at faster than real-time.
Video fairly simple, audio a bit trickier, especially if one likes to
catch up quickly with the minimal delay point. Thus, one either miss
media or may end up with a significant time delay that take time to
drain. Catching up is also resource demanding as one must be able to
decode faster than real-time.

Based on this, I wonder if you there need to be clearer recommendations
what to do. For example if I discard up until the last receiver media
entry point available, should I then send mediadiscarded event? Is the
application happier if I play from start and then spend 15 seconds
catching up? How do we know which behaviour an application prefer here?

Maybe the issue and possible strategies should be highlighted, and
further note that application may want to ensure that signalling has
concluded before sending media.

I am not happy to have to go into detail here, but it also looks like
this will be one pile of inconsistent behaviour between implementations.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------