Kỹ thuật truyền dòng dữ liệu và ứng dụng trong truyền thông dữ liệu video audio

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

Báo Cáo

Truyền Thông Đa Phương Tiện
ĐỀ TÀI

: Kỹ thuật truyền dòng dữ liệu và ứng dụng

trong
truyền thông dữ liệu video-audio.
GV Hướng Dẫn : PGS.TS Nguyễn Thị Hoàng Lan
SV Thực Hiện : Hoàng Hữu Hợi
Phạm Minh Hiếu

– 20121772.
– 20121693.

Nguyễn Văn Phương – 20122252.
Trương Văn Tam – 20122370.
Nguyễn Trung Hiếu – 20121690.


Hà Nội, Tháng 12 năm 2015
PHÂN CÔNG CÔNG VIỆC.
• Tìm hiểu chung về mô hình và kỹ thuật truyền dòng dữ liệu (Data
Streaming) –Hoàng Hữu Hợi.
• Khảo sát các công nghệ triển khai kỹ thuật “Data Streaming” hiện nay trong
các ứng dụng truyền thông dữ liệu video-audio – Nguyễn Văn Phương.
• Tìm hiểu giao thức RTMP (Real Time Message Protocol) – Phạm Minh

Hiếu
• Hoạt động của RTMP trong Video streaming - Trương Văn Tam
• Sự khác nhau về kỹ thuật truyền dòng dùng RTMP với kỹ thuật truyền dòng
dùng RTP – Nguyễn Trung Hiếu.


MỤC LỤC


I.
1.

TÌM HIỂU CHUNG VỀ MÔ HÌNH VÀ KỸ THUẬT
TRUYỀN DÒNG DỮ LIỆU

Khái niệm

Truyền dòng là kỹ thuật truyền dữ liệu mà trong đó dữ liệu được client nhận và
hiển thị một cách liên tục, đồng thời với quá trình gửi từ phía server.
2.

Kỹ thuật truyền dòng (Data Streaming):

• Cấu trúc hệ thống sử dụng “Streaming Server”. Đóng vai trò quan trọng
trong việc cung cấp các dịch vụ trực truyến. Để cung cấp các dịch vụ trực
tuyến chất lượng. Các máy chủ streaming được yêu cầu phải xử lý dữ liệu
video/audio với sự ràng buộc về thời gian, hạn chế thời gian trễ và hỗ trợ
hoạt động kiểm soát tương tác như tạm dừng (pause), tua (fast forword) tiếp
tục, nhanh chóng chuyển tiếp và nhanh chóng quay lại. Một máy chủ
Streaming thường bao gồm ba hệ thống con: Một hệ thống kết nối giao

tiếp, một hệ điều hành và một hệ thống lưu trữ.
• Sử dụng giao thức UDP. Là giao thức truyền dữ liệu đơn giản và hiệu quả.
Tuy nhiên không có cơ chế nào trong giao thức để đảm bảo việc giao tập tin
media đi . Nếu dữ liệu bị mất, việc stream có thể khiến cho chất lượng bị sụt
giảm.
• Truyền dữ liệu với tốc độ phù hợp tốc độ trình diễn file. Nếu các Streaming
Client nhận được các dữ liệu nhanh hơn so với yêu cầu, nó cần phải lưu dữ
liệu dư thừa trong một bộ đệm. Nếu luồng dữ liệu không đủ nhanh tải về, dữ
liệu sẽ không được mịn màng khi hiển thị.
• Dữ liệu trình diễn xong không lưu trữ ở thiết bị vật lý. Các dữ liệu lưu ở bộ
nhớ đệm sau khi trình diễn xong thì sẽ được xóa ngay sau đó.
3.

Nguyên tắc truyền dòng

Dữ liệu video, audio thu bằng máy thu hoặc lưu ở file sẽ được nén lại. Dữ liệu
nén này sau đó được phân thành các gói có kích thước bằng nhau rồi được truyền đi
qua mạng. Đến nơi nhận, các gói sẽ được khôi phục lại, đồng bộ và giải nén sau đó sẽ
được trình diễn trên client.
Các kĩ thuật chủ yếu được sử dụng trong quá trình truyền dữ liệu thời gian
thực:
• Đóng gói dữ liệu. Tạo ra các gói dữ liệu có độ dài như nhau
4


