2012年6月13日 星期三

ONVIF Core Streaming 心得


ONVIF是一個定義網路影像監控系統的國際標準組織,ONVIF-Streaming-Spec-v211 則介紹網路影像監控系統上的串流機制,包含如何封裝 JPEG/RTP,並針對 RTSP 的控制作了幾個功能擴充,此篇會針對 Streaming-Spec 作一基本介紹。



基本知識

此 spec 建議 RTP clock rate 使用 90000 Hz,因此當 frame=1/30時,兩個frame之間的timestamp差應該為3000,因為 3000/90000=1/30。


JPEG over RTP (RFC2435)

JPEG over RTP 採用 RTP extension,有其特殊格式,由於一張圖可能會切割成多個封包傳送,因此對一個Frame而言,第一個封包的前16個bits是0xFFD8,其他封包的前16個bits是0xFFFF。


串流控制行為的定義

1. Keep-alive method for RTSP session
  • 預設的 timeout 時間為 60 秒, client可以更改此值,使用Set<configurationEntity>EncoderConfiguration。
  • 每次 client 送出 SETUP,伺服器的回應訊息便可以記錄 timeout 的秒數
  • client端在時間 timeout 之前,要與Server進行RTSP的溝通,以保持此session alive,建議方式是透過傳送 SET_PARAMETER。
 
2. RTSP Audio and Video Synchronization

  • 伺服器收到PLAY之後,回應訊息內應該包含 "Range",ONVIF 規定此處應該用來記錄開始時間,而不使用 SMPTE 或 NPT單位。
  • RTP-Info則是定義相對於開始時間的rtptime
  • 舉例如下:

client->server: PLAY rtsp://example.com/onvif_camera/video RTSP/1.0
CSeq: 4
Range: npt=now-
Session: 12345678 
server->client: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
Range: clock=20100217T143720.257Z-
RTP-Info: url=rtsp://example.com/onvif_camera/video; seq=1234;rtptime=3450012  

3. metadata

  • RTSP server 回應 DESCRIBE 時,應該註明支援 "vnd.onvif.metadata"

client->server: DESCRIBE rtsp://example.com/onvif_camera RTSP/1.0
CSeq: 1
server->client: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: XXX
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://example.com/onvif_camera /audio
m=video 0 RTP/AVP 26
a=control:rtsp://example.com/onvif_camera /video
m=application 0 RTP/AVP 107
a=control:rtsp://example.com/onvif_camera/metadata
a=recvonly
a=rtpmap
a=rtpmap:107 vnd.onvif.metadata/90000

4. multicast
若支援 multicast,Describe回應中應該利用"c="設定 multicast address。RFC2326定義可以設定為 0.0.0.0,但是ONVIF不使用此值。以 IPv4 而言,可以使用的 ip位址,其prefix為 224.0.0.0/4。這表示32位元位址的前四個位元固定不變,也就是可設定的值域為 224.0.0.0 to 239.255.255.255。 
注意:IP 與 MAC address 的對應,則需要以"32比1" 的方式 (28位元放入23位元),這與 IP Multicast 的發展有關,請參考這篇

擴充功能

此份規格會擴充兩個 RTSP 功能:BackChannel 與 Replay

Back Channel Connection

定義RTSP的功能擴充,利用"Require" Tag 建立RTSP雙向的連線(傳送聲音或是metadata)。
例如:可以由client將聲音傳送給 ip camera??

實作方式:

1. 兩端設備的 AudioOutputs 能力,需要能判別 "www.onvif.org/ver20/backchannel"

  • Client 送出 DESCRIBE 時需包含此值。
  • Server 收到此值後,需要在SDP內針對 Media Profile加入新增的欄位。
  • 若是 Server 不支援 backchannel,則回復 551。
  • Client可以重新送出沒有backchannel功能的Describe。

2. Server端的 SDP 要註明此 Media Profile 是 sendonly 或 readonly

3. 例子說明:不支援backchannel
Client – Server: DESCRIBE rtsp://192.168.0.1 RTSP/1.0
CSeq: 1
User-Agent: ONVIF Rtsp client
Accept: application/sdp
Require: www.onvif.org/ver20/backchannel 
Server – Client: RTSP/1.0 551 Option not supported
CSeq: 1
Unsupported: www.onvif.org/ver20/backchannel

