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

[Satoshi Futemma <satosi-f at sm.sony.co.jp>]

Dear Ali,

please see inline.

Boudani Ali wrote:
> 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 |        ....
> >                      +----+                    +----+

For example, let's suppose the receiver wants to decode only Tile 1.
He would pick up the packet whose "T" is 0 and "tile number" is 1.

Without "tile number" and if the packet containing Tile 2 Hdr is lost,
the receiver could not know whether the following packets belonging
to Tile 1 or Tile 2.
"fragment offset" shows only the ordering of the codestream, but
it doesn't indicate which tile the received packets belong to.

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

Yes.ã
priority = 255 and mh_id = 0 are specification of jpeg2000-15 draft.

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

Hmm... It's not bad idea, but I still think fixed payload length is
easy (less complex) to implemente it.

Best Regards,

Futemma

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