Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 21:48:24 -0800

On 10/28/2013 10:49 AM, Colin Perkins wrote:
> I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that.

[catching up on pre-IETF mail)

God yes.  Switching between files encoded at different rates is nothing 
like what the applications are doing here - realtime encoding.

Either use a dummy source that (with small delays in response to account 
for encoding time) follows the rate recommendations on the nose with 
dummy data (which is not *that* far off from reality, BTW) or use a real 
encoder with real video.

I'll note that a real encoder may steal a few bits for a frame and give 
them back the next frame, etc - this gets hidden in practice because the 
data goes into jitter buffers on reception, so isn't played out as it 
comes in.  (Or more to the point, the audio data is run through a jitter 
buffer, and the video data is queued in a buffer to be decoded in sync 
with the audio - the effect is the same; there is smoothing over the 
approximate jitterbuffer-length. However, modeling the encoder as 
perfectly following the signals from the CC should produce a fine result.)

-- 
Randell Jesup
[email-masked]

---

From: Varun Singh <[email-masked]>
Date: Mon, 4 Nov 2013 10:06:34 -0800

Hi,

Slideset from yesterday's meeting are available at:
https://speakerdeck.com/vr000m/media-traffic-generator-discussion
Note takers, if you could send the notes to me, I can then process and
post them to the mailing lists.

Cheers,
Varun

On Wed, Oct 30, 2013 at 6:49 AM, Varun Singh <[email-masked]> wrote:
> Hi all,
>
> Practical details for the meeting on **RMCAT Traffic models**
>
> Date: 03.11. 2013
> Time: 12:30 to 14:30.
> Assigned Room: Regency A
>
> Cheers,
> Varun
>
> On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh <[email-masked]> wrote:
>> Hi all,
>>
>> In RMCAT WG there has been discussion surrounding the use
>> of a media traffic generator and to facilitate discussion,
>> RMCAT is hosting a side meeting on Sunday, 03 November
>> at 1300-1500. I suppose the room details will be announced
>> shortly.
>>
>> Below is a list of questions that will help design or choose
>> an appropriate traffic generator for Interactive multimedia traffic.
>> The list is an initial set and mainly to foster discussion both
>> on the mailing list and at the meeting.
>>
>> Mirja and Lars are not available that day, hence on their behalf,
>> the meeting is hosted by Colin and I .
>>
>> Cheers,
>> Varun
>> ---
>>
>> Traffic generator: to model the intrinsic variability of video:
>>
>> - what target bit rates can be achieved? (max?, min?)
>> - how much variability in media bit rate for a given target bit rate
>> - how to model motion? capturing high motion leads to bursty video
>>   (higher than target bit rate), but by how much? can this even be done?
>>
>> Traffic generator: on responsiveness to a new target bitrate:
>>
>> - how quickly can the codec generate a lower bit rate?
>> - immediately? does this depend on the new or requested bit rate?
>> - what is immediately? is it next frame or a few frames later, until then
>>   does it generates at the current rate?
>> - if not immediately, what bitrates (and duration) will it generate before
>>   meeting the target bitrate.
>>
>>
>> - how quickly can the codec generate a higher bit rate?
>> - immediately in the next frame? does this also depend on the new
>>    or requested bit rate?
>> - not immediately but in steps of intermediate bitrates, i.e., intermediate
>>   bitrate for a short duration then an increase in step, repeating until
>>   reaching the target bit rate.
>>
>> - If the target bit rate is achieved in steps, can they be announced to the
>>   congestion controller, i.e., the congestion controller knows the ramp up
>>   curve to meet the target bit rate.
>>
>> - If the media bit rate has not yet reached the requested target bit rate and
>>   the congestion control requests a new target bit rate, how does the codec
>>   respond?
>>
>> Application design related:
>> - should the congestion control be able to change the frame rate (video) or
>>   packetization time (audio) or is this something that the application controls.
>> - should the congestion control be able to change video resolution?
>> - should error-repair: NACKs, FEC be considered part of congestion control or
>>   outside it, i.e., it is something that the application does and not
>>   congestion control
>> - If FEC is controlled by the congestion control, how quickly can the sending
>>   rate be adapted by reducing/adding redundancy (FEC)? is something link this
>>   done? Does this makes sense at all?
>> - Apart from loss and RTT, what other congestion cues are currently used by
>>   congestion control algorithms? e.g., Decoding rate/goodput, application
>>   decode error rate, ECN, PCN, etc.
>> - If the codec is data limited, i.e., producing a sending rate smaller than the
>>   one calculated by the congestion control, can the congestion control probe
>>   the bandwidth by sending additional data packets in a certain pattern (e.g.,
>>   PathChirp)? would somehting link this help?
>> - application input on prioritization: audio vs video (vs data)
>>
>>
>>
>>
>>
>> --
>> http://www.netlab.tkk.fi/~varun/
>
>
>
> --
> http://www.netlab.tkk.fi/~varun/

-- 
http://www.netlab.tkk.fi/~varun/