[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] Comments on draft-ietf-avt-rtp-jpeg2000-05.txt

Hi,

I have reviewed the RTP payload format for JPEG-2000.

1. It seems that this draft has had the same fate as number of others, getting the form feed character stripped, and having empty lines being doubled.

2. Section 4.1: Timestamp:
"The same timestamp must appear in each fragment of a given frame."
I think the must is a normative one, thus it should be MUST. Including a "value" and clarifying that it concerns RTP packet would make the sentence more readable:
"The same timestamp value MUST appear in each RTP packet carrying a fragment of a given frame."

3. Section 4.2:
The X bit: I would change the name of this bit to R, as in Reserved. I would also clarify the receiver operations in regards to the value. One can either specify that receiver shall ignore it, thus allowing extension that do not change the packet format. For example using it to indicate some certain state, that one can make without, but is not required to have. Otherwise, one declare that it must be checked, and the payload discarded if not 0. That way one can deploy format changes, however these will be ignored by old receivers.

4. Section 4.2: The MHF values: Is really the two possibilities for MHF value 3 the same. I would think that the treatment of a packet is different depending on if it is fully contained or fragmented. Thus if no other reason exist, is it not better to split them and used value 1, for one of them.

5. Section 4.2: mh_id:
"The initial value of mh_id is random, except for 0." I would clarify this and use probably use normative values: For example:

"The initial value of mh_id is random, and may take any value between 1-7, but MUST NOT be 0."

6. Section 4.2: Fragment offset:
"This value must be set to the byte offset in the JPEG 2000 data stream contained in this RTP packet."

I don't think it is really clear from what the offset is calculated. Please specify this better, for example it should be explicit, that it is the data stream for a specific frame. Is it also clear what the data stream that one fragments is, i.e. include seperators, etc.

7. Section 5.2:
"In Intelligent mode, the JPEG 2000 code stream is packetized by
"packetization unit" we introduce newly."
At first I thought "newly" was a spelling correction error, however looking up in Webster:
Main Entry: new·ly
Pronunciation: 'nü-lE, 'nyü-
Function: adverb
1 : LATELY, RECENTLY <a newly married couple>
2 : ANEW, AFRESH

I assume that you are going for the meaning 2. It might be simpler to use "next" or "below".

8. Section 5.2:
"If a packetization unit with headers is larger than the MTU size, it may be fragmented." This should probably be a normative MAY.

9. Section 6.1:
   "In principle, the priority mapping table is
    negotiated between the sender and the receiver through external
    protocols (such as: RTSP, SIP, etc), which is not within the scope
    of this document."

I don't agree that it outside of the scope of this document. If it is at all going to be possible to negotiate this, you will need to define how it does relate to RTP payload format. This is an MIME parameter

10. Section 6.2:
"A sender can transmit each priority level packets using separate
    multiple RTP sessions."

You don't need both separate and multiple. However you might also consider what you are trying to express. You seem to lacking a clear indication of what should be sent on different sessions. I would formulate the sentence as:

"A sender may transmit RTP packets with different priority levels, in separate RTP sessions. For example in a multicast session, transmit the most important priority levels on one multicast address, and use others for lower priority levels."

11. Section 7.1:
"If the mh_id field is set to 0, the receiver MUST not save the
    main header and MUST NOT compensate for lost headers using the
    above method."

Move this to 7.2, the paragraph defines receiver behavior not sender.

12. Section 8.

   "RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specifications[3]."

Please change to this:

    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specifications[3] and any applicable profile.


13. Section 8. Second paragraph: The consideration should express if MJPEG-2000 has this property that one can create pathological data that significantly increases the computational complexity.


14. Section 9.1: MIME parameters
I think this format has a number of MIME parameters that should be defined:
- Intelligent mode: yes/no?
- Priority mapping tables?
- Image size or maximum?
- Used priority schemes

15. Section 10:
The IPR statement is not updated. Please see section 5 of RFC 3668.

16. Section 11.1: Is color space totally indicate internal to the MJPEG stream? Even if so, is it something that should be possible to negotiate in the signalling protocol? If so, include a MIME parameter for it.

17. Missing Offer/Answer section as section 9.3.

18. Section 13: Please include in reference [3] the indication that it is standard:
[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
"RTP: A Transport Protocol for Real Time Applications", STD 64, 

        RFC 3550, July 2003.


Mostly minor things, it seems to be the MIME and offer/answer section that are the major short comings.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


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