Subject: [rtcweb] Cullen Notes from RTCWeb interim on June 18, 2015

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 18 Jun 2015 18:00:36 +0000

These are just my rough notes and chairs will form minutes from everything we get

* make sure to add note well slide to slide deck 

LS Behavior 
- Magnus points out that if JSEP overrides 5888, we will have issue with legacy things
- Martin points needs more thought to make declarative groups
- Martin raised point that we might be able to add some extra signaling that indicates that we can support this declarative LS usage 

Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2 

ImageAttr specification (receiver)
- people are good on what we send (intersection)
- do need to talk more about  with receiving min or not 

b= slide 
- no issues

c= slide 
- no issue 
Note :: does not work in c line but the 0.0.0.0 does 

Moving on to Open Issue slides 

Issue #9 - changing b=
Do we need to deal with bs=RS/RR 

Magnus - reason to honor this... consider use case with middle box where middle box wants to tune RTCP to ensure the middle box gets enough feedback. 5% is a problem if you want rapid feedback and low bit rate media. So you might want to use this to up it. 

Randal - might want to be up this above 5% to improve bandwidth estimation

Magnus - thinks we need to be able to set them and have endpoint honor them 

Randal - use case is what if you want to send feedback on every frame of a video for some congestion control use case

Justin - hard to implement and not clear at this point

Randal - propose what we implement now is if you receive this, you will not go over the specified value (but does not mean that the implementation would necessarily send more)

Magnus propose. Browsers set it (at default 5% is fine). This allows middle boxes to change. And browsers interpret it and do not exceed it. 

Conclusion: browser need to be able to receive RS/RR and honor it 

#144 b= at session level
- no objections

#122 b=TIAS 
- OK with this 

#148/149 a=ssrc
- Question can we list both and switch ? 

- read more in https://tools.ietf.org/html/rfc7160

- HTA raise point that switching is not going to happen in a session with simulcast 

- HTA proposal, if on a session that is not simulcast, and you see a SSRC switch, just deal with it

Next steps: go study what this hybrid approach would look like 

# question on imageattr - what happens when rotate

Proposal: always send image attr in landscape and rely on CVO for rotations. We need to take this idea and circulate widely (such as 3GPP).

Randal - what if native is not rotated. 

CVO is Coordination of Video Orientation (CVO) section 7.4.5 of [TS26.114]

Probably needs some offline discussion. 

Magnus will see if he can get someone to explain where the 3GPP and related standards are on this. 

#16 Accessors 
- no comments

Skip forward to last slide on Upscaling video 

Conclusion:
- we add some sort of switch that sets if upscale is allowed or not
- default is to allow upscale

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 22 Jun 2015 13:19:59 +0200

> Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2
Just FWIW:

Personally, I don't see the added value in adding LS groups.

We already have a well defined, declarative (=one-way) means of 
declaring synchronization in the form of the MSID values, which bind 
MediaStreamTracks into MediaStreams, which you're supposed to try 
syncing if you can (it's not a hard requirement in the spec that you 
should succeed).

If we want to be extra helpful for non-WebRTC implementations, and end 
up in the case where we have one audio and one video track from one 
stream in one direction using the same media descriptions as an audio 
and video track in the other direction (which will be the normal case 
when your application is trying to emulate a single-channel VC unit), I 
have no particular problems with adding LS group markings to those media 
descriptions - but I don't want to spend resources changing the 
semantics of LS groups (and thereby imperiling the exact interworking 
we're trying to make easier) when we already have something that fulfils 
all the requirements for a pure WebRTC scenario.

My $0.02.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Jun 2015 10:24:42 -0700

I think that LS makes more sense. Doing both LS and MSID was a comprise the WG came to long ago. We need for a say to synchronized audio and video and the IETF has already defined a widely deployed way of doing that so I don't see a gain in ignoring it and inventing something else. 

> On Jun 22, 2015, at 5:19 AM, Harald Alvestrand <[email-masked]> wrote:
> 
> We already have a well defined, declarative (=one-way) means of declaring synchronization in the form of the MSID values, which bind MediaStreamTracks into MediaStreams, which you're supposed to try syncing if you can (it's not a hard requirement in the spec that you should succeed).
> 
> If we want to be extra helpful for non-WebRTC implementations, and end up in the case where we have one audio and one video track from one stream in one direction using the same media descriptions as an audio and video track in the other direction (which will be the normal case when your application is trying to emulate a single-channel VC unit), I have no particular problems with adding LS group markings to those media descriptions - but I don't want to spend resources changing the semantics of LS groups (and thereby imperiling the exact interworking we're trying to make easier) when we already have something that fulfils all the requirements for a pure WebRTC scenario.
> 
> My $0.02.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb