Subject: RE: [AVT] Working group last call: JPEG-2000 payload format

From: "Boudani Ali" <[email-masked]>
Date: Tue, 15 May 2007 19:00:31 +0200

Hello,
I read the two drafts. Before going to the IESG, It will be better if
the authors clarify some issues.
Here are my comments:

1- How can we identify the packets belonging to the same Codestream
(frame) (especially when using multiple RTP sessions). Don't you think
that we need to add a frame_id identifier?.

2- In section 4.1 of Draft-ietf-avt-rtp-jpeg2000-15.txt: you consider 90
KHz for the Timestamp, this is not enough for professional video using
JPEG2K: isn't better to leave this to the implementers? 

3- Adding a payload header is an overhead, so smaller payload header
size is better. Now, why do we need "T" and "tile number" fields? You
said that many tiles may exist in the same packet, so in this case no
meaning of "tile number" and "T" fields?

4- Is the tp (type) field necessary?. The RTP payload has already the
payload type (PT) and we can use it instead of tp? If not this
information can be communicated out of band and can be optional as the
width and height in section 8.1!
 
5- Why do you use the fragment offset?. Isn't (for one RTP session) the
sequence number of the RTP packet enough? 
When using multiple RTP sessions for layered video, the parser that
extracted the data for a particular layer (for a particular RTP session)
may be transmitted out of band also (the index file is stored either as
a separate file or as meta-data). The index file is transmitted to the
receiver also, so the receiver can rebuild the codestream.

6- Do we really need to have an MHD flag? The size of main header may be
about 300 bytes so is there any chance that this packet will be
fragmented?

7- For the priority field use (the example in section 1.3.1): the
receiver can select which parts of the codestream to decode without
using the priority field. It can rebuild the codestream and extract the
parts to decode by reading the main header?. 

Cheers,
Ali 
-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: lundi 14 mai 2007 13:59
To: IETF AVT WG
Cc: Roni Even; Tom-PT Taylor
Subject: [AVT] Working group last call: JPEG-2000 payload format

This is to announce a working group last call on the RTP Payload  
Format for JPEG-2000:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-15.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000- 
beam-06.txt

Please send any final comments on these drafts to the <[email-masked]>  
mailing list by 28 May 2007. If no substantive comments are received  
by that time, we will ask the IESG to consider these drafts for  
publication as Proposed Standard RFCs.

Note that there is declared IPR on the "beam" draft:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=697

-- 
Colin Perkins
http://csperkins.org/

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

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 21 May 2007 18:12:59 +0100

Thanks - these are good questions, which should be addressed before  
the draft progresses. Authors?

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Satoshi Futemma <[email-masked]>
Date: Mon, 28 May 2007 16:36:59 +0900

Dear Ali,

Thank you for the comments.
Please see inline.

> that we need to add a frame_id identifier?.

RTP timestamp can be used for that purpose.

> JPEG2K: isn't better to leave this to the implementers? 

RTP timestamp is a presentation timestamp.
Same frame has same rtp timestamp and timestamp difference
between frames is constant. Therefore 90KHz timestamp is enough.

How many clock rate would you consider for RTP timestamp ?
If there is a strong incentive, I feel no reluctance to
select different clock using rtpmap.

> meaning of "tile number" and "T" fields?

As you pointed, "tile number" and "T" may not be necessary when
many tiles exists in the same packet, but if no tile header exists
in a packet, which may be more possible, "tile number" and "T"
is needed for receiver to clarify which tile the codestream
is belonging to.

> width and height in section 8.1!

We believe it is necessary because the receiver identify whether
the received codestream is odd or even field's.

"tp" can be used for determining the reciever's action.
For example, if it receives odd field continuously, it can interpolate
even field in some way, or simply discard the duplicated odd field.

> receiver also, so the receiver can rebuild the codestream.

When using multiple RTP session for layered video,	
JPEG2000 codestream may be split with interleaving.

For example,

Codestream
+----------+----+----+----+----------+----+----+----+----------+----
|Tile 0 Hdr| L0 | L1 | L2 |Tile 1 Hdr| L0 | L1 | L2 |Tile 2 Hdr| ...
+----------+----+----+----+----------+----+----+----+----------+----

RTP 1
+----------+----+         +----------+----+        +----------+----
|Tile 0 Hdr| L0 |         |Tile 1 Hdr| L0 |        |Tile 2 Hdr| L0
+----------+----+         +----------+----+        +----------+----

RTP 2           +----+                    +----+
                | L1 |                    | L1 |             ....
                +----+                    +----+

RTP 3                +----+                    +----+
                     | L2 |                    | L2 |        ....
                     +----+                    +----+
In that case,
interleaved codestream doesn't alwasy arrive at the receiver
in original order.
Fragment offset helps the receiver to rebuild the codestream.

Also, if the fragment offset exist, the receiver need less
memory because it doesn't need de-intgerleave buffer to
rebuilt codestream. It can use same memory space to rebulit it.

> about 300 bytes so is there any chance that this packet will be

Typical main header may be at most 300 bytes long, but if some JPEG2000
coding options are used, it may be longer.
So MHF flag is neccessary for such situation.

> parts to decode by reading the main header?. 

Main header contains the progression order information, but it doesn't
include the address information (start position) of each priority level.

Priority field helps the receiver to select the codestream to put into
decoder easily. Without priority field, the receives needs more memory
to rebuild it and has to parse the codestream.

Best Regards,

Futemma

---

From: Colin Perkins <[email-masked]>
Date: Tue, 29 May 2007 21:03:58 +0100

Dear Ali, Satoshi,

Thank you for your comments and response. My reading is that the  
issues raised are adequately addressed, and there is no need to  
change the draft. If this reading is incorrect, please respond by 1  
June 2007, otherwise we'll ask the IESG to consider this draft for  
publication.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 May 2007 13:57:28 +0200

> JPEG2K: isn't better to leave this to the implementers? 

Can you please clarify why it isn't enough with a 90 kHz clock even for 
professional video? When is their need for time jitter related to when a 
frame was sampled needs to be smaller than what a 90kHz clock provide. 
Especially considering that most of the frame rates used will have 
perfect match to a particular tick increment per frame. I don't think we 
have heard any such issues being raised in AVT before. If we do miss a 
critical motivation then this applies to all our video payload formats, 
not only one.

However unless there is strong motivation to change this I think staying 
with 90kHz is a good choice. I know of least two reasons, both having to 
do why you shouldn't leave this with the implementors.

1. First, if any timestamp rate can occur all receivers need to include 
code that support any values. This makes implementations more complex.

2. The timestamp rate may not be set to low, as this will reduce the 
utility of the RTCP receiver reports that uses the media codec timestamp 
rate in its measurement. This has occurred for example for MPEG-4 which 
allows flexible timestamp setting, when some senders used 30Hz as 
timestamp rate. For RTCP sakes the timestamp rate should at least be 1kHz.

Therefore I think staying with 90kHz as one and only rate is better. But 
please provide more motivation why pro-video will have issues with that.

Cheers

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