TRƯỜNG ĐẠI HỌC HỒNG ĐỨC

KHOA CNTT & TT

BÁO CÁO TỔNG KẾT

THỰC TẬP TỐT NGHIỆP

NĂM HỌC 2020 - 2021

ĐỀ TÀI: XÂY DỰNG GIẢI PHÁP

VIDEO STREAMING ĐA NỀN TẢNG

Thuộc nhóm ngành khoa học: Khoa học máy tính

THANH HÓA, THÁNG 3/2021

 TRƯỜNG ĐẠI HỌC HỒNG ĐỨC
KHOA CNTT & TT

BÁO CÁO TỔNG KẾT

THỰC TẬP TỐT NGHIỆP

NĂM HỌC 2020 - 2021

ĐỀ TÀI: XÂY DỰNG GIẢI PHÁP

VIDEO STREAMING ĐA NỀN TẢNG

Thuộc nhóm ngành khoa học: Khoa học máy tính

Sinh viên thực hiện: Lưu Nguyên Bằng Nam, Nữ: Nam
Dân tộc: Kinh
Lớp, khoa: K19 ĐH CNTT Năm thứ: 4 /Số năm đào tạo: 4
Ngành học: Công nghệ thông tin

Người hướng dẫn: PGS.TS. Phạm Thế Anh

THANH HÓA, THÁNG 3/2021

Trang i DANH SÁCH THÀNH VIÊN TRONG NHÓM TTTN

TT Họ và tên Lớp Nội dung tham gia

1 Lưu Nguyên Bằng K19 ĐH CNTT Cài đặt, làm báo cáo
Trang ii MỤC LỤC

Mục Tên chương, phần, mục và tiểu mục Trang

Danh sách thành viên trong nhóm TTTN i
Mục lục ii
Danh mục các bảng biểu iii
Danh mục các ký hiệu, chữ viết tắt iv
Thông tin kết quả nghiên cứu v
Chương I GIỚI THIỆU VỀ WEB RTC 1
1 Sơ lược lịch sử phát triển 1
2 Thiết kế của Web RTC 2
2.1 Các thành phần chính 2
2.2 Các giao thức được sử dụng 3
2.3 Kiến trúc hệ thống WebRTC 3
3 Những lợi ích của WebRTC 4
Chương II GIỚI THIỆU VỀ KURENTO MEDIA SERVER 6
1 Khái niệm Media Servers 6
2 Kurento và Kurento Media Server 7
2.1 Giới thiệu chung 7
2.2 Nguyên lý thiết kế của Kurento 9
2.3 Kurento API 10
Chương III GIẢI PHÁP VIDEO STREAMING ĐA NỀN TẢNG 15
CHO CAMERA IP BẰNG KURENTO
1 Kiến trúc phát triển ứng dụng 17
2 Tích hợp WebRTC và Camera IP 25
3 Sử dụng Kurento Media Server 27
4 Giải pháp video streaming đa nền tảng 30
5 Các vấn đề về chứng chỉ tự ký 32
6 Kết quả thử nghiệm 35
7 Kết luận 38
8 Tài liệu tham khảo 39
 Trang iii DANH MỤC CÁC HÌNH ẢNH, BẢNG BIỂU

TT Tên bảng biểu

Hình 1.1 Protocol Stack trong WebRTC
Hình 1.2 Kiến trúc phổ biến của hệ thống WebRTC
Hình 2.1 WebRTC P2P và WebRTC có media server
Hình 2.2 Những tính năng của WebRTC Media Server điển hình
Hình 2.3 Những tính năng của Kurento Media Server
Hình 2.3
Hình 2.4 Cài đặt Kurento Client API trong Java SDK và Javascript SDK
Bảng 2.1 Các Endpoint trong Kurento API
Bảng 2.2 Các Filter trong Kurento API
Bảng 2.3 Các Hub trong Kurento API
Hình 2.5 Hộp công cụ Kurento mở rộng
Hình 2.6 Các mô-đun trong Kurento Media Server
Hình 3.1 Sự tương đồng trong kiến trúc phân lớp của ứng dụng web và ứng dụng
đa phương tiện (Kurento)
Hình 3.2 Các mặt phẳng truyền thông và tín hiệu trong kiến trúc ứng dụng
Kurento
Hình 3.3 Tương tác chính giữa các mô-đun trong đàm phán và trao đổi media
Hình 3.4 Tương tác trong một phiên WebRTC
Hình 3.5 Ví dụ pipeline cho một phiên WebRTC
Hình 3.6 Ví dụ một Media Pipeline đơn giản
Hình 3.7 Kiến trúc đơn giản của Media Gateway
Hình 3.8 Kiến trúc đầy đủ của Media Gateway WebRTC
Hình 3.9 Kiến trúc Media Gateway trong Kurento Media Server
Hình 3.9
Hình 3.10 Cấu hình xử lý cho nhiều người xem trên thiết bị đầu cuối khác nhau
Hình 3.11 Đo các thông số CPU và RAM tại máy chủ streaming
Hình 3.12 Hình ảnh video streaming của 6 camera
Trang iv DANH MỤC CÁC KÍ HIỆU, CHỮ VIẾT TẮT

Ký hiệu, chữ viết tắt Được hiểu là

WebRTC Giao tiếp web thời gian thực
(Web Real-time Communication)
P2P Liên kết ngang hàng (peer-to-peer)
API Giao diện lập trình ứng dụng
(Application Programming Interface)
KMS Máy chủ truyền thông Kurento (Kurento Media Server)
SDK Bộ công cụ phát triển phần mềm
(Software Developmenrt Kit)
SRTP Giao thức truyền dữ liệu thời gian thực có đảm bảo
(Secure Real-time Transport Protocol)
REMB Tốc độ bit tối đa theo bên nhận ước lượng
(Receiver Estimated Maximum Bitrate)
PLI Dấu hiệu mất hình ảnh (Picture Loss Indication)
GIF Định dạng trao đổi hình ảnh
(Graphics Interchange Format)
HTML Ngôn ngữ đánh dấu siêu văn bản
(Hypertext Markup Language)
HTTPS Giao thức truyền tải siêu văn bản bảo mật
(Hyper Text Transfer Protocol Secure)
RTSP Giao thức truyền tin thời gian thực
(Real Time Streaming Protocol)
 SSL Tầng socket bảo mật (Secure Sockets Layer)

Trang v THÔNG TIN KẾT QUẢ NGHIÊN CỨU

1. Tên đề tài: Xây dựng giải pháp media streaming đa nền tảng
2. Loại đề tài: Thực tập tốt nghiệp
3. Nhóm sinh viên thực hiện:
- Họ và tên: Lưu Nguyên Bằng - Mã sinh viên: 1661030009
- Khoa: Công nghệ thông tin và Truyền thông
4. Giảng viên hướng dẫn: PGS.TS Phạm Thế Anh
5. Thời gian thực hiện: 04 tháng (từ tháng 11/2020 đến tháng 3/2021).
 CHƯƠNG I: GIỚI THIỆU VỀ WEB RTC

1. SƠ LƯỢC LỊCH SỬ PHÁT TRIỂN

WebRTC (Web Real-Time Communication) là một web API được phát
triển bởi Google và Hiệp hội W3C (World Wide Web Consortium), có khả năng
hỗ trợ trình duyệt giao tiếp với nhau thông qua Video Call, Voice Call hay
truyền dữ liệu Peer-to-Peer (P2P) mà không cần browser phải cài thêm plugins
hay phần mềm hỗ trợ nào từ bên ngoài.
WebRTC bắt đầu từ lúc Google muốn xây dựng một chuẩn thay thế cho
Flash để thực hiện các ứng dụng thời gian thực trên tất cả các trình duyệt. Năm
2010, Google mua lại hai công ty On2 và Global IP Solutions (GIPS) để lấy
công nghệ truyền dữ liệu thời gian thực làm nền tảng cho WebRTC về sau.
Tháng 5/2011, Google ra mắt một dự án mã nguồn mở dành cho việc giao
tiếp thời gian thực giữa trình duyệt với nhau, và từ lúc này dự án mang tên
WebRTC. Song song đó, Hiệp hội World Wide Web (W3C) và Hiệp hội Kĩ sư
quốc tế (IETF) cũng đang phát triển một số giao thức để dùng cho việc việc kết
nối thời gian thực, thế nên họ bắt tay nhau tiếp tục hoàn thiện để rồi quyết định
kết hợp chung vào WebRTC.
Đến 27/10/2011, W3C ra mắt bản nháp đầu tiên của WebRTC. Tháng
11/2011, Chrome 23 ra mắt, trở thành trình duyệt đầu tiên có hỗ trợ sẵn (built-
in) WebRTC. Dưới đây là một số mốc thời gian trong quá trình phát triển của
WebRTC:
 5/2011: Ericsson Labs xây dựng bản thực thi đầu tiên của WebRTC.
 10/2011: W3C công bố bản nháp đầu tiên của WebRTC.
 11/2011: WebRTC bắt đầu hỗ trợ trên Google Chrome 23.
 1/2013: Hỗ trợ trên Mozilla Firefox.
 2/2013: Thực hiện cuộc gọi cross-browser (đa trình duyệt) đầu tiên.
 7/2013: Hỗ trợ phiên bản beta của Chrome 29 trên Android.
 10/2013: Bắt đầu hỗ trợ trên phiên bản Opera beta.
 2/2014: Truyền dữ liệu cross-browser (đa trình duyệt) lần đầu tiên.
 3/2014: Bắt đầu hỗ trợ phiên bản Opera 20 trên Android.

1
  7/2014: Tích hợp trong Google Hangouts.
 11/2017: W3C chuyển WebRTC từ bản nháp (Working Draft) thành
đề nghị ứng viên (Candidate Recommendation).
 1/2018: WebRTC 1.0 bản ổn định (stable release).
Đến nay, WebRTC đã được hỗ trợ sẵn trên phiên bản desktop và mobile
của các trình duyệt Google Chrome, Mozilla Firefox, Safari, Opera và các trình
duyệt nhân Chromium khác. Ngoài ra, WebRTC còn có những ứng dụng khác
ngoài trình duyệt, trên các nền tảng di động và các thiết bị IoT (Internet of
Things).
2. THIẾT KẾ CỦA WEB RTC
2.1. Các thành phần chính
WebRTC bao gồm các JavaScript API sau:
 getUserMedia: cho phép trình duyệt web truy cập vào camera,
microphone để lấy dữ liệu hình ảnh, âm thanh cho việc truyền tải.
 RTCPeerConnection: dùng để cài đặt videocall/voicecall giữa các
browser. Thực hiện các công việc: xử lý ra tín hiệu, chuyển đổi định
dạng audio/video, giao tiếp P2P, bảo mật, quản lý băng thông.
 RTCDataChannel: truyền dữ liệu hai chiều giữa các trình duyệt.
Dùng các API như WebSockets với độ trễ rất thấp.
WebRTC API cũng hỗ trợ hàm thống kê:
 getStats: cho phép ứng dụng web lấy tập hợp các số liệu thống kê về
các session WebRTC.
2.2. Các giao thức được sử dụng
Do đặc điểm cần thời gian thực cao hơn độ tin cậy, giao thức UDP được
sử dụng trong WebRTC làm giao thức vận chuyển dữ liệu. Nhưng để thỏa mãn
yêu cầu của trình duyệt, phải hỗ trợ giao thức và dịch vụ ở các lớp khác nữa. Về
cơ bản các giao thức chính sử dụng trong WebRTC được thể hiện ở hình dưới:

2
 Hình 1.1 Protocol Stack trong WebRTC
Các giao thức ICE, STUN, and TURN là cần thiết để thiết lập và duy trì
kết nối ngang hàng (peer-to-peer) qua UDP. DTLS được sử dụng để bảo mật
cho việc truyền dữ liệu giữa các bên, bởi mã hóa là 1 tính năng bắt buộc của
WebRTC. SCTP and SRTP là các giao thức ứng dụng được dùng để kết hợp các
luồng dữ liệu khác nhau, cung cấp điều khiển tắc nghẽn và điều khiển luồng,
cung cấp sự phân phối đáng tin cậy một phần và các dịch vụ bổ sung khác trên
nền UDP.
2.3. Kiến trúc hệ thống WebRTC
Khác với các hệ thống web truyền thống trong đó browser trao đổi thông
tin với web server thông qua HTTP hoặc WebSocket, WebRTC sử dụng kiến
trúc P2P. Ứng dụng WebRTC sử dụng một server trung gian gọi là Signaling
Server chạy trên thời gian thực nhằm trao đổi các thông tin cần thiết để hai trình
duyệt có thể kết nối với nhau. Sau khi kết nối, các trình duyệt sẽ trực tiếp trao
đổi dữ liệu âm thanh, hình ảnh … với nhau.
Kiến trúc hệ thống WebRTC được minh họa một cách đơn giản như sau:

3
 Hình 1.2 Kiến trúc phổ biến của hệ thống WebRTC
WebRTC không giới hạn kết nối giữa hai người dùng (one to one) mà có
thể kết nối từ một người dùng đến nhiều người dùng khác nhau (one to many).
WebRTC không quy định 1 giao thức ra tín hiệu (signaling protocol) cụ
thể nào mà người lập trình có thể cài đặt tùy theo lựa chọn của họ. Điều này cho
phép việc chỉnh sửa các ứng dụng WebRTC một cách linh hoạt tùy theo nhu cầu
sử dụng hay hoàn cảnh cụ thể.
3. NHỮNG LỢI ÍCH CỦA WEB RTC
Trước kia để xây dựng một ứng dụng đa phương tiện người ta cần phải
dùng Flash, Java Applet và tích hợp plugins từ các nhà cung cấp thứ ba để thực
hiện. Vì thế WebRTC ra đời để giải quyết vấn đề này. Dưới đây là một số lợi ích
và đặc tính mà WebRTC cung cấp:
 Miễn phí: WebRTC là một dự án mã nguồn mở, miễn phí và hỗ trợ
sẵn trên tất cả các trình duyệt phổ biến hiện nay.
 Hỗ trợ mọi nền tảng thiết bị: Bất kì trình duyệt nào bật WebRTC
trên hệ điều hành bất kì có thể tạo một kết nối thời gian thực tới thiết
bị WebRTC khác. Lập trình viên có thể viết các đoạn mã HTML làm
việc trên cả máy tính và các thiết bị di động.
 Bảo mật dữ liệu: WebRTC sử dụng giao thức SRTP (Secure Real-
time Transport Protocol) để mã hóa và xác thực dữ liệu âm thanh, hình
ảnh. Điều này giúp người dùng tránh được việc bị nghe lén hay quay
trộm khi thực hiện các tác vụ media.

4
 Không Plugins: WebRTC không cần phải cài các plugin của bên thứ
ba để sử dụng các ứng dụng đa phương tiện, vốn là điều làm cho các
ứng dụng đa phương tiện phải phụ thuộc vào các nền tảng khác nhau.
Với WebRTC, ta không cần quan tâm đến vấn đề này.
 Dễ sử dụng: Có thể tích hợp các tính năng của WebRTC trong các
dịch vụ web bằng các JavaScript API và những Framework có sẵn. Sử
dụng các API đã được chuẩn hóa, lập trình viên sẽ không cần thiết phải
tìm hiểu sâu về WebRTC. Điều này giúp giảm thời gian phát triển ứng
dụng.
 Thích ứng với các điều kiện mạng khác nhau: WebRTC hỗ trợ việc
xử lý với nhiều kiểu media và thiết bị đầu cuối khác nhau. Điều này
giúp các ứng dụng tương tác video hoặc gọi thoại sử dụng băng thông
hiệu quả hơn. Các API và signaling server có thể thỏa thuận kích
thước và định dạng video phù hợp cho từng thiết bị đầu cuối riêng biệt.

5
 CHƯƠNG II: GIỚI THIỆU VỀ KURENTO MEDIA SERVER

1. KHÁI NIỆM MEDIA SERVERS

WebRTC cho phép các trình duyệt trực tiếp giao tiếp với nhau không cần
qua bất kỳ hạ tầng trung gian nào. Tuy nhiên, mô hình này chỉ đủ để tạo các ứng
dụng web cơ bản, và rất khó để thực hiện các tính năng phức tạp có nhu cầu cao
về tính toán hay băng thông như giao tiếp nhóm, ghi lại dòng dữ liệu (media
stream), quảng bá (broadcasting) hoặc chuyển mã dữ liệu (media transcoding).
Vì lý do này, nhiều ứng dụng yêu cầu một máy chủ truyền thông (media server)
riêng, có trách nhiệm trung gian chuyển/nhận các luồng dữ liệu tới các đối tác
(peer). Khi đó các peer chỉ cần kết nối với media server và nhận/truyền stream
từ server đó.

Hình 2.1 WebRTC P2P và WebRTC có media server

Có thể hiểu WebRTC media server như một phần mềm trung gian đa
phương tiện (multimedia middleware), nơi dữ liệu (audio, video…) sẽ đi qua khi
di chuyển từ nguồn đến đích.
Media servers có khả năng xử lý các luồng dữ liệu và cung cấp các tính
năng:
 Giao tiếp nhóm: phân phối luồng media tạo ra từ 1 peer đến nhiều nơi
nhận khác nhau, hoạt động như một đơn vị hội nghị đa điểm (MCU,
Multi-Conference Unit).
 Trộn media: chuyển đổi nhiều luồng vào thành 1 luồng ra duy nhất.

6
  Chuyển mã: chuyển đổi định dạng video cho các máy khách không
tương thích.
 Ghi lại: lưu và bảo toàn những thông tin trao đổi giữa các peer.

Hình 2.2 Những tính năng của WebRTC Media Server điển hình
2. KURENTO VÀ KURENTO MEDIA SERVER
2.1. Giới thiệu chung
Kurento là một dự án nguồn mở bao gồm một máy chủ truyền thông
WebRTC và một bộ API giúp đơn giản hóa việc phát triển các ứng dụng video
nâng cao cho các nền tảng web và mobile. Được bắt đầu phát triển từ năm 2010,
đến nay Kurento đã ra tới phiên bản 6.2.
Cốt lõi của Kurento là Kurento Media Server (KMS). Ngoài các tính năng
thông thường của một WebRTC media server như liên lạc nhóm, chuyển mã,
ghi lại, trộn, phát sóng và định tuyến dòng nghe nhìn, KMS còn cung cấp khả
năng xử lý nâng cao trong các lĩnh vực thị giác máy tính, tạo chỉ mục video,
thực tại tăng cường và phân tích giọng nói.
KMS được xây dựng dựa trên thư viện đa phương tiện Gstreamer và cung
cấp những tính năng sau:
 Truyền dữ liệu trên mạng theo các giao thức HTTP, RTP, hay
WebRTC.

7
  Truyền thông nhóm (MCU và SFU), hỗ trợ cả trộn dữ liệu media và
định tuyến, gửi media.
 Hỗ trợ các bộ lọc thực hiện các thuật toán Thị giác máy (Computer
Vision) và Thực tại tăng cường (Augmented Reality).
 Lưu dữ liệu dưới định dạng WebM, MP4 và phát ở tất cả các định
dạng hỗ trợ bởi Gstreamer.
 Tự động chuyển đổi giữa các bộ codec được Gstreamer hỗ trợ, bao
gồm VP8, H.264, H.263, AMR, OPUS, Speex, G.711, và nhiều dạng
khác.
Ngoài các thư viện Kurento Client Java và Javascript có sẵn, nếu muốn
dùng ngôn ngữ khác, lập trình viên có thể dùng Kurento Protocol dựa trên
WebSocket và JSON-RPC để cài đặt.
KMS có kiến trúc mô-đun, cung cấp tính năng dưới dạng các mô-đun cắm
(pluggable module) có thể được bật tắt dễ dàng. Ngoài ra, lập trình viên có thể
tự tạo các mô-đun để mở rộng KMS với các tính năng mới một cách linh hoạt.
Kiến trúc dạng mô-đun của Kurento giúp đơn giản hóa việc tích hợp các thuật
toán xử lý nội dung (vd: nhận dạng giọng nói, phân tích cảm xúc, nhận dạng
khuôn mặt, …) của bên thứ ba vào ứng dụng của mình để sử dụng như những
tính năng có sẵn (built-in features).

Hình 2.3 Những tính năng của Kurento Media Server

8
2.2. Nguyên lý thiết kế của kurento
Kurento được thiết kế dựa trên những nguyên lý chính sau:
 Tách biệt mặt media và signaling: Mặt tín hiệu (signaling plane) phụ
trách việc trao đổi thông tin trong khi tạo và điều khiển kết nối giữa
các thiết bị, cũng như việc quản lý mạng. Mặt media (media plane)
quản lý việc truyền dữ liệu media với các hàm thương lượng media,
tham số hóa QoS, thiết lập cuộc gọi, đăng ký người dùng,… Trong
Kurento 2 mặt này được thiết kế tách biệt nhau để ứng dụng có thể xử
lý chúng một cách riêng rẽ.
 Phân phối media và các dịch vụ ứng dụng: KMS và các ứng dụng có
thể được gộp lại hay phân tán trên các thiết bị khác nhau. Một ứng
dụng có thể gọi dịch vụ của nhiều Kurento Media Server. Một KMS
cũng có thể trả lời yêu cầu của nhiều ứng dụng.
 Thích hợp điện toán đám mây: Kurento có thể được tích hợp lên các
môi trường điện toán đám mây để trở thành 1 PaaS (Platform as a
Service – Nền tảng như một dịch vụ).
 Đường ống media (media pipelines): kết nối các media elements
(phần tử media) thông qua media pipelines là 1 cách tiếp cận để giảm
bớt sự phức tạp của việc xử lý đa phương tiện.
 Phát triển ứng dụng nhanh chóng: Lập trình viên không cần phải
hiểu những kiến trúc nội bộ phức tạp của KMS, họ có thể triển khai
ứng dụng trên công nghệ hay framework (khung phần mềm) mà họ
thích, từ client tới server, từ browser tới cloud service (dịch vụ đám
mây).
 Giao tiếp đầu cuối end-to-end: Kurento cung cấp cung cấp khả năng
giao tiếp end-to-end nên lập trình viên không cần phải xử lý những
công đoạn vận chuyển, mã hóa/giải mã và kết xuất dữ liệu trên máy
trạm.
 Dòng dữ liệu có thể xử lý được: Kurento cho phép cả tương tác
người-người (vd: đàm thoại nghe/gọi tương tự Skype), và giao tiếp
người-máy (vd: dịch vụ phát video theo yêu cầu) và máy-máy (vd: ghi
lại video từ xa, trao đổi dữ liệu đa giác quan (multisensory media)).

9
  Xử lý media theo module: Việc module hóa bằng media elements và
pipelines cho phép định nghĩa các chức năng xử lý của 1 ứng dụng qua
1 ngôn ngữ “hướng đồ thị”, nơi các nhà phát triển có thể tạo ra logic
mong muốn bằng việc kết nối các chức năng phù hợp.
 Kiểm tra: Kurento cho phép việc theo dõi QoS (Quality of Service –
chất lượng dịch vụ) một cách chi tiết, cho phép việc thanh toán và
kiểm toán.
 Tích hợp IMS liền mạch: Kurento được thiết kế để hỗ trợ tích hợp
liền mạch vào cơ sở hạ tầng IMS của các nhà cung cấp dịch vụ điện
thoại.
 Lớp thích ứng media trong suốt (media adaptation layer): Kurento
cung cấp một lớp thích ứng trong suốt để có thể hội tụ các thiết bị khác
nhau với yêu cầu khác nhau về kích thước màn hình, mức tiêu thụ
điện, tốc độ truyền, …
2.3. Kurento API
Kurento Media Server có thể được điều khiển thông qua API mà nó hiển
thị, và các nhà phát triển ứng dụng có thể sử dụng các ngôn ngữ cấp cao để
tương tác. Dự án Kurento cung cấp sẵn các cài đặt Kurento Client cho một số
nền tảng (Java SDK và JavaScript SDK). Ngoài những ngôn ngữ được hỗ trợ
(Java, Javascript), lập trình viên có thể tự cài đặt Kurento Client theo ngôn ngữ
mình thích bằng cách dùng Kurento Protocol dựa trên WebSocket và JSON-
RPC.
Dưới đây (Hình 2.4) cho thấy cách sử dụng Kurento trong ba trường hợp:
 Sử dụng SDK Kurento JavaScript trực tiếp từ trình duyệt WebRTC
(chỉ nên dùng cho thử nghiệm, không cho phát triển sản phẩm).
 Sử dụng Kurento Java SDK trong Máy chủ ứng dụng (Application
Server) Java EE độc lập. Trình duyệt web là bên khách (client) của
ứng dụng cho các tác vụ như HTML và báo hiệu WebRTC (WebRTC
signaling), trong khi bản thân ứng dụng là client của KMS (sử dụng
Kurento Protocol để điều khiển KMS).
 Sử dụng Kurento JavaScript SDK trong Máy chủ ứng dụng Node.js.
Tương tự như khi dùng Java SDK, trình duyệt web là client của ứng
dụng, trong khi ứng dụng là client của KMS.
10
 Hình 2.4 Cài đặt Kurento Client API trong Java SDK và Javascript
SDK
Kurento có 2 khái niệm căn bản, Media Element và Media Pipeline:
 Media Elements (phần tử phương tiện): mỗi Media Element là một
đơn vị chức năng thực hiện một tác vụ cụ thể trên dòng dữ liệu. Mỗi
media element được xem như một “hộp đen” đối với nhà phát triển
ứng dụng: họ dùng chức năng đó mà không cần phải hiểu chi tiết cài
đặt ở mức thấp của nó. Media element có thể nhận dữ liệu từ element
khác (thông qua media source) và gửi tới element khác (thông qua
media sinks). Dựa trên chức năng, media element được chia thành các
nhóm:
o Input Endpoints (đầu vào điểm cuối): đây là các Media Elements
thực hiện việc nhận dữ liệu và truyền vào 1 pipeline (đường ống). Có
nhiều loại input endpoints khác nhau (File/Network/Capture input
endpoint) đảm nhận việc lấy media từ (File/Network/Camera) tương
ứng.

11
 o Filters (bộ lọc): thực hiện việc phân tích và chuyển đổi dữ liệu. Có
các bộ lọc cho việc trộn (mixing), phối hợp (muxing), phân tích, tăng
cường,…
o Hubs: quản lý nhiều luồng media trong 1 pipeline. Một Hub có các
HubPort cho từng media element kết nối tới. Tùy thuộc vào loại Hub,
có những cách khác nhau để điều khiển media. Ví dụ: Hub
Composite hợp nhất tất cả các luồng video đầu vào thành một luồng
video đầu ra duy nhất, với tất cả các đầu vào được sắp xếp trong một
lưới (grid).
o Output Endpoints (đầu ra điểm cuối): là element có khả năng lấy
luồng media ra khỏi pipeline. Tương tự input endpoint, có nhiều loại
output endpoint chuyên biệt cho file, network, màn hình máy tính,…
 Media Pipeline (đường ống phương tiện): là một chuỗi các Media
Element kết nối với nhau, nơi luồng ra của phần tử này được truyền
vào phần tử tiếp theo. Từ đó, media pipeline có khả năng thực hiện
một chuỗi các thao tác khác nhau trên một luồng media.
Kurento API được xây dựng hướng đối tượng. Các lớp trong đó bao gồm
các thuộc tính thể hiện trạng thái bên trong của Kurento server, và các phương
thức là các thao tác mà server thực hiện.
Dưới đây là bảng danh sách các mô-đun chính trong Kurento, bao gồm
các Endpoint, Filter và Hub:
Bảng 2.1 Các Endpoint trong Kurento API
Tên Chức năng Minh họa
WebRtcEndpoint Là endpoint vào/ra cung cấp việc
truyền phát media cho giao tiếp
thời gian thực trên web. Dùng
công nghệ WebRTC để giao tiếp
với trình duyệt.
RtpEndpoint Là endpoint vào/ra cung cấp việc
truyền tải nội dung 2 chiều giữa
các bên thông qua giao thức RTP.
Dùng giao thức SDP cho thương

12
 lượng media (media negotiation).
HttpPostEndpoint Là endpoint đầu vào, nhận media
bằng các yêu cầu HTTP POST
tương tự như chức năng upload
file qua HTTP.
PlayerEndpoint Là endpoint đầu vào lấy nội dung
media từ hệ thống file, HTTP
URL hay RTSP URL và truyền
vào Media Pipeline.
RecorderEndpoin Là endpoint đầu ra cung cấp hàm
t để lưu lại nội dung, chứa Media
Sink cho audio và video.

Bảng 2.2 Các Filter trong Kurento API

Tên Chức năng Minh họa
ZBarFilter Phát hiện mã QR, mã vạch trong
luồng video và gọi hàm sự kiện
CodeFoundEvent. Client có thể thêm
hàm lắng nghe để bắt và xử lý sự
kiện.
FaceOverlayFilter Phát hiện khuôn mặt trong video và
phủ lên nó 1 ảnh có thể cấu hình
được.

GStreamerFilter Là giao diện lọc chung (filter

interface) cho phép thêm các phần tử
Gstreamer vào Media Pipeline.

Bảng 2.3 Các Hub trong Kurento API

Tên Chức năng Minh họa

13
Composite Trộn các luồng audio của những input
được kết nối với Hub và xây dựng 1 lưới
với những luồng video của chúng.

DispatcherOneToMany Gửi 1 input nhận được tới tất cả các

output theo HubPort được kết nối.

Dispatcher Cho phép định tuyến giữa các cặp

HubPort input-output tùy ý.

Ngoài các tính năng cơ bản, Kurento còn có một số mô-đun bổ sung được
tích hợp sẵn, làm ví dụ về cách mở rộng các tính năng cơ bản của Kurento
Media Serve:
 kms-pointerdetector: Bộ lọc phát hiện con trỏ trong luồng video, dựa
trên theo dõi màu sắc.
 kms-chroma: Bộ lọc lấy một dải màu ở lớp trên cùng và làm cho nó
trong suốt, để lộ một hình ảnh khác phía sau.
 kms-crowddetector: Bộ lọc phát hiện đám đông người trong các
luồng video.
 kms-platedetector: Bộ lọc phát hiện biển số xe trong các luồng video.
Như vậy, hộp công cụ Kurento (Kurento toolbox) hoàn chỉnh bao gồm
hộp công cụ cơ bản được mở rộng với nhiều bộ lọc Computer Vision và
Augmented Reality, như hình minh họa sau:

14
 Hình 2.5 Hộp công cụ Kurento mở rộng

Ngoài ra, nhà phát triển cũng có thể tự viết mô-đun của riêng mình để mở rộng
các tính năng của Kurento Media Server. Có hai lựa chọn chính:
 Các mô-đun dựa trên thư viện OpenCV: nên theo hướng này nếu muốn
thêm các tính năng như Thị giác máy tính hoặc Thực tế tăng cường.
 Các mô-đun dựa trên thư viện Gstreamer: loại mô-đun này cung cấp
một điểm vào chung để xử lý media trong khuôn khổ GStreamer. Các
mô-đun như vậy mạnh hơn, nhưng cũng khó phát triển hơn, và yêu cầu
có kiến thức tốt về phát triển GStreamer.
Tóm lại, kiến trúc mô-đun của KMS bao gồm các tính năng cơ bản, các mô-đun
tích hợp bổ sung và các mô-đun tùy chỉnh do người dùng tự tạo:

15
Hình 2.6 Các mô-đun trong Kurento Media Server

16
 CHƯƠNG III: GIẢI PHÁP VIDEO STREAMING ĐA NỀN TẢNG
CHO CAMERA IP BẰNG KURENTO

1. KIẾN TRÚC PHÁT TRIỂN ỨNG DỤNG

1.1. Kiến trúc chung
Kurento có thể được sử dụng theo nguyên tắc kiến trúc của web. Việc tạo
một ứng dụng đa phương tiện dựa trên Kurento cũng tương tự như khi tạo một
ứng dụng web bằng bất kỳ khung phát triển web phổ biến nào.
Ở mức trừu tượng cao nhất, các ứng dụng web có kiến trúc bao gồm ba
lớp khác nhau:
 Lớp trình bày (phía máy khách): Lớp này chứa toàn bộ phần mã ứng
dụng chịu trách nhiệm thực thi tương tác với người dùng cuối để thông
tin được thể hiện một cách toàn diện. Phần này thường bao gồm các
trang HTML với mã JavaScript.
 Lớp logic ứng dụng (phía máy chủ): Lớp này chịu trách nhiệm triển
khai các chức năng cụ thể được thực thi bởi ứng dụng.
 Lớp dịch vụ (phía máy chủ hoặc phía Internet): Lớp này cung cấp
các tính năng mà lớp logic ứng dụng sử dụng như cơ sở dữ liệu, truyền
thông, bảo mật... Các dịch vụ này có thể được lưu trữ trong cùng một
máy chủ với lớp logic ứng dụng hoặc có thể được cung cấp bởi bên
ngoài.
Tương tự như vậy, các ứng dụng đa phương tiện được tạo bằng Kurento
cũng có thể được triển khai theo cùng một kiến trúc:
 Lớp trình bày: Phụ trách việc biểu diễn và thu nội dung phương tiện.
Nó thường dựa trên các tính năng cụ thể có sẵn của máy khách. Ví dụ:
khi tạo ứng dụng dựa trên trình duyệt, lớp trình bày sẽ sử dụng các tính
năng như thẻ HTML <video> hoặc các API JavaScript của WebRTC .
 Lớp logic ứng dụng: Lớp này cung cấp logic đa phương tiện cụ thể.
Nói cách khác, lớp này chịu trách nhiệm xây dựng pipeline thích hợp
(bằng cách xâu chuỗi các Media Elements mong muốn) mà các luồng
dữ liệu liên quan đến ứng dụng sẽ cần phải đi qua.

17
  Lớp dịch vụ: Lớp này cung cấp các dịch vụ đa phương tiện hỗ trợ
logic ứng dụng như ghi video, mã hóa video... Kurento Media Server
(Media Pipeline chứa các Media Elements cụ thể) phụ trách lớp này.
Điều thú vị ở đây là, giống như khi phát triển các ứng dụng web, các ứng
dụng Kurento có thể đặt lớp Trình bày ở phía máy khách và lớp Dịch vụ ở phía
máy chủ. Tuy nhiên, lớp logic Ứng dụng, trong cả hai trường hợp, có thể nằm ở
một trong hai bên hoặc thậm chí phân bố giữa chúng. Ý tưởng này được thể hiện
trong hình sau:

Hình 3.1 Sự tương đồng trong kiến trúc phân lớp của ứng dụng
web và ứng dụng đa phương tiện (Kurento)
Điều này có nghĩa là các nhà phát triển Kurento có thể chọn để đưa phần
mã tạo media pipeline cụ thể mà ứng dụng của họ yêu cầu ở phía máy khách (sử
dụng Kurento Client phù hợp hoặc cài trực tiếp với Kurento Protocol) hoặc có
thể đặt nó ở phía máy chủ. Cả hai tùy chọn đều hợp lệ nhưng ngụ ý các phong
cách phát triển khác nhau. Tuy vậy, điều quan trọng cần lưu ý là trong phát triển
web, các nhà phát triển thường có xu hướng để mã phía máy khách càng đơn
giản càng tốt, và đưa hầu hết logic ứng dụng lên máy chủ. Đây cũng là cách sử
dụng Kurento thông thường nhất.
Ở những phần sau, ta mặc định coi là tất cả việc xử lý logic Kurento được
thực hiện ở phía máy chủ. Mặc dù đây là cách phổ biến nhất để sử dụng
Kurento, điều quan trọng cần lưu ý là tất cả logic đa phương tiện có thể được
thực hiện tại máy khách với Kurento JavaScript Client.
18
1.2. Kiến trúc ứng dụng
Kurento, như hầu hết các công nghệ truyền thông đa phương tiện hiện có,
được xây dựng bằng cách sử dụng hai lớp, được gọi là mặt phẳng (plane), để
trừu tượng hóa các chức năng chính trong tất cả các hệ thống truyền thông tương
tác:
 Mặt tín hiệu (Signaling Plane): Là các phần của hệ thống chịu trách
nhiệm quản lý giao tiếp, nghĩa là, các mô-đun cung cấp các chức năng
đàm phán media, tham số hóa QoS, thiết lập cuộc gọi, đăng ký người
dùng, … được coi là một phần của Mặt tín hiệu .
 Mặt đa phương tiện (Media Plane): Các chức năng như truyền tải
video, mã hóa/giải mã video và xử lý video tạo nên Media Plane, nơi
đảm nhiệm việc xử lý media. Sự khác biệt đến từ sự khác nhau về điện
thoại giữa việc xử lý giọng nói và việc xử lý các thông tin meta như
tone, billing...
Hình dưới đây mô tả khái niệm về kiến trúc cấp cao của Kurento:

Hình 3.2 Các mặt phẳng truyền thông và tín hiệu trong kiến trúc ứng
dụng Kurento

19
 Phần bên phải hiển thị ứng dụng, phụ trách mặt phẳng tín hiệu và chứa
logic nghiệp vụ và các kết nối của ứng dụng đa phương tiện cụ thể đang được
triển khai. Nó có thể được xây dựng với bất kỳ công nghệ lập trình nào như
Java, Node.js, PHP, Ruby, .NET, v.v. Ứng dụng có thể sử dụng các công nghệ
hoàn thiện như HTTP và SIP Servlets, Web Services, trình kết nối cơ sở dữ liệu,
dịch vụ nhắn tin, v.v. Nhờ điều này, mặt phẳng này cung cấp truy cập vào các
giao thức báo hiệu đa phương tiện thường được sử dụng bởi các máy khách đầu
cuối như SIP, RESTful và các định dạng dựa trên HTTP thô, SOAP, RMI,
CORBA hoặc JMS. Các giao thức báo hiệu này được dùng bởi phía máy khách
của các ứng dụng để điều khiển việc tạo ra các media session và để thay chúng
thương lượng các đặc điểm mong muốn. Do đó, đây là phần của kiến trúc có
tiếp xúc với các nhà phát triển và vì lý do này, nó cần được thiết kế một cách
đơn giản và linh hoạt.
Ở phần bên trái là Máy chủ phương tiện Kurento (Kurento Media
Server), thực hiện các chức năng của mặt phẳng phương tiện cung cấp quyền
truy cập tới các tính năng phương tiện cấp thấp: truyền tải, mã hóa/giải mã,
chuyển mã, trộn, xử lý, v.v. KMS phải có khả năng quản lý các luồng đa phương
tiện với độ trễ tối thiểu và thông lượng tối đa. Do đó, Kurento Media Server phải
được tối ưu hóa để đạt hiệu quả.
1.3. Giao tiếp máy khách, máy chủ và Kurento
Như có thể quan sát trong hình bên dưới, một ứng dụng Kurento liên quan
đến sự tương tác giữa ba mô-đun chính:
 Ứng dụng Máy khách (Client Application): Bao gồm các chức năng
đa phương tiện gốc của nền tảng máy khách cộng với logic ứng dụng
cụ thể phía máy khách. Nó có thể sử dụng Kurento Clients được thiết
kế cho các nền tảng client (ví dụ: Kurento JavaScript Client).
 Máy chủ ứng dụng: Liên quan đến một máy chủ ứng dụng và phần
logic ứng dụng phía máy chủ. Nó có thể sử dụng Kurento Clients được
thiết kế cho các nền tảng servers (ví dụ: Kurento Java Client cho Java
EE và Kurento JavaScript Client cho Node.js).

20
  Kurento Media Server: Nhận các lệnh để tạo ra các chức năng đa
phương tiện cụ thể (tức là các đường ống cụ thể thích hợp cho nhu cầu
của ứng dụng).
Các tương tác được duy trì giữa các mô-đun này phụ thuộc vào các chi
tiết cụ thể của từng ứng dụng. Tuy nhiên, nói chung, đối với hầu hết các ứng
dụng có thể được rút gọn thành sơ đồ khái niệm sau:

Hình 3.3 Tương tác chính giữa các mô-đun trong đàm phán và trao
đổi media
1.3.1 Pha đàm phán media (signaling)
Ở giai đoạn đầu tiên, một ứng dụng khách (trình duyệt trong máy tính,
một ứng dụng trên điện thoại di động, ...) gửi thông báo đến ứng dụng yêu cầu
một số loại chức năng đa phương tiện. Thông báo này có thể được thực hiện với
bất kỳ giao thức nào (HTTP, WebSocket, SIP, v.v.). Ví dụ: yêu cầu đó có thể là
hiển thị một video clip nhất định.
Khi ứng dụng nhận được yêu cầu, nếu phù hợp, nó sẽ thực hiện logic ứng
dụng phía máy chủ cụ thể, có thể bao gồm Xác thực, Ủy quyền và Kế toán
(AAA), tạo CDR, sử dụng một số loại dịch vụ web, v.v.

21
 Sau đó, ứng dụng xử lý yêu cầu và, theo các hướng dẫn cụ thể được lập
trình bởi nhà phát triển, ra lệnh cho Kurento Media Server khởi tạo các Media
Element phù hợp và kết nối chúng trong một Media Pipeline thích hợp. Khi
đường ống đã được tạo thành công, Kurento Media Server sẽ phản hồi tương
ứng và ứng dụng sẽ chuyển tiếp phản hồi đến máy khách, hiển thị cách thức và
nơi có thể tiếp cận dịch vụ truyền thông.
Trong các bước nêu trên, không có dữ liệu đa phương tiện nào thực sự
được trao đổi. Tất cả các tương tác đều có mục tiêu là thương lượng về whats
(những gì), hows (như thế nào), wheres (ở đâu) và whens (khi nào) của việc trao
đổi dữ liệu. Đó là lý do nó được gọi là pha đàm phán. Rõ ràng giai đoạn này chỉ
liên quan tới các giao thức báo hiệu (signaling protocols).
1.3.2 Pha trao đổi media
Sau phần signaling, một giai đoạn mới bắt đầu với mục đích tạo ra sự trao
đổi dữ liệu đa phương tiện thực tế. Máy khách gửi yêu cầu về dữ liệu Kurento
Media Server bằng cách sử dụng thông tin thu thập được trong giai đoạn thương
lượng.
Tiếp tục với ví dụ hiển thị video clip được đề cập ở trên, trình duyệt sẽ
gửi yêu cầu GET đến địa chỉ IP và cổng của Kurento Medai Server nơi có thể
lấy clip và kết quả là sẽ nhận được phản hồi HTTP chứa media tương ứng.
Ta có thể tự hỏi tại sao cần một sơ đồ phức tạp như vậy để chỉ phát một
video, khi trong hầu hết các tình huống thông thường, khách hàng chỉ gửi yêu
cầu đến URL thích hợp của video mà không cần bất kỳ sự thương lượng nào.
Câu trả lời là Kurento được thiết kế cho các ứng dụng đa phương tiện liên quan
đến các xử lý phức tạp. Vì lý do này, cần thiết lập một cơ chế hai giai đoạn cho
phép thực hiện đàm phán trước khi trao đổi dữ liệu. Cái giá phải trả là các ứng
dụng đơn giản, chẳng hạn như một ứng dụng chỉ tải video, cũng cần phải trải
qua các giai đoạn này. Tuy nhiên, lợi thế là khi tạo ra các dịch vụ nâng cao hơn,
triết lý đơn giản tương tự sẽ được duy trì. Ví dụ: nếu ta muốn thêm các tính năng
Thực tế tăng cường hoặc Thị giác máy tính vào video clip đó, ta chỉ cần tạo
pipeline thích hợp chứa các Media Element mong muốn trong giai đoạn đàm
phán. Sau đó, từ góc độ máy khách, clip đã xử lý sẽ được nhận như bất kỳ video
nào khác.
1.4. Ứng dụng WebRTC thời gian thực với Kurento

22
 Máy khách truyền đạt các tính năng đa phương tiện mong muốn của mình
thông qua thương lượng SDP Offer/Answer. Do đó, Kurento có thể khởi tạo
điểm cuối WebRTC thích hợp và yêu cầu nó tạo SDP Answer dựa trên khả năng
của chính nó và trên SDP Offer. SDP Answer khi nhận được sẽ được gửi lại cho
máy khách và có thể bắt đầu quá trình trao đổi dữ liệu. Sự tương tác giữa các
mô-đun khác nhau được tóm tắt trong hình sau:

Hình 3.4 Tương tác trong một phiên WebRTC

Nhà phát triển ứng dụng có thể tạo pipeline mong muốn trong giai đoạn
đàm phán, để luồng đa phương tiện thời gian thực được xử lý phù hợp với nhu
cầu của ứng dụng.
Ví dụ, giả sử ta muốn tạo một ứng dụng WebRTC ghi lại video nhận được
từ khách hàng và tăng cường nó để nếu tìm thấy một khuôn mặt người, một
chiếc mũ sẽ được hiển thị trên đó. Pipeline này được thể hiện theo sơ đồ trong
hình bên dưới, với giả định rằng phần tử Bộ lọc (Filter element) trong đó có khả
năng phát hiện khuôn mặt và thêm chiếc mũ vào đó.

23
 Hình 3.5 Ví dụ pipeline cho một phiên WebRTC
Ở ví dụ này, một WebRtcEndpoint được kết nối với 1 RecorderEndpoint
lưu trữ luồng phương tiện đã nhận và với một bộ lọc Thực tế tăng cường
(Augmented reality), bộ lọc này sẽ cung cấp luồng phương tiện đầu ra của nó trở
lại máy khách. Do đó, người dùng cuối sẽ nhận được hình ảnh của chính mình
đã được lọc (chẳng hạn có thêm một chiếc mũ trên đầu) và luồng sẽ được ghi lại
vào kho lưu trữ (ví dụ tệp dữ liệu) để có thể khôi phục sau này.
1.5. Mặt phẳng đa phương tiện (Media Plane)
Từ góc độ nhà phát triển ứng dụng, các Phần tử phương tiện (Media
Element) giống như những mảnh ghép Lego: bạn chỉ cần lấy các phần tử cần
thiết cho một ứng dụng và kết nối chúng, theo cấu trúc liên kết mong muốn.
Trong Kurento, một biểu đồ của các phần tử phương tiện được kết nối được gọi
là Đường ống phương tiện (Media Pipeline). Do đó, khi tạo pipeline, các nhà
phát triển cần xác định các tính năng họ muốn sử dụng (các element) và cấu trúc
liên kết xác định element nào cung cấp dữ liệu cho element nào khác (tính kết
nối).

24
 Hình 3.6 Ví dụ một Media Pipeline đơn giản

Kết nối được kiểm soát thông qua giao diện nguyên thủy (primitive)
connect, được hiển thị trên tất cả các Kurento Client API.
Primitive này luôn được gọi trong phần tử đóng vai trò là nguồn và lấy
phần tử đích (sink element) làm đối số theo lược đồ:
sourceMediaElement.connect(sinkMediaElement)
Ví dụ: nếu muốn tạo một ứng dụng ghi các luồng WebRTC vào hệ thống
tệp, bạn sẽ cần 2 phần tử phương tiện: WebRtcEndpoint và RecorderEndpoint.
Khi một máy khách kết nối với ứng dụng, bạn sẽ cần phải khởi tạo các phần tử
phương tiện này làm sao cho luồng nhận được bởi WebRtcEndpoint (có khả
năng nhận luồng WebRTC) sẽ được đưa đến RecorderEndpoint (có khả năng ghi
các luồng phương tiện vào hệ thống tệp). Cuối cùng, bạn sẽ cần kết nối chúng để
luồng nhận được bởi phần tử trước sẽ được chuyển sang phần tử sau:
WebRtcEndpoint.connect(RecorderEndpoint)
Để đơn giản hóa việc xử lý các luồng WebRTC ở phía máy khách,
Kurento cung cấp một tiện ích có tên là WebRtcPeer. Tuy nhiên, API WebRTC
tiêu chuẩn (getUserMedia, RTCPeerConnection, v.v.) cũng có thể được sử dụng
để kết nối với WebRtcEndpoints.
2. TÍCH HỢP WEB RTC VÀ CAMERA IP
Điều đầu tiên cần lưu ý khi tích hợp Camera IP vào ứng dụng WebRTC là
tính tương thích giữa các luồng dữ liệu video. Đặc tả của WebRTC nói rất rõ về
các chuẩn mã hóa video (codecs) được hỗ trợ, bao gồm VP8 và H.264. Đây là
các mã hóa tiêu chuẩn trên hầu hết Camera IP và được hỗ trợ trên hầu hết các

25
trình duyệt web hiện nay. Chuẩn H.264 cũng là codec phổ biến trên rất nhiều
thiết bị thu phát video khác. Trên lý thuyết, điều này có nghĩa những video
chuẩn H.264 được thu bởi camera có thể được hiểu bởi trình duyệt, và có thể
được truyền đi trực tiếp như là 1 luồng dữ liệu WebRTC thông qua 1 cổng
truyền thông (Media Gateway), như minh họa ở hình dưới:

Hình 3.7 Kiến trúc đơn giản của Media Gateway

Một cấu hình truyền dữ liệu đơn giản như trên giúp giảm xuống tối thiểu
việc tiêu thụ các tài nguyên hệ thống (CPU, RAM). Tuy nhiên vấn đề sẽ nảy
sinh nếu các bên nhận không hỗ trợ cùng một bộ codec, hoặc đường truyền
mạng không ổn định và người xem không có đủ băng thông để xem video.
WebRTC ra đời không phải chỉ để gửi các luồng dữ liệu RTSP qua lại
một cách đơn giản. Mục đích của WebRTC là truyền video một cách an toàn,
hiệu quả và đáng tin cậy. Hệ thống phải có khả năng phản hồi lại một cách phù
hợp khi kết nối của người xem không ổn định và bị ảnh hưởng bởi các vấn đề
thực tế như nghẽn đường truyền, mất gói tin, …
Để giải quyết việc này, WebRTC cung cấp cơ chế phản hồi (feedback
mechanism) cho phép người xem thông báo lại tình trạng của mạng tới người
gửi:

26
 Hình 3.8 Kiến trúc đầy đủ của Media Gateway WebRTC
Bằng cách thêm vào một bộ mã hóa + giải mã để thực hiện chuyển mã
(transcoding), gateway có thể giải quyết cả 2 vấn đề về tính tương thích mã và
độ tin cậy của mạng. Bộ mã hóa trung gian có thể theo dõi thông tin các phản
hồi và phản ứng lại như sau:
 Khi có tắc nghẽn mạng, bên nhận sẽ gửi lại cho gateway các gói tin
điều khiển SRTCP có các tin nhắn REMB, trong đó chứa thông tin về
lượng băng thông thực còn khả dụng cho việc nhận video. Gateway
căn cứ vào đó để thay đổi tốc độ bit (bitrate) mã hóa thích hợp.
 Khi có gói tin bị mất đi trên đường truyền, bên nhận gửi lại các gói
SRTCP có tin nhắn PLI để yêu cầu gửi lại khung hình nhằm phục hồi
lại dữ liệu video bị mất.
Ví dụ, khi mạng bị nghẽn (băng thông của bên gửi bị giảm), bộ mã hóa sẽ
được hướng dẫn qua tin nhắn REMB để giảm bitrate và tạo ra video chất lượng
thấp hơn, kích thước nhẹ hơn để vẫn có thể truyền ổn định qua mạng.
Cơ chế phản hồi của WebRTC hoạt động khá tốt trong các sự cố mạng
điển hình, cái giá phải trả là server phải xử lý nặng hơn nhiều. Tuy nhiên sự
đánh đổi này thường là đáng giá.
3. SỬ DỤNG KURENTO MEDIA SERVER
Những khó khăn nêu ra trên đây là những vấn đề điển hình gặp phải khi
truyền video từ camera (hay các nguồn phát video khác) tới thiết bị chạy

27
WebRTC (như trình duyệt web), mà bất kỳ một media gateway nào cũng phải
giải quyết.
Kurento Media Server đưa ra một giải pháp toàn diện cho việc này.
Kurento Media Gateway sẽ bao gồm 2 thành phần chính. PlayerEndpoint phụ
trách việc lấy luồng video từ nhiều nguồn khác nhau, và thực hiện chuyển mã.
Sau đó WebRtcEndpoint sẽ xử lý tất cả những công việc liên quan đến giao
tiếp WebRTC với bên nhận. Chỉ với 2 thành phần này, ta có thể tạo ra 1 cổng
truyền thông WebRTC hoạt động đầy đủ và hiệu quả cho các camera IP (hình
3.3).

Hình 3.9 Kiến trúc Media Gateway trong Kurento Media Server
Phần chủ chốt trong mô hình này là công đoạn Agnostic transcoding
(chuyển mã agnostic), được thực hiện bởi thành phần agnosticbin trong
Kurento.
Thành phần này chứa thao tác chuyển mã, nơi xử lý các gói SRTCP và
điều chỉnh bitrate (với các tin nhắn REMB) hay tái tạo khung hình bị mất (trong
trường hợp nhận được tin nhắn PLI). Agnosticbin cũng là nơi chọn ra codec của
video cho phù hợp với yêu cầu của bên nhận. Ví dụ nếu video gốc được mã hóa
H.264 nhưng bên nhận chỉ hỗ trợ VP8, thì ở đây video sẽ được chuyển thành
VP8.
WebRtcEndpoint còn cho phép điều chỉnh bitrate tối đa, tối thiểu của
video gửi đi. Khi đó băng thông ước lượng trong tin nhắn REMB sẽ được giới
hạn trong phạm vi đặt ra cho ứng dụng.

28
 Ở đây nảy sinh một câu hỏi: khi streaming cho nhiều người xem, liệu có
cần cung cấp cho mỗi người xem một pipeline với quy trình chuyển mã
(transcoding process) riêng? Sẽ là lý tưởng nếu có thể cung cấp một quy trình
chuyển mã riêng để điều chỉnh codec và bitrate cho mỗi người. Tuy nhiên cách
làm này rất tốn tài nguyên và có thể gây quá tải cho hệ thống khi người xem
tăng lên số lượng lớn.
Kurento đưa ra một giải pháp thỏa hiệp, trong đó dùng một pipeline duy
nhất để giải mã dữ liệu từ camera và chuyển mã thành tất cả các loại codec được
hỗ trợ (VP8, H.264). Khi có nhiều người xem, KMS tạo ra nhiều phần tử
WebRTCEndPoint kết nối đến nguồn dữ liệu đã giải mã, mỗi WebRTCEndPoint
chịu trách nhiệm truyền dữ liệu đến cho một người xem theo codec phù hợp
(hình 3.4). Do mã hóa video là một tác vụ khá “ngốn” CPU, việc chỉ chuyển mã
một lần sẽ giúp hệ thống xử lý trung tâm KMS tiết kiệm đáng kể tài nguyên bộ
nhớ và CPU xử lý. Khi đã hoàn thành, lượng tài nguyên cần tiêu tốn khi có thêm
người dùng WebRtcEndpoint sẽ là không đáng kể.

Hình 3.10 Cấu hình xử lý cho nhiều người xem trên thiết bị đầu cuối khác
nhau
29
4. GIẢI PHÁP VIDEO STREAMING ĐA NỀN TẢNG
Giải pháp Kurento như trên chạy tốt trên các nền tảng Android, Windows
(với các trình duyệt Chrome, Firefox) nhưng không chạy ổn định trên các hệ
điều hành iOS, Mac OS (trình duyệt Safari), do những nguyên nhân sau đây.
Thứ nhất là do Apple, hãng công nghệ xây dựng và phát triển hệ điều
hành iOS cũng như trình duyệt Safari, chỉ thêm hỗ trợ chuẩn mã hóa video VP8
từ phiên bản Safari 68 trở đi. Những phiên bản cũ hơn chỉ hỗ trợ chuẩn H.264
nên để đảm bảo tính tương thích, KMS cần phải chuyển mã video nguồn sang
H.264 trước khi truyền sang các thiết bị chạy WebRTC trên Safari.
Thứ hai là do một số khác biệt của chính sách HTML về chế độ hiển thị
video trên trình duyệt Safari trên iOS:
 Chế độ autoplay
Thông thường, để thêm một video vào file HTML, ta làm như sau:
<video id="myVideo" autoplay></video>
Hầu hết trình duyệt (bao gồm cả Safari trên Mac OS) đều hỗ trợ thuộc
tính autoplay, hàm video.play() được gọi ngầm và video sẽ được phát tự động
ngay khi có kết nối tới nguồn phát. Tuy nhiên Safari trên iOS là ngoại lệ, bởi nó
có một bộ quy tắc để hạn chế việc phát video bằng thẻ HTML. Từ phiên bản
iOS Safari 10 trở đi, autoplay chỉ được dùng cho những video không có âm
thanh, bị tắt tiếng (muted) hay phần âm thanh (audio track) đã bị vô hiệu hóa
(disabled). Nếu không, autoplay sẽ bị bỏ qua và video sẽ không tự động phát.
Để giải quyết, ta có thể phát video trong trạng thái tắt tiếng bằng cách
thêm thuộc tính muted trong cặp thẻ video:
<video id="myVideo" autoplay muted></video>
Như thế người dùng sẽ biết được là quá trình phát video (video streaming)
đã bắt đầu. Sau đó trình duyệt sẽ hiển thị tùy chọn cho người dùng bấm vào để
bật audio.
Một phương án khác là không dùng thuộc tính autoplay trong thẻ HTML
mà phát video qua một tương tác nào đó. Chẳng hạn có thể thêm một nút bấm và
cài đặt hàm bắt sự kiện onclick trong đó gọi hàm video.play() để phát video.
 Chế độ playsinline

30
 Hầu hết trình duyệt sẽ phát video trong một khung có kích thước cụ thể
được định ra trong cặp thẻ video. Chẳng hạn:
<video id="myVideo" width="480px" height="360px"></video>
sẽ phát video trong 1 khung có kích thước 480 x 360 điểm ảnh (pixel).
Tuy nhiên, trên iOS Safari video được phát mặc định ở chế độ toàn màn
hình: trình duyệt sẽ mở rộng video để phủ hết toàn bộ màn hình thiết bị (điện
thoại, máy tính bảng). Có thể ngăn việc này bằng cách thêm thuộc tính
playsinline vào thẻ video:
<video id="myVideo" width="480px" height="360px"
playsinline></video>
và video sẽ được phát trong khung hình như đã định (480 x 360).
Tóm lại, để tự động phát video trên iOS Safari giống như trên các trình
duyệt khác, cần làm như sau:
 Dùng thuộc tính muted cùng autoplay để tự động phát video tắt tiếng.
 Dùng thuộc tính playsinline để ngăn việc phát video toàn màn hình.
Một thẻ HTML video khi đó sẽ có dạng như sau:
<video id="myVideo" playsinline autoplay muted></video>
Để làm rõ sự khác biệt giữa iOS Safari và các trình duyệt khác, cần tìm
hiểu quá trình phát triển trình duyệt này.
Kể từ khi Safari bắt đầu hỗ trợ video trên hệ điều hành iOS 3, dữ liệu chỉ
được tải về khi người dùng tương tác với trang web. Tới iOS 8, Safari cho phép
tải trước một phần dữ liệu để xác định kích thước, thời lượng và các luồng
(track) của video. Safari trên iOS 10 cho phép tự động phát các video không có
âm thanh mà không cần cử chỉ của người dùng (user gesture).
Điều này giúp tiết kiệm được một lượng đáng kể tài nguyên hệ thống khi
sử dụng video chuẩn H.264 để mã hóa các bức ảnh động thay vì dùng khuôn
dạng ảnh GIF, bởi GIF có thể tiêu tốn tới 12 lần băng thông và 2 lần năng lượng
sử dụng so với dùng video H.264. Các nhà phát triển dần dùng thẻ <video> thay
thế cho thẻ <img> khi muốn trình chiếu hay hiển thị ảnh động trên website của
mình.
Tuy nhiên, trên hệ điều hành iOS 9 trở về trước, các video trên Safari chỉ
được phát khi có cử chỉ của người dùng (chẳng hạn bấm 1 nút bấm hay ấn bàn

31
phím), và sẽ phát ở chế độ mặc định là toàn màn hình. Do đó, để video hiển thị
như trên các trình duyệt khác mà vẫn tiết kiệm băng thông và pin cho thiết bị, kể
từ iOS 10, Apple đã thay đổi WebKit (bộ công cụ xây dựng trang web) và thêm
vào các chính sách mới:
 cho phép autoplay nếu video không có âm thanh, tắt tiếng hay phần
âm thanh (audio track) bị vô hiệu hóa.
 video chỉ bắt đầu phát khi hiển thị trên màn hình và sẽ tạm dừng nếu
không được hiển thị, chẳng hạn khi bị cuộn ra khỏi khung nhìn
(viewport).
 có thể thêm thuộc tính playsinline để ngăn phát video toàn màn hình.
Những thay đổi này không chỉ giúp việc tùy biến hiển thị các video trở
nên tự nhiên và dễ dàng hơn, mà còn cho phép những tính năng nâng cao như
hiển thị <video> trên nền <canvas> mà không cần để video ở toàn màn hình,
hay kết xuất (render) đồ họa trong ngữ cảnh WebGL.
Khi áp dụng những thay đổi trên, ta thu được một giải pháp media
streaming toàn diện có thể chạy ổn định trên hầu hết các nền tảng hệ điều hành
hiện nay (Windows, Linux, MacOS hay Android, iOS).
5. CÁC VẤN ĐỀ VỀ CHỨNG CHỈ TỰ KÝ
Để bật tất cả các loại tính năng bảo mật cho ứng dụng, từ HTTPS đến
Secure WebSocket (wss://), ta cần cung cấp chứng chỉ SSL hợp lệ. Có hai lựa
chọn sau:
 Có được chứng chỉ đáng tin cậy (trusted certificate) ký bởi Nhà cung
cấp chứng thực số (Certification Authority - CA). Đây nên là lựa chọn
chính khi triển khai phiên bản hoàn thiện của phần mềm.
 Tạo chứng chỉ tự ký (self-signed certificate) tùy chỉnh, không đáng tin
cậy (untrusted). Cách này có thể giảm bớt các hoạt động trong giai
đoạn phát triển phần mềm và làm cho việc kiểm thử dễ dàng hơn.
Trên mạng có nhiều hướng dẫn cách tạo một chứng chỉ tự ký, tuy nhiên
nhà phát triển được khuyên dùng một công cụ tạo chứng chỉ, chẳng hạn mkcert.
Việc sử dụng trực tiếp các lệnh OpenSSL là hoàn toàn ổn, nhưng trên web có
đầy các hướng dẫn lỗi thời và có thể sẽ gặp phải rất nhiều cạm bẫy do các bản
cập nhật thường xuyên về chính sách trình duyệt quy định cách tạo chứng chỉ.

32
Thay vào đó, công cụ tạo chứng chỉ đã tính đến các điều kiện cần và hạn chế của
hầu hết các ứng dụng và trình duyệt phổ biến.
Để tạo tệp chứng chỉ mới với mkcert, ta chạy các lệnh sau:
# Tạo file chứng chỉ tự ký mới.
CAROOT="$PWD" mkcert -cert-file cert.pem -key-file key.pem \
"127.0.0.1" \
"::1" \
"localhost" \
"*.test.local"
# Tạo 1 file kết hợp để dùng với KMS.
cat cert.pem key.pem > cert+key.pem
# Chống ghi đè lên file.
chmod 440 *.pem
Lệnh này bao gồm một số tác dụng: cho phép truy cập từ localhost ở dạng
IPv4, IPv6 và tên máy chủ; sử dụng ký tự đại diện *.test.local, giúp máy phát
triển có thể truy cập được thông qua bất kỳ các miền phụ mong muốn nào. Bằng
cách này, các tệp cert có thể được sử dụng không chỉ cho localhost mà còn cho
kiểm thử trong mạng LAN. Do *.local bị cấm dùng cho các tên miền cấp cao
nhất (TLD - Top Level Domain), nên ta dùng *.test.local.
5.1. Sử dụng tên miền cục bộ
Ta có thể tận dụng ký tự đại diện tên miền như *.test.local, bằng cách chỉ
cần thêm một mục mới vào file /etc/hosts trong máy tính phụ nơi sẽ truy cập vào
các dịch vụ đang phát triển trên máy chính.
Ví dụ: ta có thể thêm dòng này vào file hosts:
192.168.1.50 dev.test.local
Lúc, ta có thể mở trình duyệt Firefox hoặc Chrome, nhập dev.test.local
vào thanh địa chỉ và truy cập máy phát triển chính tại địa chỉ 192.168.1.50.
Ngoài ra, ta có thể xuất IP của máy chính của mình dưới dạng địa chỉ
Zeroconf. Kỹ thuật này rất tiện dụng, bởi vì thực tế hầu hết các nền tảng hiện
đại đều bao gồm một ứng dụng khách mDNS để phân giải địa chỉ Zeroconf. Ví
dụ: nếu máy phát triển sử dụng Ubuntu, ta có thể chạy:

33
# Lấy và xuất địa chỉ IP lên cổng mạng mặc định.
IP_ADDRESS="$(ip -4 -oneline route get 1.0.0.0 | grep -Po 'src \K([\d.]+)')"
avahi-publish --address --no-reverse -v "dev.test.local" "$IP_ADDRESS"
Hiện nay, ngoại trừ Android là nền tảng duy nhất chưa hỗ trợ phân giải
địa chỉ Zeroconf cục bộ, các nền tảng khác đều có cách hỗ trợ tương ứng: trên
Windows thông qua mDNS và DNS-SD, trên Mac và iOS cũng có sẵn mDNS,
trên Linux cũng hỗ trợ mDNS bằng cách cài đặt gói Avahi phù hợp.
5.2. Việc tin tưởng chứng chỉ tự ký
Chứng chỉ tự ký sẽ làm cho các trình duyệt hiển thị một cảnh báo bảo mật
lớn mà người dùng phải chấp nhận. Các ứng dụng không phải trình duyệt khác
cũng sẽ cần được định cấu hình để vượt qua kiểm tra bảo mật. Đây không phải
là một vấn đề vì nó sẽ chỉ xảy ra trong giai đoạn phát triển và thử nghiệm. Có
một ngoại lệ là trên iOS Safari, trình duyệt sẽ từ chối luôn các chứng chỉ không
đáng tin thay vì hiển thị cảnh báo. Ta có thể khắc phục điều này bằng cách cài
đặt Root CA lên máy phát triển để chứng chỉ tự ký được tin cậy như thể nó được
cấp bởi Nhà cung cấp có uy tín.
Trên các trình duyệt máy tính để bàn, có thể cài đặt Root CA một cách dễ
dàng bằng mkcert như sau:
CAROOT="$PWD" mkcert -install
Trên thiết bị di động, việc cài đặt Root CA khó hơn một chút:
 Với iOS, ta có thể gửi file rootCA.pem qua email cho chính mình, sử
dụng AirDrop hoặc truyền tệp từ máy chủ HTTP. Thông thường, một
hộp thoại sẽ bật lên hỏi ta có muốn cài đặt chứng chỉ mới hay không;
sau đó, ta phải kích hoạt hoàn toàn tin tưởng vào nó (thông qua
Settings -> General -> About -> Certificate Trust Settings, dưới phần
"Enable full trust for root certificates" bật trust cho Certificate tương
ứng). Khi hoàn tất, chứng chỉ tự ký sẽ được hệ thống tin cậy và iOS
Safari sẽ cho phép truy cập các trang trên miền phụ *.test.local. Có
một lưu ý là trên iOS chỉ cho phép tải và cài đặt chứng chỉ thông qua
các ứng dụng AirDrop, Apple Mail hoặc Safari.
 Với Android, ta sẽ phải cài đặt Root CA lên thiết bị và sau đó cấp
quyền root cho người dùng trong bản phát triển của ứng dụng.

34
6. KẾT QUẢ THỬ NGHIỆM
Dưới đây là so sánh hiệu năng khi sử dụng thử nghiệm các kiến trúc
Media Gateway không có transcoding (hình 3.1) và có transcoding (hình 3.3)
khi cài đặt Kurento Media Server.
6.1. Cấu hình máy chủ streaming
Ta sử dụng hai máy chủ có cấu hình như sau:
- Máy tính mini NUC: Core i3-6100U CPU, 2.30GHz, 4 GB RAM
- Máy tính CPU: Core i7-7700 @ 4.2GHz, 8 GB RAM
- Số lượng camera sử dụng: 6 camera IP (của hãng Dahua).
6.2. So sánh hiệu năng khi dùng VP8 và H.264
Trước hết, với mô hình 3.1, ta thiết lập cho KMS sử dụng chuẩn H.264
làm video codec mặc định:
videoCodecs" : [
{
"name" : "VP8/90000"
}
]
Lúc này khi kết nối, KMS sẽ báo cho máy khách (trình duyệt web) chuẩn
giao tiếp là H.264. Dữ liệu đọc từ camera ở dạng mã hóa là H.264 được truyền
sang và trình duyệt sẽ không thực hiện chuyển mã từ H264 sang VP8 mà chỉ
giải mã sang định dạng thô (raw data) để hiển thị trên thẻ HTML <video>.
Với mô hình 3.3, ta cần báo cho KMS biết các trình duyệt yêu cầu chuẩn
nén VP8. Bộ xử lý trung tâm sẽ thực hiện việc giải mã và mã hóa thành dữ liệu
VP8 trước khi gửi cho các WebRTCEndPoint. Cấu hình KMS như sau:
videoCodecs" : [
{
"name" : "VP8/90000"
}
]
Hoặc nếu muốn KMS hỗ trợ cả hai chuẩn VP8 và H.264, ta cần thiết lập:
videoCodecs" : [

35
 {
"name" : "VP8/90000"
},
{
"name" : "H264/90000"0
}
]
Khi đó, KMS sẽ luôn chọn VP8 làm video codec mặc định. Nếu video
nguồn đã là VP8 thì máy khách (vd Chrome, FireFox) sẽ chỉ giải mã VP8 thành
dạng dữ liệu thô (Raw Data) để hiển thị trên thẻ video của HTML; ngược lại,
nếu video nguồn (gửi từ KMS) là H.264 thì dữ liệu này khi đến máy khách, các
trình duyệt sẽ thực hiện on-the-fly transcoding (chuyển đổi video codec) từ
H.264 sang VP8, sau đó decoding VP8 sang Raw Data để hiển thị trên trình
duyệt. Quá trình chuyển mã từ H.264 sang VP8 sẽ tiêu tốn thêm một lượng tài
nguyên CPU và RAM nhất định.
Hình 3.5 minh họa tài nguyên cần thiết để truyền dữ liệu từ 6 camera
dùng kiến trúc 3.1. Ta thấy CPU và RAM sử dụng là rất nhỏ (RAM: 1.2Gb trên
4 GB), CPU chỉ dao động khoảng 18%. Hình ảnh từ 6 camera được hiển thị
trên Hình 3.6. CPU sử dụng khi bỏ qua khối giải mã – mã hóa (transcoding) là
rất nhỏ tại bộ xử lý trung tâm. Tuy nhiên, khi có chế độ giải mã – mã hóa (ví dụ
dùng chuẩn VP8), thì CPU trên máy tính NUC nhảy vọt lên 100% trong khi
RAM không thay đổi đáng kể đối với 6 camera. Thực tế máy hoạt động hết
công suất và khá nóng.
Khi lặp lại thử nghiệm trên cho máy chủ streaming thứ hai (Core i7-7700
@ 4.2GHz, 8 GB RAM) thì dù có dùng transcoding thì CPU usage chỉ tăng lên
khá nhỏ (khoảng 6%). Điều này là do chip của máy chủ thứ hai này có thể được
tối ưu hóa cho việc video decoding nên quá trình này không tiêu hao nhiều
CPU. Ngoài ra, đối với cả hai loại máy chủ streaming ở trên, nếu bổ sung đồng
thời thêm chức năng ghi dữ liệu vào ổ cứng (định dạng webm) thì CPU tăng lên
không đáng kế (5%). Như vậy, hiệu năng recording khá ổn định đối với cả hai
chuẩn H264 và VP8.

36
 Hình 3.11 Đo các thông số CPU và RAM tại máy chủ streaming

Hình 3.12 Hình ảnh video streaming của 6 camera

Một nhận xét khác ở phía trình duyệt đó là dù transcoding hay không thì
phía trình duyệt vẫn phải giải mã dữ liệu video (hoặc H264 hoặc VP8) thành
raw data để hiển thị lên các thẻ HTML. Tiêu hao CPU cho việc này là không
đáng kể (khoảng 18% trên máy CPU core i7). Băng thông tăng từ 1Mbps đến
2Mbps (rendering 2 cam đồng thời trên trình duyệt).

37
 KẾT LUẬN

Với nhiều ưu điểm như hoàn toàn miễn phí, cài đặt gọn nhẹ, dễ tùy biến,
hỗ trợ xử lý tốt sự cố khi truyền tải dữ liệu, công nghệ Kurento dựa trên
WebRTC là một giải pháp hữu ích cho nhu cầu streaming đang ngày càng tăng
và có thể được áp dụng rộng rãi vào nhiều lĩnh vực của đời sống, từ camera
giám sát an ninh tới các ứng dụng livestream, video chat hay video conference
(hội nghị trực tuyến).

Báo cáo này đã trình bày chi tiết về công nghệ WebRTC và Kurento
Media Server, cũng như những cài đặt cần thiết cho KMS dùng khi streaming
trên các hệ điều hành khác nhau. Dựa trên đó, ta có thể tích hợp thêm nhiều
thuật toán xử lý hình ảnh để tạo ra các ứng dụng phức tạp với tính năng nâng
cao hơn. Sự phát triển nhanh chóng của ngành công nghiệp livestream trong
thời đại 4.0 hứa hẹn tiềm năng đáng kể cho các ứng dụng như vậy.

Cuối cùng, chúng em xin gửi lời cảm ơn tới thầy Phạm Thế Anh và các
thầy cô trong Khoa CNTT&TT đã kiên nhẫn, tận tình hướng dẫn, giúp đỡ nhóm
chúng em trong quá trình thực tập. Những kiến thức, kĩ năng nhận được khi học
và làm tại Khoa sẽ là hành trang quý báu cho chúng em trong công việc và cuộc
sống sau này.

38
 TÀI LIỆU THAM KHẢO

1. https://webrtc-security.github.io/

2. https://viblo.asia/p/webrtc-la-gi-gioi-thieu-ve-kurento-mot-may-chu-
truyen-thong-webrtc-gGJ59xjJlX2

3. https://doc-kurento.readthedocs.io/en/latest/user/intro.html

4. https://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras

5. https://doc-kurento.readthedocs.io/en/latest/knowledge/safari.html

6. https://webkit.org/blog/6784/new-video-policies-for-ios/

7. http://www.vp9.vn/

8. https://www.ffmpeg.org/

9. https://www.wowza.com/

10. Miguel Grinberg, Video Streaming with Flask, 2014,

https://blog.miguelgrinberg.com/post/video-streaming-with-flask

11. Martin Bohme, Tutorial 01: Making Screencaps,

http://dranger.com/ffmpeg/tutorial01.html

KHOA CNTT&TT BỘ MÔN QUẢN LÝ GV HƯỚNG DẪN TRƯỞNG NHÓM SV

PHẠM THẾ ANH TRỊNH VIẾT CƯỜNG PHẠM THẾ ANH LƯU NGUYÊN BẰNG

39