Re: [rtcweb] Plan A, respun

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

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