Re: [rtcweb] JS app interaction with congestion control

This really is almost all W3c stuff; cc'ing that list where most 
discussion should occur.

Updated suggestion based on Justin's comments:  (largely for W3C 
discussion)

This is rough, and a first cut, but we need to start somewhere.

I propose we add a callback on PeerConnection and some attributes on it
and MediaTracks:

{
...
     // allow app to limit total bitrate used for the PeerConnection
     attribute unsigned long maxBitrate;
     attribute readonly unsigned long currentBitrate;  // [Open issue] - 
how much smoothing?

     attribute Function? onBitrateChange;
     // don't notify until change since last notify is more than this
     attribute unsigned long minBitrateChangeToNotify;
     attribute Function? onResolutionChange;  // not strictly needed

     // These are global settings that can be overridden on a per-track 
basis
     attribute float minFramerate;
     attribute float maxFramerate; // might not be needed
     attribute boolean preferMotion;  // false means preference for 
Resolution
}


To each MediaTrack:

{
...
     // If the app bumps up the currentBitrate of one track and doesn't 
lower another track, the
     // system will make cuts to keep the total bitrate within bounds.
     attribute unsigned long currentBitrate;
     attribute short priority;  // for allocating bits

     // The rest of these are for video (is short guaranteed enough, 
always?  Probably)
     attribute unsigned short width;  // Let app override the values 
chosen automatically
     attribute unsigned short height;
     attribute float framerate;
     attribute float minFramerate;
     attribute float maxFramerate; // might not be needed
     attribute boolean preferMotion;  // false means preference for 
Resolution

     // typically derived from QP
     attribute readonly unsigned short videoQuality;
     // audioQuality?? (samplerate?)

}

Should some of these be echoed in MediaTrackLists or MediaStreams?


-- 
Randell Jesup
randell-ietf@jesup.org