Re: [AVT] Comments on draft-ietf-avt-rtp-uemclip-02.txt

[yusuke hiwasaki <[e-mail]>]

Dear Aurelien,

Thanks for your comments. The replies are in-line:

> * Section 2
> 
> It seems it is a 20-ms framed coder. You should state it.
> Is there a reference to the coder spec?

Indeed, it is a 20-ms framed coder. I will add a description that it
operates at 20-ms frame. The coder spec is obtainable from the
authors, but will be disclosed under certain terms of
conditions. Should I be specific about it?

> * Section 3.1, the paragraph on the timestamp is not very clear.
> 
> "the RTP timestamp MUST advance based on a multiple of 8 kHz ..."
> I think the word 'clock' is missing somewhere.
> It would be clearer to talk about the RTP timestamp clock that is 8 or 16 kHz, and explain how it is chosen.

Ok, I will try to specify at an appropriate place. My understanding is
that the "timestamp" advance at the "clock rate", and will reflect it
accordingly.

> * Section 3.3.1
> 
>   - In figure 3, I think you could remove all the "0 1 2 3 ..." in the fields.
> The classical rule is to use network byte order. If it is the case, simply state it and simplify the figure.

I will change the figures as suggested.

>   - ID : For it to be useful, it should be a MUST. What is the intent of this field?

This field is a redundant information to inform the decoder that what
it is actually trying to decode a UEMCLIP bitstream. Authors would
like to keep it as it is now.

>   - BS : it is not clear how it is used when multiple frames are packed. By the way, is this field really needed? It seems redundant with the payload size.

It will only indicate the byte size in a frame, not the payload
size. 

>   - MX and PC : add reference to the describing sections

Those subsections will be referenced.

> * Sections 3.3.1.1 and 3.3.1.2
> 
>  - It could be interesting to have informational text on the goal and the way to use these fields.
> For example how is computed PW1 or PW2? How could V1 and V2 be different? ...
> I think more documentation is desirable.

As described, the PW1 is specifically used for the mixing information
and only indicates the power indices current frame (note, it is only
indices, and I believe how to encode this field would be out of the
scope of this document). On the other hand, PW2 is power of any frames
that the field K points at.

Regarding V1 and V2, to obtain the best achievable quality, we believe
that using different criterion is favourable for mixing and PLC. This
means that those can have different values in a frame. I have
clarified that those flags may be different (where it used to be "may
be as same").

>  - R3 : reserved bit are usually set to zero

I agree, but this one needs to be set otherwise. Since it specifies a
default value, I think it should be ok as is now.

> * Section 3.3.2
> 
>  - Is SB really useful? I think with CI, FI and QI and figure 3 you can deduce the sub layer size?

Yes, but this field is reserved for future use. Or perhaps I should
set it as "reserved" and write down the default values to avoid
confusions? 

>  - Figure 3 : CI is set to zero but the text says it should be "0x1"

My mistake. This will be fixed to "0" in the updated version.

> * Section 5
> 
> "UEMCLIP does not have any built-in mechanism for reducing the bandwidth"
> -> I don't think it is true since you can remove high level layers if you want.

You are right. I will enhance this section and try to clarify how
bandwidth can be reduced.

> * Section 6.1
> 
>  - this part should be self-contained so when referring Sections, you should add "of RFC XXXX"

Will be changed as suggested.

> * Section 6.2
> 
> I'm not sure the "Bandwidth" paragraph is needed.

It seems that recent RFCs regarding RTP payload type specs don't have
this paragraph. I will delete it.

> * Section 6.3.2
> 
> It is a little incorrect to state "In the example below, the ptime is set to 60, and this
>    means that there are 3 frames in each packet."
> 
> RFC 3264 says "If the ptime attribute is present for a stream, it indicates the
>    desired packetization interval that the offerer would like to
>    receive."

I will try to improve the statement.

Best regards,
yusuke
-- 
============
Yusuke Hiwasaki, NTT Cyber Space Labs.
[e-mail]
Tel: [phone] (Fax: [phone])


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt