Báo cáo: Truyền thông đa phương tiện
Đề tài 18 – Nhóm 14: tìm hiểu công nghệ chia sẻ audio và nghe nhạc trực tuyến
qua mạng IP trên môi trường windows hoặc linux
Tên thành viên:
Trần Việt Anh – 20121242
An Mạnh Công – 20121330
Nguyễn Như Nai - 20122096
Đoàn khắc hùng - 20121821

Contents

Chương 0: Giới thiệu
Ngày nay, ngành công nghệ thông tin đang phát triển, việc chia sẻ nhạc, video, audio cho lĩnh
vực giải trí là cần thiết. Đáp ứng nhu cầu này, một số giải pháp một số dịch vụ ra đời.
Hiện nay chúng ta có thể biết đến một số trang web chia sẻ nhạc như: zing.vn, youtobe.com,
mp3.vn … Việc truy cập vào, và sử dụng dịch vụ nghe nhạc trực tuyến ở các trang web chia sẻ
nhạc này là rất đơn giản. Vậy chúng ta hãy tự hỏi chúng hoạt động như thể nào? Làm sao mà chỉ


một thiết bị như máy tính, điện thoại lại có thể phát được các bài hát yêu thích khi chỉ cần vào
các trang web này? Vậy dữ liệu là gì và nó được truyền như thể nào?
Trong khuôn khổ báo cáo này chúng em sẽ giải thích về một hệ thống chia sẻ nhạc có thể là
audio or video, nó làm việc như thể nào, và nó sử dụng công nghệ gì? Các công nghệ áp dụng
vào thực tế như thế nào (phần demo).
Chúng em lựa chọn việc nghiên cứu về hệ thống chia sẻ nhạc trên web, môi trường lựa chọn tìm
hiểu là môi trường windows và dịch vụ là youtube.

Chương I: Tổng quan hệ thống chia sẻ nhạc
Yêu cầu: Tìm hiêu chức năng và hoạt động hệ thống chia sẻ audio và nghe nhac trưc tuyến qua
mạng IP, khảo sát dịch vụ hiện có trên môi trường Window hoặc Linux?

1. Chức năng mô hình hoạt động của hệ thống
Chức năng: chức năng của hệ thống chia sẻ nhạc nhằm mục đích tạo ra một kho nhạc có thể chia
sẻ cho một hoặc nhiều người dùng. Người dùng có thể truy cập vào kho nhạc và thoải mái lựa
chọn và chơi nhạc.

Trước khi bắt đầu chúng em xin giới thiệu về một mô hình chia sẻ nhạc cơ bản


Mô hình trên bao gồm 3 phần quan trọng:
-

Data music: đây là phần dữ liệu, có thể là các file nhạc, hoặc hệ thống lưu trữ nhạc.
Nói chugn data music là một kho lưu trữ nhạc. Ngày nay một số trang web đã lấy một

-

số các nguồn online.
Server: server đây là server chia sẻ nhạc, có thể là web server, có thể là streaming

-

server …
Application Client: Ứng dụng phía client có thể là ứng dụng, có là thiết bị
smartphone, hoặc chính browser của chúng ta. Công việc của người dùng là truy cập
vào site chia sẻ nhạc chơi và thưởng thức.

2. Khảo sát một dịch vụ trên môi trường windows
Có rất nhiều ứng dụng cũng như dịch vụ chia sẻ nhạc hiện có.
Như chúng ta đã biết đến thì youtube, zing, mp3 … là những trang web chia sẻ nhạc phổ biến.
Đối với windows có thể sử dụng windows player để chia sẻ nhạc trong môi trường mạng IP.

Ngoài ra cũng có một số các phần mềm khác như VLC …
Trong phần thực hành này chúng em sẽ tìm hiểu nghiên cứu về công nghệ sử dụng của youtube
data streaming.

