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

From: "Boudani Ali" <[email-masked]>
Date: Wed, 30 May 2007 09:56:21 +0200

Satoshi,

1- As Colin suggested in a previous mail can you put "SHOULD use a 90kHz
timestamp" to make it a strong recommendation, but allow the option of
using a different value if necessary. You have it in section 4.1 and
section 8.2 (in JPEG2000-15 draft ).

2- OK, I can agree with the offset field but for T and tile number I am
not convinced. If I am using the offset I can not see the utility of
using these T and tile number. 
I will take the same example you gave me:
> 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 |        ....
>                      +----+                    +----+

For the 3 packets, it is obvious that "T" and "tile number" are useless
:-) since I have data from different tiles.

If (in most cases) they are not useful, so why should I put them in my
JPEG2K packet header.

3- I can understand that priority and mh_id are useful for people who
wants to implement the "beam draft", but if someone not willing to use
them (as in the first draft jpeg2000-15) why should they exist in my
packet? Isn't possible to say that these fields are optional (not only
using 255 for priority 0 for the mh_id) but to not use them at all ?. It
is some kind of overhead to have (11 bits for priority and mh_id) + (8
bits reserved) + if I am not using the T and tile number (17 bits) = 36
bits that I am not using at all in my processing.

Cheers,
Ali
 
-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: mardi 29 mai 2007 22:04
To: Boudani Ali; Satoshi Futemma
Cc: Andrew Leung; ITAKURA Eisaburo; IETF AVT WG
Subject: Re: [AVT] Working group last call: JPEG-2000 payload format

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

On 28 May 2007, at 08:36, Satoshi Futemma wrote:
> Dear Ali,
>
> Thank you for the comments.
> Please see inline.
>
> Boudani Ali wrote:
>> 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?.
>
> RTP timestamp can be used for that purpose.
>
>> 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?
>
> 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.
>
>> 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?
>
> 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.

>
>> 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!
>
> 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.
>
>> 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.
>
> 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.
>
>> 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?
>
> 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.
>
>> 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?.
>
> 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
>
>
>> 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

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

---

From: Satoshi Futemma <[email-masked]>
Date: Wed, 30 May 2007 19:41:06 +0900

Dear Ali,

Thank you fot the comment.
Please see inline

> section 8.2 (in JPEG2000-15 draft ).

I doubt the current description is not enough.
Colin said there was no need to change the draft.

> If (in most cases) they are not useful, so why should I put them in my

The purpose of tile number field is different from that of
fragment offset.

Tile number field can be used to select an arbitrary tile to decode
easily, which means the receiver can choose some rectangle area of
picture to decode.
Random access of the picture is one feature of JPEG 2000.

> bits that I am not using at all in my processing.

Two drafts use same media type, so we should use same payload format.

As another approach, it would be considered to use an extension payload
header for "beam draft", but it makes header generation processing
more complex.

"beam draft" compliant sender has to support both kinds of payload 
header, so fixed length payload header would be favorable,
for example, when payload header is generated by hardware logic.

Also, authors suppose the overhead is not so high because
most RTP packets would be at least 1 KB long.

Best Regards,

Satoshi