• Tạo dòng dữ liệu. Dòng liên tiếp các gói dữ liệu được đưa vào mạng theo
nhịp thời gian, phù hợp ứng dụng.
• Đồng bộ dữ liệu. Với cơ chế đồng bộ, ứng dụng tại bên nhận có thể hiển thị
video gần giống như khi nó được khởi tạo tại bên gửi.

Ưu điểm:
• Ta có thể sử dụng dữ liệu trong khi đang truyền tải dữ liệu. Không cần
tải toàn bộ dữ liệu về máy. Do đó không tốn thời gian để chờ đợi dữ liệu
được tải về.
• Streaming là cách nhanh nhất để truy cập nội dung trên Internet.
Nhược điểm:
• Kết nối Internet chậm hoặc bị gián đoạn có thể gây ra một số vấn đề.
Việc sử dụng dữ liệu sẽ bị dừng lại khi hết dữ liệu ở bộ đệm mà vẫn chưa
có dữ liệu tải thêm. Để bù đắp sự thiếu hụt này chất lượng hình ảnh
hoặc âm thanh sẽ bị giảm xuống.
• Tính streaming liên tục của luồng video – âm thanh của Radio/TV
thường ngăn cản khả năng điều khiển việc phát lại của người nhận. Tuy
nhiên, vấn đề này có thể được khắc phục bởi bộ nhớ đệm của máy chủ và
bộ đệm của thiết bị phát.
5


4.

Mô hình

a. Unicast
Unicast gửi một bản sao riêng media stream từ máy chủ đến mỗi người nhận.
Người sử dụng kết nối với máy chủ streaming mà luồng gửi nhận hoàn toàn tách biệt
với mọi người dùng khác.
Bất lợi của các công nghệ truyền thống unicast: có các dòng dữ liệu giống nhau
trên các phần khác nhau của mạng. Cấu hình này sử dụng lãng phí các tài nguyên
mạng (node, băng thông) làm cho máy chủ truyền tải nặng nề.
b. Multicast
Sự phân bố của các dòng dữ liệu không được xử lý bởi máy chủ nhưng nó được

chia sẻ bởi các nút mạng. Vì vậy, máy chủ streaming chỉ cần truyền một dòng dữ liệu
tới địa chỉ đại diện của nhóm. Việc này giúp sử dụng tối ưu các nguồn tài nguyên
mạng và giảm tải máy chủ.
Nhóm Multicast có thể được xác định bởi địa chỉ mạng đặc biệt, có địa chỉ Ipv4
từ 224.0.0.0 đến 239.255.255.255. Một nhóm multicast chỉ có một địa chỉ nhóm đại
diện cho tất cả các thành viên trong nhóm và các dữ liệu được gửi đến địa chỉ nhóm
này sẽ được gửi tới tất cả các thành viên trong nhóm.

6


II.

KHẢO SÁT CÔNG NGHỆ TRIỂN KHAI KỸ THUẬT
“DATA STREAMING” HIỆN NAY TRONG CÁC ỨNG
DỤNG TRUYỀN THÔNG DỮ LIỆU VIDEO – AUDIO

Hiện nay kĩ thuật streaming được sử dụng rộng rãi, khi ta xem các video clip,
xem truyền hình trên internet đều bắt gặp streaming.

• Trình duyệt sẽ yêu cầu tập tin đa phương tiện sau thông tin liên lạc server.
• Trình duyệt sẽ đưa tệp tin đa phương tiện đến player và trình chiếu nó
• Sau đó Server sẽ stream tệp video/audio đến player

7


1

Data Streaming được sử dụng trong giao thức RSTP

RSTP được thiết kế để điều khiển truyền dòng dữ liệu đa phương tiện với thông
tin thời gian đáp ứng yêu cầu trình diễn tại máy user.
RSTP yêu cầu client duy trì thông tin về phiên streaming qua các request
RTSP.Cả 2 phía client và sever đều có thể đưa ra các RSTP request

5.

Data streaming còn được sử dụng trong giao thức thời gian thực RTP/RTCP

6.

Data streaming còn dùng trong sử dụng giao thức RTMP (Real Time Message Protocol)

8


III. GIAO THỨC RTMP (REAL TIME MESSAGING
PROTOCOL)
1

Giới thiệu

