Re: [rtcweb] Issue with "priority" defined in rtcweb-transports

[Harald Alvestrand <[e-mail]>]

Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
>     For instance, screenshare-type video varies enormously in
>     bandwidth (very low at static images, enormous at slide change) - if it
>     competes against audio, a "relative" bitrate ratio will not be useful at
>     all.
> 
> 
> I think that's where it's important to get the terminology right; for
> example, rtcweb-transports uses the term "capacity", which implies that
> it's possible to use fewer bits than the capacity. Maybe that's the best
> way to think of this. We also can allow some implementation flexibility.
> 
>     Is there a way we can punt this?
> 
> 
> If we do punt this, I still think we should remove the part of
> rtcweb-transports that talks about the priority causing codecs to be
> configured with send rates at these 1:2:4:8 ratios:
> 
>        o  When the available bandwidth is known from the congestion control
>           algorithm, configure each codec and each data channel with a
>           target send rate that is appropriate to its share of the available
>           bandwidth.
> 
> 
> We should make it clear that the priority only affects the delivery of
> packets (pacing decisions, QoS, SCTP priority), and not how the packets
> are generated upstream. Assuming others agree.

The words about configuring the codecs were intended as advice - most
codecs are terrible at dealing with random lost packets (even with FEC
and NACK and all that), so if the pacer is going to throw their packets
away, the best thing to do is to not generate them.

(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though. So
sometimes it works.)

This section is already headed with the words "Two example
implementation strategies are:", so it should already be clear that it's
advice, not normative language.

I'm happy to weaken the words even more, but wouldn't want to lose the
advice entirely.