Re: [AVT] The storage format of EVRC/SMV vocoder (resent)

[Randall Gellens <[e-mail]>]

At 12:31 AM -0700 4/22/03, Adam Li wrote:

>  Below is the summary of the rationales for each of the choices:
>
>    draft-ieft-avt-evrc-smv-03.txt    |    draft-garudadri-qcp-00.txt
>  ------------------------------------+--------------------------------
>  (1) Mature specification, been      | (1) Brand new ID
>      developed for 2.5 years in AVT  |

I'm not sure it makes sense to call a specification "mature" based on 
the amount of time between inception and standardization.  That is, I 
believe "mature" refers to the amount of time multiple interoperating 
implementations have been deployed.

I also do not believe it is accurate to imply that the qcp format is 
not mature simply because the Internet Draft is new.  In reality, the 
specification has been available for some years now, and there are a 
number of implementations which do interoperate.

>  ------------------------------------+--------------------------------
>  (2) Covers both EVRC and SMV        | (2) Only cover EVRC

The qcp format covers QCELP 13K as well as EVRC.  An updated version 
covers SMV as well.

>  ------------------------------------+--------------------------------
>  (3) Referred to by 3GPP2(*) FFMS    | (3)
>      specifications                  |

My understanding is that the 3GPP2 FFMS specifications refer to both 
(it is waiting on RFC publications for both).

>  ------------------------------------+--------------------------------
>  (4) Implemented and used by many 3G | (4) Supported in Eudora
>      telecom operators (e.g., SKT,   |
>      KTF, LGT). The interoperability |
>      has been tested among them.     |

The qcp format is supported by PureVoice and QuickTime, both 
available on Windows and Macs.   Also, a large number of CDMA 
handsets deployed today create and play qcp files and use this to 
interoperate.  A number of services and tools on the web use the qcp 
format (often calling it PureVoice).

My information on the implementation of the evrc-smv draft's format 
is that Nextreaming uses this as an internal intermediate format 
prior to generating ".3g2" files (as specified in the 3GPP2 FFMS 
specification, which include both formats).  That is, my 
understanding is that this implementation is not used to exchange 
data.  If my understanding is not correct, please let me know.  Can 
you please provide more information on the telecom operators (e.g., 
SKT,  KTF, LGT) implementations that you refer to, and if these 
implementations are used to exchange data in the format specified in 
the evrc-smv draft?

>  ------------------------------------+--------------------------------
>  (5) Simple and efficient design,    | (5)
>      quick to implement              |

The text in the qcp draft is more confusing than it should be.  An 
updated version is about to be published which replaces the pseudo-C 
description with clear ABNF, showing that the two formats are 
actually very close.  In essence, the qcp format is the same as the 
evrc-smv format, except that some additional data is present at the 
start of the file.  But in both formats, individual vocoder frames 
are stored with a preceding byte which describes the frame size.

>  ------------------------------------+--------------------------------
>  (6) Registration already in IANA,   | (6)
>  ------------------------------------+--------------------------------
>  (7) Supported and developed by 7    | (7) Supported and developed by
>      companies and universities      |     Qualcomm
>      (including Qualcomm)            |

The qcp format is supported/implemented by QuickTime, PureVoice, and 
numerous handset vendors and operators, plus a number of web services.

>  ------------------------------------+--------------------------------
>  (8) No IP related to this format    | (8) IP situation unclear

There is no IP associated with the the qcp format.  (The draft 
includes an explicit statement that it is in full compliance with all 
provisions of Section 10 of RFC2026.)

>  ------------------------------------+--------------------------------
>
>  (*) ERVC and SMV are both vocoders developed and defined in the
>  international consortium 3GPP2 (http://www.3gpp2.org) for the next
>  generation wireless network cdma2000.
>
>  Thank you very much.
>
>  Adam
>
>  PS. This is a resent of the previous message, which did not seem to go
>  through maybe because of the long cc list. If you think anyone is missed
>  out, please let me know. Thanks.
>
>>  -----Original Message-----
>>  From: Adam Li [mailto:[e-mail]]
>>  Sent: Saturday, March 15, 2003 9:20 PM
>>  To: 'Ietf-Avt'
>>  Cc: '[e-mail]'; 'Scott Bradner'; 'Colin Perkins'; 'Allison
>>  Mankin'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; 'magnus.westerlund@era-
>>  t.ericsson.se'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]';
>>  '[e-mail]'; '[e-mail]'; '[e-mail]'
>>  Subject: Issues for the file format for EVRC/SMV vocoder
>>
>>  Hi folks,
>>
>>  The topic of the file format for EVRC/SMV vocoders hopefully will be
>>  discussed in this meeting at San Francisco. Below is a list of the
>>  issues that might be related to this topic. They are listed here as
>>  potential issues for you to consider before the discussion at the
>>  meeting.
>>
>>  (1) Technically differences. Is there much difference in efficiency
>>  and performance between the format in draft-ietf-avt-evrc-smv and
>>  draft-garudadri-qcp? Are the differences simply on the file syntax?
>>
>>  (2) Completeness. For EVRC codec data, formats defined in both
>>  document can handle it. For SMV codec data, the format defined in
>>  draft-ietf-avt-evrc-smv is currently the only file format that
>>  handles SMV data. draft-garudadri-qcp does not handle SMV at this
>>  time.
>>
>>  (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has
>>  its first version submitted to AVT on November 2000. It has been
>>  actively worked on all these years, and is co-authored by people
>>  from seven companies and universities. It is currently on the RFC
>>  editor's queue. draft-garudadri-qcp is submitted in February 2003.
>>  Will there be concerns about the maturity of the drafts,
>>  particularly the handling of SMV codec hasn't been written in the
>>  later draft yet?
>>
>>  (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2
>>  for their CDMA networks, formats recognized by them are likely to be
>>  the most widely used format for those codecs. Which of the formats,
>>  as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has
>>  been considered by 3GPP2 for the format for storing EVRC and SMV
>>  data?
>>
>>  (5) Document organization. Even though this is a rather minor point,
>>  but would there be enough reasons to trade-off for the additional
>>  complexity for having the MIME registration of EVRC/SMV refering to
>>  a separate and yet to be complete draft?
>>
>>  Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If
>>  we want to consider deleting the file format that is in the draft
>>  for almost two years in the last minute before it becomes an RFC and
>>  using another yet to be complete new draft instead, we should be
>>  providing ourselves with the clear justification for doing so.
>>
>>  I will not be there for the discussion unfortunately since I have
>>  not made the plan to attend in advance. However, I hope the list of
>>  potential issues above might be useful for us to discuss and
>>  consider.
>>
>>  Wish we have a fruitful meeting in San Francisco.
>>
>>  Adam
>
>
>  _______________________________________________
>  Audio/Video Transport Working Group
>  [e-mail]
>  https://www1.ietf.org/mailman/listinfo/avt


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