Chương II: Khảo sát – phân tích công nghệ sử dụng
1. Tổng quan về công nghệ sử dụng (Youtube)
Được thành lập năm 2005, Youtube là một trong những website phát triển nhanh nhất, và đã trở
thành một trong những website được truy cập nhiều nhất trên Internet .Nó có một tác động đáng
kể đến sự phân bố lưu lượng truy cập Internet, nhưng chính điều đó làm hạn chế khả năng mở
rộng và chất lượng dịch vụ. Hiểu biết về các tính năng của YouTube là như vậy, rất quan trọng
cho mạng lưới mạng và kỹ thuật để phát triển bền vững thế hệ của các dịch vụ mới này. Trong
bài khảo sát, đầu tiên chúng tôi mô tả cách tăng tính sẵn sàng của siêu dữ liệu trong Web 2.0
có thể được khai thác một cách hiệu quả để cải thiện hiệu suất và khả năng của YouTube. Đặc
biệt, chúng ta nghiên cứu những lợi ích đạt được bằng cách bộ nhớ đệm địa phương cùng với tìm
nạp trước trong việc giảm các thời gian truy cập của client và bắt đầu lên chậm trễ trong việc
xem video.


2. Phân tích công nghệ sư dụng của youtube
a. Youtube làm việc như thế nào?
Một trong những chìa khóa thành công của YouTube là việc sử dụng Flash Video (FLV) định
dạng của Adobe để phân phối video . Trong khi người dùng có thể tải lên các nội dung trong một
loạt các định dạng phương tiện truyền thông (ví dụ, WMV, MPEG và AVI), YouTube chuyển đổi
chúng sang Flash Video trước khi gửi bài cho họ. Điều này cho phép người dùng xem các video
mà không cần tải bất kỳ trình duyệt bổ sung thêm điều kiện họ có cài đặt Flash Player. Để kích
hoạt tính năng phát lại các video Flash trước khi nội dung được tải xong, YouTube dựa trên công
nghệ tải về tiến bộ của Adobe. Truyền thống download-and-play đòi hỏi các tập tin FLV đầy đủ
để được tải về trước khi phát lại có thể bắt đầu. Tính năng tải về tiến bộ của Adobe cho phép phát
lại để bắt đầu mà không cần tải file hoàn toàn. Điều này được thực hiện bằng cách sử dụng lệnh
ActionScript đó cung cấp các tập tin FLV để người chơi như là nó đang được tải về, cho phép

phát lại các tập tin đã tải về một phần. Tải về tiến bộ làm việc với máy chủ Web và nội dung
video được giao sử dụng HTTP / TCP.
Kỹ thuật vận chuyển này đôi khi được gọi là pseudo-streaming để phân biệt nó từ phương tiện
truyền thông truyền thống streaming. Truyền thống về yêu cầu trực tuyến của các tập tin đa
phương tiện lưu thông thường đòi hỏi việc sử dụng các máy chủ trực tuyến dành riêng cho rằng
điều kiện tương tác client-server trong quá trình phát lại video. Sự tương tác này có thể được sử
dụng cho việc thích ứng của chất lượng video hoặc sử dụng tương tác như nhanh về phía trước
hoặc tua lại hoạt động. Trong khi nội dung video thường là trọng tâm của một lượt xemm các
trang web YouTube, có nhiều chuyển file đó xảy ra đằng sau hậu trường để nhúng các file video
và hiển thị xung quanh nội dung trang web. Ví dụ, khi người dùng nhấp vào một video quan tâm,
một yêu cầu GET cho các trang tiêu đề của HTML cho các yêu cầu video được thực hiện. Trang
HTML này thường bao gồm các tài liệu tham khảo cho một số tập tin javascript. Những kịch bản
này chịu trách nhiệm cho việc nhúng Shockwave Flash (SWF) chơi, và nhiệm vụ ngoại vi khác
như xếp hạng xử lý video và bình luận. Các tập tin SWF là tương đối nhỏ (26 KB), do đó, các
trang web tải nhanh chóng. Một khi người chơi được nhúng, một yêu cầu cho các file video FLV
được ban hành. Các file video FLV được tải về máy tính của người dùng bằng cách sử dụng một
yêu cầu HTTP GET, được phục vụ bởi một trong hai máy chủ YouTube hoặc một máy chủ từ
một mạng lưới phân phối nội dung (CDN)


