Re: [AVT] Comments on draft-hiwasaki-avt-rtp-uemclip-00

[yusuke hiwasaki <[e-mail]>]

Dear Roni,

Thank you very much for your comments. I'm very grateful that you
checked through the draft in quite detail.

The reply comments are put in-line, however, please take into account
that unanswered comments does not mean that it is being ignored, but
means that it will be reflected in the next draft submission.

At Fri, 3 Nov 2006 20:32:33 +0200,
Even, Roni wrote:
> 4. In section 2 "Fs is the sampling frequency in Hz" should be KHz

Yes, it should not be Hz, but I am thinking that perhaps it should be
"kHz" with a small "k". Here, I am assuming that the large "K" means
2^10, and small "k" as 10^3. Would that be ok?

> 7. Maybe change the title of section 3 to media packetization

Ok, but the title might not fit the outlines indicated in
draft-ietf-avt-rtp-howto-00.txt. I will try to figure out a solution.

> 9. You have figure 1 and 3 not figure 2. In figure 3 there is a
> subheader not described in the frame description.

The BNF expression somehow got the figure number "2", but this did not
show up in the formatted result. Because the BNF expression will be
taken out in the next draft, this will be fixed automatically.

About the figure 3, what I meant "sub-header + sub-layer" was the
"sub-layer data" described in Section 3.2. I will take out
"sub-header" expressions from this figure.

> 10. In section 3 before figure 3 you mention layer ID but it is not
> defined.

When I said "layer ID", I was meaning as a combination of channel,
frequency and quality indices. Since the expression is misleading, the
sentence will changed and be placed in Section 3.2.

> 11. In section 3.1 you have the main header as 10 bytes, figure 3 and 4
> shows 9 bytes.

There was a mistake in Figure 3 (now Fig.2) and 4 (now Fig.3). It
should be 10 bytes as stated, because of an extra reserved byte.

> 12. In section 3.1 you have "packet size" which field is "packet
> size"

I meant "Byte size" (BS) as "packet size". The sentence is wrong
anyways (the value should be subtracted by 3, not 5) and the
description will be merged into "BS" description.

> 13. Power #1 - what is the meaning of this field, is it relevant to
> G.711
> 
> 14. VAD flag #2 - why have it if the same as V1 and is redundant
> 
> 15. Frame indicator (K) - What do you mean by the frame offset of U2 and
> P2. Offset from where. In figure 4 and in the text U2 is one byte after
> K and P2 follows or am I missing something.
> 
(snip) 
> 16. What is P1 or P2 is it relevant to G.711 frame. If this is part of
> the codec information you should have a reference to it. But since you
> want anyone to be able to get the G.711 from this codec bitstream you
> should explain the meaning of the header fields and how to extract G.711
> maybe in a separate section.

Although not clearly stated in the current draft, the fields in main
header from C1 to PW1 are intended for use in hubs (MCUs or mixing
server) for mixing multiple locations (mixing info.), and C2 to PW2
are intended for packet-loss concealment (PLC). These fields are
encoded from G.711 signals, by a UEMCLIP encoder.

This feature is one of the advantages of using UEMCLIP, because by
calculating those auxiliary information at the encoder, we can avoid
load that arises on the mixing server. What a UEMCLIP mixer does is
that it fully mixes the G.711 part while selecting the enhancement
layers of an active location from judgments based on the mixing
info. Thus a (pseudo) wideband speech mixing can easily be performed
at the mixing hubs.

Again, V1 and V2 are redundant because those are intended for mixing
and PLC, respectively. The current implementation of our codec sets
the same value for those, thus either can be left out. However, in the
future, we might have a different value that fit better for each
purpose. This also applies to PW1 and PW2 too.

> 17. You have ES as 8 bits but to me it looks like EH can be bigger the
> 8*EH since SB is also given as a bit and LD is 8*SB and LD is part of
> EH.
> 

Sorry for awkward explanations. LD is not a part of EH, but rather,
belongs to sub-layer data. Sub-layer data are placed after the
main-header (and the main-header which includes EH). Thus the field
order should be:

... | PW2 | ES | EH | CI | FI | QI | R4 | SB | LD | CI | ...

This means that the main-header can have a size larger than 10 bytes,
because EH can be elastic. This leaves us some room for future
extensions. Currently our implementation has 0x00 set to ES, which
means that EH has zero length (thus the main-header size is 10 bytes).
I will certainly try to fix the explanations in the next version.

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