RTMP là giao thức được tạo ra bởi Macromedia (hiện nay là Adobe) dùng để truyền
tải các đối tượng Flash và video trên các kết nối mạng. Hiện tại chỉ có 2 máy chủ hỗ trợ giao
thức này là Macromedia Media Sever, và server mã nguồn mở Red5.
Đây là một giao thức đơn giản, được tối ưu cho các kết nối tốc độ thấp. Nó có thể hỗ
trợ tối đa 64 luồng dữ liệu trên cùng một kết nối. Trong header của một AMF có chứa chỉ số
của luồng dữ liệu mà nó thuộc về. Một message RTMP có thể chứa nhiều hơn một đối tượng
AMF.

7.

Các chế độ hoạt động của RTMP

RTMP ở chế độ tiêu chuẩn chạy trên TCP với cổng mặc định là 1935. Ngoài ra
RTMP có thể chạy trong chế độ đường hầm trên một kết nối HTTP sử dụng cổng 80.

Hình 1: RTMP ở chế độ tiêu chuẩn

Hình 2: RTMP ở chế độ đường hầm

9


8.

Cấu trúc gói tin

Server và máy chủ gửi tin nhắn rtmp thông qua mạng để liên kết đến nhữg
server và máy chủ khác. tin nhắn bao gồm audio, video, dữ liệu hay bất cứ tin nhắn
khác.tin nhắn rtmp có 2 phần là phần Header và phần Payload
+ Header:
Messge type: cho biết kiểu gói tin.
Payload Length: cho biết kích thước phần payload.
Timestamp: nhãn thời gian của gói tin.
Stream ID: xác định dòng của gói tin.
+ Payload: chứa dữ liệu thực tế của gói tin.
9.

Quá trình bắt tay

Hoạt động cơ bản của RTMP như sau : Tất cả quá trình truyền thông được khởi
động bởi client. Client khởi tạo một kết nối RTMP bằng cách gửi một byte có giá trị
0x03 – byte này được theo sau bởi một khối dữ liệu 1536 byte. Định dạng của khối
dữ liệu này cho đến nay vẫn chưa biết nhưng nó dường như không thực sự được sử
dụng bởi giao thức ngoại trừ thao tác bắt tay.
Server khi nhận được gói dữ liệu sẽ lưu lại khối dữ liệu 1536 byte này, và cũng
gởi 1 byte giá trị 0x03 theo sau bởi hai khối 1536 byte. Khối thứ hai chính là nội dung
đã được gửi lên bởi client trước đó.
10


Client nhận hai khối dữ liệu 1536 byte từ server, so sánh với khối dữ liệu ban
đầu nó gửi lên server, nếu phù hợp thì kết nối được thiết lập, nó cũng gửi trả khối dữ
liệu này về lại cho server.

Hình 3: Quá trình bắt tay giữa Client và Server trong giao thức RTMP
Sau thao tác bắt tay Client tiếp tục gửi ba đối tượng AMF lên server để khởi
động truyền dữ liệu. Đối tượng đầu tiên là đối tượng connect nhằm thông báo client
đã sẵn sàng cho quá trình truyền thông. Đối tượng AMF thứ hai chính là đối tượng
NetConnection từ client, lớp Action Script này được sử dụng tạo kết nối tới media
server. Đối tượng AMF thứ ba là đối tượng NetStream từ client dùng để xác định file
cần stream từ server.
10.

Tiêu đề RTMP

RTMP có bốn loại tiêu đề đó là tiêu đề 12, 8, 4 hoặc 1 byte. Byte đầu tiên của
tiêu đề rất quan trọng, 2 bit đầu tiên của nó xác định kích thước của tiêu đề.
•

0x00: tiêu đề 12 byte

•

0x01: tiêu đề 8 byte

•

0x02: tiêu đề 4 byte
11


•

0x03: tiêu đề 1 byte

Sáu bít còn lại biểu diễn chỉ số của đối tượng AMF. Một khi đối tượng AMF đã
được nhận đầy đủ bởi client thì chỉ số này có thể được tái sử dụng.