Hình 1 minh hoạ các thông tin liên lạc giữa các máy khách, máy chủ YouTube, và một máy chủ
của CDN. Khi một khách hàng đã chọn một video cụ thể, một thông GET HTTP được gửi từ
máy khách đến máy chủ web YouTube. Thông báo này chỉ ra rằng client được yêu cầu một video
cụ thể được xác định bởi một định video duy nhất. Sau khi nhận được tin nhắn GET, các máy
chủ web sẽ trả lời với một tin nhắn chuyển hướng. Thông báo này có chứa một trường phản ứngheader vị trí, mà chuyển hướng khách hàng đến máy chủ video từ mà video sẽ được xem trực
tiếp.
Các cơ chế chuyển hướng giới thiệu cân bằng tải cho hệ thống từ máy chủ web có thể chuyển
hướng khách hàng đến một máy chủ video một cách năng động. Vì vậy, máy chủ web phải biết
được video có thể được phục vụ từ đó các máy chủ video và tải trọng thực tế của video servers.
Để cho phép cân bằng tải, YouTube, sử dụng một dịch vụ CDN cung cấp bởi cả hai máy chủ

YouTube và Google Video Limelight CDN . Một dịch vụ tự động phân phối video đến các máy
chủ CDN


b. Buffer management
Trong khi truyền dữ liệu qua mang – có thể là audio hoặc video, cần một cơ chế để thiết lập kích
thước bộ nhớ đệm (client buffer) để làm sao việc trình diễn audio (video) là tốt nhất để client
(người dùng) có một trải nghiệm dịch vụ trên youtube là mượt nhất. Thông thường các Flash
Player – Plugin xem video sẽ xử lý việc này, sẽ quy định cách xử lý các các giải quyết đối với
buffer client tương ứng để cho người dùng cuối có một trải nghiệm dịch vụ tốt nhất. Sau đây là
một số cách để phân chia buffer client được sử dụng rộng dãi.
Standard video buffering,
Dual-threshold buffering,
H.264 encoded video buffering.

i.

Standard video buffering

Đối với cách này, Streaming server (máy chủ chia sẻ nhạc) quản lý bộ nhớ đẹm với một cách
thức khá đơn giản. Server gửi dữ liệu tới client và dữ liệu đó được lưu trữ trên buffer (bộ nhớ
đệm của client). Dữ liệu gửi với tốc độ mạng cho phép – càng nhanh càng tốt. Khi buffer đầy (bộ
nhớ đệm đầy) – ngưỡng được định nghĩa trước cho phép lưu trữ, thì bắt đầu phát video (audio).
Khi đó server tiếp tục gửi dữ liệu cho client nhưng mà chỉ gửi để đủ số lượng buffer cho đầy.
Nếu tốc độ mạng không cho phép gửi đủ để đầy dữ liệu thì có thể phải đợi một khoảng thời gian
để buffer đầy (trường hợp xem video bị treo). Như vậy việc lựa chọn size buffer rất quan trọng,
nó ảnh hưởng tới chất lượng video.Nếu thực hiện xem lại video thì quá trình thực hiện như lúc đầu,
gọi là cơ chế rebuffer-ing.

Một buffer size nhỏ có thể trả lại kết quả ngay lập tức (xem video ngay tức khắc). Còn đối với

buffer size lớn lại giúp khả năng phục hồi cao phù hợp vào băng thông (việc thực hiện phát lại có
thể dễ dàng)
ii.

Dual-threshold buffering

Có vẻ như cách giải quyết “standard buffering” – cố định buffer không tối ưu khi băng thông
tăng hoặc giảm đột ngột. “Dual-threshold buffering” là một các sử lý buffer để có thể tối ưu hóa
vấn đề này. Khi buffer được làm đầy một lượng nhất định (ngưỡng đầu tiên), thì video được trình
chiếu như bình thường. Sau đó server gửi dữ liệu cho client nhưng sẽ được lưu ở buffer thứ 2.
Khi video được trình chiếu hết ở buffer có thể chiển sang video thứ 2 để trình chiếu tiếp. Một sự


lặp đi lặp lại sẽ được diễn ra, Chú ý buffer thứ 2 sẽ không có xác đinh size, như vậy sẽ giải quyết
được vấn đề nếu băng thông dữ liệu tăng đột ngột.
iii.

H.264 encoded video buffering.

