Đề tài xây dựng giải pháp video streaming đa nền tảng

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ứ: /Số năm đào tạo: 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 TT DANH SÁCH THÀNH VIÊN TRONG NHÓM TTTN Họ tên Lưu Nguyên Bằng Lớp K19 ĐH CNTT Nội dung tham gia 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 tiểu mục Trang Danh sách thành viên nhóm TTTN i Mục lục ii Danh mục bảng biểu iii Danh mục ký hiệu, chữ viết tắt iv Thông tin kết nghiên cứu v GIỚI THIỆU VỀ WEB RTC 1 Sơ lược lịch sử phát triển Thiết kế của Web RTC 2.1 Các thành phần chính 2.2 Các giao thức được sử dụng 2.3 Kiến trúc hệ thống WebRTC 3 Những lợi ích của WebRTC GIỚI THIỆU VỀ KURENTO MEDIA SERVER Khái niệm Media Servers Kurento và Kurento Media Server 2.1 Giới thiệu chung 2.2 Nguyên lý thiết kế của Kurento 2.3 Kurento API 10 Chương I Chương II Chương III GIẢI PHÁP VIDEO STREAMING ĐA NỀN TẢNG CHO CAMERA IP BẰNG KURENTO 15 Kiến trúc phát triển ứng dụng 17 Tích hợp WebRTC và Camera IP 25 Sử dụng Kurento Media Server 27 Giải pháp video streaming đa tảng 30 Các vấn đề về chứng chỉ tự ký 32 Kết thử nghiệm 35 Kết luận 38 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 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 của WebRTC Media Server điển hình Hình 2.3 Hình 2.3 Những tính của Kurento Media Server Hình 2.4 Cài đặt Kurento Client API Java SDK và Javascript SDK Bảng 2.1 Các Endpoint Kurento API Bảng 2.2 Các Filter Kurento API Bảng 2.3 Các Hub Kurento API Hình 2.5 Hộp công cụ Kurento mở rộng Hình 2.6 Các mô-đun Kurento Media Server Hình 3.1 Sự tương đồng kiến trúc phân lớp ứng dụng web ứng dụng đa phương tiện (Kurento) Hình 3.2 Các mặt phẳng truyền thơng tín hiệu kiến trúc ứng dụng Kurento Hình 3.3 Tương tác mơ-đun đàm phán và trao đổi media Hình 3.4 Tương tác phiên WebRTC Hình 3.5 Ví dụ pipeline cho 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 Hình 3.9 Kiến trúc Media Gateway Kurento Media Server Hình 3.10 Cấu hình xử lý cho nhiều người xem thiết bị đầu cuối khác Hình 3.11 Đo thông số CPU RAM máy chủ streaming Hình 3.12 Hình ảnh video streaming camera Trang iv DANH MỤC CÁC KÍ HIỆU, CHỮ VIẾT TẮT Ký hiệu, chữ viết tắt WebRTC Được hiểu 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ả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 Trang v Tầng socket bảo mật (Secure Sockets Layer) THÔNG TIN KẾT QUẢ NGHIÊN CỨU Tên đề tài: Xây dựng giải pháp media streaming đa nền tảng Loại đề tài: Thực tập tốt nghiệp Nhóm sinh viên thực hiện: - Họ 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 Giảng viên hướng dẫn: PGS.TS Phạm Thế Anh 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 SƠ LƯỢC LỊCH SỬ PHÁT TRIỂN WebRTC (Web Real-Time Communication) web API phát triển Google và Hiệp hội W3C (World Wide Web Consortium), có khả hỗ trợ trình duyệt giao tiếp với 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ợ từ bên WebRTC lúc Google muốn xây dựng chuẩn thay thế cho Flash để thực các ứng dụng thời gian thực tất trình duyệt Năm 2010, Google mua lại hai cơng ty On2 Global IP Solutions (GIPS) để lấy công nghệ truyền liệu thời gian thực làm tảng cho WebRTC sau Tháng 5/2011, Google mắt dự án mã nguồn mở dành cho việc giao tiếp thời gian thực trình duyệt với nhau, từ lúc dự án mang tên WebRTC Song song đó, Hiệp hội World Wide Web (W3C) Hiệp hội Kĩ sư quốc tế (IETF) phát triển số giao thức để dùng cho việc việc kết nối thời gian thực, nên họ bắt tay tiếp tục hoàn thiện để định kết hợp chung vào WebRTC Đến 27/10/2011, W3C mắt nháp WebRTC Tháng 11/2011, Chrome 23 mắt, trở thành trình duyệt có hỡ trợ sẵn (builtin) WebRTC Dưới là một số mốc thời gian 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ợ Google Chrome 23  1/2013: Hỗ trợ 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 beta Chrome 29 Android  10/2013: Bắt đầu hỗ trợ phiê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 Opera 20 Android  7/2014: Tích hợp 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 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, các nền tảng di động và các thiết bị IoT (Internet of Things) 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 liệu hình ảnh, âm 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ý 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 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 số liệu thống kê 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 độ tin cậy, giao thức UDP sử dụng WebRTC làm giao thức vận chuyển dữ liệu Nhưng để thỏa mãn yêu cầu trình duyệt, phải hỗ trợ giao thức dịch vụ các lớp khác Về giao thức sử dụng WebRTC thể hình dưới: Hình 1.1 Protocol Stack WebRTC Các giao thức ICE, STUN, and TURN là cần thiết để thiết lập và 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à tính 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 phần dịch vụ bổ sung khác 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 đó 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 thời gian thực nhằm trao đổi thông tin cần thiết để hai trình duyệt kết nối với Sau 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 Kiến trúc hệ thống WebRTC được minh họa một cách đơn giản sau: Hình 3.6 Ví dụ mợt Media Pipeline đơn giản Kết nối kiểm sốt thông qua giao diện nguyên thủy (primitive) connect, hiển thị tất Kurento Client API Primitive ln gọi phần tử đóng vai trị nguồn lấy phần tử đích (sink element) làm đối số theo lược đồ: sourceMediaElement.connect(sinkMediaElement) Ví dụ: muốn tạo ứng dụng ghi luồng WebRTC vào hệ thống tệp, bạn cần phần tử phương tiện: WebRtcEndpoint RecorderEndpoint Khi máy khách kết nối với ứng dụng, bạn cần phải khởi tạo phần tử phương tiện cho luồng nhận WebRtcEndpoint (có khả nhận luồng WebRTC) đưa đến RecorderEndpoint (có khả ghi luồng phương tiện vào hệ thống tệp) Cuối cùng, bạn cần kết nối chúng để luồng nhận phần tử trước sẽ chuyển sang phần tử sau: WebRtcEndpoint.connect(RecorderEndpoint) Để đơn giản hóa việc xử lý luồng WebRTC phía máy khách, Kurento cung cấp tiện ích có tên WebRtcPeer Tuy nhiên, API WebRTC tiêu chuẩn (getUserMedia, RTCPeerConnection, v.v.) sử dụng để kết nối với WebRtcEndpoints TÍCH HỢP WEB RTC VÀ CAMERA IP Điều đầu tiên cần lưu ý 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 hầu hết Camera IP và được hỗ trợ hầu hết các 25 trình duyệt web hiện Chuẩn H.264 cũng là codec phổ biế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 trực tiếp là luồng dữ liệu WebRTC thông qua cổng truyền thông (Media Gateway), 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 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 đờ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ả phản hồi lại một cách phù hợp 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ế nghẽn đường truyền, mất gói tin, … Để giải quyết việc này, WebRTC cung cấp 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ả 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 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, đó 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ứ vào đó để thay đổi tốc độ bit (bitrate) mã hóa thích hợp  Khi có gói tin bị mất đườ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ụ, 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 video chất lượng thấp hơn, kích thước nhẹ để 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 các sự cố mạng điển hình, cái giá phải trả là server phải xử lý nặng nhiều Tuy nhiên sự đánh đổi này thường là đáng giá SỬ DỤNG KURENTO MEDIA SERVER Những khó khăn nêu là những vấn đề điển hình gặp phải 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 một giải pháp toàn diện cho việc này Kurento Media Gateway sẽ bao gồm 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 thành phần này, ta có thể tạo 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 Kurento Media Server Phần chủ chốt 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 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 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 bên nhận chỉ hỗ trợ VP8, thì ở 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 Khi đó băng thông ước lượng tin nhắn REMB sẽ được giới hạn phạm vi đặt cho ứng dụng 28 Ở nảy sinh một câu hỏi: 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 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 người xem tăng lên số lượng lớn Kurento đưa giải pháp thỏa hiệp, dùng pipeline để giải mã 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 nhiều phần tử WebRTCEndPoint kết nối đến nguồn liệu giải mã, mỗi WebRTCEndPoint chịu trách nhiệm truyền liệu đến cho người xem theo codec phù hợp (hình 3.4) Do mã hóa video tác vụ “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 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 thiết bị đầu cuối khác 29 GIẢI PHÁP VIDEO STREAMING ĐA NỀN TẢNG Giải pháp Kurento chạy tốt các tảng Android, Windows (với các trình duyệt Chrome, Firefox) không chạy ổn định các hệ điều hành iOS, Mac OS (trình duyệt Safari), những nguyên nhân sau Thứ nhất là Apple, hãng công nghệ xây dựng và phát triển hệ điều hành iOS cũng 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ở Những phiên bản cũ 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 truyền sang các thiết bị chạy WebRTC Safari Thứ hai là một số khác biệt của chính sách HTML về chế độ hiển thị video trình duyệt Safari iOS:  Chế độ autoplay Thông thường, để thêm một video vào file HTML, ta làm sau: Hầu hết trình duyệt (bao gồm cả Safari 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 có kết nối tới nguồn phát Tuy nhiên Safari 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 (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 trạng thái tắt tiếng bằng cách thêm thuộc tính muted cặp thẻ 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 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 đó gọi hàm video.play() để phát video  Chế độ playsinline 30 Hầu hết trình duyệt sẽ phát video một khung có kích thước cụ thể được định cặp thẻ video Chẳng hạn: sẽ phát video khung có kích thước 480 x 360 điểm ảnh (pixel) Tuy nhiê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: và video sẽ được phát khung hình đã định (480 x 360) Tóm lại, để tự động phát video iOS Safari giống các trình duyệt khác, cần làm 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 đó sẽ có dạng sau: Để 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ừ Safari bắt đầu hỗ trợ video hệ điều hành iOS 3, dữ liệu chỉ được tải về 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 iOS 10 cho phép tự động phát các video không có âm 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 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à lần 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ẻ thay thế cho thẻ muốn trình chiếu hay hiển thị ảnh động website của mình Tuy nhiên, hệ điều hành iOS trở về trước, các video Safari chỉ được phát có cử chỉ của người dùng (chẳng hạn bấm 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ị 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 (audio track) bị vô hiệu hóa  video chỉ bắt đầu phát hiển thị màn hình và sẽ tạm dừng nếu không được hiển thị, chẳng hạn bị cuộn 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 cao hiển thị nền mà không cần để video ở toàn màn hình, hay kết xuất (render) đồ họa 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 hầu hết các nền tảng hệ điều hành hiện (Windows, Linux, MacOS hay Android, iOS) CÁC VẤN ĐỀ VỀ CHỨNG CHỈ TỰ KÝ Để bật tất loại tính bảo mật cho ứng dụng, từ HTTPS đến Secure WebSocket (wss://), ta cần cung cấp chứng SSL hợp lệ Có hai lựa chọn sau:  Có chứng đá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ựa chọn triển khai phiên bản hoàn thiện phần mềm  Tạo chứng tự ký (self-signed certificate) tùy chỉnh, không đáng tin cậy (untrusted) Cách giảm bớt hoạt động giai đoạn phát triển phần mềm làm cho việc kiểm thử dễ dàng Trên mạng có nhiều hướng dẫn cách tạo một chứng chỉ tự ký, 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 lệnh OpenSSL hồn tồn ổn, web có đầy hướng dẫn lỗi thời gặp phải nhiều cạm bẫy cập nhật thường xun sách trình duyệt quy định cách tạo chứng 32 Thay vào đó, công cụ tạo chứng tính đến điều kiện cần hạn chế hầu hết ứng dụng trình duyệt phổ biến Để tạo tệp chứng với mkcert, ta chạy 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 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 bao gồm một số tác dụng: cho phép truy cập từ localhost dạng IPv4, IPv6 tên máy chủ; sử dụng ký tự đại diện *.test.local, giúp máy phát triển truy cập thông qua các miền phụ mong muốn Bằng cách này, tệp cert sử dụng khơng cho localhost mà cịn cho kiểm thử 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 tận dụng ký tự đại diện tên miền *.test.local, cách cần thêm mục vào file /etc/hosts máy tính phụ nơi truy cập vào dịch vụ phát triển máy chính Ví dụ: ta thêm dịng vào file hosts: 192.168.1.50 dev.test.local Lúc, ta mở trình duyệt Firefox Chrome, nhập dev.test.local vào địa truy cập máy phát triển địa 192.168.1.50 Ngồi ra, ta xuất IP máy dạng địa Zeroconf Kỹ thuật tiện dụng, thực tế hầu hết tảng đại bao gồm ứng dụng khách mDNS để phân giải địa Zeroconf Ví dụ: máy phát triển sử dụng Ubuntu, ta 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 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: Windows thông qua mDNS và DNS-SD, Mac và iOS cũng có sẵn mDNS, 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 tự ký làm cho trình duyệt hiển thị 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ần định cấu hình để vượt qua kiểm tra bảo mật Đây khơng phải vấn đề xảy giai đoạn phát triển thử nghiệm Có một ngoại lệ là iOS Safari, trình duyệt sẽ từ chối 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 thể cấp Nhà cung cấp có uy tín Trên 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 sau: CAROOT="$PWD" mkcert -install Trên thiết bị di động, việc cài đặt Root CA khó chút:  Với iOS, ta gửi file rootCA.pem qua email cho mình, sử dụng AirDrop truyền tệp từ máy chủ HTTP Thông thường, hộp thoại bật lên hỏi ta có muốn cài đặt chứng hay khơng; sau đó, ta phải kích hoạt hồn tồn tin tưởng vào (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 tự ký hệ thống tin cậy iOS Safari cho phép truy cập trang miền phụ *.test.local Có một lưu ý là 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 phải cài đặt Root CA lên thiết bị sau cấp quyền root cho người dùng bản phát triển của ứng dụng 34 KẾT QUẢ THỬ NGHIỆM Dưới là so sánh hiệu 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) 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 sau: - Máy tính mini NUC: Core i3-6100U CPU, 2.30GHz, GB RAM - Máy tính CPU: Core i7-7700 @ 4.2GHz, GB RAM - Số lượng camera sử dụng: camera IP (của hãng Dahua) 6.2 So sánh hiệu 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 kết nối, KMS sẽ báo cho máy khách (trình duyệt web) chuẩn giao tiếp 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ị thẻ HTML Với mô hình 3.3, ta cần báo cho KMS biết trình duyệt yêu cầu chuẩn nén VP8 Bộ xử lý trung tâm thực việc giải mã mã hóa thành liệu VP8 trước gửi cho WebRTCEndPoint Cấu hình KMS sau: videoCodecs" : [ { "name" : "VP8/90000" } ] Hoặc nếu muốn KMS hỗ trợ hai chuẩn VP8 H.264, ta cần thiết lập: videoCodecs" : [ 35 { "name" : "VP8/90000" }, { "name" : "H264/90000"0 } ] Khi đó, KMS sẽ chọn VP8 làm video codec mặc định Nếu video nguồn VP8 máy khách (vd Chrome, FireFox) giải mã VP8 thành dạng liệu thô (Raw Data) để hiển thị thẻ video HTML; ngược lại, video ng̀n (gửi từ KMS) H.264 liệu đến máy khách, trình duyệt thực on-the-fly transcoding (chuyển đổi video codec) từ H.264 sang VP8, sau decoding VP8 sang Raw Data để hiển thị 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 liệu từ camera dùng kiến trúc 3.1 Ta thấy CPU RAM sử dụng nhỏ (RAM: 1.2Gb GB), CPU dao động khoảng 18% Hình ảnh từ camera hiển thị Hình 3.6 CPU sử dụng bỏ qua khối giải mã – mã hóa (transcoding) nhỏ xử lý trung tâm Tuy nhiên, có chế độ giải mã – mã hóa (ví dụ dùng chuẩn VP8), CPU máy tính NUC nhảy vọt lên 100% RAM khơng thay đổi đáng kể camera Thực tế máy hoạt động hết cơng suất nóng Khi lặp lại thử nghiệm cho máy chủ streaming thứ hai (Core i7-7700 @ 4.2GHz, GB RAM) dù có dùng transcoding CPU usage tăng lên nhỏ (khoảng 6%) Điều chip máy chủ thứ hai tối ưu hóa cho việc video decoding nên q trình khơng tiêu hao nhiều CPU Ngoài ra, hai loại máy chủ streaming trên, bổ sung đồng thời thêm chức ghi liệu vào ổ cứng (định dạng webm) CPU tăng lên khơng đáng kế (5%) Như vậy, hiệu recording ổn định hai chuẩn H264 VP8 36 Hình 3.11 Đo thông số CPU RAM máy chủ streaming Hình 3.12 Hình ảnh video streaming camera Một nhận xét khác phía trình duyệt dù transcoding hay khơng phía trình duyệt phải giải mã liệu video (hoặc H264 VP8) thành raw data để hiển thị lên thẻ HTML Tiêu hao CPU cho việc không đáng kể (khoảng 18% máy CPU core i7) Băng thông tăng từ 1Mbps đến 2Mbps (rendering cam đồng thời trình duyệt) 37 KẾT LUẬN Với nhiều ưu điểm 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ố truyền tải dữ liệu, công nghệ Kurento dựa WebRTC là một giải pháp hữu ích cho nhu cầu streaming 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ững cài đặt cần thiết cho KMS dùng streaming các hệ điều hành khác Dựa đó, ta có thể tích hợp thêm nhiều thuật toán xử lý hình ảnh để tạo các ứng dụng phức tạp với tính nâng cao Sự phát triển nhanh chóng của ngành công nghiệp livestream thời đại 4.0 hứa hẹn tiềm đáng kể cho các ứng dụng 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ô Khoa CNTT&TT đã kiên nhẫn, tận tình hướng dẫn, giúp đỡ nhóm chúng em quá trình thực tập Những kiến thức, kĩ nhận được học và làm tại Khoa sẽ là hành trang quý báu cho chúng em công việc và cuộc sống sau này 38 TÀI LIỆU THAM KHẢO https://webrtc-security.github.io/ https://viblo.asia/p/webrtc-la-gi-gioi-thieu-ve-kurento-mot-may-chutruyen-thong-webrtc-gGJ59xjJlX2 https://doc-kurento.readthedocs.io/en/latest/user/intro.html https://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras https://doc-kurento.readthedocs.io/en/latest/knowledge/safari.html https://webkit.org/blog/6784/new-video-policies-for-ios/ http://www.vp9.vn/ https://www.ffmpeg.org/ 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 PHẠM THẾ ANH LƯU NGUYÊN BẰNG TRỊNH VIẾT CƯỜNG 39