Wikipedia

Khác biệt giữa bản sửa đổi của “Real Time Streaming Protocol”

Duyệt lịch sử tương tác
← Thay đổi trướcThay đổi sau →
Nội dung được xóa Nội dung được thêm vào
Trực quanMã wiki
Unicodifying using AWB
n replaced: ( → ( (13), ) → ) (11), . → ., , → ,, ; → ; (83), môt → một using AWB
Dòng 79:
"RTSP" và "RTSPu" dùng để chỉ các tài nguyên mạng thông qua giao thức RTSP. Phần này quy định cụ thể cú pháp và ngữ nghĩa cho RTSP URLs.
 
rtsp_URL  =   ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
 
Host      =   <A legal Internet host domain name of IP address
Dòng 105:
Session identifiers là một chuỗi độ dài tùy ý không xác định. Session identifiers được lựa chọn ngẫu nhiên và phải có ít nhất là tám octet làm cho phỏng đoán khó khăn hơn.
 
session-id   =   1*( ALPHA | DIGIT | safe )
 
==== [null E.   SMPTE RELATIVE TIMESTAMPS] ====
Dòng 137:
NPT được định nghĩ trong DSM-CC: "Theo trực giác NPT là đồng hồ liên kết trình xem với một chương trình thường kỹ thuật số hiển thị trên một VCR. NPT cải tiến bình thường khi ở chế độ chơi bình thường (quy mô = 1), tiến bộ nhanh hơn. NPT (logic) tương đương với mã thời gian SMPTE. "
 
npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
 
npt-time     =   "now" | npt-sec | npt-hhmmss
Dòng 168:
utc-date     =   8DIGIT                    ; < YYYYMMDD >
 
utc-time     =   6DIGIT [ "." fraction ]   ; < HHMMSS.fraction >
 
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
Dòng 213:
Ngoại trừ tiêu đề Pragma, Transfer-Encoding và Upgrade headers chưa được xác định:
 
general-header     =     Cache-Control     ; Section 12.8
 
|     Connection        ; Section 12.10
 
|     Date              ; Section 12.18
 
|     Via               ; Section 12.43
 
==== [null K.  REQUEST] ====
Tin nhắn yêu cầu từ một client đến một máy chủ hoặc ngược lại bao gồm, trong dòng đầu tiên của tin nhắn đó, phương pháp này được áp dụng cho các nguồn tài nguyên, nhận dạng của tài nguyên, và phiên bản giao thức được sử dụng.
 
Request      =       Request-Line          ; Section 6.1
 
<nowiki>*</nowiki>(      general-header        ; Section 5
 
|       request-header        ; Section 6.2
 
|       entity-header )       ; Section 8.1
 
CRLF
 
[ message-body ]      ; Section 4.3
 
==== [null L.   REQUEST LINE] ====
Request-Line = Method SP Request-URI SP RTSP-Version CRLF.
 
Method         =         "DESCRIBE"              ; Section 10.2
 
|         "ANNOUNCE"              ; Section 10.3
 
|        "GET_PARAMETER"        ; Section 10.8
 
|         "OPTIONS"               ; Section 10.1
 
|         "PAUSE"                 ; Section 10.6
 
|         "PLAY"                  ; Section 10.5
 
|         "RECORD"                ; Section 10.11
 
|         "REDIRECT"              ; Section 10.10
 
|         "SETUP"                 ; Section 10.4
 
|        "SET_PARAMETER"        ; Section 10.9
 
|         "TEARDOWN"              ; Section 10.7
 
|         extension-method
Dòng 278:
Sau khi tiếp nhận và phiên dịch một tin nhắn yêu cầu, người nhận trả lời bằng một tin nhắn phản hồi RTSP.
 
Response    =     Status-Line         ; Section 7.1
 
<nowiki>*</nowiki>(    general-header      ; Section 5
 
|     response-header     ; Section 7.1.2
 
|     entity-header )     ; Section 8.1
 
CRLF
 
[ message-body ]    ; Section 4.3
 
