[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Working group last call: JPEG-2000 payload format
Dear Ali,
Thank you fot the comment.
Please see inline
Boudani Ali wrote:
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 ).
I doubt the current description is not enough.
Colin said there was no need to change the 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.
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.
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.
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.
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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt