Subject: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: Storage format

From: [email-masked]
Date: Fri, 10 Sep 2004 12:36:29 -0700

Hi Magnus,

> > As I mentioned in my previous reply, the storage format 
> does not have any MIME parameter associated with it. 
> 
> Actually I think you are not correct. It makes a lot of sense to have 
> the following parameters also for the file format.
> 
> mode-set: So that you can indicate what is used in the file. 
> For example 
> by using mode-set=3 you can indicate interoperable mode.

Since the VMR-WB decoder does not need any mode information, therefore, the use of mode-set parameter does not give you any advantage. If you generate a storage file with any mode, even switch between permissible modes, why do you need to signal it to the decoder where it does not need that information?

For the interoperable mode, we are using a different magic number and file extension, so again the decoder does not need any additional information.

> channels: Indicate the actual number of channels present in the file

This parameter is included in the multi-channel file header. So, why do you need to signal it again?

> dtx: To indicate that DTX is used in this file
> 
> What do you say?

The storage format in VMR-WB always uses DTX concept (i.e., for silence frames nothing but a NO_DATA frame type is stored and at some points during silence periods, SID_UPDATE frames are saved. The VMR-WB simulation does not allow the use of "-dtx" and "-mime" command line options together since "-mime" command line option uses the DTX concept.

Therefore, this is a redundant parameter for the file storage.
 
> > I am not following the discussion on media types registration.
> > Considering that we have only MIME parameters associated with RTP
> > payload, could you please tell me how does this discussion 
> affect VMR-WB
> > I-D?
> 
> My conclusions of the discussion is that you will need to define one 
> MIME type for the RTP payload format, and another for the 
> file format as 
> they have different formats.
> 

Now, if there is no MIME parameter associated with the storage format, is there any change regarding the media types registration in the draft?

By the way, the media types registration rules that you referred to is still an individual draft and still under review and discussion, we cannot really follow any of the guidelines in this draft until they are finalized. Can we?

Regards

-Sassan Ahmadi   

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Sep 2004 10:06:54 +0200

Hi Sassan,

First, the reason to have the information (mode-set and channels) in the 
MIME type, and not only in the file header is so that a receiver prior 
to downloading the complete content can determine its formats. If you 
only have them in the magic numbers, then you will need get the first 
bytes of content. A strong argument in this reasoning is email systems. 
Many do allow you to fetch everything except attachments which then 
later can be fetched if desired. In such a system as I understand it, 
you will get the MIME type of the attachment together with the main 
body. That way one can refuse to download an attachment one can't handle.

As VMR-WB is going to be extended and there will be a new mode-set 
later. I would think it is very appropriate that one can actually 
perform the above operation before download content, as there is a clear 
risk that the content of the file may not be playable on the device that 
downloads it.

[email-masked] wrote:
> 
> Now, if there is no MIME parameter associated with the storage format,
> is there any change regarding the media types registration in the draft?

See above arguments why I think it is appropriate to have parameters 
also in file format case.

However independently of the above issue, you will need to assign 
different MIME names to the RTP payload format and the file format: For 
example you could name them:

audio/vmr-wb-pt  (RTP payload type)
audio/vmr-wb-ff  (File format)

> 
> By the way, the media types registration rules that you referred to is
> still an individual draft and still under review and discussion, we
> cannot really follow any of the guidelines in this draft until they are
> finalized. Can we?

Although this is an ongoing discussion, I think we should align where 
this is reasonable and we do agree. On the issue of defining two MIME 
types, one for the file format and one for the RTP payload format, I do 
clearly see the motivation for that statement.

I would also like to point out that the MIME types are going to expert 
MIME review and need to pass this. So not aligning it with clearly 
expressed views is going to make it harder. I am not saying to through 
your own reasoning overboard, however you better start a discussion with 
them if your view do not align on how things should be.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Sep 2004 10:13:23 +0200

Hi,

On 13 Sep 2004, at 10:06, Magnus Westerlund wrote:
> First, the reason to have the information (mode-set and channels) in 
> the MIME type, and not only in the file header is so that a receiver 
> prior to downloading the complete content can determine its formats. 
> If you only have them in the magic numbers, then you will need get the 
> first bytes of content. A strong argument in this reasoning is email 
> systems. Many do allow you to fetch everything except attachments 
> which then later can be fetched if desired. In such a system as I 
> understand it, you will get the MIME type of the attachment together 
> with the main body. That way one can refuse to download an attachment 
> one can't handle.
>
> perform the above operation before download content, as there is a 
> clear risk that the content of the file may not be playable on the 
> device that downloads it.

Agreed with this.

> different MIME names to the RTP payload format and the file format: 
> For example you could name them:
>

I'm not sure about this - these would seem to be the same format, so 
they should use the same media type.

> types, one for the file format and one for the RTP payload format, I 
> do clearly see the motivation for that statement.
>
> your own reasoning overboard, however you better start a discussion 
> with them if your view do not align on how things should be.

I have done so.

Collin