Re: [rtcweb] Plan A, respun

[Martin Thomson <[e-mail]>]

This is a pretty complicated example, but I agree that it is quite relevant.

If the camera that can produce Z is attached (to the
RTCPeerConnection), then an offer would include X, Y and Z, but it
would probably have to be marked sendonly.  Other m-lines could be
used to offer to receive X and Y.

I don't see this being solved very well by SDP at all.  Regardless of
the option chosen.

On 8 May 2013 06:06, Stefan Håkansson LK
<[e-mail]> wrote:
> One more question (and I think this one is applicable to Plan B as well). It
> has to do with devices with HW encoders.
>
> If I have a system that supports video encoding and decoding of format X and
> Y it is pretty obvious what the offer should look like.
>
> But if I add a camera that can also encode in format Z, what should the
> offer look like?
>
> The camera would not decode, so for sendrecv m-lines format Z could not be
> included in an offer.
>
> Does this mean that to utilize camera encoders (if the corresponding
> decoders are not available in the system), we'd be limited to sendonly
> m-lines?
>
> Stefan
>
>
>
> On 2013-05-08 14:38, Stefan Håkansson LK wrote:
>>
>> A couple of questions (and sorry for the rtcweb/webrtc centric
>> perspective) for clarification:
>>
>> * How would the info about PC-track and PC-stream id's be conveyed (I
>> assume the msid draft)?
>>
>> * What is your thinking regarding mapping between PC-tracks and m-lines?
>> For example, if Alice's app initiates a session with two video
>> PC-track's flowing to Bob's app, that would presumable create a session
>> with two sendonly m-lines. If, at a later stage, Bob's app upgrades the
>> session by sending three video PC-tracks to Alice's app. How would the
>> Bob -> Alice video PC-tracks be allocated to the existing m-lines
>> (becoming sendrecv), and how would pick which one to use a new m-line?
>> E.g., would it be random, or should the app decide, and based on what in
>> that case?
>>
>> Stefan
>>
>>
>>
>> On 2013-05-07 20:30, Adam Roach wrote:
>>>
>>> In order to facilitate discussion between the two SDP format
>>> alternatives we're considering, I've put together a document that more
>>> clearly spells out the Plan A approach as we originally envisioned it.
>>> Note that this is a slightly different approach than Cullen outlined in
>>> Orlando. I fear the Orlando approach may have suffered from its attempts
>>> to incorporate some elements of Plan B in an attempt to appease
>>> proponents of that approach; and, in doing so, lost some of its clean
>>> architecture.
>>>
>>> The cleaned up, new-and-improved description of the Plan A approach is
>>> available here:
>>>
>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
>>>
>>> Note that we've omitted discussion of glare reduction from that
>>> document, as I believe that mid-session glare can be completely avoided
>>> by applications implementing a set of non-normative behaviors. These
>>> behaviors are described in the a separate companion document:
>>>
>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
>>>
>>> Thanks.
>>>
>>> /a
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb