Subject: [AVT] WGLC on draft-ietf-avt-rfc3016bis

From: Roni Even <[email-masked]>
Date: Tue, 23 Nov 2010 16:00:15 +0200

Hi,

I would like to start a working group last call on
http://tools.ietf.org/html/draft-ietf-avt-rfc3016bis-01 

RTP Payload Format for MPEG-4 Audio/Visual Streams

The WGLC will end on December 13th , 2010

Please review the draft and send comments to the list

Note that section 1.3 and 1.4 discuss the changes from RFC3016

Roni Even

AVT co-chair

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 23 Nov 2010 14:13:01 -0800

I did not check the parameters or their values for accuracy but I have some comments on the payload format specification.

- Last sentence in section 1: I think it should " error resiliency tools". Also in section 1.1 (and elsewhere), it should be " error resiliency functionalities".
- Title of section 1.1 (and elsewhere). Please capitalize the first letter in each word
- Spell out "VOP" in first use
- There are 2119 keywords in 1.2 which used before referring to 2119 later in the doc. IESG usually does not like this.
- End of section 1.2 (and in some other places, too), references are duplicated (5109 and 2198)
- Section 3, first para. says "If needed for an H.323 terminal, H.245 codepoint  "decoderConfigurationInformation" MUST be used for this purpose". A MUST in a conditional like this (if needed) does not seem very right. Maybe reword this?
- Section 4.2, firs para. why do we have a SHOULD requirement for choosing different PT values for scalable audio streams? And why does RFC 5583 have a SHOULD relation here? Is there any other way in SDP to signal dependency?
- Section 5.1. Should not "rate" be a required parameter?
- I think there is no need for section 6.2.
- Section 7: for this section, there is more text provided from a boilerplate for the payload format drafts. You might wanna copy/paste that text into here. Just check a recent payload format RFC.

HTH,
-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Tuesday, November 23, 2010 9:00 AM
> To: [email-masked]
> Cc: 'DRAGE, Keith (Keith)'; [email-masked]
> Subject: [AVT] WGLC on draft-ietf-avt-rfc3016bis
> 
> Hi,
> 
> I would like to start a working group last call on http://tools.ietf.org/html/draft-ietf-avt-rfc3016bis-01
> 
> 
> 
> AVT co- ass=MsoNormal>

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Nov 2010 11:20:27 +0800

Hi, all:
I spot a tiny bug in the example (b) in the section 3.3 of draft-ietf-avt-rfc3016bis.
Here is how example (b) is described:
"
   (b) is another example of the RTP packet containing the configuration
   information.  It differs from example (a) in that the RTP packet also
   contains a video packet in the VOP following the configuration
   information.  Since the length of the configuration information is
   relatively short (typically scores of bytes) and an RTP packet
   containing only the configuration information may thus increase the
   overhead, the configuration information and the immediately following
   GOV and/or (a part of) VOP can be packetized into a single RTP packet
   as in this example.

"
Comparing with original RFC3016, In the new figure 2 of draft-ietf-avt-rfc3016bis, one VOP header is newly inserted following VOL header and preceeding Video packet 
in the drawing (b).
Therefore it seems that the drawing (b) of figure 2 still not consistent with what is described above in the example (b) of section 3.3.

Firstly the difference between drawing (a) and drawing (b) in the figure 2 of draft-ietf-avt-rfc3016bis is
both "VOP header" and "Video Packet" are appended at the end of RTP packet in the drawing (b).

Secondly GOV described in the example (b) of section 3.3 is not appeared in the drawing (b) of figure 2.

What am I missing?

Besides this bug in the example (b), I am a little confused with the new text in the section 4.1 of draft-ietf-avt-rfc3016bis as follows:
"
Section 4.1 RTP Packet Format
   o  In the out-of-band configuration case the number of PayloadMux
      elements contained in each audioMuxElement can only be set once.
      If values greater than one PayloadMux Element are used, special
      care is required to ensure that the last RTP packet remains
      decodable.

"
What do you means  *values* greater than one PayloadMux Element in the above sentence? 
Are you saying
"
If more than one PayloadMux Element are used, special
  care is required to ensure that the last RTP packet remains
  decodable.
"
?

Regards!
-Qin
  ----- Original Message ----- 
  From: Roni Even 
  To: [email-masked] 
  Cc: 'DRAGE, Keith (Keith)' ; [email-masked] 
  Sent: Tuesday, November 23, 2010 10:00 PM
  Subject: [AVT] WGLC on draft-ietf-avt-rfc3016bis

  Hi,

  Roni Even

  AVT co- ass=MsoNormal> 

------------------------------------------------------------------------------

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

---

From: Roni Even <[email-masked]>
Date: Tue, 30 Nov 2010 01:48:31 +0200

Hi

I reviewed the document and have some comments.

1.       The last sentence in the abstract about comments can be deleted. 

2.       The last sentence in section 1.3, Do you recommend using ES
instead, so why  are you updating this draft at all and not making it
historic, is it just for 3GPP? How to decide if to use this payload or 3640.
Maybe say preferred and not recommended and leave it open to the
implementer.

3.       In section 3 " If needed for an H.323 terminal, H.245 codepoint
"decoderConfigurationInformation" MUST be used for this purpose ". I saw
Ali's comment and I think it will be best to just delete this sentence since
you are not defining mandatory text for H.323.

4.       In section 4.1 the two bullets are not clear. Maybe you can
rephrase these two bullets. (Qin Wu had a similar comment)

5.       In section 5.1 in the interoperability consideration you have "This
parameter mutually to the same value." Does this mean that symmetric mode
must be used.

6.       In section 5.3 in the object parameter - what do you mean by coder
is it the encoder or decoder or both.

7.       In section 5.3 if cpresent is 0 does this requires a config
parameter to follow this parameter.

8.       In section 5.3 if cpresent is 1 is it allowed to have a config
parameter and if yes how to merge the in band and out of band config
parameter.

9.       Section 6 about IANA consideration just need to provide the
directives for IANA. In this case since this document obseletes RFC 3016 the
section should say " This document updates the media subtypes "MP4A-LATM"
and "MP4V-ES" from RFC 3016. The new registration are in sections  5.1 and
5.3 of this memo." There is no need for 6.1 and 6.2

Roni Even

As individual

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Tuesday, November 23, 2010 4:00 PM
To: [email-masked]
Cc: 'DRAGE, Keith (Keith)'; [email-masked]
Subject: [AVT] WGLC on draft-ietf-avt-rfc3016bis

Hi,

Roni Even

AVT co- ass=MsoNormal>

  _____