Buffering – bộ nhớ đệm trong H.264 encoded videos phức tạp hơn nhiều so với video FLV
buffering bình thường. Trong H.264 encode video, video frames có thể tham nhiều từ trong quá
khứ và tương lai. Vì vậy nó có thể yêu cầu tại lại một frame trước khi bắt đầu phát. Điều này có
nghĩa rằng các video được mã hóa với H.264 cần một buffer đặc biệt để xử lý các video này, và
dịch vụ cung cấp thì không khuyến cáo điều này. Giải pháp này chỉ áp dụng đối với video có
kiểu encode là H.264.

Chương III: Kỹ thuật truyền dữ liệu – youtube streaming
1. Kỹ thuật Video Streaming
a.


Giới thiệu

Streaming video sử dụng cách thức phát lại các đoạn video được lưu trữ trên các máy tính trên
mạng tới người dùng đầu cuối muốn xem đoạn video mà không cần tải đoạn video đó về trên
máy tính.
Về bản chất, streaming video là quá trình chia nhỏ file video thành các frame, rồi lần lượt gửi
từng frame tới một bộ đệm trên máy tính của người xem và hiển thị nội dung frame đó. Và quá
trình này tuân thủ chặt chẽ về ràng buộc theo thời gian, nói khác là tuân thủ chặt chẽ theo giao
thức RTSP, RTP và RTCP.
b.

Kỹ thuật streaming video

Các bước thực hiện kỹ thuật streaming video:


- Phần mềm máy khách (media player, web browser, ...) cần kết nối được và xác định file video
trên máy streaming server muốn xem.
- Yêu cầu streaming file video đó sẽ được gửi tới streaming server để tìm file video đó.
- Chương trình thực hiện streaming chạy trên máy streaming server sẽ chia file video thành các
frame rồi gửi các frame đó tới máy yêu cầu sử dụng các giao thức ràng buộc về thời gian (RTSP,
RTP, RTCP).
- Khi các frame về máy khách, sẽ được lưu trữ trong vùng đệm và nội dung các frame sẽ được
giải mã (decode) và hiển thị thông qua các chương trình chơi video (ví dụ VLC)


2. Quá trình truyền dữ liệu
a.

Quá trình truyền dòng


B1:Mã hóa:
-

Âm thanh stream được nén bằng cách sử dụng định dạng âm thanh như MP3, Vorbis hoặc

-

AAC.
Hình ảnh video stream được nén bằng cách sử dụng codec video như H.264 hoặc VP8

B2.Phân gói:(Lấy mẫu)
-

là chia nhỏ nôi dung video thành các khối nhỏ thích hợp để có thể truyền đi trong môi trường

-

mạng ,thực hiện theo thời gian+không gian
o Thời gian:tương ứng với thời gian thể hiện của các khung hình
o Không gian:chia nhỏ các khung hình thành các phần với kích thước thích hợp.
Yêu cầu:các mẫu phải chứa đủ thông tin dùng cho việc khôi phục lại dữ liêu video ,audio về

-

cả không gian và thời gian khi bên nhận nhận được.
Được thực hiện tự đông với giao thức RTP.

B3.Truyền các mẫu qua mạng
-


có thể thực hiện trực tiếp thông qua các giao diện của môi trường mạng như Socket hoặc
thông qua giao thức cấp cao ở tâng ứng dụng như RTP.Thường dùng cách 2


-

các mẫu được đóng gói thành các gói tin ,mang đầy đủ thông tin như thời gian,số thứ tự và
các thông tin khác đảm bảo việc khôi phục và đồng bộ các dòng khi bên nhận nhận và trình
diễn.Các gói tin được truyền đi thông qua các giao thức lớp dứoi

B4.Khôi phục dữ liệu và đồng bộ
-

bên nhận căn cứ vào thông tin trong từng gói để xác định vị trí không gian và thời gian của

-

các mẫu dữ liệu mà gói tin mang theo.
trường hợp nhiều dòng nhiều dòng khác nhau có quan hệ về thời gian thực thì cần đồng bộ

-

các dòng về mặt thời gian.
được thực hiện tự động bời các giao thức truyền dòng thời gian thực như RTP.

B5. Giải nén
-

b.

-

giải nén dòng video/audio với chuẩn nén được dùng khi nén.

