Re: [rmcat] How to handle an increasing send buffer

["Mo Zanaty (mzanaty)" <[e-mail]>]

I encourage folks to read and give feedback on the app interaction draft which covers all of this.

The interaction between the congestion control and encoder is limited to things like Allowed Rate (CC to codec), Media Elasticity (codec to CC), etc.

Codec decisions like changing frame rate, frame type, quantization, etc. are not part of the CC-codec interaction, so no solution candidate should include such things.

Simulated codecs should have the exact same interactions with CC as real ones, and their internal behavior should model real ones. For example, simulate changes in frame rate, frame type, quantization, etc. with proportional changes in synthetic output size and frequency.

Mahalo!
Mo


On 11/11/14, 9:10 PM, Randell Jesup <[e-mail]<mailto:[e-mail]>> wrote:

On 11/11/2014 6:53 PM, Xiaoqing Zhu (xiaoqzhu) wrote:
Regarding what’s the best way to model the encoder behavior …

We submitted a new draft on synthetic video traffic modeling for RMCAT evaluation, which contains some discussions what behaviors we want to model for such a codec (Sec 3):

https://tools.ietf.org/html/draft-zhu-rmcat-video-traffic-source-00

Thought I forwarded the new draft submission to the mailing list before but turns out I never did (Thanks to Varun for pointing this out).

I would NOT have the congestion controller send "drop frame" commands.  It should indicate:
* Estimated bitrate share
* Target bitrate (assuming continuous generation)
* Estimated additional one-way-delay above base estimate
and/or estimated number of buffered bits at bottleneck
* Loss indication/level (not for direct recovery - that's handled by other RTCP messages - but to tune the generated traffic

For the synthetic algorithm, I suggest that the fake encoder drop limited number of frames when the overhang (bits-behind-the-8-ball, number of bits buffered at bottleneck, or additional OWD*bitrate - all ways to say the same thing) is on the order of multiple encoded frames.  This moves the frame skipping out where it belongs, in the app/encoder (which we're abstracting here).

Errors when reported back to the sender would invoke one of several recovery mechanisms:
* retransmit - congestion-invoked loss means retransmit will need to steal N bits from your available total in the next encoding cycle, perhaps plus more.
* FEC - means loss may not cause an error result, at the code of "burning" some of your bandwidth.   Adaptive FEC will use more bits if errors are higher (or are anticipated to, see Varun's paper), so differences between algorithms in resultant error rates will affect quality (reduced by using more FEC bits) and number of recoveries-by-IDR (when FEC fails).
* IDR request - PLI/etc - classic recovery, causes a burst of traffic and in many (not all) cases may be best followed by a frame drop or two or three.  Obviously the size of the burst will affect the delay, but also affects quality.  This can be compensated for without waiting for a delay signal.  Note that dropping  frames is NOT good if we're not causing or near a bottleneck.

Since errors caused by the congestion mechanism affect the sending codec rates, they're important.

--
Randell Jesup -- rjesup a t mozilla d o t com