-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-avtcore-rtp-j2k-scl-02.xml
1756 lines (1502 loc) · 68.9 KB
/
draft-ietf-avtcore-rtp-j2k-scl-02.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="std" ipr="trust200902" consensus="true"
docName="draft-ietf-avtcore-rtp-j2k-scl-02" xml:lang="en" version="3">
<front>
<title abbrev="Sub-codestream latency J2K over RTP">RTP Payload Format for
sub-codestream latency JPEG 2000 streaming</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-rtp-j2k-scl-02"/>
<author initials='P.-A.' surname='Lemieux' fullname='Pierre-Anthony Lemieux' role="editor">
<organization>Sandflow Consulting LLC</organization>
<address>
<postal>
<city>San Mateo</city>
<region>CA</region>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials='D. S.' surname='Taubman' fullname='David Scott Taubman'>
<organization abbrev="University of New South Wales">University of New
South Wales</organization>
<address>
<postal>
<city>Sydney</city>
<country>AU</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<area>Applications and Real-Time Area</area>
<workgroup>Audio/Video Transport Core Maintenance</workgroup>
<keyword>JPEG 2000</keyword>
<keyword>J2K</keyword>
<keyword>HTJ2K</keyword>
<keyword>low latency</keyword>
<keyword>scalable</keyword>
<keyword>streaming</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>This RTP payload format specifies the streaming of a video signal
encoded as a sequence of JPEG 2000 codestreams.</t>
<t>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:</t>
<ul>
<li>the payload format allows sub-codestream latency such that the first
RTP packet of a given codestream to be emitted before the entire
codestream is available. Specifically, the payload format does not rely
on the JPEG 2000 PLM and PLT marker segments for recovery after RTP
Packet loss since these markers can only be written after the codestream
is complete and are thus incompatible with sub-codestream latency.
Instead, the payload format includes payload header fields
(<tt>ORDH</tt>, <tt>ORDB</tt>, <tt>POS</tt> and <tt>PID</tt>) 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 <xref target="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.</li>
<li>as in <xref target="RFC4175"/>, the payload header contains an
extension (<tt>ESEQ</tt>) 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).</li>
<li>the payload header optionally contains a temporal offset
(<tt>PTSTAMP</tt>) relative to the first RTP Packet with the same value
of RTP <tt>timestamp</tt> field (<xref target="def-timestamp"/>). The
higher resolution of <tt>PTSTAMP</tt> compared to the <tt>timestamp</tt>
allows receivers to recover the sender's clock more rapidly.</li>
</ul>
<t>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
(<tt>QUAL</tt> and <tt>RES</tt> fields), without having to parse the
underlying codestream.</t>
</section>
<section>
<name>Requirements Language</name>
<t>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
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section>
<section>
<name>Media format description</name>
<t>The following summarizes the structure of the JPEG 2000 codestream,
which is specified in detail at <xref target="jpeg2000-1"/>.</t>
<t>NOTE: as described at <xref target="sec-codestream"/>, a JPEG 2000
codestream allows capabilities defined in any part of the JPEG 2000 family
of standards, including those specified in <xref target="jpeg2000-2"/> and
<xref target="jpeg2000-15"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The rest of the codestream consists of additional marker segments
(tile-part headers) interleaved with coded image data.</t>
<t>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.</t>
<t>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:</t>
<dl>
<dt>Position (P)</dt>
<dd>The first lines of the image come before the last lines of the
image.</dd>
<dt>Component (C)</dt>
<dd>The first component of the image come before the last component of
the image.</dd>
<dt>Resolution Layer (R)</dt>
<dd>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.</dd>
<dt>Quality Layer (L)</dt>
<dd>The information needed to reconstruct the most-significant bits of
each sample come before the information needed to reconstruct the
least-significant bit of each sample.</dd>
</dl>
<t>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.</t>
</section>
<section>
<name>Video signal description</name>
<t>This RTP payload format supports three distinct video frame scanning
techniques:</t>
<ul>
<li>Progressive frame</li>
<li>Interlaced frame, where each frame consists of two fields. Field 1
occurs temporarily before Field 2. The height in lines of each field is
half the height of the image.</li>
<li>Progressive segmented frame (PsF), where each frame consists of two
segments. Segment 1 contains the odd lines (1, 3, 5, 7,...) of a frame
and Segment 2 contains the even lines (2, 4, 6, 8,...) of the same
frame, where lines from the top of the frame to the bottom of the frame
are numbered sequentially starting at 1.</li>
</ul>
<t>All frames are scanned left to right, top to bottom.</t>
</section>
<section>
<name>Payload Format</name>
<section>
<name>General</name>
<figure anchor="fig-payload-header">
<name>Packetization of a sequence of JPEG 2000 codestreams (not to
scale).</name>
<artwork type="ascii-art">
<![CDATA[
<----------- Codestream (image) --------->
| |
< Extended Header > |
| | |
+-----+-----+-----+------------//--+-----+-----+---------
| SOC | ... | SOD | .............. | EOC | P | SOC ...
+-----+-----+-----+------------//--+-----+-----+---------
| |
| |
| |
+---------------------+------+-//--+-----------+---------
Packets | Main | Body | ... | Body | Main ...
+---------------------+------+-//--+-----------+---------
SOC = Start of codestream marker
SOD = Start of data marker
EOC = End of codestream marker
P = (Optional) padding bytes
]]>
</artwork>
</figure>
<t>Each RTP packet, as specified at <xref target="RFC3550"/>, is either
a Main Packet or a Body Packet.</t>
<t>A Main Packet consists of the following ordered sequence of
structures concatenated without gaps:</t>
<ul>
<li>the RTP Fixed Header;</li>
<li>a Main Packet Payload Header, as specified at <xref
target="sec-main-packet-header"/>; and</li>
<li>the payload, which consists of a JPEG 2000 codestream
fragment.</li>
</ul>
<t>A Body Packet consists of the following ordered sequence of
structures concatenated without gaps:</t>
<ul>
<li>the RTP Fixed Header;</li>
<li>a Body Packet Payload Header, as specified at <xref
target="sec-body-packet-header"/>; and</li>
<li>the payload, which consists of a JPEG 2000 codestream
fragment.</li>
</ul>
<t>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 <xref target="fig-payload-header"/>).</t>
<t>The JPEG 2000 codestreams MUST conform to <xref
target="sec-codestream"/>.</t>
<t>The padding bytes MUST be ignored by the recipient.</t>
<t>NOTE: Padding bytes can be used to achieve constant bit rate
transmission.</t>
<t> A JPEG 2000 codestream consists of the bytes between, and including,
the SOC and EOC markers, as defined in <xref target="jpeg2000-1"/>.</t>
<t>A JPEG 2000 codestream fragment does not necessarily contain complete
JPEG 2000 packets, as defined in <xref target="jpeg2000-1"/>.</t>
<t>A JPEG 2000 codestream Extended Header consists of the bytes between,
and including, the SOC marker and the first SOD marker.</t>
<t>The payload of a Body Packet MUST NOT contain any bytes of the JPEG
2000 codestream Extended Header.</t>
<t>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.</t>
<t>A payload MUST NOT contain bytes from more than one JPEG 2000
codestream.</t>
</section>
<section>
<name>RTP Fixed Header Usage</name>
<t>The following RTP header fields have a specific meaning in the
context of this payload format:</t>
<dl newline="true">
<dt><tt>marker</tt></dt>
<dd>
<dl>
<dt>1</dt>
<dd>The payload contains an EOC marker.</dd>
<dt>0</dt>
<dd>Otherwise</dd>
</dl>
</dd>
<dt anchor="def-timestamp"><tt>timestamp</tt></dt>
<dd>
<t>The <tt>timestamp</tt> is the presentation time of the image to
which the payload belongs.</t>
<t>The <tt>timestamp</tt> clock rate is 90 kHz.</t>
<t>The <tt>timestamp</tt> of successive progressive frames MUST
advance at regular increments based on the instantaneous video frame
rate.</t>
<t>The <tt>timestamp</tt> of Field 1 of successive interlaced frames
MUST advance at regular increments based on the instantaneous video
frame rate, and the <tt>Timestamp</tt> of Field 2 MUST be offset
from the <tt>timestamp</tt> of Field 1 by one half of the
instantaneous frame period.</t>
<t>The <tt>timestamp</tt> of both segments of a progressive
segmented frame MUST be equal.</t>
<t><tt>timestamp</tt> of all RTP packets of a given image MUST be
equal.</t>
</dd>
<dt anchor="def-seq"><tt>sequence number</tt></dt>
<dd>
<t>The low-order bits of the RTP sequence number.</t>
<t>The higher order bits of the RTP sequence number are contained in
the <tt>ESEQ</tt> field, which is specified at <xref
target="def-ESEQ"/>.</t>
<t>The RTP sequence number is calculated as follows:</t>
<t><tt>ESEQ * 65536 + sequence number</tt></t></dd>
</dl>
</section>
<section anchor="sec-main-packet-header">
<name>Main Packet Payload Header</name>
<t><xref target="fig-main-payload-header"/> specifies the structure of the
payload header. Fields are interpreted as unsigned binary integers in
network order.</t>
<figure anchor="fig-main-payload-header">
<name>Structure of the Main Packet Payload Header</name>
<artwork type="ascii-art">
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MH | TP |ORDH |P|XTRAC| PTSTAMP | ESEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|C| RSVD |*| PRIMS | TRANS | MAT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| XTRAB |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* RANGE
]]>
</artwork>
</figure>
<dl newline="true">
<dt anchor="def-MH">MH (Codestream Main Header Presence)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd>The RTP Packet is a Body Packet.</dd>
<dt>1</dt>
<dd>The RTP Packet is a Main Packet and the codestream has more
than one Main Packet. The next RTP Packet is a Main Packet.</dd>
<dt>2</dt>
<dd>The RTP Packet is a Main Packet and the codestream has more
than one Main Packet. The next RTP Packet is a Body Packet.</dd>
<dt>3</dt>
<dd>The RTP Packet is a Main Packet and the codestream has exactly
one Main Packet.</dd>
</dl>
</dd>
<dt anchor="def-TP">TP (Image Type)</dt>
<dd>
<t>Indicates the scanning structure of the image to which the
payload belongs.</t>
<dl newline="true">
<dt>0</dt>
<dd>Progressive frame.</dd>
<dt>1</dt>
<dd>Field 1 of an interlaced frame, where the first line of the
field is the first line of the frame.</dd>
<dt>2</dt>
<dd>Field 2 of an interlaced frame, where the first line of the
field is the second line of the frame.</dd>
<dt>3</dt>
<dd>Field 1 of an interlaced frame, where the first line of the
field is the second line of the frame.</dd>
<dt>4</dt>
<dd>Field 2 of an interlaced frame, where the first line of the
field is the first line of the frame.</dd>
<dt>5</dt>
<dd>Segment 1 of a progressive segmented frame, where the
first line of the image is the first line of the frame.</dd>
<dt>6</dt>
<dd>Segment 2 of a progressive segmented frame, where the
first line of the image is the second line of the frame.</dd>
<dt>7</dt>
<dd>Extension value. See <xref target="sec-receiver-ext"/> and
<xref target="sec-sender-ext"/>.</dd>
</dl>
</dd>
<dt anchor="def-ORDH">ORDH (Progression Order [Main Packet])</dt>
<dd>
<t>Specifies the progression order used by the codestream and
whether resync points are signaled.</t>
<dl newline="true">
<dt>0</dt>
<dd>Resync points are not necessarily signaled. The progression
order can vary over the codestream.</dd>
<dt>1</dt>
<dd>The progression order is LRCP for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>2</dt>
<dd>The progression order is RLCP for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>3</dt>
<dd>The progression order is RPCL for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>4</dt>
<dd>The progression order is PCRL for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>5</dt>
<dd>The progression order is CPRL for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>6</dt>
<dd>The progression order is PRCL for the entire codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
<dt>7</dt>
<dd>The progression order can vary over the codestream. The
first resync point is specified in every Body Packet that
contains one or more resync points.</dd>
</dl>
<t><tt>ORDH</tt> MUST be 0 is the codestream consists of more than
one tile.</t>
<t>NOTE: Only <tt>ORDH</tt> = 4 and <tt>ORDH</tt> = 6 allow
sub-codestream latency streaming.</t>
<t>NOTE: Progression order PRCL is defined in <xref
target="jpeg2000-2"/>. The other progression orders are specified
in <xref target="jpeg2000-1"/>.</t>
</dd>
<dt anchor="def-P">P (Precision Timestamp Presence)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd><tt>PTSTAMP</tt> is not used.</dd>
<dt>1</dt>
<dd><tt>PTSTAMP</tt> is used.</dd>
</dl>
</dd>
<dt anchor="def-XTRAC">XTRAC (Extension Payload Length)</dt>
<dd>Length, in multiples of 4 bytes, of the <tt>XTRAB</tt> field.</dd>
<dt anchor="def-PTSTAMP">PTSTAMP (Precision Timestamp)</dt>
<dd>
<t>PTSTAMP = (<tt>timestamp</tt> + <tt>TOFF</tt>) mod 4096, if
<tt>P</tt> = 1 in the Main Packet of this codestream.</t>
<t><tt>TOFF</tt> is the transmission time of this RTP Packet, in the
timebase of the <tt>timestamp</tt> clock and relative to the first
packet with the same <tt>timestamp</tt> value.</t>
<t><tt>TOFF</tt> = 0 in the first RTP Packet with the same
<tt>timestamp</tt> value.</t>
<t><tt>PTSTAMP</tt> = 0, if <tt>P</tt> = 0 in the Main Packet of this
codestream.</t>
<t>NOTE: As described at <xref target="sec-sender-ptstamp"/> and
<xref target="sec-recv-ptstamp"/>, <tt>PTSTAMP</tt> is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
<tt>timestamp</tt> fields differ by no more than 45 ms =
4095/90,000. <xref target="RFC5450"/> provides addresses the general
case when a RTP packet is transmitted at a time other than its
nominal transmission time.</t>
</dd>
<dt anchor="def-ESEQ">ESEQ (Extended Sequence Number)</dt>
<dd>
<t>The high order bits of the RTP sequence number.</t>
<t><xref target="def-seq"/> specifies the The low-order bits of the
RTP sequence number and the formula to compute the RTP sequence
number</t>
</dd>
<dt anchor="def-R">R (Codestream Main Header Reuse)</dt>
<dd>
<t>Determines whether Main Packet and codestream header information
can be reused across codestreams.</t>
<dl newline="true">
<dt>1</dt>
<dd>
<t>All Main Packets in this stream, as identified by its
<tt>SSRC</tt> value:</t>
<ul>
<li>MUST have identical Main Packet Payload Headers, with the
exception of their <tt>TP</tt>, <tt>MH</tt>, <tt>ESEQ</tt> and
<tt>PTSTAMP</tt> fields;</li>
<li>MUST contain the same codestream main header information,
with the exception of the SOT and COM marker segments, and any
pointer marker segments; and</li>
<li>MUST NOT contain bytes other than Extended Header
bytes.</li>
</ul>
</dd>
<dt>0</dt>
<dd>Otherwise</dd>
</dl>
</dd>
<dt anchor="def-S">S (Parameterized Colorspace Presence)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd><t>Component colorimetry is not specified, and left to the
session or the application.</t>
<t><tt>PRIMS</tt>, <tt>TRANS</tt> and <tt>MAT</tt> and
<tt>RANGE</tt>
MUST be zero.</t>
</dd>
<dt>1</dt>
<dd>
<t>Component colorimetry is specified by the <tt>PRIMS</tt>,
TRANS and <tt>MAT</tt> and <tt>RANGE</tt> fields.</t>
<t>The codestream components MUST conform to one of the
combinations at <xref target="t-color-map"/>.</t>
<table anchor="t-color-map">
<name>Mapping of codestream components to color
channels</name>
<thead>
<tr>
<th rowspan="2">Combination name</th>
<th colspan="4">Component index</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
</tr>
</thead>
<tbody>
<tr>
<th>Y</th><td>Y</td><td></td><td></td><td></td>
</tr>
<tr>
<th>YA</th><td>Y</td><td>A</td><td></td><td></td>
</tr>
<tr>
<th>RGB</th><td>R</td><td>G</td><td>B</td><td></td>
</tr>
<tr>
<th>RGBA</th><td>R</td><td>G</td><td>B</td><td>A</td>
</tr>
<tr>
<th>YCbCr</th><td>Y</td><td>C<sub>B</sub></td>
<td>C<sub>R</sub></td><td></td>
</tr>
<tr>
<th>YCbCrA</th><td>Y</td><td>C<sub>B</sub></td>
<td>C<sub>R</sub></td><td>A</td>
</tr>
</tbody>
<tfoot>
<tr>
<td colspan="5">The channel <tt>A</tt> 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.</td>
</tr>
</tfoot>
</table>
</dd>
</dl>
</dd>
<dt anchor="def-C">C (Code-block Caching Usage)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd>Code-block caching is not in use.</dd>
<dt>1</dt>
<dd>
<t>Code-block caching is in use.</t>
<t><tt>R</tt> MUST be equal to 1.</t>
</dd>
</dl>
</dd>
<dt anchor="def-RSVD">RSVD (Reserved)</dt>
<dd>Reserved value. See <xref target="sec-receiver-reserved"/> and
<xref target="sec-sender-reserved"/>.</dd>
<dt anchor="def-F">RANGE (Video Full Range Usage)</dt>
<dd>Value of the VideoFullRangeFlag specified in <xref
target="rec-itu-t-h273"/></dd>
<dt anchor="def-PRIMS">PRIMS (Color Primaries)</dt>
<dd>One of the ColourPrimaries values specified in <xref
target="rec-itu-t-h273"/></dd>
<dt anchor="def-TRANS">TRANS (Transfer Characteristics)</dt>
<dd>One of the TransferCharacteristics values specified in
<xref target="rec-itu-t-h273"/></dd>
<dt anchor="def-MAT"><tt>MAT (Color Matrix Coefficients)</tt></dt>
<dd>One of the MatrixCoefficients values specified in <xref
target="rec-itu-t-h273"/></dd>
<dt anchor="def-XTRAB">XTRAB (Extension Payload)</dt>
<dd>Allows the contents of the Main Packet Payload Header to be
extended in the future. See <xref target="sec-receiver-xtrab"/> and
<xref target="sec-sender-xtrab"/>.</dd>
</dl>
</section>
<section anchor="sec-body-packet-header">
<name>Body Packet Payload Header</name>
<t><xref target="fig-body-payload-header"/> specifies the structure of
the Body Packet Payload Header. Fields are interpreted as unsigned
binary integers in network order.</t>
<figure anchor="fig-body-payload-header">
<name>Structure of the Body Packet Payload Header</name>
<artwork type="ascii-art">
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MH | TP |RES |*|QUAL | PTSTAMP | ESEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ORDB
]]>
</artwork>
</figure>
<dl newline="true">
<dt>MH</dt>
<dd>See <xref target="def-MH"/>.</dd>
<dt>TP</dt>
<dd>See <xref target="def-TP"/>.</dd>
<dt anchor="def-RES">RES (Resolution Layers)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd>The payload can contribute to all resolution layers.</dd>
<dt>Otherwise</dt>
<dd>The payload contains at least one byte of one JPEG 2000 packet
belonging to resolution level (N<sub>L</sub> + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N<sub>L</sub> is the number of decomposition
levels of the codestream.</dd>
</dl>
</dd>
<dt anchor="def-ORDB">ORDB (Progression Order [Body Packet]</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd>No resync point is specified for the payload.</dd>
<dt>1</dt>
<dd>The payload contains a resync point.</dd>
</dl>
<t><tt>ORDB</tt> MUST be 0 is the codestream consists of more than
one tile.</t>
</dd>
<dt anchor="def-QUAL">QUAL (Quality Layers)</dt>
<dd>
<dl newline="true">
<dt>0</dt>
<dd>The payload can contribute to all quality layers.</dd>
<dt>Otherwise</dt>
<dd>The payload contributes only to quality layer index
<tt>QUAL</tt> or above.</dd>
</dl>
</dd>
<dt>PTSTAMP</dt>
<dd>See <xref target="def-PTSTAMP"/>.</dd>
<dt>ESEQ</dt>
<dd>See <xref target="def-ESEQ"/>.</dd>
<dt anchor="def-POS">POS (Resync Point Offset)</dt>
<dd>
<t>Byte offset from the start of the payload to the first byte of
the resync point belonging to the precinct identified by PID.</t>
<t><tt>POS</tt> MUST be 0 if <tt>ORDB</tt> = 0.</t>
</dd>
<dt anchor="def-PID">PID (Precinct Identifier)</dt>
<dd>
<t>Unique identifier of the precinct of the resync point.</t>
<t><tt>PID = c + s * num_components</tt></t>
<t>where:</t>
<ul>
<li><em>c</em> is the index (starting from 0) of the image
component to which the precinct belongs;</li>
<li><em>s</em> is a sequence number which identifies the precinct
within its tile-component; and</li>
<li><em>num_components</em> is the number of components of the
codestream.</li>
</ul>
<t>If <tt>PID</tt> is present, the payload MUST NOT contain
codestream bytes from more than one precinct.</t>
<t><tt>PID</tt> MUST be 0 if <tt>ORDB</tt> = 0.</t>
<t>NOTE: <tt>PID</tt> is identical to precinct identifier I
specified in <xref target="jpeg2000-9"/>.</t>
</dd>
</dl>
</section>
</section>
<section anchor="sec-codestream">
<name>JPEG 2000 codestream requirements</name>
<section>
<name>General</name>
<t>The JPEG 2000 codestream MAY include capabilities beyond those
specified at <xref target="jpeg2000-1"/>, including those specified in
<xref target="jpeg2000-2"/> and <xref target="jpeg2000-15"/>.</t>
<t>NOTE: The <tt>Rsiz</tt> parameter and <tt>CAP</tt> marker segments of
each JPEG 2000 codestream contain detailed information on the
capabilities necessary to decode the codestream.</t>
<t>NOTE: The <tt>caps</tt> media type parameter defined in
<xref target="sec-media-type-def"/> allows applications to signal
required device capabilities.</t>
<t>NOTE: The block coder specified at <xref target="jpeg2000-15"/>
improves throughput and reduces latency compared to the original
arithmetic block coder defined in <xref target="jpeg2000-1"/>.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="sec-sender">
<name>Sender requirements</name>
<section>
<name>Main Packet</name>
<t>Only Main Packets MAY contain bytes of the JPEG 2000 codestream
Extended Header.</t>
<t>The sender MUST either emit a single Main Packet with <tt>MH</tt> =
3, or one or more Main Packets with <tt>MH</tt> = 1 followed by a
single Main Packet with <tt>MH</tt> = 2.</t>
<t>The Main Packet Payload Headers fields MUST be identical in all Main
Packet of a given codestream, with the exception of:</t>
<ul>
<li><tt>MH</tt>;</li>
<li><tt>ESEQ</tt>; and</li>
<li><tt>PTSTAMP</tt>.</li>
</ul>
</section>
<section>
<name>RTP Packet filtering</name>
<t>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.</t>
</section>
<section>
<name>Resync point</name>
<t>A resync point is the first byte of JPEG 2000 packet header data for
a precinct and for which PID < 2<sup>24</sup>.</t>
<t>NOTE: Resync points cannot be specified if the codestream consists of
more than one tile (<tt>ORDB</tt> and <tt>ORDH</tt> are both equal to
zero).</t>
<t>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.</t>
</section>
<section anchor="sec-sender-ptstamp">
<name>PTSTAMP field</name>
<t>A sender SHOULD set <tt>P</tt> = 1, but only if it can generate
<tt>PTSTAMP</tt> accurately.</t>
<t><tt>PTSTAMP</tt> can be derived from the same clock that is used to
produce the 32-bit <tt>timestamp</tt> 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
<tt>PTSTAMP</tt> field.</t>
<t>If <tt>P</tt> = 1, then the transmission time <tt>TOFF</tt> (as
defined at <xref target="def-PTSTAMP"></xref>) for two consecutive RTP
packets with identical <tt>timestamp</tt> fields MUST NOT differ by more
than 4095.</t>
</section>
<section>
<name>RES field</name>
<t>A sender SHOULD set <tt>RES</tt> > 0 whenever possible.</t>
<t>NOTE: While a sender can always safely set <tt>RES</tt> = 0, this
makes it more difficult to discard packets based on resolution, as
described at <xref target="recv-RES"/>.</t>
</section>
<section anchor="sec-sender-xtrab">
<name>Extra information</name>
<t>The sender MUST set the value of <tt>XTRAC</tt> to 0.</t>
<t>Future edition of this specification can permit other values.</t>
</section>
<section anchor="sec-sender-reserved">
<name>Reserved values</name>
<t>The sender MUST set reserved values to 0.</t>
<t>Future edition of this specification can specify other values such
that these values can be ignored by receivers that conform to this
specification.</t>
</section>
<section anchor="sec-sender-ext">
<name>Extension values</name>
<t>A sender MUST NOT use an extension value.</t>
</section>
<section anchor="sec-send-block-caching">
<name>Code-block caching</name>
<t>This section applies only if <tt>C</tt> = 1.</t>
<t>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 <tt>C</tt> = 1, and
as described at <xref target="sec-rcv-block-caching"/>, a receiver
maintains a simple cache of previously received code-blocks, which it
uses to replace empty code-blocks.</t>
<t>A sender alone determines which and when code-blocks are replaced
with empty code-blocks.</t>
<t>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.</t>
<t>A code-block is <em>empty</em> if:</t>
<ul>
<li>it does not contribute code-bytes as specified in the parent JPEG
2000 packet header; or</li>
<li>if the code-block conforms to <xref target="jpeg2000-15"/>,
contains an HT cleanup segment and the first two bytes of the Magsgn
byte-stream are between <tt>0xFF80</tt> and <tt>0xFF8F</tt>.</li>
</ul>
<t>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 <xref target="jpeg2000-15"/>,
F.4.</t>
</section>
</section>
<section anchor="sec-receiver">
<name>Receiver</name>
<section anchor="sec-recv-ptstamp">
<name>PTSTAMP</name>
<t>Receivers can use <tt>PTSTAMP</tt> values to accelerate sender clock
recovery since <tt>PTSTAMP</tt> typically updates more regularly than
<tt>timestamp</tt>.</t>
</section>
<section>
<name>QUAL</name>
<t>A receiver can discard packets where <tt>QUAL</tt> > N if it is
interested in reconstructing an image that only incorporates quality
layers N and below.</t>
</section>
<section anchor="recv-RES">
<name>RES</name>
<t>The JPEG 2000 coding process decomposes an image using a sequence of
discrete wavelet transforms (DWT) stages.</t>
<table anchor="t-res-ll-example">
<name>Optional discarding of Body Packets based on the value of the
<tt>RES</tt> field when decoding a reduced resolution image, in the
case where N<sub>L</sub> = 5 and all DWT stages consist of both
horizontal and vertical transforms. The image has nominal width and
height of W x H.</name>
<thead>
<tr>
<th>Decomposition level</th>
<th>Resolution level</th>
<th>Subbands</th>
<th>Keep all Body Packets with RES equal to or less than this
value...</th>
<th>... to decode an image with at most these dimensions</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>