forked from onvif/specs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Streaming.xml
2108 lines (2092 loc) · 118 KB
/
Streaming.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"?>
<?xml-stylesheet href="docbook.xsl" type="text/xsl" ?>
<book xmlns="http://docbook.org/ns/docbook" version="5.0">
<info>
<title>Streaming Specification</title>
<titleabbrev>Streaming</titleabbrev>
<releaseinfo>23.06</releaseinfo>
<author>
<orgname>ONVIF™</orgname>
<uri>www.onvif.org</uri>
</author>
<pubdate>June, 2023</pubdate>
<mediaobject>
<imageobject>
<imagedata fileref="media/logo.png" contentwidth="60mm"/>
</imageobject>
</mediaobject>
<copyright>
<year>2008-2023</year>
<holder>ONVIF™ All rights reserved.</holder>
</copyright>
<legalnotice>
<para>Recipients of this document may copy, distribute, publish, or display this document so
long as this copyright notice, license and disclaimer are retained with all copies of the
document. No license is granted to modify this document.</para>
<para>THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR
AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE;
OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS,
TRADEMARKS OR OTHER RIGHTS.</para>
<para>IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR
RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION,
MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2)
SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR
DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT
APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR
RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF
THE CORPORATION.</para>
</legalnotice>
<revhistory>
<revision>
<revnumber>2.1</revnumber>
<date>Jul-2011</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Split from Core 2.0 Change Requests 201, 225</revremark>
</revision>
<revision>
<revnumber>2.1.1</revnumber>
<date>Jan-2012</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Change Requests 282, 283, 284, 296, 289, 290, 264, 316, 333, 549</revremark>
</revision>
<revision>
<revnumber>2.2</revnumber>
<date>May-2012</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Change Request 613</revremark>
</revision>
<revision>
<revnumber>2.2.1</revnumber>
<date>Dec-2012</date>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Change Requests 768, 878</revremark>
</revision>
<revision>
<revnumber>2.3</revnumber>
<date>May-2013</date>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Change Request 1051</revremark>
</revision>
<revision>
<revnumber>2.4.1</revnumber>
<date>Dec-2013</date>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Change Request 1285</revremark>
</revision>
<revision>
<revnumber>2.4.2</revnumber>
<date>Jun-2014</date>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Change Request 1323</revremark>
</revision>
<revision>
<revnumber>2.5</revnumber>
<date>Dec-2014</date>
<author>
<personname>Hans Busch</personname>
</author>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Added support for gzip compressed metadata Change Request 1443</revremark>
</revision>
<revision>
<revnumber>2.6</revnumber>
<date>Jun-2015</date>
<author>
<personname>Michio Hirai</personname>
</author>
<revremark>Change Request 1571, 1605, 1624</revremark>
</revision>
<revision>
<revnumber>16.06</revnumber>
<date>Jun-2016</date>
<author>
<personname>Hiroyuki Sano</personname>
</author>
<revremark>Change Request 1717, 1725, 1852</revremark>
</revision>
<revision>
<revnumber>16.12</revnumber>
<date>Dec-2016</date>
<author>
<personname>Sujith Raman</personname>
</author>
<author>
<personname>Hans Busch</personname>
</author>
<author>
<personname>Hiroyuki Sano</personname>
</author>
<revremark>Added RTSP over WebSocket Change Request 1886, 1888, 1890</revremark>
</revision>
<revision>
<revnumber>17.06</revnumber>
<date>Jun-2017</date>
<author>
<personname>Hiroyuki Sano</personname>
</author>
<revremark>Change Request 1843, 1954, 1997, 2084, 2085, 2128</revremark>
</revision>
<revision>
<revnumber>17.12</revnumber>
<date>Dec-2017</date>
<author>
<personname>Hiroyuki Sano</personname>
</author>
<revremark>Change Request 2165, 2180, 2181, 2206, 2210</revremark>
</revision>
<revision>
<revnumber>18.06</revnumber>
<date>Jun-2018</date>
<author>
<personname>Hiroyuki Sano</personname>
</author>
<revremark>Change Request 2229, 2247, 2254, 2275, 2284, 2285</revremark>
</revision>
<revision>
<revnumber>19.06</revnumber>
<date>Jun-2019</date>
<author>
<personname>Hiroyujki Sano</personname>
</author>
<revremark>Change Request 2446, 2464</revremark>
</revision>
<revision>
<revnumber>19.12</revnumber>
<date>Dec-2019</date>
<author>
<personname>Dora Han</personname>
</author>
<revremark>Added Multitrack Streaming</revremark>
</revision>
<revision>
<revnumber>21.06</revnumber>
<date>Jun-2021</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Improve section on timeout and keep-alive handling.</revremark>
</revision>
<revision>
<revnumber>21.12</revnumber>
<date>Dec-2021</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Remove obsolete exi default compression.</revremark>
</revision>
<revision>
<revnumber>22.12</revnumber>
<date>Dec-2022</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Add secure RTSPS streaming.</revremark>
</revision>
<revision>
<revnumber>23.06</revnumber>
<date>Jun-2023</date>
<author>
<personname>Hans Busch</personname>
</author>
<revremark>Update description and figure to remove emphasis on SET_PARAMETER.</revremark>
</revision>
</revhistory>
</info>
<chapter>
<title>Scope</title>
<para>This document defines the ONVIF specific streaming extensions for live and replay streaming. The corresponding web service APIs to retrieve the streaming URIs are defined in separate documents and are not covered in this document.</para>
</chapter>
<chapter>
<title>Normative references</title>
<para>ISO/IEC 14496-2:2004, <emphasis>Information technology -- Coding of audio-visual objects -- Part 2: Visual</emphasis></para>
<para>ISO/IEC 14496-3:2005, <emphasis>Information technology -- Coding of audio-visual objects -- Part 3: Audio</emphasis></para>
<para>ISO/IEC 14496-10:2008, <emphasis>Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding</emphasis></para>
<para>ISO/IEC 23008-2:2015,<emphasis> Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding</emphasis></para>
<para role="reference">ITU-T G.711, <emphasis>Pulse code modulation (PCM) of voice frequencies</emphasis> <<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.711-198811-I!!PDF-E&type=items"></link>></para>
<para>ITU-T G.726,<emphasis> 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)</emphasis></para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.726-199012-I!!PDF-E&type=items"></link>></para>
<para>RSA Laboratories, PKCS #10 v1.7: <emphasis>Certification Request Syntax Standard, RSA Laboratories</emphasis></para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf"></link>></para>
<para>IETF RFC 2246, The TLS Protocol Version 1.0</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc2246.txt"></link>></para>
<para>IETF RFC 2326, Real Time Streaming Protocol (RTSP)</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc2326.txt"></link>></para>
<para>IETF RFC 2396, Uniform Resource Identifiers (URI): General Syntax</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc2396.txt"></link>></para>
<para>IETF RFC 2435, RFC2435 - RTP Payload Format for JPEG-compressed Video</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc2435.txt"></link>></para>
<para>IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams</para>
<programlisting><![CDATA[http://www.ietf.org/rfc/rfc3016.txt
]]></programlisting>
<para>IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc3550.txt"></link>></para>
<para>IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc3551.txt"></link>></para>
<para>IETF RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc3640.txt"></link>></para>
<para>IETF RFC 3711, The Secure Real-time Transport Protocol (SRTP)</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.ietf.org/rfc/rfc3711.txt"></link>></para>
<para>IETF RFC 3984, RTP Payload Format for H.264 Video</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc3984"></link>></para>
<para>IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc3016"></link>></para>
<para>IETF RFC 4566, SDP: Session Description Protocol</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc4566.txt"></link>></para>
<para>IETF RFC 4567, Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) </para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc4567.txt"></link>></para>
<para>IETF RFC 4571, Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc4571.txt"></link>></para>
<para>IETF RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc4585.txt"></link>></para>
<para>IETF 5104, Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc5104.txt"></link>></para>
<para>IETF RFC 5888 The Session Description Protocol (SDP) Grouping Framework</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https:/tools.ietf.org/html/rfc5888"></link>></para>
<para>IETF RFC 6455, The WebSocket Protocol</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc6455.txt"></link>></para>
<para>IETF RFC 7798, RTP Payload Format for High Efficiency Video Coding (HEVC)</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc7798.txt"></link>></para>
<para>IETF RFC 7826, Real-Time Streaming Protocol Version 2.0</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/rfc7826.txt"></link>></para>
<para>GZIP file format specification version 4.3</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc1952"></link>></para>
<para>Apple Computer Inc. RTSP over HTTP, Tunneling QuickTime RTSP and RTP over HTTP</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf"></link>></para>
<para>ONVIF Core Specification</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf"></link>></para>
<para>ONVIF Media Service Specification</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.onvif.org/specs/srv/media/ONVIF-Media-Service-Spec.pdf"></link>></para>
<para>ONVIF Media2 Service Specification</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.onvif.org/specs/srv/media/ONVIF-Media2-Service-Spec.pdf"></link>></para>
<para>ONVIF Replay Control Service Specification</para>
<para role="reference"><<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.onvif.org/specs/srv/replay/ONVIF-ReplayControl-Service-Spec.pdf"></link>></para>
</chapter>
<chapter>
<title>Terms and Definitions</title>
<section>
<title>Definitions</title>
<informaltable>
<tgroup cols="2">
<colspec colname="c1" colwidth="24*" />
<colspec colname="c2" colwidth="76*" />
<tbody valign="top">
<row>
<entry align="left">
<para>
<emphasis role="bold">Access Unit</emphasis>
</para>
</entry>
<entry align="left">
<para>One or more frames or samples of audio, video, or metadata which are contained in a group of RTP packets having the same presentation time.</para>
</entry>
</row>
<row>
<entry align="left">
<para>
<emphasis role="bold">Metadata</emphasis>
</para>
</entry>
<entry align="left">
<para>All streaming data except video and audio, including video analytics results, PTZ position data and other <phrase>metadata (such as textual data from POS applications)</phrase>.</para>
</entry>
</row>
<row>
<entry align="left">
<para>
<emphasis role="bold">Recording</emphasis>
</para>
</entry>
<entry align="left">
<para>Represents the currently stored media (if any) and metadata on the NVS from a single data source. A recording comprises one or more tracks. A recording can have more than one track of the same type e.g. two different video tracks recorded in parallel with different settings</para>
</entry>
</row>
<row>
<entry align="left">
<para>
<emphasis role="bold">Track</emphasis>
</para>
</entry>
<entry align="left">
<para>An individual data channel consisting of video, audio, or metadata. This definition is consistent with the definition of track in [RFC 2326]</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section>
<section>
<title>Abbreviations</title>
<informaltable>
<tgroup cols="2">
<colspec colname="c1" colwidth="24*" />
<colspec colname="c2" colwidth="76*" />
<tbody valign="top">
<row>
<entry valign="middle">
<para>AAC</para>
</entry>
<entry valign="middle">
<para>Advanced Audio Coding</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>EOI</para>
</entry>
<entry valign="middle">
<para>End Of Image</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>HEVC</para>
</entry>
<entry valign="middle">
<para>High Efficiency Video Coding also coined H.265</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>JFIF</para>
</entry>
<entry valign="middle">
<para>JPEG File Interchange Format </para>
</entry>
</row>
<row>
<entry valign="middle">
<para>JPEG</para>
</entry>
<entry valign="middle">
<para>Joint Photographic Expert Group</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>MPEG-4</para>
</entry>
<entry valign="middle">
<para>Moving Picture Experts Group - 4</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>PTZ</para>
</entry>
<entry valign="middle">
<para>Pan/Tilt/Zoom</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>RTCP</para>
</entry>
<entry valign="middle">
<para>RTP Control Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>RTP</para>
</entry>
<entry valign="middle">
<para>Realtime Transport Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>RTSP</para>
</entry>
<entry valign="middle">
<para>Real Time Streaming Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>RTSPS</para>
</entry>
<entry valign="middle">
<para>Secure Real Time Streaming Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>SDP</para>
</entry>
<entry valign="middle">
<para>Session Description Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>SOI</para>
</entry>
<entry valign="middle">
<para>Start Of Image </para>
</entry>
</row>
<row>
<entry valign="middle">
<para>SOF</para>
</entry>
<entry valign="middle">
<para>Start Of Frame</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>SOS</para>
</entry>
<entry valign="middle">
<para>Start Of Scan</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>SRTP</para>
</entry>
<entry valign="middle">
<para>Secure Realtime Transport Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>TCP</para>
</entry>
<entry valign="middle">
<para>Transmission Control Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>UDP</para>
</entry>
<entry valign="middle">
<para>User Datagram Protocol</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>UTC</para>
</entry>
<entry valign="middle">
<para>Coordinated Universal Time</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>UTF</para>
</entry>
<entry valign="middle">
<para>Unicode Transformation Format</para>
</entry>
</row>
<row>
<entry valign="middle">
<para>EXI</para>
</entry>
<entry valign="middle">
<para>Efficient XML Interchange Format</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section>
</chapter>
<chapter>
<title>Overview</title>
<figure xml:id="_Ref213819468">
<title>Layer structure</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/image2.svg" contentwidth="160.6mm" contentdepth="121.4mm" />
</imageobject>
</mediaobject>
</figure>
<para>This standard defines media streaming options and formats. A distinction is made between <emphasis>media plane </emphasis>and <emphasis>control plane,</emphasis> as illustrated in <xref linkend="_Ref213819468" />. A set of media streaming (audio, video and meta data) options, all based on RTP [RFC 3550], are described in order to provide interoperable media streaming services.</para>
<para>The metadata streaming container format allows well-defined, real-time streaming of analytics, PTZ status and notification data.</para>
<para>Media configuration is done over SOAP/HTTP and is covered by the media configuration service as discussed in Section 4.6. </para>
<para>Media control is accomplished over RTSP as defined in RFC 2326. This standard utilizes RTP, RTCP and RTSP profiling, as well as JPEG over RTP extensions and multicast control mechanisms.</para>
<para>The standard introduces extensions to the RTSP standard to allow bi-directional streaming connections.</para>
<para>Streaming configurations for the following video codecs are provided:</para>
<itemizedlist>
<listitem>
<para>JPEG (over RTP), see <xref linkend="_Ref289166764"/><phrase>.</phrase></para>
</listitem>
<listitem>
<para>MPEG-4, Simple Profile (SP) [ISO 14496-2] </para>
</listitem>
<listitem>
<para>MPEG-4, Advanced Simple Profile (ASP) [ISO 14496-2] </para>
</listitem>
<listitem>
<para>H.264, baseline [ISO 14496-10] </para>
</listitem>
<listitem>
<para>H.264, main [ISO 14496-10] </para>
</listitem>
<listitem>
<para>H.264, extended [ISO 14496-10] </para>
</listitem>
<listitem>
<para>H.264, high [ISO 14496-10] </para>
</listitem>
<listitem>
<para>HEVC [ISO23008-2]</para>
</listitem>
</itemizedlist>
<para>and for the following audio codecs:</para>
<itemizedlist>
<listitem>
<para>G.711 [ITU-T G.711 uLaw]</para>
</listitem>
<listitem>
<para>G.726 [ITU-T G.726]</para>
</listitem>
<listitem>
<para>AAC [ISO 14496-3]</para>
</listitem>
</itemizedlist>
</chapter>
<chapter xml:id="_Toc208657708">
<title>Live Streaming</title>
<para>This section describes real-time streaming of video, audio and metadata. There is <emphasis>no specific </emphasis>service associated with the real-time streaming. The real-time configurations via Web Service commands are defined in the Media Service and the ReceiverService.</para>
<section>
<title>Media stream protocol</title>
<section>
<title>Transport format</title>
<para>Real-time Transport Protocol (RTP) is a media transfer protocol (see Section <xref linkend="_Ref474396811" />). The following four sections describe RTP data transfer.</para>
<section>
<title>RTP data transfer via UDP</title>
<para>UDP has the smallest overhead and is able to transfer real-time data in an efficient manner. A device shall support the RTP/UDP protocol and the device should support RTP/UDP multicasting.</para>
</section>
<section>
<title>RTP/TCP</title>
<para>This optional mode has been deprecated due to ambiguities in the interpretation of the respective RFCs. RTP/TCP protocol is defined in [RFC 4571] and [RFC 4572].</para>
</section>
<section>
<title>RTP/RTSP/TCP</title>
<para>The device should support media transfer using RTP/RTSP to traverse a firewall using an RTSP tunnel. This protocol shall conform to [RFC 2326] Section 10.12 (Embedded [Interleaved] Binary Data).</para>
</section>
<section>
<title>SRTP data transfer via UDP</title>
<para>This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 for transmission and RFC 4567 for key exchange.</para>
</section>
<section xml:id="_Ref213038219">
<title>RTP/RTSP/HTTP/TCP</title>
<para>The data stream shall be sent via HTTP to traverse a firewall. A device shall support media transfer using RTP/RTSP/HTTP/TCP. If a device supports TLS, the data stream shall support transmission via HTTPS to traverse a firewall, and a device shall support media transfer using RTP/RTSP/HTTPS/TCP.</para>
<para>This protocol shall conform to [RFC 2326] Section 10.12.</para>
<para>This traversal method shall conform to [RTSP over HTTP]. Note that according to this specification all data sent from the client via POST must be base64 encoded.</para>
</section>
<section>
<title>RTP/RTSP/TCP/WebSocket</title>
<para>The device indicating support for RTSP over WebSocket, as explained in section 5.11 of the ONVIF Media2 Service Specification and section 5.5 of the ONVIF Replay Control Service Specification, shall support streaming media using WebSocket protocol according to this specification. The provided URI shall set the hierarchical part (hier_part) to absolute path (abs_path) [RFC 2396]. For example, if the WebSocket URI with network path is “ws://1.2.3.4/my-websocket-uri”, the provided URI shall be “ws:/my-websocket-uri”.</para>
<para>For RTSP tunneling over WebSocket a device shall support RTP/RTSP/TCP interleaved binary data as defined in [RFC 2326] Section 10.12.</para>
<para>WebSocket protocol implementation shall conform to [RFC 6455] - The WebSocket Protocol.</para>
<para>The mechanism to be used for establishing a WebSocket connection between a client and server is explained in detail in Section 7.</para>
</section>
</section>
<section xml:id="_Ref474396811">
<title>Media Transport </title>
<section>
<title>RTP</title>
<para>The Real-time Transport Protocol provides real-time transfer for media streams between two end points. The RTP protocol provides support for re-ordering, de-jittering and media synchronization.</para>
<para>All media streams transferred by the RTP protocol shall conform to [RFC 3550], [RFC 3551], [RFC 3984], [RFC 7798], [RFC 3016] or [RFC 3640], and JPEG over RTP (see Section <xref linkend="_Toc214944378" />).</para>
<figure>
<title>RTP header</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/rtpHeader.svg" contentwidth="160mm"/>
</imageobject>
</mediaobject>
</figure>
<para>An RTP header shall be filled up with following values.</para>
<table>
<title>RTP header value</title>
<tgroup cols="3">
<colspec colname="c1" colwidth="28*" />
<colspec colname="c2" colwidth="38*" />
<colspec colname="c3" colwidth="34*" />
<thead>
<row>
<entry>
<para>Header field</para>
</entry>
<entry>
<para>Value</para>
</entry>
<entry>
<para>Description</para>
</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry>
<para>Version (V): 2 bits</para>
</entry>
<entry>
<para>2</para>
</entry>
<entry />
</row>
<row>
<entry>
<para>Padding (P): 1 bit</para>
</entry>
<entry>
<para>0/1</para>
</entry>
<entry>
<para>If the payload includes padding octet, this should be set to “1”</para>
</entry>
</row>
<row>
<entry>
<para>Extension (X): </para>
<para>1 bit</para>
</entry>
<entry>
<para>0/1</para>
</entry>
<entry>
<para>Depends on the use of extension of RTP header. The specification defines two scenarios where a RTP header extension could be used to transmit additional information:</para>
<para>1) “JPEG over RTP” (see Section <xref linkend="_Toc214944378" />).</para>
<para>2) Replay (see Section <xref linkend="_Ref279441431" />)</para>
<para>If the header extension is used the Extension bit shall be set. </para>
</entry>
</row>
<row>
<entry>
<para>CSRC count (CC): </para>
<para>4 bits</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry />
</row>
<row>
<entry>
<para>Marker (M): </para>
<para>1 bit</para>
</entry>
<entry>
<para>0/1</para>
</entry>
<entry>
<para>The usage shall be conform to related RFCs (e.g. [RFC 3984] for H.264 Video) or to this standard e.g “JPEG over RTP” (see Section <xref linkend="_Toc214944378" />) or RTP streaming of metadata (see Section <xref linkend="_Ref213223702" />).</para>
</entry>
</row>
<row>
<entry>
<para>Payload type (PT): </para>
<para>7 bits</para>
</entry>
<entry>
<para>See [RFC 3551] Section 6.</para>
</entry>
<entry />
</row>
<row>
<entry>
<para>Sequence Number: </para>
<para>16 bits</para>
</entry>
<entry />
<entry>
<para>The initial value of the “sequence number” should be random (unpredictable) to make known-plaintext attacks on encryption more difficult.</para>
<para>This number increments by one for each RTP data packet sent</para>
</entry>
</row>
<row>
<entry>
<para>timestamp: </para>
<para>32 bits</para>
</entry>
<entry />
<entry>
<para>The initial value of the “timestamp” should be random (unpredictable) to make known-plaintext attacks on encryption more difficult.</para>
<para>See Section <xref linkend="_Toc208657714" /> for further details of Media Synchronization. </para>
<para>The usage of the timestamp is <phrase>dependent</phrase> on the codec.</para>
</entry>
</row>
<row>
<entry>
<para>SSRC</para>
<para>32 bits</para>
</entry>
<entry />
<entry>
<para>The synchronization source for the data stream. This specification makes no restrictions on the use of this field.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<section xml:id="_Ref213223702">
<title>RTP for Metadata stream</title>
<para>Metadata streams are also transported by RTP. The usage of payload type, marker and timestamp for RTP header for the metadata stream is defined in the following way:</para>
<itemizedlist>
<listitem>
<para>A dynamic payload type (96-127) shall be used for payload type which is assigned in the process of a RTSP session setup.</para>
</listitem>
<listitem>
<para>The RTP marker bit shall be set to “1” when the XML document is closed. </para>
</listitem>
<listitem>
<para>It is RECOMMENDED to use an RTP timestamp representing the creation time of the RTP packet with a RTP clock rate of 90000 Hz. Only UTC timestamps shall be used within the metadata stream. The synchronization of video and audio data streams is done using RTCP.</para>
</listitem>
</itemizedlist>
<para>The Metadata payload is an XML document with root node <literal>tt:MetaDataStream</literal>. There is no limitation on the size of the XML document. If GZIP compression is used, the payload starts with a GZIP header according to RFC 1952 followed by the compressed data. A marker bit signals the end of the compressed data. When a synchronization point (see section “Synchronization Points” of the ONVIF Media Service Specification) is requested for the stream, the previous XML document shall be closed and a new one started. It is RECOMMENDED to start new XML documents after 1 second, at the longest. The RTP timestamp of the Metadata stream has no specific meaning. The Metadata stream multiplexes Metadata from different sources. This specification defines placeholders for the Scene Description of the Video Analytics, the PTZ Status of the PTZ controller and the Notifications of the Event Configuration. A device can select which of these parts should be multiplexed into the Metadata during the Media Configuration (see seciont “Metadata Configuration” of the ONVIF Media Service Specification). Each part can appear multiple times in arbitrary order within the document. A Metadata connection can be bi-directional using the backchannel mechanism (see Section <xref linkend="_Ref231788974" />). </para>
<para>Metadata stream contains the following elements:</para>
<itemizedlist>
<listitem>
<para>VideoAnalyticsStream</para>
</listitem>
<listitem>
<para>PTZStream</para>
</listitem>
<listitem>
<para>EventStream</para>
</listitem>
</itemizedlist>
<para>The place-holders for the different metadata sources have the following XMLstructure:</para>
<programlisting><![CDATA[<xs:complexType name="VideoAnalyticsStream">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Frame" type="tt:Frame"/>
...
</xs:choice>
</xs:complexType>
<xs:complexType name="PTZStream">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="PTZStatus" type="tt:PTZStatus"/>
...
</xs:choice>
</xs:complexType>
<xs:complexType name="EventStream">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="wsnt:NotificationMessage"/>
...
</xs:choice>
</xs:complexType>
]]></programlisting>
<para>Note: For a PTZ supported device, the PTZStream in metadata provides the PTZ position information, whenever there is a change in the PTZ position, whereas PTZStatus defined inside VideoAnalyticsStream, provides PTZ position information at the time of generating scene description.</para>
<para>The following is an example of a metadata XML document:</para>
<programlisting><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<tt:MetadataStream xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:VideoAnalytics>
<tt:Frame UtcTime="2008-10-10T12:24:57.321">
...
</tt:Frame>
<tt:Frame UtcTime="2008-10-10T12:24:57.621">
...
</tt:Frame>
</tt:VideoAnalytics>
</tt:MetadataStream>
<?xml version="1.0" encoding="UTF-8"?>
<tt:MetadataStream xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:Event>
<wsnt:NotificationMessage>
<wsnt:Message>
<tt:Message UtcTime= "2008-10-10T12:24:57.628">
...
</tt:Message>
</wsnt:Message>
</wsnt:NotificationMessage>
</tt:Event>
</tt:MetadataStream>
]]></programlisting>
</section>
</section>
<section>
<title>RTCP</title>
<para>The RTP Control Protocol provides feedback on quality of service being provided by RTP and synchronization of different media streams. The RTCP protocol shall conform to [RFC 3550]. </para>
<para>For a feedback request, [RFC 4585] and [RFC 5104] should be supported.</para>
<figure>
<title>RTCP sequence</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/image3.svg" contentwidth="104.8mm" contentdepth="89.4mm" />
</imageobject>
</mediaobject>
</figure>
<section xml:id="_Toc208657714">
<title>Media synchronization</title>
<para>A client MAY receive audio and video streams simultaneously from more than one device. In this case, each stream uses a different clock (from data acquisition to packet receiving). RTCP Sender Reports (SR) are used to synchronize different media streams. RTCP SRs shall conform to [RFC 3550]. </para>
<para>The RTCP Sender Report (SR) packet has fields for the RTP timestamp and for a wall clock timestamp (absolute date and time, 64bit NTP [Network Time Protocol]). See <xref linkend="_Ref213211787" />.</para>
<para>A device shall support RTCP Sender Report for media synchronization. The client should use RTCP for the media synchronization. </para>
<figure xml:id="_Ref213211787">
<title>RTCP Sender Report</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/senderReport.svg" contentwidth="160mm"/>
</imageobject>
</mediaobject>
</figure>
<para>The wall clock should be common in the device and each timestamp value should be determined properly. The client can synchronize different media streams at the appropriate timing based on the RTP clock and wall clock timestamps (see <xref linkend="_Ref213211876" />).</para>
<para>In case of multiple devices, the NTP timestamp should be common to all devices, and the NTP server should be required in the system <footnote xml:id="__FN1__"><para>The client can get information about “NTP server availability” from the devices by using the GetNTP command. Refer to Section 8.2.5</para></footnote>.</para>
<figure xml:id="_Ref213211876">
<title>Media Synchronization</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/image4a.svg" contentwidth="150mm" contentdepth="67.1mm" />
</imageobject>
</mediaobject>
</figure>
</section>
</section>
</section>
<section xml:id="_Toc214944378">
<title>Synchronization Point</title>
<para>Synchronization points allow clients to decode and correctly use data after the synchronization point. A synchronization point MAY be requested by a client in case of decoder error (e.g. in consequence of packet loss) to enforce the device to add an I-Frame as soon as possible or to request the current ptz or event status.</para>
<para>The WebService based methods require to support the Synchronization Point request as defined in the section “Synchronization Point” of the ONVIF Media Service Specification. </para>
<para>In addition it is recommended to support the PLI messages as described in [RFC 4585] in order to allow receivers as defined in the ONVIF Receiver Service Specification to request a Synchronization Point. </para>
<para>For H.264 and H.265 Video the SPS/PPS header shall be sent in-band if these have been changed during the transmission.</para>
</section>
<section xml:id="_Ref289166764">
<title>JPEG over RTP</title>
<section>
<title>Overall packet structure</title>
<para>The syntax for transmitting JPEG streams follows [RFC 2435]. The syntax does allow embedding additional data, beyond the limits of [RFC 2435], by using an optional RTP header extension, as specified below, with some of the RTP packets. This option, however, changes the exact semantics for frames which include such packets.</para>
<para>The overall format of the JPEG RTP packet is shown in <xref linkend="_Ref213213069" />.</para>
<figure xml:id="_Ref213213069">
<title>RTP/JPEG packet structure (only the typical content is listed for the extension payload)</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/image4.svg" contentwidth="168.3mm" contentdepth="108.5mm" />
</imageobject>
</mediaobject></figure>
<para>In order to distinguish an optional RTP header extension from possible other header extensions, the first 16 bits (the first two octets of the four-octet extension header) of an RTP shall have the value <literal>0xFFD8</literal> (JPEG SOI marker) for the initial packet and <literal>0xFFFF</literal> for other RTP packets within a frame.</para>
<para>As required by [RFC 3550], the presence of the optional header extension shall be signalled via the X-bit of the RTP header. The extension length field within the header extension counts the number of 32-bit items following as extension payloads. For example, a zero-length field following the 32-bit extension header represents an empty header extension).</para>
<para>The entropy-encoded scan data section MAY not be present in all RTP packets. A complete RTP/JPEG header however shall be present in the initial packet of every frame and all packets containing an entropy-encoded scan data section, otherwise it MAY be missing.</para>
<para>The fragment offset field within the RTP/JPEG header, according to [RFC 2435], should be used as if no header extension would be present. Additionally, if a packet does not contain an entropy-encoded scan data segment, but contains a header extension the fragment offset field shall not be zero if any packets containing an entropy-encoded scan data section for the same frame have been transmitted. If the initial packet of a frame contains no header extension, according to this standard, its fragment offset field shall be zero, otherwise it should be zero. All packets including an RTP/JPEG header with a fragment offset of zero and a Q value between 128-255 shall include a quantization table header according to Section 3.1.8 of [RFC 2435], other packets shall NOT include this header.</para>
</section>
<section>
<title>Logical decoding specification</title>
<para>For the decoding specification, it is assumed that the original packet order within the RTP stream has been restored according to the RTP sequence numbering.</para>
<para>If the initial packet of a frame contains no RTP header extension as specified above, decoders shall generate the complete scan header and perform the decoding as specified by [RFC 2435]. The scan data sections and payloads of any header extension conforming to this specification, up to and including the next RTP packet with its marker bit set, shall be concatenated as they occur within the stream ignoring their fragment offset values. </para>
<para>Otherwise (at least an empty header extension as specified above is present in the initial packet of a frame), the following rules apply for each such frame:</para>
<itemizedlist>
<listitem>
<para>If the initial packet of a frame does not contain an entropy-encoded scan data segment, but contains a header extension as specified above, then decoders shall concatenate its header extension payload with (possibly empty or not existing) header extension payload(s) conforming to this specification of the subsequent packets up to and including the first packet with the RTP marker bit set or containing an entropy-encoded scan data segment.</para>
</listitem>
<listitem>
<para>The concatenated initial RTP header extension payload (sequence) shall be logically prepended with a JPEG SOI marker (0xFFD8). </para>
</listitem>
<listitem>
<para>If the Q-value of the RTP/JPEG scan header within the initial packet of a frame is not zero, the quantization tables shall be pre-initialized according to the rules of [RFC 2435]. If Q is equal to zero the quantization tables shall be copied from the previous frame, allowing for DQT markers within this initial header extension payload (sequence) to override them. </para>
</listitem>
<listitem>
<para>If this frame is the initial frame of a sequence, the Huffman tables shall be pre-initialized according to [RFC 2435]. The Huffman tables for all subsequent frames shall be copied from the previous frame, allowing the frames to be overridden by DHT markers within the initial header extension payload (sequence). </para>
</listitem>
<listitem>
<para>If the initial RTP header extension payload (sequence) supplies no DRI marker, but the RTP/JPEG header of the initial packet of a frame contains an RTP/JPEG restart marker, a DRI marker corresponding to the rules of [RFC 2435] shall be appended to the initial header extension payload (sequence). Otherwise, if the initial RTP header extension (sequence) supplies a DRI marker, the marker shall take precedence over any other RTP/JPEG restart marker according to [RFC 2435] for the same frame. However, for compatibility with decoders conforming to [RFC 2435] only, encoders normally should use an RTP/JPEG restart marker with consistent values, if restart intervals are to be used.</para>
</listitem>
<listitem>
<para>DRI markers shall NOT be derived from previous frames.</para>
</listitem>
<listitem>
<para>If the initial RTP header extension payload (sequence) supplies no SOF marker, which otherwise takes precedence, a SOF marker shall be appended to it with the following values: </para>
<itemizedlist>
<listitem>
<para>If both the width and height field of the RTP/JPEG header are zero, the SOF marker of the previous frame shall be used. </para>
</listitem>
<listitem>
<para>Otherwise it shall be derived according to the rules of [RFC 2435].</para>
</listitem>
</itemizedlist>
<para>However, as long as the (rounded up) image size fits within the range as specified in [RFC 2435], encoders should specify the image size within the RTP/JPEG header consistent with the values of an additional SOF header.</para>
</listitem>
<listitem>
<para>If the initial header extension payload (sequence) supplies no SOS marker, a corresponding marker shall be derived according to [RFC 2435] and appended to it, otherwise the SOS marker in the extension takes precedence.</para>
<para>An SOS marker shall NOT be derived from previous frames.</para>
<para>If the SOS marker is present and not followed by entropy-encoded scan data within the extension, the marker shall be the final marker within the initial extension payload (sequence) of a frame. Necessary padding with 0xFF-octets shall NOT follow this marker but MAY precede it.</para>
</listitem>
<listitem>
<para>The remaining entropy-encoded scan data and header extensions payloads shall be logically appended in the same order as they occur within the RTP stream up to the end of the frame as indicated by the RTP marker bit. A final EOI marker shall also be added if it is not yet present within the logical sequence for this frame,.</para>
<para>For each frame, the resulting sequence up to and including the first (possibly added) EOI marker shall be a valid (possibly abbreviated) JPEG stream, resulting in one complete image from the decoding process for this frame. The meaning of any data after this first EOI marker for each frame is outside the scope of this specification.</para>
</listitem>
</itemizedlist>
<para>Implementations should provide for each frame the complete JPEG headers. This holds especially for the width and height information as well as the quantization and Huffman tables. If such important information is not provided for each frame, both playback and multicast streaming may suffer from incomplete JPEG header information.</para>
</section>
<section>
<title>Supported colour spaces and sampling factors</title>
<para>A Transmitter should use only greyscale and YCbCr colour space. A Client shall support both greyscale and YcbCr.</para>
<para>The sampling factors for YcbCr shall correspond to the values supported by [RFC 2435]. For example, a sampling factor of 4:2:0 (preferred) or 4:2:2.</para>
</section>
<section>
<title>Pixel aspect ratio handling</title>
<para>The pixel aspect ratio of JPEG files can be specified within the JFIF marker. If the pixel aspect ratio is different from the standard 1:1 and 1:2 ratio according to [RFC 2435], this marker should be transmitted in the initial header extension payload (sequence) of every frame to specify the (for interlaced material field-based) pixel aspect ratio.</para>
</section>
<section>
<title>Interlaced handling</title>
<para>Interlaced video is encoded as two independent fields and signalled as specified by [RFC 2435] within the RTP/JPEG header.</para>
<para>Both fields shall use the same colour space, sampling factors and pixel aspect ratio.</para>
<para>Interlaced encoding should NOT be used if the frame was originally scanned progressively.</para>
</section>
</section>
</section>
<section>
<title>Media control protocol</title>
<section>
<title>Stream control</title>
<para>The media stream is controlled using the protocol defined in the URI. The URI is returned in response to the GetStreamUri command defined in the ONVIF Media Service Specification.</para>
<figure>
<title>Stream Control</title>
<mediaobject>
<imageobject>
<imagedata fileref="media/Streaming/image5a.svg" contentwidth="151mm" contentdepth="120.7mm" />
</imageobject>
</mediaobject>
</figure>
</section>
<section>
<title>RTSP</title>
<section>
<title>General</title>
<para>All devices and clients shall support RTSP ([RFC 2326]) for session initiation and playback control. RTSP shall use TCP as its transport protocol, the default TCP port for RTSP traffic is 554. The Session Description Protocol (SDP) shall be used to provide media stream information and SDP shall conform to [RFC 4566].</para>
<table>
<title>RTSP methods.</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="21*" />
<colspec colname="c2" colwidth="10*" />
<colspec colname="c3" colwidth="11*" />
<colspec colname="c4" colwidth="58*" />
<thead>
<row>
<entry valign="middle">
<para>Method</para>
</entry>
<entry valign="middle">
<para>Direction</para>
</entry>
<entry valign="middle">
<para>SPEC<footnote xml:id="__FN2__"><para><superscript>X: Not supported, M: Mandatory, O: Optional</superscript></para></footnote></para>
</entry>
<entry>
<para>Description </para>
</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry valign="middle">
<para>OPTIONS</para>
</entry>
<entry valign="middle">
<para>R->T T->R</para>
</entry>
<entry valign="middle">