==== [null N.  STATUS-LINE] ====
Dòng 297:
'''''Status Code and Reason Phrase'''''
 
Status-Code có 3-digit số nguyên để hiểu và đáp ứng yêu cầu. Các mã được xác định đầy đủ trong Phần 11. Reason-Phrase được thiết kế để cung cấp cho một mô tả ngắn văn bản của Status-Code . Status-Code  được thiết kế để sử dụng automata và Reason-Phrase chỉ dành cho người dùng. Khách hàng không cần thiết kiểm tra hoặc hiển thị Reason-Phrase.
 
Status-Code  =     "100"      ; Continue
 
|     "200"      ; OK
 
|     "201"      ; Created
 
|     "250"      ; Low on Storage Space
 
|     "300"      ; Multiple Choices
 
|     "301"      ; Moved Permanently
 
|     "302"      ; Moved Temporarily
 
|     "303"      ; See Other
 
|     "304"      ; Not Modified
 
|     "305"      ; Use Proxy
 
|     "400"      ; Bad Request
 
|     "401"      ; Unauthorized
 
|     "402"      ; Payment Required
 
|     "403"      ; Forbidden
 
|     "404"      ; Not Found
 
|     "405"      ; Method Not Allowed
 
|     "406"      ; Not Acceptable
 
|     "407"      ; Proxy Authentication Required
 
|     "408"      ; Request Time-out
 
|     "410"      ; Gone
 
|     "411"      ; Length Required
 
|     "412"      ; Precondition Failed
 
|     "413"      ; Request Entity Too Large
 
|     "414"      ; Request-URI Too Large
 
|     "415"      ; Unsupported Media Type
 
|     "451"      ; Parameter Not Understood
 
|     "452"      ; Conference Not Found
 
|     "453"      ; Not Enough Bandwidth
 
|     "454"      ; Session Not Found
 
|     "455"      ; Method Not Valid in This State
 
|     "456"      ; Header Field Not Valid for Resource
 
|     "457"      ; Invalid Range
 
|     "458"      ; Parameter Is Read-Only
 
|     "459"      ; Aggregate operation not allowed
 
|     "460"      ; Only aggregate operation allowed
 
|     "461"      ; Unsupported transport
 
|     "462"      ; Destination unreachable
 
|     "500"      ; Internal Server Error
 
|     "501"      ; Not Implemented
 
|     "502"      ; Bad Gateway
 
|     "503"      ; Service Unavailable
 
|     "504"      ; Gateway Time-out
 
|     "505"      ; RTSP Version not supported
 
|     "551"      ; Option not supported
 
|     extension-code
Dòng 397:
Response-header fields cho phép bên nhận yêu cầu thông qua thông tin bổ sung đáp ứng không thể được đặt trong Status-Line. Những header fields cung cấp thông tin về máy chủ và truy cập tài nguyên được xác định bởi các-Request URI.
 
response-header  =     Location             ; Section 12.25
 
|     Proxy-Authenticate   ; Section 12.26
 
|     Public               ; Section 12.28
 
|     Retry-After          ; Section 12.31
 
|     Server               ; Section 12.36
 
|     Vary                 ; Section 12.42
 
|     WWW-Authenticate     ; Section 12.44
 
==== [null O.  ENTITY] ====
Dòng 420:
Entity Header Fields xác định metainformation tùy chọn về entity-body, hoặc không có mặt, các nguồn tài nguyên được xác định theo yêu cầu.
 
entity-header       =    Allow               ; Section 12.4
 
|    Content-Base        ; Section 12.11
 
|    Content-Encoding    ; Section 12.12
 
|    Content-Language    ; Section 12.13
 
|    Content-Length      ; Section 12.14
 
|    Content-Location    ; Section 12.15
 
|    Content-Type        ; Section 12.16
 
|    Expires             ; Section 12.19
 
|    Last-Modified       ; Section 12.24
 
|    extension-header
Dòng 464:
 
==== 4.    Định nghĩa các thông điệp ====
Để thực hiện kỹ thuật streaming video theo giao thức RTSP nhất thiết máy client phải gửi lên máy server ( streaming server) những request sau và phải theo một trình tự nhất định
 
