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

["Boudani Ali" <Ali.Boudani at thomson.net>]

Dear Satoshi,
Please see inline.

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

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

I agree. 

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

I know well this feature. But tell me how in your example (which is a
common case) you can use this feature by using "T" and "tile number?
Here again your 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 |        ....
>                      +----+                    +----+

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

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

Yes, but in one draft, fields are mandatory (beam) and in the second one
they are optional (jpeg2000-15). Can this be clarified like this?
The (jpeg2000-15) should be more general than (beam) and not the
inverse. I have the feeling that priority = 255 and mh_id = 0 (which is
the case in the jpeg2000-15 draft) is a special case of the (beam draft)
and so we are always following (beam) even if priority = 255 and mh_id =
0. Am I right?
A better way to do it (from my point of view) is to put all these fields
in an optional payload header (I am not talking about an extension
header). A "bit" can be used to indicate if the option is to be used or
not.

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

For RTP packets of 1470 bytes, (36 bits *100 / 1470*8 bits) = 0.3 % 
So if I have a 270 Mbit/s stream, I am using then 0.81 Mbit/s for
possibly unused data. Ok, maybe overhead is not a big problem but It is
better if we don't have it. 

Best Regards,

Ali

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt