Đề tài sử dụng phần mềm hệ thống truyền hình ảnh kỹthuật số (digital video transport system – DVTS)

-1-

Lời nói đầu
Sự xuất hiện và phát triển của internet tới ngày này đã làm thay đổi hoàn
toàn thế giới bởi những đóng góp to lớn của nó. Với những ngày đầu nó chỉ phục
vụ cho mục đích quốc phịng của Mỹ vào cuối năm 1960 có tên là ARPANET, qua
những năm phát triển sau đó internet được lan rộng và phục vụ cho mục đích dân
sự. Với khả năng kết nối mở, Internet đã trở thành một mạng lớn nhất trên thế giới,
mạng của các mạng, chúng giao tiếp với nhau qua giao thức.
Bởi chính tiện ích internet mang lại, do đó nhiều doanh nghiệp muốn triển
khai định hướng kinh doanh trên internet để cung cấp các sản phẩm, dịch vụ cần
thiết cho người dùng. Bên cạnh đó một số trường đại học, viện nghiên cứu, cũng
cho ra đời nhiều ứng dụng giúp ích cho con người thuận tiện trong việc trao đổi
thơng tin từ xa.
Hội nghị truyền hình trực tiếp là một ứng dụng cụ thể cho thành tựu nghiên
cứu của trường đại học Keio, Nhật Bản chạy trên mơi trường mạng. khắc phục khó
khăn về mặt địa lí cũng như tiết kiệm thời gian và chi phí. Với kỹ thuật mới, ứng
dụng giúp trao đổi giữa hai đầu truyền hình đạt chất lượng cao. Tại các bệnh viện,
hội chẩn đoán bệnh từ xa nhận ý kiến, thảo luận từ những bác sĩ giỏi trên thế giới
qua cầu truyền hình, đưa ra phương pháp tối ưu nhất cho việc điều trị. Hội nghị
này tạo điều kiện cho nhiều đơn vị, tổ chức, bệnh viên trao đổi kinh nghiệm, thắt
chặt mối liên kết toàn cầu cùng nghiên cứu đưa ra giải pháp trong y khoa . Ngoài
ra phục vụ cho các chương trình học từ xa và nhiều ứng dụng hơn nữa.
Do sự phát triển ngày càng mạnh mẽ của khoa học và công nghệ tạo ra
nhiều ứng dụng trong thực tiễn, chính vì vậy mơ hình này cần chú trọng, nghiên
cứu và phát triển lan rộng hơn nữa trong tương lai.


-2-

Chương 1: Tổng quan về hệ thống DVTS

1.1. Hội nghi truyền hình(video conferencing)
Để có cuộc hội nghị, hội thảo, diễn đàn từ xa thì một trong những điều kiện
khơng thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và công
nghệ.
Sử dụng các thiết bị chuyên dụng dành cho Hội nghị truyền hình (Video
Conferencing) là một trong những giải pháp hữu hiệu. Tuy nhiên, thiết bị dành cho
hội nghị truyền hình có giá thành cao, khơng phải đơn vị nào cũng có thể tự mua
sắm riêng một bộ, số điểm truy cập từ xa cũng bị hạn chế, việc cài đặt, sử dụng
phần mềm điều khiển cần được đào tạo hướng dẫn một thời gian khá dài trước khi
có thể sử dụng thành thạo các thiết bị chuyên dụng đó.
Một giải pháp đơn giản và hiệu quả hơn được sử dụng phổ biến hiện nay ở
nhiều Mạng Nghiên cứu và Đào tạo Quốc gia (NREN) ở các nước khác như: Hàn
Quốc, Nhật Bản, Thái Lan, Trung Quốc, Đài Loan, Indonesia, Malaysia, Philippine,
Úc, Tây Ban Nha…đó chính là sử dụng phần mềm Hệ thống truyền hình ảnh kỹ
thuật số (Digital Video Transport System – DVTS) :
Hệ thống đơn giản
Kinh phí thấp
Dễ sử dụng ( khơng cần đào tạo nhân lực)
1.2. Digital Video Transport System
1.2.1 Khái niệm
Digital Video Transport System viết tắt DVTS là một phần mềm ứng dụng
chạy trên đường truyền mạng máy tính 30Mbps khơng nén video để gửi và nhận
hình ảnh, âm thanh chất lượng cao với độ trễ thấp. DVTS có thể chạy trên hệ điều
hành khác nhau và hệ thống phân phối hình ảnh chất lượng bằng việc kết nối DVTS
với máy tính cá nhân thơng qua cổng giao tiếp IEEE1394.


-3-

Tổng quan

DV Mode Application
Support IEEE1394 output 

Not support IEEE1394 output
Please use HDVout tool instead!!

HDV Mode Application

DVTS

Hình 1.1: Minh họa phần mềm DVTS
Qua quá trình nghiên cứu triển khai và ứng dụng thực tiễn khi tham gia vào các
diễn đàn do CanalAVIST , trường Đại học Kyushu Nhật Bản tổ chức, có thể thấy
một số ưu điểm của việc sử dụng DVTS đó là:
-

Cài đặt phần mềm đơn giản, khơng mất nhiều thời gian, có thể tải phần mềm
về Internet;

-

Giao diện đơn giản, dễ thao tác và sử dụng;

-

Các đơn vị thành viên, cá nhân có thể tham gia diễn đàn, hội nghị, hội thảo
từ xa, đào tạo từ xa .

-

Hình ảnh được gửi đi và nhận đến có chất lượng cao….

-

Âm thanh phải sử dụng âm li điều chỉnh âm thanh mới chất lượng tốt…

-

Phần mền không tự lưu trữ, việc lưu trữ phụ thuộc máy quay video.

-

Khơng tích hợp truyền text(chat).


-4-

-

Có một khung hình nhận video.
1.2.2. Khả dụng của DVTS mang lại
1.2.2.1. Kết nối tồn cầu
Thơng qua đường truyền cáp quang băng thông rộng đã liên kết nhiều quốc

gia và DVTS là cầu nối cho các chuyên gia cùng nhau chia sẽ thuộc nhiều phạm vi .

Hình 1.2 : mơ hình mạng nghiên cứu thế giới
1.2.2.2. Ứng dụng trên thế giới
Phần mền DVTS ứng dụng rộng rãi:

• Các trường Đại học bang Florida Sở Dance sử dụng DVTS " thực hiện
hội nghị"
• The New World Symphony sử dụng DVTS cho các chương trình học từ xa
cho các nhạc sĩ và các lớp học thạc sĩ.
• Trung tâm Excellence for Remote and Medically Under Served Areas sử
dụng DVTS phục vụ cho giáo dục y tế.


-5-

• Nghiên cứu bệnh học tại Đại học Pennsylvania hệ thống y tế đang thử
nghiệm với DVTS cho telemicroscopy.
• DVTS cũng được sử dụng cho các sự kiện văn hóa khoa học, chẳng hạn
như nở hoa arum Titan.
1.2.2.3. Ứng dụng mạng nghiên cứu và đào tạo VinaREN
VinaREN là mạng Nghiên cứu và Đào tạo[7] Việt Nam hoạt động tháng
3-2008, mang lại nhiều lợi ích trong hoạt động nghiên cứu và đào tạo cho các đơn
vị thành viên tham gia kết nối và sử dụng hệ thống DVTS. Một trong những lợi ích
thiết thực và đem lại hiệu quả cao cho các thành viên đó chính là việc tổ chức tham
gia vào các diễn đàn, hội nghị, hội thảo từ xa qua mạng VinaREN[2], mạng TEIN.
Khi tổ chức tham gia các sự kiện, các kỹ sư công nghệ thông tin, các giáo
sư, bác sĩ đến từ các trường đại học, bệnh viện trong nước như: Đại học Bách Khoa
Hà Nội, Đại học Thuỷ lợi, Đại học Y Hà Nội, Đại học Huế, Bệnh viện Trung ương
Quân đội 108, Học viện Quân y, Bệnh viện Bạch Mai, Bệnh viện Nhi Trung ương,
Bệnh viện Việt Đức,….đã có điều kiện được phổ biến thêm những kiến thức, kỹ
thuật chuyên môn mới.
Thông qua việc truyền nhận hình ảnh qua DVTS, các giáo sư, bác sĩ của
các bệnh viện đã có điều kiện tham gia các cuộc phẫu thuật nội soi được thực hiện
trực tiếp tại các phịng mổ của các bệnh viện ở nước ngồi như: Prince of Wales
Hospital, Hong Kong. Mạng VinaREN phối hợp với Bệnh viện 108 tổ chức tham

gia sự kiện “International GI Endoscopy Live Demonstration” diễn ra tại Bangkok,
Thailan. Tại sự kiện này, các bác sĩ của Việt Nam tiếp tục có dịp tham gia vào
những ca mổ được thực hiện trực tiếp tại các phịng mổ của các bệnh viện.
Ngồi ra mạng VinaREN và một số đơn vị thành viên đã cùng phối hợp
tổ chức thành công khi tham gia các diễn đàn, hội nghị, hội thảo từ xa với các tổ
chức, các mạng nghiên cứu và đào tạo nước ngoài như:
Về E-Learning:


-6-

- Diễn đàn CanalAVIST – ICT Forum, ngày 31/7 và 1/8/2008. Các nước tham
gia: Việt Nam, Úc, Nhật Bản, Xingapo, Thái Lan. ( />- Diễn đàn Asian School on Computer Science, ngày 16 và 17/11/2008. Các nước
tham

gia:

Thái

Lan,

Việt

Nam,

Phillipin,

Xingapo.(

/>Về Telemedicine:

- Diễn đàn Medical, ngày 11 và 19/9/2008. Các nước tham gia:Việt Nam,
Inđônêxia,

Nhật

Bản,

Hàn

Quốc,

Malaixia,

Thái

Lan,

Xingapo.

( />- Hội thảo “23rd International WorkshoponTherapeutic Endoscopy” (với phần
trình diễn “Live Demonstration of Endoscopy”, tổ chức ngày 9/12/2008. Các nước
tham gia: Nhật Bản, Hồng Kông, Thái Lan, Đài Loan, Việt Nam.
-

Hội thảo chuyên đề “Tele-lecture of Laparoscopic Colo-Rectal Surgery” tại

Hội nghi APAN lần thứ 27. (www.apan.net ).
1.3 Xây dựng mục tiêu
Thực hiện hội nghị truyền hình(video conferencing) thì một trong những điều
kiện khơng thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và

công nghệ. Sử dụng những thiết bị chuyên dụng này là một trong những giải pháp
tốt. Xong bên cạnh đó khơng phải đơn vị nào cũng trang bị cho riêng một bộ.
Từ những khó khăn trang thiết bị nêu trên, đã đưa ra giải pháp xây dựng ra hệ
thống Digital Video Transport System(DVTS) có thể truyền hình ảnh, âm thanh
chất lượng cao với các mục tiêu chính như sau:
- Chạy trên mạng internet:
- kết nối từ camera: IEEE 1394, USB 2.0 camera.
- kết nối sound on board.
- Truyền text(chat).
- Lưu trữ video.
- Xem lại video.


-7-

Để thực hiện những mục tiêu đề ra ta cần tới một ứng dụng máy chủ RED5 đây
là một máy chủ mã nguồn mở viết bẳng ngơn ngữ java đóng vai trị làm trung gian
thực hiện cơng việc trung chuyển hình ảnh, âm thanh. Trên máy chủ Red5 này ta
tạo ra gói AppServer phản hồi các kết nối từ client, lưu trữ video và sreaming video.
Ngoài ra tạo một ứng dụng Client có tên LHDVTS viết bằng ngơn ngữ Mxml +
ActionScript thực hiện cơng việc chính truyền, hiển thị hình ảnh, âm thanh nhận từ
server, chat và xem lại video.
Nghiên cứu các chuẩn nén :
™ Chuẩn nén âm thanh High Efficiency AAC(HE-AAC)

Hình 1.3: mơ hình tích hợp chuẩn nén HE-AAC
™ Chuẩn nén hình ảnh Moving Picture Experts Group/H264(MPEG4/H264)

Hình 1.4: mơ hình chia nhỏ hình ảnh cosine trong MPEG-4/H264

-8-

™ Giao thức truyền thời gian thực RTMP(Real Time Messaging protocol)
- RTMP chạy trên TCP với port 1935.
- RTMP chạy đường hầm trên kết nối HTTP port 80.
- RTMPS là RTMPT kết nối bảo mật sử dụng cho HTTPS.

RTMP ở chế độ tiêu chuẩn

RTMP ở chế độ đường hầm
Hình 1.5: gói tin rtmp được cắt nhỏ trong các dạng đường truyền.


-9-

Chương 2
Mơ hình hệ thống và máy chủ Red5
2.1. Mơ hình hệ thống
2.1.1. Mơ hình Peer to Peer

Hình 2. 1: Mơ hình Peer to Peer trong DVTS
Mơ hình Peer to Peer được sử dụng bởi một số phần mềm cung cấp dịch vụ
video như Skype, DVTS, … Có nhiều giải pháp cho mơ hình Peer to Peer, trong đó
DTVS là một hệ thống cho phép chuyển phát hình ảnh, âm thanh giữa các nơi sử
dụng mơ hình này bằng địa chỉ IP Multicast (như trong hình).
Ưu điểm chủ yếu của mơ hình này là khả năng tận dụng các máy đầu cuối.
Tuy nhiên nhược điểm của nó là khơng thể quản lý được người dùng nếu ở mơ
hình Peer to Peer truyền thống. Do đó việc áp dụng rộng rãi mơ hình này gặp nhiều
khó khăn cho những tổ chức nhỏ.

- 10 -

2.1.2. Mơ hình Client – Server

Hình 2.2: Mơ hình Client – Server
Mơ hình Client – Server là một mơ hình thơng dụng được sử dụng bởi các nhà
cung cấp dịch vụ video nổi tiếng như Yahoo, Youtube,…
• Mơ hình này có nhiều ưu điểm:
- Khả năng đáp ứng nhanh: người dùng có thể kết nối đến server dễ nhành để
nhận được sự cung cấp dịch vụ.
- Dễ dàng cho việc thi công và cung cấp dịch vụ: nhà cung cấp dịch vụ chỉ cần
thiết kế server quản lý và cung cấp dịch vụ của mình. Sau đó để đưa tới tay người
sử dụng thì chỉ cần sử dụng thêm tên miền hoặc địa chỉ IP là có thể sẫn sàng đáp
ứng dịch vụ cho người dùng.
- Dễ dàng quản lý truy cập của người dùng.
• Nhược điểm chủ yếu của mơ hình này là :
- Dễ dàng bị quá tải do số người truy cập tăng.
Tuy nhiên có thể giải quyết vấn đề này bằng cách tuỳ thuộc vào khả năng của máy
làm server, người quản trị hoặc người thiết kế dịch vụ cần giới hạn khả năng đáp


- 11 -

ứng của dịch vụ. Hoặc xây dựng các giải pháp về mạng khác để tăng khả năng đáp
ứng cho server tránh bị quá tải khi yêu cầu tăng. Với các nhận định trên, trong quá
trình phát triển server chuyển phát âm thanh và hình ảnh, em đã sử dụng mơ hình
Client – Server.

2.1.3 Kiến trúc Server
Kiến trúc của server được thiết kế như hình sau:

Hình 2.3: Kiến trúc của Server
Server hoạt động dựa trên nền tảng giao thức RTMP đóng vai trị như một
framework. Các ứng dụng (Application) hoạt động trên Server trong suốt với giao
thức, server đảm nhiệm công việc làm trong suốt này và giúp cho ứng dúng chạy
trên Server liên lạc được với các Client tham gia vào ứng dụng này.


- 12 -

Trong một ứng dụng được chia làm nhiều phịng (Room). Trong mỗi phịng
có nhiều người dùng (User). Mỗi người dùng này thực chất là một Client đang hoạt
động kết nối tới Server với một ứng dụng được cung cấp nào đó của Server.
Cũng theo mơ hình kiến trúc mỗi Client cịn có nhiều kênh (Channel). Các
kênh này giúp cho người dùng có thể nhận cùng lúc nhiều loại dữ liệu khác nhau mà
không cần phải tạo nhiều kết nối tới Server.
Hình minh hoạ trên chỉ ra một Server cung cấp các ứng dụng cho phép các
người dùng chia sẻ video, nhạc và một ứng dụng cho phép các bác sĩ tạo và tham
gia vào các cuộc hội chẩn từ xa. Mỗi phịng có nhiệm vụ giống như một cuộc hội
chẩn. Còn các kênh giúp cho các bác sĩ vừa có thể xem các đoạn video về ca phẫu
thuật đang tiến hành, vừa có thể nói chuyện bàn bạc được với nhau. Đồng thời các
bác sĩ cũng có thể xem thơng tin bệnh nhân và các hình ảnh liên quan tới bệnh nhân
này.
2.2 Máy chủ Red5
Red5 là một máy chủ mã nguồn mở Flash Server viết bằng ngôn ngữ Java. Hệ
thống Server được xây dựng đã hỗ trợ sẵn các dịch vụ về hình ảnh, âm thanh.
Server sử dụng chuẩn nén Video H.264 và Audio HE-AAC. Chuẩn nén H.264 có tỉ
số nén cao nhưng vẫn khơng làm giảm nhiều chất lượng Video. Người ta tính tốn

ra được đối với chuẩn nén H.264 khi Video có độ phân giải 700x525 và tốc độ
frame là 30 frame/sec thì băng thơng u cầu nhỏ hơn 1.5 Mbps. Với băng thông
yêu cầu chỉ khoảng 1.5 Mbps thì hệ thống Server đang được xây dựng có thể hoạt
động trên những đường truyền Internet tốc độ trung bình.
Nếu so sánh hệ thống đang được xây dựng với các giải pháp phần cứng thì hệ
thống đang được xây dựng sẽ có chi phí thấp hơn đáng kể do không cần sử dụng các
thiết bị chuyên dụng, không cần phải sử dụng kênh thuê riêng nhưng về chất lượng
truyền dẫn thì khơng đảm bảo bằng vì trên các đường truyền Internet thơng thường
có thể xảy ra tắc nghẽn. Ngoài ra do sử dụng Web và Flash nên hệ thống đang được
xây dựng có tính khả chuyển và mềm dẻo chứ không bị cố định tại một vài địa điểm


- 13 -

như các hệ thống phần cứng. Việc thêm một địa điểm tham gia vào ứng dụng chỉ
cần một máy tính có gắn camera và phone là đủ mà không cần phải đầu tư thêm
thiết bị đắt tiền như các hệ thống dựa trên phần cứng.
Dưới đây là những hỗ trợ của máy chủ Red5 :
•

Streaming Video (FLV, F4V, MP4, 3GP)

•

Streaming Audio (MP3, F4A, M4A, AAC)

•

Recording Client Streams (FLV and AVC+AAC in FLV container)

•

Shared Objects

•

Live Stream Publishing

•

Remoting

•

Protocols: RTMP, RTMPT, RTMPS, and RTMPE


- 14 -

Chương 3
Giao thức truyền và các chuẩn nén
3.1. Giao thức truyền tải dữ liệu thời gian thực
3.1.1. Giới thiệu
Mạng Internet vốn được xây dựng để truyền dữ liệu, và các giao thức truyền
tải lớp Transport như TCP (Transmission Control Protocol) hay UDP (User
Datagram Protocol) chỉ có khả năng truyền dữ liệu từ đầu cuối đến đầu cuối mà
không có bất kì cơ chế nào để đảm bảo gói dữ liệu được truyền đến đích trong một
thời gian xác định nghĩa là không đảm bảo vấn đề thời gian thực cho âm thanh, hình
ảnh. Khi truyền một gói dữ liệu trên mạng Internet có nhiều nguyên nhân khiến gói
dữ liệu đến đích khơng đúng thời gian (có thể đến sớm hoặc đến trễ) chẳng hạn như

lưu lượng trên mạng tại thời điểm gửi quá lớn, cũng có thể gói dữ liệu phải đi qua
một link có tốc độ thấp, một hoặc vài router bị quá tải… khiến cho gói dữ liệu đến
trễ không theo một quy luật nào (jitter). Ngồi ra cịn vấn đề mất gói dữ liệu khi
Time-to-Live trong gói dữ liệu bị giảm xuống 0, các router drop các gói dữ liệu khi
bị quá tải…Tất cả các ngun nhân trên khiến cho mạng Internet khơng thật thích
hợp để truyền âm thanh,hình ảnh. Tuy nhiên, người ta sử dụng cơ chế “Buffering”
(vùng đệm Playback) ở phía nhận để giảm jitter khi truyền âm thanh, hình ảnh trên
mạng Internet. Cơ chế này như sau:

Hình 3.1: Vùng đệm dùng cho việc playback


- 15 -

Bên nhận khi nhận được dữ liệu thì không phát ra ngay mà lưu vào vùng
đệm K. Khi vùng đệm K đầy thì bên nhận bắt đầu phát hình ảnh và âm thanh (lấy
dữ liệu ra khỏi vùng đệm K với một tốc độ không đổi). Trong lúc phát âm thanh,
hình ảnh thì nó tiếp tục nhận dữ liệu âm thanh, hình ảnh từ bên gửi bù đắp vào dữ
liệu được lấy ra khỏi vùng đệm K để phát. Nếu chỉ có trì hỗn nhỏ xảy ra thì vùng
đệm K sẽ không bị cạn kiệt và đảm bảo triệt tiêu jitter, nếu có trì hỗn lớn hoặc mất
dữ liệu thì tới một lúc nào đó vùng đệm K sẽ bị cạn kiệt, khi đó bên nhận sẽ dừng
phát âm thanh, hình ảnh và phải tiến hành thao tác trên lại từ đầu. Có một vài điểm
đáng lưu ý khi chọn kích thước của vùng đệm K. Nếu chọn K lớn thì có thể giảm
đáng kể jitter nhưng thời gian chờ đợi trước khi bắt đầu phát âm thanh, hình ảnh sẽ
rất lâu. Ngược lại nếu chọn K nhỏ thì thì thời gian chờ đợi trước khi bắt đầu phát
âm thanh, hình ảnh sẽ ngắn nhưng trong quá trình phát thường hay dừng để đệm lại
dữ liệu.
3.1.2. Giao thức RTP (Real Time Transport Protocol)
3.1.2.1 Định dạng RTP
Giao thức này tên là giao thức truyền tải thời gian thực nhưng nó khơng chứa

đựng các cơ chế đảm bảo truyền dữ liệu đúng thời hạn, những đảm bảo này phải
được cung cấp bởi hệ thống cơ sở. Thay vì thế, RTP cung cấp hai phương tiện chủ
chốt: đánh số thứ tự trong mỗi packet để cho phép nơi nhận phát hiện ra việc
chuyển phát không đúng thứ tự hoặc bị mất, và timestamp để cho phép nơi nhận
kiểm sốt việc playback.
Vì RTP được thiết kế để truyền tải nhiều loại dữ liệu thời gian thực khác nhau,
bao gồm cả âm thanh và video, nên RTP khơng bó buộc một cách diễn dịch ngữ
nghĩa chung nhất. Thay vì thế, mỗi packet bắt đầu với một phần đầu cố định; các
vùng trong phần đầu này xác định cách diễn dịch các vùng còn lại. Sau đây là định
dạng phần đầu trong RTP.


- 16 -

Hình 3.2: Khn dạng giao thức RTP
Mỗi packet bắt đầu với một số phiên bản (2-bit) của RTP trong vùng V; phiên
bản hiện tại là 2. Vùng 16 bit “Sequence number” chứa số thứ tự của packet. Số thứ
tự đầu tiên trong một giao dịch được chọn ngẫu nhiên. Có một số ứng dụng định
nghĩa sự mở rộng tùy chọn cho phần đầu, được đặt giữa phần cố định và phần
payload. Nếu kiểu của ứng dụng cho phép việc mở rộng, thì bit X được sử dụng để
xác định xem phần mở rộng có tồn tại trong packet khơng. Việc diễn dịch của hầu
hết các vùng cịn lại trong phần đầu tùy thuộc vào vùng 7 bit PT (payload Type) để
xác định kiểu playload; nó được sử dụng với việc mã hóa; trong đó yêu cầu dữ liệu
được cấp phát theo những khối cố định. Việc diễn dịch của bit M (marker) cũng tùy
thuộc vào ứng dụng, nó được sử dụng bởi ứng dụng nào cần đánh dấu các điểm đặc
biệt trong dòng dữ liệu.
Kiểu payload cũng ảnh hưởng đến việc diễn dịch của vùng Timestamp.
Timestamp là một giá trị 32 bit để cho thời gian tại đó octet đầu tiên của dữ liệu số
hóa được lấy mẫu, với timestamp ban đầu được chọn ngẫu nhiên. Chuẩn xác định
rằng timestamp được tăng liên tục, ngay cả trong những lúc khơng có tín hiệu hay

khơng có giá trị được gửi đi, nhưng nó khơng xác định độ gia tăng chính xác. Độ
gia tăng được xác định bởi kiểu payload, nghĩa là mỗi ứng dụng có thể chọn một độ
gia tăng, cho phép nơi nhận định vị được những mục trong dữ liệu xuất với mục
chính xác thích hợp trong ứng dụng. Ví dụ, nếu một dịng dữ liệu thoại được truyền


- 17 -

qua RTP, thì độ gia tăng timestamp (theo logic) một nhịp đồng hồ cho một mẫu là
thích hợp. Tuy nhiên, nếu dữ liệu video được truyền, thì độ gia tăng timestamp cần
phải lớn hơn để cho việc playback được trung thực.
3.1.2.2 . Đóng gói RTP
Từ tên gọi của nó, RTP là giao thức mức chuyên chở. Nếu nó đóng vai trị như
giao thức chun chở thơng thường, thì RTP sẽ u cầu mỗi thơng điệp được đóng
gói trực tiếp trong một IP datagram. Thực ra, RTP khơng có chức năng là giao thức
chuyên chở; mặc dù nó được phép, nhưng việc đóng gói trực tiếp trong IP khơng
xảy ra trong thực tế. Thay vì thế, RTP chạy trên UDP; có nghĩa là mỗi thơng điệp
RTP được đóng gói trong một UDP datagram. Ưu điểm chính của việc sử dụng
UDP là xử lí song song – một máy tính có thể có nhiều ứng dụng cùng sử dụng
RTP.

Hình 3.3: Minh họa đóng gói tiêu đề RTP
Khơng giống như nhiều giao thức ứng dụng khác, RTP không sử dụng một giá
trị cổng UDP dành riêng. Thay vì thế, một cổng được cấp phát để sử dụng cho mỗi
giao dịch, và ứng dụng ở xa phải được thông báo về giá trị cổng này. Theo qui ước,
RTP chọn một cổng UDP có số chẵn.
3.1.3. Giao thức RTMP (Real Time Messaging Protocol)
3.1.3.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.


- 18 -

Đâ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.
3.1.3.2. 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. Ngồi ra
RTMP[8] 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 3.4: RTMP ở chế độ tiêu chuẩn

Hình 3.5: RTMP ở chế độ đường hầm
3.1.3.3. 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 đó.


- 19 -

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.6: 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 q 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.
3.1.3.4. 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


- 20 -

• 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 3.7: 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.