Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-17.txt

From: [email-masked]
Date: Fri, 07 Sep 2007 12:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-17.txt
	Pages		: 36
	Date		: 2007-9-7
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered in the design
   of this payload format.  JPEG 2000 is a truly scalable compression
   technology allowing applications to encode once and decode many
   different ways.  JPEG 2000 video stream is formed by extending from a
   single image to a series of JPEG 2000 images.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-17.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtp-jpeg2000-17.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-17.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Sep 2007 11:09:31 +0200

Hi,

there is an error in the application of rate in the example in section 8.2:

      m=video 49170/2 RTP/AVP 98 99
      a=rtpmap:98 jpeg2000/27000000
      a=rtpmap:99 jpeg2000/90000
      a=fmtp:98 rate=27000000;sampling=YCbCr-4:2:0;width=128;height=128
      a=fmtp:99 rate=90000;sampling=YCbCr-4:2:0;width=128;height=128

"rate=27000000" and "rate=90000" should not be in the a=fmtp line. RFC
4855 the common mapping to SDP rules in section 3 says the following:

      o  The general (possibly optional) parameters "rate" and
         "channels" also go in "a=rtpmap" as clock rate and encoding
         parameters, respectively.

I don't see any reason for having the value appear twice in the
declaration. The rate value in the rtpmap line is sufficent.

Thus the current text in section 8.2 of the draft should be changed:

   o  The REQUIRED parameters, "rate" and "sampling", MUST be included
      in the "a=fmtp" line of SDP.

I think simply remomve the "rate" and plural for "parameters" from this
line should fix it.

Then you need to fix all the examples in the draft and in the "BEAM" draft.

Best regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Satoshi Futemma <[email-masked]>
Date: Tue, 11 Sep 2007 13:36:19 +0900

Hi, Magnus,

Thank you for your detail comments.

I misunderstood SDP description of "rate" parameter.
I read RFC4855 again, and I've got what you pointed out.

Thank you and Best Regards,

Futemma

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 01:13:48 +0300

Dear RTP Experts,

Could anyone help to clarify the following: what is the RTP topology,
and what is the right term for end-point B?

The topology is as follows:

      +----+           +---+             +---+
       | A  |=====>| B | ----------->| C |
      +----+           +---+             +---+

- A sends a scalable bitstream of multiple layers using multiple RTP
sessions (layered multicast).
- B aggregates the input RTP streams from the multiple RTP sessions to
one RTP stream and sends to C. 

I failed to map the topology to any of those (or their combinations)
mentioned in draft-ietf-avt-topologies-06.txt , where all seem talking
about end points within one RTP session. Also I am wondering whether B
can be called a translator, mixer or (RTCP terminating) MCU? There are
multiple RTP sessions between A and B, and there seems to be only one
RTP sessions between B and C, therefore B terminates RTP sessions. If
this is true, then B can neither be called translator nor mixer,
according to the comment made by Colin earlier (on August 18 2007 in the
AVT reflector that "Neither an RTP translator or a RTP mixer terminate
the RTP session."). Or is it so that the one RTP stream from B to C are
still of multiple sessions (hence B does not terminate RTP sessions)?

BR, YK

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Sep 2007 11:51:20 +0200

> The topology is as follows:

Well, the RTP topologies document hasn't very much discussed the issue
of scalability modification of streams. In my view B is either a mixer
or a translator depending on how it does the aggregation. The fact that
it appears that it terminates some of the RTP sessions for the higher
layers I don't think really count in this case. There is correlation
between the RTP sessions carrying the layers that I think is maintained
over the translation. I do expect that CNAMEs etc are consistent over
all the layers. But it will be interesting to rewrite the RTCP reports
to correctly reflect that your packets from layer X which was sent to
the receiver in the aggregate has been delivered or lost.

I think this maybe needing more discussion in the SVC document. It is
after all proposing to do these things using what it call MANEs.

Cheers

Magnus Westerlund