Hình 4: Tiêu đề RTMP 12 byte
Đối với tiêu đề 12 byte thì 3 byte tiếp theo là trường timestamp (little-endian), 3
byte tiếp theo nữa là chiều dài của đối tượng AMF (big-endian), byte kế tiếp quy định
nội dung của đối tượng AMF (xem hình ?), 4 byte cuối cùng xác định source id.
Đối với tiêu đề 8 byte thì bỏ đi trường source id trong tiêu đề 12 byte.
Đối với tiêu đề 4 byte thì bỏ đi trường length, content type trong tiêu đề 8 byte.
Đối với tiêu đề 1 byte thì bỏ đi trường timestamp trong tiêu đề 4 byte nghĩa là
nó chỉ gồm byte đầu tiên chứa kiểu tiêu đề và chỉ số đối tượng AMF.

12

Bảng 5: Một số giá trị trong trường Content Type
11.

Truyền tải nhiều đối tượng AMF trên cùng một kết nối

Mỗi đối tượng AMF được chia thành các khối dữ liệu có kích thước 128 byte
(ngoại trừ audio có kích thước 64 byte) . Khối đầu tiên thường được gắn tiêu đề 12
byte, các khối tiếp theo thường được gắn tiêu đề 1 byte, trong bất kì loại tiêu đề nào
cũng có chứa chỉ số của đối tượng AMF tương ứng.

13


Hình 6: Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03
Để có thể truyền nhiều đối tượng AMF trên một kết nối đơn người ta không
truyền các khối dữ liệu của một đối tượng AMF liên tiếp nhau mà truyền xen kẽ các
khối dữ liệu của nhiều đối tượng AMF.

14


Hình 7: Truyền các khối dữ liệu xen kẽ nhau.

15


IV. HOẠT ĐỘNG CỦA RTMP TRONG VIDEO STREAMING
1. Tìm hiểu RTMP trong ứng dụng Flash Video

RTMP được sử dụng trong ứng dụng Flash Video trên internet.Một giao thức
đặc biệt cho các ứng dụng máy chủ thời gian thực khác nhau,từ tin nhắn thức thời để
chia sẻ dữ liệu hợp tác với video streaming.
RTMP trong Flash Video được cung cấp bởi phần mềm máy chủ cấp phép từ
Adobe,đặc biệt là Flash Media Server (FMS).FMS được cài đặt trên một máy chủ
được nối mạng và quản lý trực tuyến Flash Video riêng rẽ với các máy chủ Web lưu
trữ các bộ phim Flash.FMS cấp phép cho các trang web âm lượng cao.
2. Phân tích ứng dụng
Một trong những lợi ích của việc dùng giao thức RTMP là phát lại gần như tức
thời của video,cung cấp các tập tin Flash.Video được mã hóa với một bitrate thích
hợp cho tốc độ kết nối của người xem.Real-time-streaming cũng có thể tìm được file
FLV vào bất kỳ thời điểm nào trong nội dung.Tính năng này đặc biệt thuận lợi cho
nội dung trong thời gian dài vì người xem không phải chờ đợi cho các tệp tin video để
tải trước khi nhảy.
Những người muốn lưu trữ video có thể sử dụng thời gian thực streaming video
ở bất kỳ định dạng video nào không chỉ là Flash Video.Khi các luồng video RTMP
dựa vào Flash Video,âm thanh và dữ liệu video chỉ được lưu trữ trong bộ nhớ đệm
Flash Player.Toàn bộ tập tin Flash Video không được sao chép hoặc lưu trữ vào bộ
nhớ cache của trình duyệt web.
Các giao thức sử dụng có thể ảnh hưởng đến chiến lược triển khai Flash
Video.Nếu ta mã hóa các tập tin Flash Video với một công cụ nén,ta nên xác định
giao thức để sử dụng trước khi tạo ra các tập tin FLV.Vì kết nối RTMP gửi dữ liệu
video từ một máy chủ từ xa đến một máy nghe nhạc đệm tạm thời,tốc độ dữ liệu
Video của Flash nên được dự đoán trong suốt thời gian phát lại.Tính nhất quán dữ
liệu tốc độ này chỉ có thể được thực hiện với tốc độ bit không đổi (CBR) mã hóa.Gần
như tất cả bộ mã hóa Flash Video cung cấp các tùy chọn lựa chọn bitrate không đổi
hoặc bitrate biến (VBR) mã hóa.Nếu công cụ mã hóa Flash Video không cung cấp
một sự lựa chọn,nó có thể sử dụng mã hóa CBR.
Nếu nội dung Flash Video được mã hóa với một thiết lập VBR,tập tin có thể có
gai dữ liệu cực mà vượt qua tốc độ bit trung bình của video.Những gai đột ngột có thể

trống rỗng đệm Flash Player và cho kết quả phát lại tạm thời bị đình trệ và một pauseplay-pause gây nhiễu.Tuy nhiên,nếu nội dung Flash Video sẽ không được phân phối
16


qua RTMP,ta có thể an toàn sử dụng mã hóa VBR vơi tiêu chuẩn trên một máy chủ
web. Bởi vì Flash Video tải dần dần và được lưu trữ trong bộ nhớ cache của trình
duyệt web, gai dữ liệu có lẽ sẽ không xảy ra trong quá trình phát lại cung cấp các
bitrate đang sử dụng là phù hợp với tốc độ kết nối của người xem.
Tuy nhiên, điều này không phải luôn luôn chia sẻ với giao thức RTMP - Flash
Video. Cổng mặc định cho các kết nối RTMP là 1935, trong đó có thể không được
cho phép trên các bức tường lửa chặt chẽ. Nếu nỗ lực đầu tiên Flash Player để chạy
video qua cổng 1935 không thành công, Flash Player tự động cố gắng để kết nối với
các dòng video với RTMP trên cổng 80. Nếu phép thử thứ hai này không thành công,
cuối cùng có sẵn cho Flash Player là để thử một HTTP kết nối -tunneled trên cổng 80.
Một đường hầm kết nối có nghĩa là các gói dữ liệu RTMP được gói (hoặc đeo mặt nạ)
trong một gói dữ liệu HTTP. Một số bức tường lửa cho phép lưu lượng này, vì các
gói dữ liệu dường như là bình thường lưu lượng HTTP Web. Nếu các bức tường lửa
kiểm tra dữ liệu HTTP, tuy nhiên, nó vẫn có thể từ chối các kết nối, và các Video
Flash sẽ không chạy.
Nếu ta kiểm soát quyền truy cập vào nội dung Flash Video, và ta không muốn
người dùng các file FLV ra khỏi bộ nhớ cache của trình duyệt web của họ, ta phải sử
dụng thời gian thực Streaming Flash Video. Ngay sau khi ta đặt các file FLV ở một vị
trí có thể truy cập công khai trên một máy chủ Web,ta đang cho phép người sử dụng
để sao chép các tập tin FLV và làm bất cứ điều gì họ muốn.Rất nhiều tập tin Flash
Video trên Web thậm chí từ số lượng lớn các trang web của Neutrino thời gian thực
Streaming Flash Video. Tìm kiếm video của Google và Youtube là những ví dụ của
các trang web cung cấp trình duyệt cache. Tuy nhiên, thời gian thực Streaming Flash
Video thường là lựa chọn duy nhất khả thi cho công ty và các tổ chức (như hãng phim
và các mạng truyền hình) mà cần phải kiểm soát cách thức nội dung của họ được xem
và truy cập bởi công chúng.

Nếu ứng dụng Flash được thiết kế để chạy từ một nguồn địa phương như ổ
cứng của người dùng hoặc phương tiện truyền thông cố định (CD / DVD-ROM),ta có
thể cung cấp các nội dung Flash Video để cùng tồn tại với các tập tin địa phương
khác được sử dụng cho các ứng dụng. Trừ khi ta muốn yêu cầu một kết nối Internet
cho các ứng dụng Flash để chạy ta không cần phải lưu trữ các tập tin Flash video trên
các máy chủ từ xa Web (HTTP) hoặc thời gian thực máy chủ Streaming (RTMP).
Theo chiều dài của một file video tăng lên, vì vậy nên khả năng sử dụng thời
gian thực Streaming Flash Video (RTMP) trong Flash Video dần tải (HTTP). Bất kể
tốc độ dữ liệu được sử dụng bởi các tập tin video, file còn có kích thước file lớn
hơn. Khi một HTTP-giao Flash Video bắt đầu tải về vào trong Flash Player, theo mặc
17


định các tập tin tiếp tục tải vào bộ nhớ cache của trình duyệt cho dù người sử dụng
đồng hồ nội dung. Nếu ta lưu trữ các tập tin FLV lớn trên máy chủ web , các byte dữ
liệu chuyển giao các máy chủ Web sẽ tăng một cách nhanh chóng, có khả năng tăng
chi phí tài chính của lưu trữ các tập tin. Nếu bạn lưu trữ các tập tin FLV lớn trên một
FMS (hoặc Flash Video Streaming Service), chi phí truyền dữ liệu của bạn chỉ bao
gồm các phần của Video Flash dõi bởi mỗi người dùng.

