Subject: [AVT] RE: more on the EVRC, SMV and Common Draft

From: Thomas Zeng <[email-masked]>
Date: Thu, 11 Oct 2001 18:34:02 -0700

I have some comments preceeded by [tzeng].

Regards,
thomas zeng
packetvideo corporation

-----Original Message-----
From: Adam Li [mailto:[email-masked]]
Sent: Thursday, October 11, 2001 6:17 PM
To: Randall Gellens; Ietf-Avt
Cc: Colin Perkins; Marcello Lioy; Thomas Zeng; Greg Sherwood; 'Stephen
Casner'; 'John D. Villasenor'; 'Yung Lyul Lee'; 'Jeong-Hoon Park';
'Keith Miller'; 'Craig Greer'; 'Tom Hiller'; 'Peter J. McCann'; 'David
Leon'; 'Nikolai Leung'; 'Dan Gal'; [email-masked];
[email-masked]; 'Lars-Erik Jonsson (EPL)';
[email-masked]; 'Vivek Bhargava'
Subject: more on the EVRC, SMV and Common Draft

>
> 1.  Are there likely to be implementations which need to
> support multiple vocoders?
>
> 2.  Would a common format make the implementation easier?
>

From standardization point of view, simplicity and consistency between
standards and revisions are always nice things to have. People who make the
devices probably will give a better suggestion on advantages on
implementation.

One more issues on the EVRC draft: with one small change, we can make the
current EVRC in exactly the same format at PureVoice in RFC 2658. The only
small change we will need to make is to take the current ToC byte and put
them in front of each data frame, instead of collecting the ToC in the
beginning of the packet.

[tzeng] The advantage of collecting ToC entries at the beginning of the
payload is such that ULP can be used, for instance, by
          covering only the ToC bytes with UDPlite-type of checksum schemes.

Actually the EVRC draft was like that before. There is really not much
difference technically. The ToC collected at the beginning of the packet was
chosen simply because that is the trend in contemporary design used in other
newer formats (such as AMR).

Maybe we should reverse that choice. And by doing that we can get rid of the
F bits. Also, if Peter thinks D bits can be packet based instead of frame
base, we can use one of the R bits in the Interleave Byte.

In this way, we can have a new format for EVRC/SMV (Type 1) totally
compatible with RFC 2658. PV/EVRC/SMV will have exactly the same format for
a nice consistency. And there is no need to retire RFC 2658 with a
imcompatible duplicate format for PureVoice. Everything fits perfectly in
place.
[tzeng] May be we should first find out whether PureVoice is still an active
Vocoder. Or is it a out-of-date vocoder, totally replaced by EVRC and SMV?

We should do that. What do you think? Editing that in should be very easy.

[tzeng] Before we do that, we should answer the question above, and debate
whether it is important to support UDPlite type of checksum schemes.

[tzeng] Thanks, thomas zeng

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: "Adam Li" <[email-masked]>
Date: Thu, 11 Oct 2001 18:49:02 -0700

>           covering only the ToC bytes with UDPlite-type of

In this particular case, receiving the Table of Content (ToC) but losing the
actual Content probably won't help much.

Adam

----------
Adam H. Li
Image Communication Lab                    (310) 825-5178 (Lab)
University of California, Los Angeles      (310) 825-7928 (Fax)

---

From: Pete McCann <[email-masked]>
Date: Fri, 12 Oct 2001 10:58:11 -0500 (CDT)

Hi,

 > actual Content probably won't help much.

Well, I don't know exactly how ULP works, but it may be the case that
only some of the Contents are damaged, but others can be recovered
because we have an intact ToC.

Anyway, let me just re-post here our suggested payload header for Type 
1 packets, because I'm not sure people on the AVT list saw it:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      RTP Header [RTP]                         |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |R|R| LLL | NNN | DDD | Frm Cnt |  TOC  |  ...  |  TOC  |padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |one or more codec data frames, one per TOC entry               |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is similar to the format suggested by Randy et al, except we are
adding the "reduced rate" DDD bits and reducing the frame count field
from 6 bits to 5 bits, implying a maximum of 32 frames per packet.
This should be more than enough - for conversational voice it probably
doesn't make sense to do bundling anyway.

The DDD field would have a codec-specific meaning to reduce the rate
of the peer, with the constraint that higher values of DDD imply an
equal or lesser rate.  We could supply appropriate text for each
codec.  For PureVoice, there might be only 2 meaningful values.  For
EVRC and SMV, it would have the meaning defined by the RATE_REDUC
field from IS-127 and the SMV draft standard, respectively.

This brings the D bit out of the per-frame TOC entries.  We agree with
earlier comments that it is unnecessary to signal this bit on a
per-frame basis.  However, if we want to cover SMV, we definitely need
3 bits.  EVRC can also make use of the 3 bits if you look at the
IS-127 standard.

What do people think?

-Pete

---

From: "Adam Li" <[email-masked]>
Date: Fri, 12 Oct 2001 16:13:48 -0700

