Re: [rtcweb] Plan A, respun

[Stefan Håkansson LK <[e-mail]>]

On 5/8/13 5:47 PM, "Martin Thomson" <[e-mail]> wrote:

>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.

That's in line with my conclusion.

>
>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