Streaming với băng thông và lưu trữ
Băng thông rộng tốc độ từ 2,5 Mbit /s trở lên được khuyến khích cho việc streaming phim
điện ảnh, ví dụ như AppleTV, GoogleTV hoặc SonyTV Blu-ray Disc Player, vào khoảng 10

-

Mbit/s cho các nội dung độ nét cao HD
Kích thước lưu trữ Streaming media được tính bằng băng thông để Streaming và chiều dài
của các tập tin Media, bằng cách sử dụng công thức sau đây (cho một người dùng duy nhất và
tập tin):
Kích thước lưu trữ (MB) = chiều dài (giây) × tỷ lệ bit (bit / s) / (8 × 1024 × 1024)
Ví dụ thực tế:
Một giờ video được mã hóa ở 300 kbit /s (đây là băng thông video điển hình năm 2005 và nó
thường được mã hóa 320 x 240 điểm ảnh) sẽ là:
(3.600 s × 300.000 bit / s) / (8 × 1024 × 1024) yêu cầu dung lượng lưu trữ ~128 MB.
Nếu tập tin được lưu trữ trên một máy chủ cho việc streaming theo yêu cầu và được xem bởi
1.000 người cùng một lúc bằng cách sử dụng một giao thức Unicast, yêu cầu là:
300 kbit/s × 1000 = 300.000 kbit/s = 300 Mbit/s của băng thông.
Điều này tương đương với khoảng 135 GB cho mỗi giờ. Sử dụng giao thức Multicast server
sẽ gửi ra chỉ một luồng đơn(thông thường) cho tất cả người dùng. Do đó, việc Stream như
vậy sẽ chỉ sử dụng 300 kbit/s băng thông.
Mã hóa âm thanh và video stream được nhúng trong một gói bitstream như FLV, WebM, ASF
hoặc ISMA.
Bitstream được phân phối từ một streaming server tới một streaming client bằng cách sử
dụng một giao thức truyền tải, ví dụ như là MMS hoặc RTP.
Các streaming client có thể tương tác với streaming server bằng cách sử dụng một giao thức

kiểm soát, chẳng hạn như MMS hoặc RTSP.


i.


Giao thức RTSP

Giới thiệu
- RTSP (Real Time Streaming Protocol) -Giao thức truyền tin thời gian thực là một tiêu chuẩn
-

do Nhóm chuyên trách kỹ thuật Internet - Internet Engineering Task Force (IETF) phát hành
là một giao thức điều khiển trên mạng được thiết kế để sử dụng giao tiếp giữa máy client và
máy streaming server. Giao thức này được sử dụng để thiết lập và điều khiển phiên giao dịch



giữa các máy tính (end points).
Đặc điểm
- RTSP là một giao thức ở tầng ứng dụng trong bộ các giao thức Internet .
- Về hình thức giao thức RTSP cũng có nét tương đồng với giao thức HTTP, RTSP định nghĩa
-

một bộ các tín hiệu điều khiển tuần tự, phục vụ cho việc điều khiển quá trình playback.
Trong khi giao thức HTTP là giao thức không có trạng thái thì RTSP là giao thức có xác định
trạng thái. Một định danh được sử dụng khi cần thiết để theo dõi các phiên giao dịch hiện tại

-


của quá trình streaming video gọi là số hiệu session.
Cũng giống như HTTP, RTSP sử dụng TCP là giao thức để duy trì một kết nối đầu cuối tới
đầu cuối và các thông điệp điểu khiển của RTSP được gửi bởi máy client tới máy server. Nó
cũng thực hiện điều khiển lại các đáp trả từ máy server tới máy client. Cổng mặc định được



sử dụng bởi giao thức này là 554.
Cách thực hiện
- Client 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.

B1.
+ client gửi yêu cầu OPTIONS kèm link trỏ tới file video cần xem tới server, để server chấp
nhận .

+Nếu server trả về mã chấp nhận link trên thì 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ừ server cho yêu cầu DESCRIBE của client bao gồm :
•

bản tin miêu tả chi tiết phiên giao dịch( Session Description Protocol – SDP).

•


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.

Hình 3: DESCRIBE Request
B2.
+client sẽ tiếp tục gửi tiếp yêu cầu SETUP tới 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.

Hình 4: SETUP Request
B3.
+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, client
gửi yêu cầu PLAY để thực hiện truyền các frame dữ liệu thật sự từ server tới 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ô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.


Hình 5: PLAY Request
Trong quá trình streaming video, nếu như người dùng muốn tạm dừng quá trình streaming
thì sẽ gửi yêu cầu PAUSE tới máy server, yêu cầu này sẽ làm tạm dừng một hay nhiều luồng dữ
liệu đang truyền các frame về máy client. Máy server sẽ tạm dừng gửi các frame dữ liệu tới máy
client.

Hình 6: PAUSE Request
Trong quá trình streaming video, nếu như người dùng muốn dừng hẳn quá trình streaming
thì sẽ gửi yêu cầu TEARDOWN để dừng truyền và kết thúc một phiên giao dịch của giao thức
RTSP. Máy server sẽ đáp trả lại thông điệp xác nhận cho yêu cầu TEARDOWN và sẽ dừng gửi
các frame tới máy client.

Hình 7: TEARDOWN Request
ii.


Giao thức RTP

Giới thiệu
- Tiêu chuẩn RTP (Real Time Transport Protocol) – Giao thức truyền tải thời gian thực
cung cấp các dịch vụ truyền tải dữ liệu tuân theo thời gian thực giữa các điểm đầu

cuối như là âm thanh, video. RTP do Nhóm chuyên trách kỹ thuật Internet (Internet
Engineering Task Force (IETF)) xây dựng và phát triển ban hành dưới dạng RFC



(Request for Comment)
Đặc điểm


RTP được thiết kế cho quá trình streaming theo thời gian thực từ theo kiểu điểm tới điểm.
Giao thức này cung cấp tiện ích để dò ra những gói tin RTP đã quá hạn. Trên thực tế, gói tin RTP
sử dụng địa chỉ IP trên mạng để định danh các máy tính gửi và nhận. RTP cũng hỗ trợ truyền dữ
liệu tới nhiều điểm đích thông qua địa chỉ IP multicast.
- RTP được sử dụng kết hợp với các giao thức khác như H.323 và giao thức RTSP. Chuẩn
RTP định nghĩa một cặp giao thức làm việc với nhau đó là RTP và RTCP. RTP được sử dụng để
truyền tải dữ liệu đa phương tiện và giao thức RTCP được sử dụng để gửi các thông tin điều
khiển với các tham số QoS. Đặc tả RTP gồm 2 giao thức con là RTP và RTCP:
•

Giao thức truyền, RTP, quy định cách thức truyền dữ liệu theo thời gian thực. Thông
tin được cung cấp bởi giao thức này bao gồm thời gian đồng bộ (timestamps), số thứ
tự gói tin (phục vụ cho việc tìm gói tin bi lạc ) và chi phí cho việc mã hóa định dạng
dữ liệu.

•

Giao thức điều khiển, RTCP được sử dụng cho việc kiểm tra chất lượng (QoS) luồng
dữ liệu và thực hiện đồng bộ giữa các luồng dữ liệu. So với RTP, thì băng thông của
RTCP sẽ nhỏ hơn, vào cỡ 5%.


Hình vẽ dưới đây là hình ảnh của một header của gói tin RTP

-Kích thước nhỏ nhất của một header của gói tin RTP là 12 bytes. Sau phần header chính, là phần
header mở rộng và không cần thiết phải có phần header này. Chi tiết các trường trong một header
như sau:
•

Version ( 2 bits): Cho biết phiên bản của giao thức này. Phiên bản hiện tại là
phiên bản 2.


•

P (Padding) (1 bit) : Cho biết số các byte mở rộng cần thêm vào cuối của gói
tin RTP. Ví dụ trong trường hợp ta muốn sử dụng các thuật toán mã hóa, ta có
thể thêm vào một số byte vào phần kết thúc của gói tin để tiến hành mã hóa
frame trên đường truyền.

•

X ( Extension) ( 1bit): Cho biết có thêm phần header mở rộng vào sau phần
header chính hay không.

•

CC (CSRC Count) ( 4 bit) : Chứa con số định danh CSRC cho biết kích thước
cố định của header.

•


M ( Marker) ( 1 bit) : Cho biết mức của ứng dụng và được định nghĩa bởi một
profile. Nếu được thiết lập, có nghĩa là dữ liệu hiện tại đã được tính toán chi
phí một cách thích hợp

•

PT (Payload Type) ( 7 bit) : Cho biết định dạng của file video. Đây là một đặc
tả được định nghĩa bởi một profile RTP.

•

Sequence Number (16 bits) : số hiệu của frame. Và sẽ được tăng lên 1 đơn vị
cho mỗi gói tin RTP trước khi gửi và được sử dụng bởi bên nhận để dò ra các
gói bị lạc và có thể phục hồi lại gói có số thứ tự đó.

•

Timestamp ( 32 bits): Được sử dụng thông báo cho bên nhận biết để phát lại
frame này trong khoảng thời gian thích hợp.

SSRC ( 32 bits): Định danh cho nguồn streaming. Mỗi nguồn cho phép streaming video
sẽ định danh bởi một phiên RTP duy nhất
iii.


Giao thức RTCP

Giới thiệu

Tiêu chuẩn RTCP (Real Time Transport Control Protocol) – Giao thức điều khiển vận chuyển

thời gian thực là một tiêu chuẩn do Nhóm chuyên trách kỹ thuật Internet (Internet Engineering
Task Force - IETF) phát hành.


Chức năng

Cung cấp phản hồi về chất lượng của việc truyền tải dữ liệu. Đây là một thành phần không thể
thiếu đối với giao thức RTP, đóng vai trò là giao thức vận chuyển và có liên hệ với luồng dữ liệu
và các chức năng điều khiển tắc nghẽn của các giao thức vận chuyển khác.


Cung cấp định danh giao vận (CNAME - canonical end-point identifiers – định danh điểm đầu
cuối) cho từng nguồn (source) trong RTP.
Đưa ra tỉ lệ các gói tin được gửi để từ đó RTP có thể giới hạn phạm vi số lượng đối tượng tham
gia truyền tải.
Cung cấp thông tin tối thiểu về việc điều khiển phiên truyền tải, ví dụ như việc xác định đối
tượng tham gia truyền tải được thể hiện trong giao điện người dùng.


Đặc điểm

Mỗi thành viên tham gia trong phiên RTP định kỳ gửi các gói điều khiển RTCP cho tất cả các
thành viên khác
Mỗi gói RTCP có báo cáo bên gửi hoặc báo cáo bên nhận
Báo cáo thống kê số gói gửi đi, số gói bị mất, độ trể mạng
thông tin này được sử dụng để kiểm soát hiệu suất hoặc bên gửi hiệu chỉnh việc truyền thông
Mỗi phiên RTP:sử dụng một địa chỉ multicast duy nhất
Gói RTP, RTCP phân biệt với nhau thông qua chỉ số cổng riêng biệt.



Các loại gói tin

SR (Sender Report): chứa các thông tin nhằm đồng bộ các gói tin, thống kê việc truyền, nhận…
RR (Receiver Report): các thông tin phản hồi về dữ liệu nhận được, số gói tin nhận được và mất,
độ tắc nghẽn…
SDES (Source DEScription items): Thông tin mô tả về nguồn gởi, bao gồm cả CNAME.
BYE: Xác định việc kết thúc tham gia trao đổi thông tin, báo kết thúc phiên làm việc
APP (APPlication specific functions): Xác định các chức năng phụ thuộc vào từng ứng dụng cụ
thể


Đồng bộ dữ liệu

RTCP có thể đồng bộ giữa các dòng dữ liệu khác khau trong cùng một phiên RTP. Ví dụ hội nghị
trực tuyến, mỗi người gửi tạo ra một dòng RTP với video, một dòng cho audio


Mỗi gói RTCP báo cáo bên gửi chứa: Nhãn thời gian của gói RTP và Thời điểm hiện hànhkhi
gói tin được tạo ra
Bên nhận dùng nó để đồng bộ phát sóng audio, video


Tỉ lệ băng thông

RTCP cố gắng hạn chế lưu lượng của nó chỉ đến 5% băng thông của phiên làm việc
RTCP cung cấp 75% cho các bên nhận, 25% cho bên gửi.

Chương IV: Tài liệu tham khảo
1. />2. />3. />