Subject: RE: [AVT] File format for EVRC/SMV vocoder

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 11 Mar 2003 13:52:36 +0100

> >  If we are to standardize a file format in this body, I can not see
> >  why we should not stick to the format that is already finalized and
> >  has been taken through our standards process.
> 
> Given that there are a number of deployed implementations which have 
> been using the qcp format to exchange qcelp-13k and evrc, what is the 
> advantage of having the audio/evrc media type specify a different 
> format?

OK, but why has not this issue been brought up earlier? The EVRC/SMV
format work in AVT has been going on for a long time, and therefore one
can question whether it is correct (from a procedural point of view) to
suddenly not use what has been developed in this WG, but use something
defined elsewhere. IETF standardization is usually an engineering
process, not rubber-stamping of already deployed technical solutions.

Note that I am not aware of all the details in this matter, but what
has been communicated on the list does not provide enough material for
motivating what has been proposed. "We have already deployed this 
alternative format while you were trying to agree on a standard, and
now we think you should use our format instead since it is more
widely deployed" is a rather strange way of arguing in standards
development, I think.

Once again, note that I am not addressing the technical aspects, and
the above analysis is of course a little bit extreme. However, I hope
it clarified my point. Personally, I have no strong opinions in favor
of either of the proposals, my concern is more about encouraging active
participation in our standards work, instead of encouraging people to
work in parallel with our standards efforts. It is a process concern.

Cheers,
/L-E
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Adam Li" <[email-masked]>
Date: Sat, 15 Mar 2003 21:18:05 -0800

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

---

From: Randall Gellens <[email-masked]>
Date: Sun, 16 Mar 2003 10:42:07 -0800

At 9:18 PM -0800 3/15/03, Adam Li wrote:

>  discussed in this meeting at San Francisco.

We may be able to resolve this before the meeting, in email.  If not, 
then I think it may be discussed at the AVT meeting.

>  Technically differences.

While the formats do have some differences, the main difference is 
that the qcp format is currently used on different hardware and 
software to interoperably store codec frames.  It doesn't appear to 
me that there is any difference in efficiency.

>  For EVRC codec data, formats defined in both document

SMV is being added to the qcp format; it's just a trivial matter of 
adding a new identifier.

>   Maturity of the format definition.

The format defined in draft-ietf-avt-evrc-smv was specified primarily 
for completeness of the document.  At the time we were working on 
this draft, I and the other authors were unaware of the qcp file 
format.  (I'm very sorry for this.)  It turns out that the qcp format 
has been widely used on multiple platforms for some time, including 
Eudora email and Quicktime media player (both on both Mac and 
Windows), and millions of CDMA handsets  I'm not aware of any current 
interoperable independent implementations of the format specified in 
draft-ietf-avt-evrc-smv.

>  Which of the formats, as

The issue of which format to specify in 3GPP2 is currently being 
discussed.  Most of the discussions to date have been on how to 
include evrc, smv, and qcelp-13k in an iso-based mp4 file format. 
The issue of specifying an independent file format for vocoders in 
3GPP2 is new.

>  yet to be complete draft?

This is very minor.  However, if the qcp format were something new, 
and not currently deployed, I'd be the first to say that we should 
stick with the format in draft-ietf-avt-evrc-smv.  It's only because 
of the existing interoperable use of the qcp format that I agree with 
making it the file format for the registrations.

>  ourselves with the clear justification for doing so.

I completely agree with you.  I have zero desire to delay 
draft-ietf-avt-evrc-smv.  In fact, my initial suggestion, as written 
in the qcp draft, was to take the easier path of not changing 
draft-ietf-avt-evrc-smv at all, and instead to have the qcp draft 
register a new MIME type (audio/qcp) which can be used to store evrc, 
qcelp (and SMV).  I knew this was a kludge (since the qcp format is 
already in use) but wanted to do what was quickest and easiest.

However, I was clearly told that this was not acceptable -- that we 
should do what is technically correct: allow draft-ietf-avt-evrc-smv 
to progress but without the file format, and change the qcp draft to 
modify the MIME registrations.  I agree that this is the correct way 
to proceed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is so much to be said in favor of modern journalism.
By giving us the opinions of the uneducated, it keeps us in touch
with the ignorance of the community.                --Oscar Wilde
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Jae-Yong Lee" <[email-masked]>
Date: Mon, 17 Mar 2003 10:14:58 +0900

Hello all,

My comments are inlined.

> me that there is any difference in efficiency.

The difference that I see is that the storage format described in 
draft-ietf-avt-evrc-smv is simple, straightforward and easy to generate 
from the RTP payloads and vice versa while draft-garudadri-qcp is rather 
a much more complicated scheme. This would become one of the most 
important factor if we take mobile devices into account.
What would be the technical advantage of draft-garudadri-qcp for storage
of EVRC over the current draft-ietf-avt-evrc-smv? 

> SMV is being added to the qcp format; it's just a trivial matter of 

Would it be necessary if we have draft-ietf-avt-evrc-smv?
Would it not be possible to extend RFC 2658 to include its storage format
and make it similar to draft-ietf-avt-evrc-smv?

> interoperable independent implementations of the format specified in 

To the best of my knowledge, Quicktime does not support .qcp file format
although it does support QCELP codec in QT file format.
I have some comments below (under the next point) regarding interoperable 
independent implementations of the format in draft-ietf-avt-evrc-smv.

> The issue of specifying an independent file format for vocoders in 

The 3GPP2's goal with multimedia file format is to have a single common 
file format for various applications as stated in its Stage-1 (requirements) 
document. People in 3GPP2 have agreed to have it based on the ISO base 
media file format which was already adopted for many other international 
standards, e.g., 3GPP, MPEG, JPEG.
Also the FFMS (file format for multimedia services) baseline text is refering
to draft-ietf-avt-evrc-smv for storing EVRC and SMV data in the media track.
Many (defintely more than two) handset vendors and solution providers
have already implemented this and tested interoperability and operators are
preparing services based on that.
If wanted, the media data would be easily taken and converted into the format 
specified in draft-ietf-avt-evrc-smv simply by adding the magic numbers.
I believe this sort of simple conversion would be really useful if speech-only
formats are also considered for some applications or services.

> modify the MIME registrations.  I agree that this is the correct way 

I'm not sure what is the technically correct way.
What is the technical benefit of draft-garudadri-qcp?

Above all, it would be very much undesirable to make a significant 
change at the very last minute without sufficient justification. 

Regards,
Jay