V.

GIAO THỨC RTP VÀ SỰ KHÁC NHAU GIỮA RTP VÀ
RTMP

Tín hiệu thoại sau khi nén xuống tốc độ thấp được đóng gói lại để truyền đi
trong mạng chuyển mạch gói. Có nhiều cách thức đóng gói tín hiệu thoại để truyền
trong mạng IP. Một trong những cách thức được áp dụng nhiều nhất là bộ giao thức
RTP/RTCP nhờ tính linh hoạt và khả năng giám sát trạng thái dòng thông tin một
cách hiệu quả của nó.

1

Vai trò của RTP

Giao thức RTP (Realtime Transport Protocol) cung cấp các chức năng giao vận
phù hợp cho các ứng dụng truyền dữ liệu mang đặc tính thời gian thực như là thoại và
truyền hình tương tác. Những dịch vụ của RTP bao gồm trường chỉ thị loại tải trọng
(payload identification), đánh số thứ tự các gói, điền tem thời gian (phục vụ cho cơ
chế đồng bộ khi phát lại tín hiệu ở bên thu)…
Thông thường các ứng dụng chay giao thức RTP ở bên trên giao thức UDP để
sử dụng các dịch vụ ghép kênh (mutiplexing) và kiểm tra tổng (checksum) của dịch
vụ này; cả hai giao thức RTP và UDP tạo nên một phần chức năng của giao thức tầng
giao vận. Tuy nhiên RTP cũng có thể được sử dụng với những giao thức khác của
tầng mạng và tầng giao vận bên dưới miễn là các giao thức này cung cấp được các
dịch vụ mà RTP đòi hỏi: Giao thức RTP hỗ trợ việc truyền dữ liệu tới nhiều đích sử
dụng phân bố dữ liệu multicast nếu như khả năng này được tầng mạng hoạt động bên
dưới nó cung cấp.
Một điều cần lưu ý là bản thân RTP không cung cấp một cơ chế nào đảm bảo
việc phân phát kịp thời dữ liệu tới các trạm mà nó dựa trên các dịch vụ của tầng thấp
hơn để thực hiện điều này. RTP cũng không đảm bảo việc truyền các gói theo đúng
thứ tự. Tuy nhiên số thứ tự trong RTP header ch phép bên thu xây dựng lại thứ tự
đúng của các gói bên phát.
Giao thức RTP được cố tình để cho chưa hoàn thiện. Nó chỉ cung cấp các dịch
vụ phổ thông nhất cho hầu hết các ứng dụng truyền thông hội nghị đa phương tiện.
Mỗi một ứng dụng cụ thể đều có thể thêm vào RTP các dịch vụ mới cho phù hợp với
18


các yêu cầu của nó. Các khả năng mở rộng thêm vào cho RTP được mô tả trong một
profile đi kèm. Ngoài ra, profile còn chỉ ra các mã tương ứng sử dụng trong trường

PT (Payload type) của phần tiêu đề RTP ứng với các loại tải trong (payload) mang
trong gói.
Một vài ứng dụng cả thử nghiệm cũng như thương mại đã được triển khai.
Những ứng dụng này bao gồm các ứng dụng truyền thoại, video và chuẩn đoán tình
trạng mạng (như là giám sát lưu lượng). Tuy nhiên, mạng Internet ngày nay vẫn chưa
thể hỗ trợ được đầy đủ yêu cầu của các dịch vụ thời gian thực. Các dịch vụ sử dụng
RTP đòi hỏi băng thông cao (như là truyền audio) có thể là giảm nghiêm trọng chất
lượng của các dịch vụ khác trong mạng. Như vậy những người triển khai phải chú ý
đến giới hạn băng thông sử dụng của ứng dụng trong mạng.
12.

Khuôn dạng gói RTP

Tiêu đề giao thức RTP bao gồm một phần tiêu đề cố định thường có ở mọi gói
RTP và một phần tiêu đề mở rộng phục vụ cho các mục đích nhất định
Tiêu đề cố định gói RTP