4.  例子說明:支援backchannel,允許client可送出聲音給Server
Client – Server: DESCRIBE rtsp://192.168.0.1 RTSP/1.0
CSeq: 1
User-Agent: ONVIF Rtsp client
Accept: application/sdp
Require: www.onvif.org/ver20/backchannel
Server – Client: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: xxx
v=0
o= 2890842807 IN IP4 192.168.0.1
s=RTSP Session with audiobackchannel
m=video 0 RTP/AVP 26
a=control:rtsp://192.168.0.1/video
a=recvonly
m=audio 0 RTP/AVP 0
a=control:rtsp://192.168.0.1/audio
a=recvonly
m=audio 0 RTP/AVP 0
a=control:rtsp://192.168.0.1/audioback
a=rtpmap:0 PCMU/8000
a=sendonly

Playback

擴充 RTSP 功能,以支援 Replay 功能。

Server應支援 RTP/UDP Streaming,並且針對replay的行為,可以省略RTCP的傳送動作。
Client應該選擇 TCP 來傳送Replay的封包,

作法:

1. SDP 內加入 "a:x-onvif-track:<TrackReference>",例如:
NVS – NVT: DESCRIBE rtsp://192.168.0.1 RTSP/1.0
CSeq: 1
User-Agent: ONVIF Rtsp client
Accept: application/sdp
NVT – NVS: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: xxx
v=0
o= 2890842807 IN IP4 192.168.0.1
m=video 0 RTP/AVP 26
a=control:rtsp://192.168.0.1/video
a=x-onvif-track:VIDEO001
m=audio 0 RTP/AVP 98
a=control:rtsp://192.168.0.1/audio
a=x-onvif-track:AUDIO001

2. 擴充 RTP Header,加入新的 header,extension ID=0xABAC,其中包含 NTP timestamp等資訊。如下圖

3. 需要利用"require" tag,並且在 Setup 與 Play時加以判斷。例如:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Require: onvif-replay

4. 利用 "Scale" 來操作 forward replay 或 reverse replay,其中
 "Scale: 1.0"表示forward,"Scale: -1.0"表示reverse。

5. 此時 "Range" 的值,只有一種用法,當成絕對時間。例如:
PLAY rtsp://192.168.0.1/path/to/recording RTSP/1.0
CSeq: 123
Session: 12345678
Require: onvif-replay
Range: clock=20090615T115000.440Z-20090615T114900Z
Rate-Control: no
Scale: -1.0
6. Rate-Control
若沒有設定,預設值為 "yes",
此時封包會根據RTP標準計時方式,在正確的播放時間抵達client,
例如:1/30FPS,就固定1/30秒送出一個frame。
若是 "no",則會儘快的傳送 (delivered as fast as possible)
The important difference between these two modes is that with “Rate-Control=yes”, the server is in control of the playback speed, whereas with “Rate-Control=no” the client is in control of the playback speed. Rate-controlled replay will typically only be used by non-ONVIF specific clients as they will not specify “Rate-Control=no”.

The use of RTP timestamps depends on the value of the Rate-Control header. If the value of this header is “no” (i.e. the client controls playback speed), the RTP timestamps are derived from the original sampling times of the recorded frames. If the Rate-Control header is not present or has the value “yes” (i.e. the server controls playback speed), the RTP timestamps correspond to playback timing as described in [RFC 2326] Appendix B.


7. Frames header
利用 Frames 減少傳送的 frame 數,以降低頻寬或系統負載。有三種選項
  • Intra frames only:只送I Frame。"Frames: intra"
  • Intra frames and predicted frames only:只送 I frame與 P frame,不送 B frame。"Frames: predicted"
  • All frames:此為預設值。"Frames: all"

8. Reverse Replay
During reverse playback, GOPs shall be sent in reverse order, but packets within a GOP shall be sent in forward order

9. 新增 immediate header
If the server receives a PLAY command with the Immediate header set to “yes”, it will immediately start playing from the new location, cancelling any existing PLAY command. The first packet sent from the new location shall have the D (discontinuity) bit set in its RTP extension header.
PLAY rtsp://192.168.0.1/path/to/recording RTSP/1.0
CSeq: 123
Session: 12345678
Require: onvif-replay
Range: clock=20090615T114900.440Z-
Rate-Control: no
Immediate: yes
 
參考資料

  1. ONVIF-Streaming-Spec-v211
  2. RFC2435, RFC2326
  3. http://zh.wikipedia.org/wiki/圖像群組