[AVT] Re: Issues for the file format for EVRC/SMV vocoder

[Randall Gellens <[e-mail]>]

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

>  The topic of the file format for EVRC/SMV vocoders hopefully will be
>  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
>  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.

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
>  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?

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.

>  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?

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.

>  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 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt