Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-video-traffic-model-06: (with COMMENT)

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi Benjamin,

Thanks for reviewing our draft.  A new version (-07) has been submitted in which we 
try to incorporate your comments.  For your quick reference, more detailed responses
are provided inline below (tagged [XZ]). 

Let us know if you have any further thoughts or suggestions. 

Best regards,
Xiaoqing (on behalf of all authors)

On 2/6/19, 8:32 PM, "rmcat on behalf of Benjamin Kaduk" <[e-mail] on behalf of [e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-rmcat-video-traffic-model-06: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Thank you for the easy-to-read, well-written document.  I just have a few
    minor (IIUC) editorial comments.
    
    Section 4
    
    Do we need to define I-frame?  (And P-frame, in Section 6.1 later.)
    
[XZ]  Good point. We have added a reference to H.264/AVC when I-frame and P-frame 
are first mentioned in Sec. 2. The text in 2nd paragraph of Section 3 is now updated as:

"... Finally, while most of the frames in a live session are encoded in
predictive mode (i.e., P-frames in [H264]), the encoder can occasionally
generate a large intra-coded frame (i.e., I-frame as defined in [H264]) or
a frame partially containing intra-coded blocks in an attempt to recover from
losses, to re-sync with the receiver, or during the transient period of
responding to target rate or spatial resolution changes."

    Section 6.1
    
    Could the text (either here or in a previous section) call out more clearly
    that n_s is a (new) defined parameter for the simulation?


[XZ] Good catch.  The text where n_s first appears has been modified as:

" ... the entire range of target bitrates can be divided into n_s steps. 
This leads to a encoding bitrate ladder of (n_s + 1) choices equally
spaced apart by the step length l = (R_max - R_min)/n_s. "
    
    Section 6.2.1
    
    I think I'm missing a qualifier somewhere -- in the first bullet point of
    the main algorithm, we see that:
    
                                                          It is assumed that
          the value of R_v is clipped within the range [R_min, R_max].
    
    but later on the section we calculate frame sizes for cases where  b) R_v <
    r_min , and c) r_v >= R_max.  What am I missing that makes these two places
    in the text different?
    
                      factor = R_v / R_min

[XZ]  Thanks for pointing out this discrepancy.  We added some clarifying text
in the end of Section 6.1 to distinguish bitrate range of trace files from the bitrate
range of congestion control requests:

"Finally, note that, as mentioned in previous sections, R_min and
   R_max may be modified after the initial sequences are encoded.
   Henceforth, for notational clarity, we refer to the bitrate range of
   the trace file as [Rf_min, Rf_max].  The algorithm described in the
   next section also covers the cases when the current target bitrate is
   less than Rf_min, or greater than Rf_max."

[XZ] We then revised the text in Sec. 6.2 using Rf_min and Rf_max instead
when describing how instantaneous frame sizes are calculated.

    
    Does it matter if I use integer or floating-point arithmetic to compute
    'factor'?  (Same question for R_max as well, of course.)
    
    

[XZ] We expect to use floating point arithmetic for "factor". Some additional
Clarifying text is added on how instantaneous frame size is calculated:

"In cases b) and c), floating-point arithmetic is used for computing
   the scaling factor w.  The resulting value of the instantaneous frame
   size (framesize) is further clipped within a reasonable range between
   fs_min (e.g., 10 bytes) and fs_max (e.g., 1MB)."