==== [null -           OPTIONS] ====
Dòng 486:
 
==== [null -           DESCRIBE] ====
Nếu máy server trả về mã chấp nhận đường link trên thì máy client tiếp tục gửi yêu cầu DESCRIBE tới máy server để máy server phân tích đường link. Một yêu cầu DESCRIBE bao gồm một đường link RTSP có dạng (rtsp:// ) và kiểu dữ liệu đáp trả từ phía server. Cổng mặc định được sử dụng cho giao thức RTSP là 554 và cổng này được sử dụng cho cả giao thức của tầng giao vận UDP và TCP. Thông điệp đáp lại từ máy server cho yêu cầu DESCRIBE của máy client bao gồm bản tin miêu tả chi tiết phiên giao dịch (Session Description Protocol – SDP). Ngoài ra trong thông điệp trả về từ máy server còn liệt kê các đường link thích hợp hơn tới file video cần chơi khi mà trong file video đó có trộn lẫn giữa phụ đề và âm thanh. Và điều quan trọng nhất ở trong bản tin miêu tả phiên giao dịch này là streamid của luồng video và streamid của luồng âm thanh khi mà đoạn video đó có lồng âm thanh vào trong các frame.
 
Example:
Dòng 580:
 
==== [null -        SETUP] ====
Sau khi máy client nhận được thông điệp đáp trả từ máy server sau yêu cầu DESCRIPTION thì máy client sẽ tiếp tục gửi tiếp yêu cầu SETUP tới máy server. Một yêu cầu SETUP sẽ chỉ ra cách mà một dòng dữ liệu ( single media stream ) bắt buộc phải được truyền đi như thế nào. Và yêu cầu SETUP bắt buộc phải được hoàn thành trước khi một yêu cầu PLAY được gửi từ máy client. Yêu cầu SETUP bao gồm một đường link tới file video cần streaming và một thông tin đặc tả cho phần giao vận. Đặc tả này bao gồm 2 cổng trong đó có một cổng cục bộ trên máy client dành cho việc nhận cac gói tin RTP (audio và video) và cổng còn lại dùng để nhận các gói tin RTCP ( meta information ).  Máy server sẽ đáp trả lại bằng các xác nhận các tham số đã được lựa chọn, và điền vào các phần còn thiếu ví dụ như máy server có thể chọn lại cổng của mình. Mỗi luồng dữ liệu sẽ được cấu hình cụ thể sau khi yêu cầu SETUP được hoàn tất trước khi máy client gửi yêu cầu PLAY.
 
Example:
Dòng 599:
 
==== [null -        PLAY] ====
Sau khi hoàn tất yêu cầu SETUP, cấu hình được các luồng dữ liệu để chuẩn bị streaming, máy client sẽ gửi yêu cầu PLAY để thực hiện truyền các frame dữ liệu thật sự từ máy server tới máy client , và các frame dữ liệu này sẽ được lưu trong một bộ đệm của máy client, các frame này sẽ được giải mã ( decode ), rồi được hiển thị bởi trình chơi file video và âm thanh ( VLC). Yêu cầu PLAY bao gồm một đường dẫn trỏ tới file video cần phát giống như các yêu cầu trước đó. Đường link này có thể là đường tổng hợp ( để phát các luồng dữ liệu) hoặc là môtmột đường link đơn lẻ ( chỉ phát một luồng dữ liệu duy nhất ). Trong yêu cầu PLAY, máy client cũng sẽ chỉ ra một dải ( range) chỉ rõ một cách cụ thể số hiệu frame bắt đầu được gửi và số hiệu frame kết thúc, Nếu như không chỉ rõ tham số này, thì toàn bộ các frame sẽ được gửi tới máy client. Và nếu như luồng dữ liệu có bị tạm dừng ( pause) thì luồng dữ liệu này cũng sẽ được phục hồi ở frame mà nó tạm dừng truyền.
 
Example:
Lấy từ “https://vi.wikipedia.org/wiki/Real_Time_Streaming_Protocol”