(1) Bit Saving: 4-bit ToC vs 8-bit ToC - discussed before

First of all, the bit saving is not much. We have worked that out before in
the EVRC draft. A saving of 4 bits per frame and 45% full, 5% half, 50%
eigth, will be equivalent to 4.03%. Not a significant amount considering the
complexity it added. Note that this calculation does not include the
DDD/Frame Cnt byte added. Also, if we include the header and interleave
bytes, the percentage of saving is even smaller.

(2) Complexity

Both complexity of the protocol and complexity of implementation will
increase.

In additional, I would like to point out one more issue after reading
draft-espelien-avt-common-01.txt. The storage mode specified in that draft
(with 4-bit ToC) is a design that really hard to get to work. Writing a file
with all the ToC in the beginning of the file is not a natural design. One
have to hold all the data temporarily somewhere until the end of the whole
recording is reached. Extra work there are needed which will likely to
further complicate the format.

(3) Competibility

The 4-bit ToC will prohibit making a complete compatible format with RFC
2658 for PureVoice. And competibility is a very nice thing to have when we
set the standards.

Maybe we should stick mostly with the format we have now in the EVRC draft,
add SMV in text, make the small change to make it complete compatible with
PureVoice.

Adam

----------
Adam H. Li

---

From: Randall Gellens <[email-masked]>
Date: Tue, 16 Oct 2001 17:23:26 -0700

>further complicate the format.

The storage mode doesn't require that all the TOCs be written first, in 
fact, only 6 bits worth of TOCs can be written at one time.  The draft 
specifies a storage mode where frames are written in 'groups'; a group is 
almost identical to the 'normal' format used in RTP.  A group holds one or 
more frames.  So, the file could be written frame-by-frame, with only one 
TOC entry before each frame (along with the other group fields).

The goal of the format is to make it easy to receive packets via RTP and 
write them to a file, or vice versa.  It's absolutely not intended to 
require extra buffering or other work.

>2658 for PureVoice. And competibility is a very nice thing to have when we

Compatibility is very desirable, but so is extensibility.  At the time the 
draft was written it looked like there was a requirement that some handsets 
support PureVoice as well as EVRC, SMV, and other codecs.  It now appears 
that this may not be the case; PureVoice support may not be needed after 
all, in which case any common format would only need to support EVRC, SMV, 
and other (especially future) codecs.

---

From: Pete McCann <[email-masked]>
Date: Wed, 17 Oct 2001 07:57:47 -0500 (CDT)

Hi, Adam,

Sorry about the delayed reply.  A couple of points below...

 > (1) Bit Saving: 4-bit ToC vs 8-bit ToC - discussed before
...

You are right, there is not much bit savings.  

 > (2) Complexity
...

I'm not sure about your points here - it doesn't seem that the
complexity has increased too much, and I think Randy answered your
storage mode question.

 > (3) Competibility
...

I think if we can find a way to carry PureVoice in a converged
standard it would be worth it even if we didn't have complete
backwards compatibility.

 > add SMV in text, make the small change to make it complete compatible with

Well, if we want to carry SMV, I think we definitely need the 3-bit
DDD field due to the richer mode-selection capabilities of SMV.  This
would also be useful for EVRC, according to IS-127.  I suggested the
above format because it seemed to have an obvious way to squeeze in
this field in a way that wasn't too ugly and didn't waste too many
bits; however, I am open to other suggestions... I would like to find
a way to move forward on a converged format in the most expeditious
manner. 

-Pete

---

From: "Adam Li" <[email-masked]>
Date: Sun, 21 Oct 2001 22:48:21 -0700

Dear AVT folks,

Recently we have some discussions on the mailing list on the Internet Drafts
on EVRC, SMV and Common Vocoders. These are the three IDs proposing three
payload formats for the above codecs.

Through these discussion, it seems is clear that it would be beneficial to
have a same payload format for EVRC and SMV codec for the simplicity in
protocol and the benefit in implementation because of the great amount of
similarities between the codec frames. In the same time, it would also be
nice to make it possible for other future frame based vocoder (without
existing RFC) to use this format as a base payload format, as long as they
fit in certain criteria that is common to EVRC and SMV, as many vocoders
share same characteristics.

The authors of all the three drafts have agreed to join the drafts together
and make a combined draft.

The combined draft will primarily cover EVRC and SMV codec, and will be
extendable to any frame-based codecs that are similar to these two codecs.
More specifically, it may be used for codecs that
- are frame based;
- null and erasure frames are allowed;
- total number of rates is less than 17;
- maximum full rate frame can be transported in a single RTP packet.

The combined draft will primarily based on the current EVRC draft (v08), and
incorporate the other two drafts with as little changed as possible. Any
technical changes have to be justified to be beneficial to the EVRC/SMV
payload.

We will start working on the combined draft soon. Any comments and
suggestions are very welcome.

Adam

----------
Adam H. Li