Internet-Draft | Sub-codestream latency J2K over RTP | October 2024 |
Lemieux & Taubman | Expires 11 April 2025 | [Page] |
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given codestream can be emitted before the entire codestream is available.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This RTP payload format specifies the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams.¶
In addition to supporting a variety of frame scanning techniques (progressive, interlaced and progressive segmented frame) and image characteristics, the payload format includes the following features specifically designed for streaming applications:¶
ORDH
, ORDB
, POS
and PID
) that
indicates whether the RTP packet contains a resynchronization (resync)
point and how a recipient can restart codestream processing from that
resync point. This contrasts with [RFC5371], which also
specifies an RTP payload format for JPEG 2000, but relies on codestream
structures that cannot be emitted until the entire codestream is
available.¶
ESEQ
) to the standard 16-bit RTP sequence number,
enabling the payload format to accommodate high data rates without
ambiguity. This is necessary as the standard sequence number will roll
over very quickly for high data rates likely to be encountered in this
application. For example, the standard sequence number will roll over in
0.5 seconds with a 1-Gbps video stream with RTP Packet sizes of at least
1000 octets, which can be a problem for detecting loss and out-of-order
packets particularly in instances where the round-trip time is greater
than the roll over period (0.5 seconds in this example).¶
PTSTAMP
) relative to the first RTP Packet with the same value
of RTP timestamp
field (Section 5.2). The
higher resolution of PTSTAMP
compared to the timestamp
allows receivers to recover the sender's clock more rapidly.¶
Finally, the payload format also makes use of the unique scalability
features of JPEG 2000 to allow a network agent or recipient to discard
resolutions and/or quality layers merely by inspecting payload headers
(QUAL
and RES
fields), without having to parse the
underlying codestream.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following summarizes the structure of the JPEG 2000 codestream, which is specified in detail at [jpeg2000-1].¶
NOTE: as described at Section 6, a JPEG 2000 codestream allows capabilities defined in any part of the JPEG 2000 family of standards, including those specified in [jpeg2000-2] and [jpeg2000-15].¶
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. An image can be further divided into contiguous rectangular tiles that are each independently coded and decoded.¶
JPEG 2000 codes each image as a standalone codestream. Each codestream consists of (i) marker segments, which contain coding parameters and metadata, and (ii) coded data.¶
The codestream starts with an SOC marker segment and ends with an EOC marker segment. The main header of the codestream consists of marker segments between the SOC and first SOT marker segment and contains information that applies to the codestream in its entirety. It is generally impossible to decode a codestream without its main header.¶
The rest of the codestream consists of additional marker segments (tile-part headers) interleaved with coded image data.¶
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. Code-blocks are further collected into precincts, which, accordingly, represents code-blocks belonging to a spatial region within one resolution level of one component.¶
The image coded data can be arranged into several progression orders, which dictates which aspect of the image appears first in the codestream (in terms of byte offset). The progression orders are parameterized according to:¶
For example, in the PRCL progression order, the information needed to reconstruct the first lines of the image come before that needed to reconstruct the last lines of the image and, within a collection of lines, the information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions. This progression order is particular useful for sub-frame latency operations.¶
This RTP payload format supports three distinct video frame scanning techniques:¶
All frames are scanned left to right, top to bottom.¶
Each RTP packet, as specified at [RFC3550], is either a Main Packet or a Body Packet.¶
A Main Packet consists of the following ordered sequence of structures concatenated without gaps:¶
A Body Packet consists of the following ordered sequence of structures concatenated without gaps:¶
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).¶
The JPEG 2000 codestreams MUST conform to Section 6.¶
The padding bytes MUST be ignored by the recipient.¶
NOTE: Padding bytes can be used to achieve constant bit rate transmission.¶
A JPEG 2000 codestream consists of the bytes between, and including, the SOC and EOC markers, as defined in [jpeg2000-1].¶
A JPEG 2000 codestream fragment does not necessarily contain complete JPEG 2000 packets, as defined in [jpeg2000-1].¶
A JPEG 2000 codestream Extended Header consists of the bytes between, and including, the SOC marker and the first SOD marker.¶
The payload of a Body Packet MUST NOT contain any bytes of the JPEG 2000 codestream Extended Header.¶
The payload of a Main Packet MUST contain at least one byte of the JPEG 2000 codestream Extended Header and MAY contain bytes other than those of the JPEG 2000 codestream Extended Header.¶
A payload MUST NOT contain bytes from more than one JPEG 2000 codestream.¶
The following RTP header fields have a specific meaning in the context of this payload format:¶
marker
timestamp
The timestamp
is the presentation time of the image to
which the payload belongs.¶
The timestamp
clock rate is 90 kHz.¶
The timestamp
of successive progressive frames MUST
advance at regular increments based on the instantaneous video frame
rate.¶
The timestamp
of Field 1 of successive interlaced frames
MUST advance at regular increments based on the instantaneous video
frame rate, and the Timestamp
of Field 2 MUST be offset
from the timestamp
of Field 1 by one half of the
instantaneous frame period.¶
The timestamp
of both segments of a progressive
segmented frame MUST be equal.¶
timestamp
of all RTP packets of a given image MUST be
equal.¶
sequence number
The low-order bits of the RTP sequence number.¶
The higher order bits of the RTP sequence number are contained in
the ESEQ
field, which is specified at Section 5.3.¶
The RTP sequence number is calculated as follows:¶
ESEQ * 65536 + sequence number
¶
Figure 2 specifies the structure of the payload header. Fields are interpreted as unsigned binary integers in network order.¶
Indicates the scanning structure of the image to which the payload belongs.¶
Specifies the progression order used by the codestream and whether resync points are signaled.¶
ORDH
MUST be 0 is the codestream consists of more than
one tile.¶
NOTE: Only ORDH
= 4 and ORDH
= 6 allow
sub-codestream latency streaming.¶
NOTE: Progression order PRCL is defined in [jpeg2000-2]. The other progression orders are specified in [jpeg2000-1].¶
XTRAB
field.¶
PTSTAMP = (timestamp
+ TOFF
) mod 4096, if
P
= 1 in the Main Packet of this codestream.¶
TOFF
is the transmission time of this RTP Packet, in the
timebase of the timestamp
clock and relative to the first
packet with the same timestamp
value.¶
TOFF
= 0 in the first RTP Packet with the same
timestamp
value.¶
PTSTAMP
= 0, if P
= 0 in the Main Packet of this
codestream.¶
NOTE: As described at Section 7.4 and
Section 8.1, PTSTAMP
is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
timestamp
fields differ by no more than 45 ms =
4095/90,000. [RFC5450] provides addresses the general
case when a RTP packet is transmitted at a time other than its
nominal transmission time.¶
The high order bits of the RTP sequence number.¶
Section 5.2 specifies the low-order bits of the RTP sequence number and the formula to compute the RTP sequence number¶
Determines whether Main Packet and codestream header information can be reused across codestreams.¶
All Main Packets in this stream, as identified by its
SSRC
value:¶
TP
, MH
, ESEQ
and
PTSTAMP
fields;¶
Component colorimetry is not specified, and left to the session or the application.¶
PRIMS
, TRANS
and MAT
and
RANGE
MUST be zero.¶
Component colorimetry is specified by the PRIMS
,
TRANS and MAT
and RANGE
fields.¶
The codestream components MUST conform to one of the combinations at Table 1.¶
Combination name | Component index | |||
---|---|---|---|---|
0 | 1 | 2 | 3 | |
Y | Y | |||
YA | Y | A | ||
RGB | R | G | B | |
RGBA | R | G | B | A |
YCbCr | Y | CB | CR | |
YCbCrA | Y | CB | CR | A |
The channel A is an opacity
channel. The minimum sample value (0) indicates a
completely transparent sample, and the maximum sample
value (as determined by the bit depth of the codestream
component) indicates a completely opaque sample. The
opacity channel MUST map to a component with unsigned
samples. |
MAT (Color Matrix Coefficients)
Figure 3 specifies the structure of the Body Packet Payload Header. Fields are interpreted as unsigned binary integers in network order.¶
ORDB
MUST be 0 is the codestream consists of more than
one tile.¶
Byte offset from the start of the payload to the first byte of the resync point belonging to the precinct identified by PID.¶
POS
MUST be 0 if ORDB
= 0.¶
Unique identifier of the precinct of the resync point.¶
PID = c + s * num_components
¶
where:¶
If PID
is present, the payload MUST NOT contain
codestream bytes from more than one precinct.¶
PID
MUST be 0 if ORDB
= 0.¶
NOTE: PID
is identical to precinct identifier I
specified in [jpeg2000-9].¶
The JPEG 2000 codestream MAY include capabilities beyond those specified at [jpeg2000-1], including those specified in [jpeg2000-2] and [jpeg2000-15].¶
NOTE: The Rsiz
parameter and CAP
marker segments of
each JPEG 2000 codestream contain detailed information on the
capabilities necessary to decode the codestream.¶
NOTE: The caps
media type parameter defined in
Section 9.2 allows applications to signal
required device capabilities.¶
NOTE: The block coder specified at [jpeg2000-15] improves throughput and reduces latency compared to the original arithmetic block coder defined in [jpeg2000-1].¶
For interlaced or progressive segmented frames, the height specified in the JPEG 2000 main header MUST be the height in lines of the field or the segment, respectively.¶
If any decomposition level involves only horizontal decomposition then no decomposition level MUST involve only vertical decomposition; and conversely, if any decomposition level involves only vertical decomposition then no decomposition level MUST involve only horizontal decomposition.¶
Only Main Packets MAY contain bytes of the JPEG 2000 codestream Extended Header.¶
The sender MUST either emit a single Main Packet with MH
=
3, or one or more Main Packets with MH
= 1 followed by a
single Main Packet with MH
= 2.¶
The Main Packet Payload Headers fields MUST be identical in all Main Packet of a given codestream, with the exception of:¶
A network agent MAY strip out RTP Packet from a codestream that are of no interest to a particular client, e.g., based on a resolution or a spatial region of interest. Such a network agent SHOULD include a CSRC identifier to identify the SSRC field of the original source from which content was stripped.¶
A resync point is the first byte of JPEG 2000 packet header data for a precinct and for which PID < 224.¶
NOTE: Resync points cannot be specified if the codestream consists of
more than one tile (ORDB
and ORDH
are both equal to
zero).¶
NOTE: A resync point can be used by a receiver to process a codestream even if earlier packets in the codestream have been corrupted, lost or deliberately discarded by a network agent. As a corollary, resync points can be used by a network agent to discard packets that are not relevant to a given rendering resolution or region of interest. Resync points play a role similar to pointer marker segments, albeit tailored for high bandwidth low latency streaming applications.¶
A sender SHOULD set P
= 1, but only if it can generate
PTSTAMP
accurately.¶
PTSTAMP
can be derived from the same clock that is used to
produce the 32-bit timestamp
field in the RTP fixed header.
Specifically, a sender maintains, at least conceptually, a 32-bit
counter that is incremented by a 90kHz clock. The counter is sampled at
the point when each RTP Packet is or SHOULD be at least notionally
transmitted and the 12 LSBs of the sample are stored in the
PTSTAMP
field.¶
If P
= 1, then the transmission time TOFF
(as
defined at Section 5.3) for two consecutive RTP
packets with identical timestamp
fields MUST NOT differ by more
than 4095.¶
A sender SHOULD set RES
> 0 whenever possible.¶
NOTE: While a sender can always safely set RES
= 0, this
makes it more difficult to discard packets based on resolution, as
described at Section 8.3.¶
The sender MUST set the value of XTRAC
to 0.¶
Future edition of this specification can permit other values.¶
The sender MUST set reserved values to 0.¶
Future edition of this specification can specify other values such that these values can be ignored by receivers that conform to this specification.¶
A sender MUST NOT use an extension value.¶
This section applies only if C
= 1.¶
A sender can improve bandwidth efficiency by only occasionally
transmitting code-blocks corresponding to static portions of the video
and otherwise transmitting empty code-blocks. When C
= 1, and
as described at Section 8.7, a receiver
maintains a simple cache of previously received code-blocks, which it
uses to replace empty code-blocks.¶
A sender alone determines which and when code-blocks are replaced with empty code-blocks.¶
The sender cannot however determine with certainty the state of the receiver's cache: some code-blocks might have been lost in transit, the sender doesn't know exactly when the receiver started processing the stream, etc.¶
A code-block is empty if:¶
0xFF80
and 0xFF8F
.¶
NOTE: the last condition allows the encoder to insert padding bytes to achieve a constant bit rate even when a code-block does not contribute code-bytes, as suggested at [jpeg2000-15], F.4.¶
Receivers can use PTSTAMP
values to accelerate sender clock
recovery since PTSTAMP
typically updates more regularly than
timestamp
.¶
A receiver can discard packets where QUAL
> N if it is
interested in reconstructing an image that only incorporates quality
layers N and below.¶
The JPEG 2000 coding process decomposes an image using a sequence of discrete wavelet transforms (DWT) stages.¶
Decomposition level | Resolution level | Sub-bands | Keep all Body Packets with RES equal to or less than this value... | ... to decode an image with at most these dimensions |
---|---|---|---|---|
1 | 5 | HL1,LH1,HH1 | 7 | W x H |
2 | 4 | HL2,LH2,HH2 | 6 | (W/2) x (H/2) |
3 | 3 | HL3,LH3,HH3 | 5 | (W/4) x (H/4) |
4 | 2 | HL4,LH4,HH4 | 4 | (W/8) x (H/8) |
5 | 1 | HL5,LH5,HH5 | 3 | (W/16) x (H/16) |
5 | 0 | LL5 | 2 | (W/32) x (H/32) |
Table 2 illustrates the case where each DWT stage consists of both horizontal and vertical transforms, which is the only mode supported in [jpeg2000-1]. The first stage transforms the image into (i) the image at half-resolution (LL1 sub-bands) and (ii) residual high-frequency data (HH1, LH1, HL1 sub-bands). The second stage transforms the image at half-resolution (LL1 sub-bands) into the image at quarter resolution (LL2 sub-bands) and residual high-frequency data (HH2, LH2, HL2 sub-bands). This process is repeated NL times, where NL is the number of decomposition levels as defined in the COD and COC marker segments of the codestream.¶
The decoding process reconstructs the image by reversing the coding process, starting with the lowest resolution image stored in the codestream (LLNL).¶
As a result, it is possible to reconstruct a lower resolution of the
image by stopping the decoding process at a selected stage. For example,
in order to reconstruct the image at quarter resolution (LL2), only
sub-bands with index greater than 2, e.g., HL3, LH3, HH3, HL4, LH4, HH4,
etc., are necessary. In other words, a receiver that wishes to
reconstruct an image at quarter resolution could discard all packets
where RES
>= 6 since those packets can only contribute to
HL1, LH1, HH1, HL2, LH2 and HH2 sub-bands.¶
In the case where all DWT stages consist of both horizontal and
vertical transforms, the maximum decodable resolution is reduced by a
factor of 27 - N if all Body Packets where RES
>
N are discarded.¶
Decomposition level | Resolution level | Sub-bands | Keep all Body Packets with RES equal to or less than this value... | ... to decode an image with at most these dimensions |
---|---|---|---|---|
1 | 5 | HL1,LH1,HH1 | 7 | W x H |
2 | 4 | HL2,LH2,HH2 | 6 | (W/2) x (H/2) |
3 | 3 | HX3 | 5 | (W/4) x (H/2) |
4 | 2 | HX4 | 4 | (W/8) x (H/2) |
5 | 1 | HX5 | 3 | (W/16) x (H/2) |
5 | 0 | LX5 | 2 | (W/32) x (H/2) |
Table 3 illustrates the case where some of DWT stage consist of only horizontal transforms, as specified at Annex F of [jpeg2000-2].¶
A receiver can therefore discard all Body Packets where RES
is
greater than some threshold value if it is interested in decoding an
image with its resolution reduced by a factor determined by the
threshold value, as illustrated in Table 2 and
Table 3.¶
The receiver MUST accept values XTRAC
other than 0 and MUST
ignore the value of XTRAB
, whose length is given by
XTRAC
.¶
Future edition of this specification can specify XTRAB
contents such that this content can be ignored by receivers that conform
to this specification.¶
The receiver MUST ignore the value of reserved values.¶
The receiver MUST discard an RTP packet that contains any extension value.¶
This section applies only if C
= 1.¶
When C
= 1, and as specified in Section 7.9, the sender can improve bandwidth
efficiency by only occasionally transmitting code-blocks corresponding
to static portions of the video and otherwise transmitting empty
code-blocks, as defined at Section 7.9.¶
When decoding a codestream, and for each code-block in the codestream:¶
Two code-blocks are matching if the following
characteristics are identical for both: spatial coordinates, resolution
level, component, sub-band and value of the TP
field of the
parent RTP packet.¶
This RTP payload format is identified using the media type defined at Section 9.2, which is registered in accordance with [RFC4855] and using the template of [RFC6838].¶
pixel
Specifies the pixel format used by the video sequence.¶
The parameter MUST be a URI-reference
as specified in
[RFC3986].¶
If the parameter is a relative-ref
as specified in
[RFC3986], then it MUST be equal to one of the
pixel formats specified in Table 4 and the
RTP header and payload MUST conform with the characteristics of
that pixel format.¶
If the parameter is not a relative-ref
, the
specification of the pixel format is left to the application that
defined the URI.¶
If the parameter is not specified, the pixel format is unspecified.¶
sample
Specifies the format of the samples in each component of the codestream.¶
The parameter MUST be a URI-reference
as specified in
[RFC3986].¶
If the parameter is a relative-ref
as specified in
[RFC3986], then it MUST be equal to one of the
formats specified in Appendix C and the
stream MUST conform with the characteristics of that format.¶
If the parameter is not a relative-ref
, the
specification of the sample format is left to the application that
defined the URI.¶
If the parameter is not specified, the sample format is unspecified.¶
width
Maximum width in pixels of each image. Integer between 0 and 4,294,967,295.¶
The parameter MUST be a sequence of 1 or more digits.¶
If the parameter is not specified, the maximum width is unspecified.¶
height
Maximum height in pixels of each image. Integer between 0 and 4,294,967,295.¶
The parameter MUST be a sequence of 1 or more digits.¶
If the parameter is not specified, the maximum height is unspecified.¶
Specifies the sequence of image types.¶
The parameter MUST be a URI-reference
as specified
in [RFC3986].¶
If the parameter is a relative-ref
as specified in
[RFC3986], then it MUST be equal to one of the
signal formats specified in Appendix B and
the image sequence MUST conform to that signal format.¶
If the parameter is not a relative-ref
, the
specification of the pixel format is left to the application
that defined the URI.¶
If the parameter is not specified, the stream consists of an arbitrary sequence of image types.¶
caps
The parameters contains a list of sets of constraints to
which the stream conforms, with each set of constraints
identified using an absolute-URI
defined by an
application.¶
The parameter MUST conform to the uri-list
syntax
expressed using ABNF ([RFC5234]):¶
uri-list = absolute-URI *(";" absolute-URI)¶
Each absolute-URI
MUST NOT contain any ";"
character.¶
The application that defines the absolute-URI
MUST
associate it with a set of constraints to which the stream
conforms. Such constraints can, for example, include the maximum
height and width of images.¶
If the parameter is not specified, constraints, beyond those specified in this document, are unspecified.¶
cache
The value of the parameter MUST be either false
or
true
.¶
If the parameter is true
, the field C
MAY
be 0 or 1; otherwise the field C
MUST be 0.¶
If the parameter is not specified, then the parameter is
equal to false
.¶
The mapping of the payload format media type and its parameters to SDP, as specified in [RFC8866] MUST be done according to Section 3 of [RFC4855].¶
This memo requests that IANA registers the content type specified at Section 9.¶
RTP packets using the payload format specified in this document are subject to the security considerations discussed in [RFC3550] , and in any applicable RTP profile such as [RFC3551], [RFC4585], [RFC3711], [RFC5124]. However, as [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.¶
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for RTP Packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.¶
Security considerations related to the JPEG 2000 codestream contained in the payload are discussed at Section 3 of [RFC3745].¶
Table 4 defines pixel formats.¶
NAME | SAMP | COMPS | TRANS | PRIMS | MAT | VFR | Mapping in Table 1 |
---|---|---|---|---|---|---|---|
rgb444sdr | 4:4:4 | RGB | 1 | 1 | 0 | 0, 1 | RGB |
rgb444wcg | 4:4:4 | RGB | 1 | 9 | 0 | 0, 1 | RGB |
rgb444pq | 4:4:4 | RGB | 16 | 9 | 0 | 0, 1 | RGB |
rgb444hlg | 4:4:4 | RGB | 18 | 9 | 0 | 0, 1 | RGB |
ycbcr420sdr | 4:2:0 | YCbCr | 1 | 1 | 1 | 0 | YCbCr |
ycbcr422sdr | 4:2:2 | YCbCr | 1 | 1 | 1 | 0 | YCbCr |
ycbcr422wcg | 4:2:2 | YCbCr | 1 | 9 | 9 | 0 | YCbCr |
ycbcr422pq | 4:2:2 | YCbCr | 16 | 9 | 9 | 0 | YCbCr |
ycbcr422hlg | 4:2:2 | YCbCr | 18 | 9 | 9 | 0 | YCbCr |
Each pixel format is characterized by the following:¶
NAME
COMPS
SAMP
TRANS
Identifies the transfer characteristics allowed by the pixel format, as defined at [rec-itu-t-h273]¶
PRIMS
Identifies the color primaries allowed by the pixel format, as defined at [rec-itu-t-h273]¶
MAT
Identifies the matrix coefficients allowed by the pixel format, as defined at [rec-itu-t-h273]¶
VFR
Allows values of the VideoFullRangeFlag defined at [rec-itu-t-h273]¶
prog
psf
tff
bff
This Appendix summarizes substantive changes across revisions of this specification. This summary is informative and not intended to be exhaustive.¶
draft-ietf-avtcore-rtp-j2k-scl-01
tile
media type
parameter).¶
draft-ietf-avtcore-rtp-j2k-scl-02