Re: [rmcat] Scenarios as input for new feedback format design

[Colin Perkins <[e-mail]>]

Hi,

Thanks for sending this! Some questions below, to make sure I understand, and we end up with realistic scenarios to evaluate.

> On 23 Aug 2016, at 16:09, Stefan Holmer <[e-mail]> wrote:
> As was requested in Berlin, here are a set of scenarios where we (Google) are of interested in using the feedback format. It would be great to analyze what would be needed to achieve this and discuss how we can improve the current design to possibly accommodate these scenarios.
> 
> Very low bitrate, audio only
> If a mobile connection becomes really bad for a period of time, we'd like to be able to gracefully degrade to audio only at a low bitrate. This is an extreme, but valid if the connection degrades to 2G for a while.
> - Uplink: 20 kbps
> - Downlink: 20 kbps
> - Audio packet rate: 17 packets/second

This is presumably Opus at 8kbps with 60ms frames? 

RTP/UDP/IPv4 header of 12 + 8 + 20 = 40 octets, plus 60 octets per packet Opus payload when coding 60ms frames at 8kbps CBR, gives a bit rate of 13333bps with no RTP header extensions and no RTCP. 

With 8 octets per packet for an RTP header extension (e.g., a short mid tag), this is 14400bps. Are there any other header extensions used?

It’s also presumably SRTP, so is there any extra padding, authentication tags, etc?

> Low bitrate audio and video
> - Uplink: 70-100 kbps
> - Downlink: 70-100 kbps
> - Audio packet rate: 50 packets/second
> - Video framerate: 7-15 fps
> 
> ADSL conference, 10 small thumbnail streams, 1 main stream
> - Uplink: 500 kbps
>     - Audio packet rate: 50 packets/second
>     - Video framerate: 30 fps
> - Downlink: 8000 kbps
>     - Thumbnail streams: 15 x 7 fps
>     - Main stream: 30 fps

For the video streams, what’s a typical pattern of packets-per-frame and octets-per-packet for the codecs used in these scenarios (the 30fps stream is presumably not 30 identically sized RTP packets sent evenly spaced, for example)? 

If you have packet traces, that’d be very helpful. 

Also, if it’s easier, we can schedule a call to talk through the details, and I can summarise. 

Cheers,
Colin



-- 
Colin Perkins
https://csperkins.org/