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

Hello all,

My comments are inlined.

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

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? 

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

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?

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

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.

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

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.

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

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. 

> 
> -- 
> Randall Gellens

Regards,
Jay

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt