New I-D uploaded: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-j2k-scl/06/
On Wed, Apr 30, 2025 at 7:39 AM Reese Enghardt <[email protected]> wrote: > > Hi all, > > Thanks for addressing the comments. > > I approved the three PRs, adding a nit to one. > > Best, > Reese > > > > On 4/29/25 18:54, Stephan Wenger wrote: > > Hi Pierre, > > Regarding the media-tupes registration and IANA considerations section: you > > indeed followed established practice and the guidelines of RFC8088 as > > updated. My recommendation is to keep the section organization “as is”. > > Stephan > > Sent from my iPhone > > > >> On Apr 29, 2025, at 13:26, Pierre-Anthony Lemieux <[email protected]> > >> wrote: > >> > >> Hi, > >> > >> Thanks for the detailed review. > >> > >> I have entered the issues at: > >> > >> https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/issues > >> > >> ... and addressed them at: > >> > >> https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/pulls > >> > >> I am not sure that action is required for issues #19 [1] given > >> existing practice, but do not object to moving the registration > >> information if needed. > >> > >> [1] > >> https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/issues/19 > >> > >> Please let me know if the proposed resolutions work. > >> > >> Best, > >> > >> -- Pierre > >> > >>> On Fri, Apr 25, 2025 at 2:07 PM Reese Enghardt via Datatracker > >>> <[email protected]> wrote: > >>> > >>> Document: draft-ietf-avtcore-rtp-j2k-scl > >>> Title: RTP Payload Format for sub-codestream latency JPEG 2000 streaming > >>> Reviewer: Reese Enghardt > >>> Review result: Ready with Nits > >>> > >>> I am the assigned Gen-ART reviewer for this draft. The General Area > >>> Review Team (Gen-ART) reviews all IETF documents being processed > >>> by the IESG for the IETF Chair. Please treat these comments just > >>> like any other last call comments. > >>> > >>> For more information, please see the FAQ at > >>> > >>> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > >>> > >>> Document: draft-ietf-avtcore-rtp-j2k-scl-05 > >>> Reviewer: Reese Enghardt > >>> Review Date: 2025-04-25 > >>> IETF LC End Date: 2025-04-28 > >>> IESG Telechat date: Not scheduled for a telechat > >>> > >>> Summary: The document is clear and concise, and it is ready for > >>> publication as > >>> Proposed Standard. Below are a few suggestions to make the document > >>> easier to > >>> understand and potentially more consistent. > >>> > >>> Major issues: None. > >>> > >>> Minor issues: > >>> > >>> Intro: > >>> "the payload format includes the following features specifically designed > >>> for > >>> streaming applications" Does "streaming applications" mean specifically > >>> Live > >>> streaming? If so, please consider being more specific here. In addition, > >>> please > >>> consider adding a bit more context on why these features such as > >>> sub-codestream > >>> latency are necessary and useful for use cases beyond prior RFCs. > >>> Similarly, > >>> what is preferable about JPEG2000 for the intended use cases, rather than > >>> using > >>> other options? Please consider adding a sentence or two. > >>> > >>> Section 3: > >>> "JPEG 2000 represents an image as one or more components, e.g., R, G and > >>> B, > >>> each uniformly sampled on a common rectangular reference grid." Please > >>> consider > >>> providing a definition for component. Assuming that, for example, "R" > >>> means > >>> only the red compontent of an image, does the above sentence imply that an > >>> image could be only one component, e.g., only R, on a grid? > >>> > >>> "The coded image data ultimately consists of code-blocks, each containing > >>> coded > >>> samples belonging to a rectangular (spatial) region within one resolution > >>> level > >>> of one component." Please consider providing a definition for resolution > >>> level. > >>> > >>> "Resolution Layer (R) > >>> The information needed to reconstruct the lower spatial resolutions of the > >>> image come before the information needed to reconstruct the higher spatial > >>> resolutions of the image" Is a resolution layer the same as a resolution > >>> level? If so, please consider unifying the terminology here. > >>> > >>> Section 5: > >>> This section references a "SOD marker", while Section 3 mentiones a "SOT > >>> marker". Is this intentional, and if so, what is the difference between > >>> SOD and > >>> SOT markers? The "SOT marker" also appears in Section 5.3, whereas the > >>> "SOD > >>> marker" only appears in section 5.1. > >>> > >>> "When concatenated, the sequence of JPEG 2000 codestream fragments > >>> emitted by > >>> the sender MUST be a sequence of JPEG 2000 codestreams where two > >>> successive > >>> JPEG 2000 codestreams MAY be separated by one or more arbitrary padding > >>> bytes > >>> (see Figure 1)." In the "Packets" in Figure 1, is each component > >>> delineated as > >>> "Main" or "Body" a single packet, or is it a sequence of packets? Does > >>> packet > >>> still mean RTP packet here? Please consider stating this explicitly when > >>> describing the figure. > >>> > >>> "A JPEG 2000 codestream fragment does not necessarily contain complete > >>> JPEG > >>> 2000 packets, as defined in [jpeg2000-1]." Is a JPEG 2000 packet > >>> different from > >>> an RTP packet? If so, how? Please consider defining a JPEG 2000 packet. > >>> > >>> Section 9: > >>> Is it intentional to provide the registry information in this section, > >>> rather > >>> than under "IANA Considerations" where many IETF readers would expect it? > >>> Please consider moving it under "IANA Considerations". > >>> > >>> Nits/editorial comments: None. > >>> > >>> _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