12 octets (byte) đầu tiên của phần tiêu đề có trong mọi gói RTP còn các octets
còn lại thường được mixer thêm vào trong gói khi gói đó được mixer chuyển tiếp đến
đích.
Version (V): 2 bit.
Trường này chỉ ra version của RTP. Giá trị của trường này là 2.

19


Padding (P): 1 bit.
Nếu bit padding được lập, gói dữ liệu sẽ có một vài octets thêm vào cuối gói dữ
liệu. Octets cuối cùng của phần thêm vào này sẽ chỉ kích thước của phần thêm vào
này (tính theo byte). Những octets này không phải là thông tin. Chúng được thêm vào

để đáp ứng các yêu cầu sau:
Phục vụ cho một vài thuật toán mã hóa thông tin cần kích thước của gói cố
định.
Dùng để cách ly các gói RTP trong trường hợp nhiều gói thông tin được mang
trong cùng một đơn vị dữ liệu của giao thức tầng dưới.
Extension (X): 1 bit.
Nếu như bit X được lập, theo sau phần tiêu đề cố định sẽ là một tiêu đề mở
rộng.
Marker (M): 1 bit.
Tùy từng trường hợp cụ thể mà bit này mang những ý nghĩa khác nhau ý nghĩa
của nó được chỉ ra trong một profile đi kèm.
Payload Type (PT): 7 bits.
Trường này chỉ ra loại tải trọng mang trong gói. Các mã sử dụng trong trường
này ứng với các loại tải trọng được quy định trong một profile đi kèm.
Sequence Number: 16 bits.
Mang số thứ tự của gói RTP. Số thứ tự này được tăng lên một sau mỗi gói RTP
được gửi đi. Trường này có thể được sử dụng để bên thu phát hiện được sự mất gói và
khôi phục lại trình tự đúng của các gói. Giá trí khởi đầu của trường này là ngẫu nhiên.
Timestamp (tem thời gian): 32 bits.
Phần tiêu đề mở rộng
Cơ chế mở rộng của RTP cho phép những ứng dụng riêng lẻ của giao thức RTP
thực hiện được với những chức năng mới đòi hỏi những thông tin thêm vào phần tiêu
đề của gói. Cơ chế này được thiết kế để một vài ứng dụng có thể bỏ qua một số ứng
dụng khác lại có thể sử dụng được phần nào đó.

20


Nếu như bit X trong phần tiêu đề cố định được đặt bằng 1 thì theo sau phần tiêu
đề cố định là phần tiêu đề mở rộng có chiều dài thay đổi.

16 bit đầu tiên trong phần tiêu đề được sử dụng với mục đích riêng cho từng
ứng dụng được định nghĩa bởi profile. Thường nó được sử dụng để phân biệt các loại
tiêu để mở rộng.
Length: 16 bits. Mang giá trị chiều dài của phần tiêu đề mở rộng tính theo đơn
vị là 32 bits. Giá trị này không bao gồm 32 bit đầu tiên của phần tiêu đề mở rộng.
13.

So sánh giữa RTP và RTMP

Hai giao thức RTP và RTMP rõ ràng không cung cấp cơ chế để chuyển phát
đúng thời hạn, điều này phải được đảm bảo hệ thống cơ sở. Chúng chỉ cung cấp cơ
chế timestamp để kiểm soát việc playback. Trong RTP có sequence number để kiểm
tra trật tự các gói còn trong RTMP việc này được đảm bảo bởi TCP. Cả hai cùng phải
sử dụng cơ chế vùng đệm để giảm jitter. Có thể nói khả năng của hai giao thức này là
tương đương nhau. Việc chọn RTMP trong đề tài là do nó gắn liền với Flash. Sở dĩ sử
dụng Flash là vì tính đơn giản, khả chuyển và mềm dẻo của nó
Các điểm khác nhau của RTP và RTMP:
RTP/RTCP
-Phát triển bởi IETF
- Chạy trên nền UDP
- File dữ liệu không được lưu lại
- Sử dụng trong mạng LAN

RTMP
- Phát triển bởi Adobe
- Chạy trên nền TCP
- Dữ liệu được lưu tạm thời
- Sử dụng trong mạng WAN

21

TÀI LIỆU THAM KHẢO
• Slide truyền thông đa phương tiện – IT4618 của PGS. TS. Nguyễn Thị
Hoàng Lan.
• />• />• />
22