[AVT] Re: Comments on draft-singer-mpeg4-ip-03.txt

["Lim, Young-Kwon" <[e-mail]>]

Dear all,

As you might already notice new draft does not contain substantial changes
because I'm waiting the approval from the MPEG group to change the document.
It could be done during the meeting starting tomorrow. Then, I'll go to the
IETF meeting next week to finalize the discussion with IETF AVT

I want to discuss the open issues both on-line and off-line in parrallel
since many of interesting people are not here. Here are the draft
disposition about the comments from Colin;

> > - The restriction in characteristic 2.3 (ISO/IEC 14496 timescale MUST be
used
> >   as the RTP timescale) is not present in
draft-ietf-avt-mpeg4-multisl-03.txt
> >   I assume it is implicit, but this should be made explicit.

This is a mismatch between generic payload format and framework. And generic
payload format should be revised accordingly. Phillipe?

> >
> > - Characteristic 2.4 (MUST implement a default scheme) is meaningless
unless
> >   the default is defined.

This is a mismatch between ISO document and I-D. Default scheme is multiSL
draft. Here are the sentence from the ISO document. " To achieve a base
level of interoperability, and to ensure that any ISO/IEC 14496 stream may
be carried, all receivers should implement a generic payload format defined
in “draft-ietf-avt-mpeg4-multisl-00.txt” as default RTP payload mapping
scheme. Any new payload format should be a configurable subset of the
generic payload format."

> >
> > - Characteristic 2.6: where is the mapping for RFC 3016 defined?

We asked the authors of RFC3016 to prepare the document about the mapping.
The issue at that time was not technical but procedural. As you remember
authors of RFC3016 don't want to delay of getting the RFC number because
strict schedule of using it for ITU-T standards. Do you think we can add a
section about the mapping in RFC3016 now?

> >
> > - Characteristic 2.6 is repeated, the numbering needs to be corrected.

Editorial mistake.

> >
> > - Characteristics 2.7 - 2.9 are inconistent with the FlexMux format in
> >   draft-curet-avt-rtp-mpeg4-flexmux-02.txt. Which is correct?

I think framework is correct. We will discuss this issue during this
meeting.

> >
> > - I'm concerned about the use of the "a=mpeg4-iod:" attribute at the SDP
> >   session level, given that it is not mentioned in the payload format
> >   drafts. This restricts a session description to describing a single
> >   MPEG-4 session, and it is not clear how sessions that do not use
MPEG-4
> >   Systems will interact with this. Similar with a=mpeg4-iod-xmt

This topic was discussed on the reflector. No technical changes are
required. More detailed explanation about the scenario for the case of
mixing MPEG-4 presentation and non-MPEG-4 streams would be helpful. Do you
agree Colin?

> >
> > - Are there any encoding considerations for URLs in SDP? Presumably the
> >   URL encoding needs to be performed, which is more than just enclosing
> >   the URL in double quotes?

We don't want to specify any specific encoding method here. But we have a
example. Quotes from FDIS, "The location should be a URL enclosed in
double-quotes, which will supply the IOD (e.g. small ones may be encoded
using "data:", otherwise "http:" or other suitable file-access URL)." Is
this sufficient?

> >
> > - Characteristic 3.2 informally defines a number of MIME types (mpeg4-sl
> >   and mpeg4-flexmux) which should be defined by reference to their
specs.

If you are concerned about the names in the example, we can simple remove
it.

> >
> > - Characteristic 3.4 would be better included as part of the payload
> >   format, as an a=fmtp parameter.

We are specifying basic rules as a guideline for payload format design.

> >
> > - Characteristic 4.1 contradicts the multi-sl draft, which also defines
> >   "application" as a valid top level MIME type for MPEG4

This topic was discussed and resolved. "application" could be top level MIME
type for MPEG-4 streams except audio visual elementary streams. Both of
draft will be updated accordingly.

> >
> > - Characteristic 4.4 contradicts RFC 3016, which uses video/mp4v-es. It
> >   may be better to use mp4... as the prefix for all the MIME types, not
> >   mpeg4..., to be consistent with RFC 3016 and the file formats (e.g. in
> >   4.5 - 4.7).

We prefer to use mpeg4 rather than mp4. mp4 should be used only for file
format.

> >
> > - In 4.8, the mpeg4-flexmux type is registered. This should either be
done
> >   as part of the FlexMux payload format, or the registration should be
> >   explicit that this is for the file format, and an alternative format
> >   will be used for streaming with RTP.

This comment is little bit confusing to me. Can you answer this, Dave?

> >
> > - You need an IANA considerations section, if this is to be published as
> >   an RFC.

No disagreement.

> >
> > - References need updating. If this is to be published as an RFC, there
> >   may be normative dependence on the payload formats..

Absolutely.

Looking forward to receiving comments.

Sincerely,
Young.



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