Ngay từ những ngày đầu tiên làm việc trên hệ thống giám sát video trên đám mây, chúng tôi đã phải đối mặt với một vấn đề mà không có giải pháp nào mà chúng tôi có thể từ bỏ trên Ivideon - đây là Everest của chúng tôi, việc leo núi tốn rất nhiều năng lượng, nhưng giờ đây cuối cùng chúng tôi đã có nhét một chiếc rìu băng vào đầu câu đố đa nền tảng.
Hệ thống truyền âm thanh và video qua Internet không được phụ thuộc vào thiết bị, ứng dụng khách Web và các tiêu chuẩn mà chúng hỗ trợ, đồng thời cũng hoạt động chính xác khi có Trình dịch địa chỉ mạng và tường lửa. Người dùng giám sát video trên đám mây muốn truy cập dịch vụ, ngay cả khi anh ta sử dụng camera analog và thích xem video phát trực tiếp trên thiết bị hiện đại nhất.
Điều rất quan trọng là người dùng muốn xem video với độ trễ tối thiểu. Hầu như cách duy nhất để hiển thị video có độ trễ thấp trong trình duyệt là sử dụng WebRTC (giao tiếp thời gian thực trên web). WebRTC là một tập hợp các công nghệ để truyền video và âm thanh ngang hàng trong trình duyệt, ban đầu được thiết kế để truyền và phát lại các luồng video có độ trễ thấp. Với mục đích này, trong số những mục đích khác, giao thức UDP được sử dụng.
Trước khi cho bạn biết công cụ mới mang lại cho người dùng những gì, chúng tôi sẽ nhắc bạn lý do và lý do chúng tôi hỗ trợ công nghệ HLS cũng như lý do chúng tôi quyết định tiếp tục.
Động cơ HLS: ưu và nhược điểm
()
Công nghệ HLS (HTTP Live Streaming) được Apple phát triển, vì vậy không có gì ngạc nhiên khi nó được hỗ trợ đầu tiên trên các thiết bị của Apple. Ngày nay, video HLS cũng được hỗ trợ bởi hầu hết các đầu thu kỹ thuật số và nhiều thiết bị chạy hệ điều hành này. Android.
Công cụ HLS sử dụng codec video H264 nổi tiếng kết hợp với luồng âm thanh AAC hoặc MP3 để truyền dữ liệu video. Toàn bộ luồng dữ liệu âm thanh và video được đóng gói vào bộ chứa truyền tải MPEG-TS. Để truyền qua giao thức HTTP, thông tin có trong luồng được chia thành các đoạn được mô tả trong danh sách phát m3u8. Và chỉ khi đó những đoạn này cùng với danh sách phát mới được truyền qua HTTP. Chunking tự động có nghĩa là độ trễ tính bằng giây. Đây là một tính năng của bộ chứa MPEG-TS.
Công cụ HLS cũng hỗ trợ các luồng đa tốc độ, Live/VOD.
Ưu điểm chính của HLS:
- hỗ trợ tích hợp trong tất cả các trình duyệt chính;
- dễ thực hiện (so với WebRTC);
- Sẽ rất thuận tiện và hiệu quả khi tổ chức tất cả các loại chương trình phát sóng tới một lượng lớn khán giả do thực tế là các phân đoạn có thể được tải lên CDN một lần.
Mặc dù động cơ đơn giản nhưng không phải mọi thứ đều suôn sẻ như người ta tưởng. Vấn đề chính là các nhà phát triển trình phát bên thứ ba đã bỏ qua các đề xuất của Apple, chẳng hạn như về các định dạng âm thanh được hỗ trợ. Đặc biệt, nhiều nhà phát triển bắt đầu bổ sung khả năng hoạt động với các luồng âm thanh phổ biến: video mpeg2, âm thanh mpeg2, v.v. Kết quả là họ phải tạo các định dạng danh sách phát khác nhau cho những trình phát khác nhau.
Nhưng một trong những vấn đề lớn nhất với công cụ HLS là độ trễ truyền dữ liệu cao.
Nguồn gốc của “phanh”
Nguyên nhân chính khiến HLS có độ trễ cao nằm ở chỗ các lập trình viên đã tạo ra công cụ để thu được hình ảnh chất lượng cao nhất. Do đó, các tham số về khoảng thời gian khung hình được sử dụng và kích thước của bộ đệm phát lại đơn giản là không phù hợp để phát sóng video trực tiếp. Do đó, việc truyền đoạn phim video có độ trễ khá cao, có thể là 5-7 giây.
Một mặt, con số này không nhiều, chẳng hạn đối với những người xem phim từ máy chủ lưu trữ video. Nhưng đối với các hệ thống giám sát video, độ trễ truyền cảnh quay video có thể rất quan trọng.
Nếu bạn đang xem một văn phòng nơi nhân viên nhìn lên từ màn hình của họ mỗi giờ một lần thì độ trễ 5 giây không thành vấn đề. Nhưng mọi người bắt đầu phàn nàn rằng, chẳng hạn như khi phát sóng một trận bóng đá, họ đã viết GOOOOL trong cuộc trò chuyện, nhưng điều này vẫn chưa có trên video :). Chúng tôi đã có một số trường hợp người dùng trong đó Ivideon gần như có thể thay thế Skype.
Có thể đánh bại độ trễ trong HLS không? Câu trả lời cho câu hỏi này nghe giống như bài phát biểu của một chuyên gia diệt chuột có kinh nghiệm tại bài giảng dành cho các chuyên gia kiểm soát dịch hại mới vào nghề: “Không thể tiêu diệt chuột, nhưng số lượng của chúng có thể giảm đến mức tối thiểu hợp lý”. Tương tự với độ trễ trong HLS, sẽ không thể giảm nó xuống XNUMX, nhưng có những giải pháp trên thị trường có thể giảm đáng kể độ trễ.
Vết cắt mịn
Một nhược điểm khác của công cụ này là việc sử dụng các tệp nhỏ để truyền dữ liệu. Có vẻ như điều này có vấn đề gì?
Bất cứ ai đã cố gắng sao chép một số lượng lớn các tệp nhỏ từ phương tiện này sang phương tiện khác có lẽ đã nhận thấy rằng tốc độ ghi của một tập hợp như vậy thấp hơn nhiều so với một tệp lớn có cùng kích thước. Và cường độ truy cập vào ổ cứng tăng lên đáng kể, điều này thường ảnh hưởng tiêu cực đến hiệu suất của toàn bộ máy tính. Do đó, việc truyền dữ liệu video theo từng đoạn nhỏ 10 giây cũng góp phần làm tăng độ trễ của động cơ.
Hãy tóm tắt ngắn gọn tất cả những ưu và nhược điểm của công nghệ HLS.
Ưu điểm của HL:
- Khả năng làm việc với mọi thiết bị. Bạn có thể xem video trên bất kỳ thiết bị hiện đại nào, có thể là điện thoại thông minh, máy tính bảng, máy tính xách tay hoặc máy tính để bàn. Điều chính là trình duyệt web được cập nhật và tương thích với HTML5 và Tiện ích mở rộng nguồn phương tiện.
- Chất lượng hình ảnh tuyệt vời. Chức năng truyền dữ liệu thích ứng được sử dụng cho phép bạn tự động thay đổi chất lượng của video được truyền tùy thuộc vào băng thông của kết nối Internet, trong khi thuật toán cố gắng duy trì chất lượng tối đa.
- Không cần cấu hình phức tạp của thiết bị của người dùng.
Nhược điểm:
- Hỗ trợ hạn chế để làm việc với động cơ trên một số thiết bị.
- Độ trễ cao trong việc truyền hình ảnh.
- Tăng đáng kể chi phí chung và độ phức tạp của việc tối ưu hóa do sử dụng các tệp nhỏ. Do tính chất của vùng chứa, chúng tôi sẽ không bao giờ có thể có độ trễ thấp hơn kích thước phân khúc.
Những nhược điểm của HLS lớn hơn những lợi thế của nó đối với chúng tôi và buộc chúng tôi phải tìm kiếm các lựa chọn thay thế.
WebRTC là gì
()
Nền tảng WebRTC được Google phát triển vào năm 2011 để truyền dữ liệu âm thanh và video trực tuyến giữa các trình duyệt và ứng dụng di động với độ trễ tối thiểu. Đối với điều này, giao thức UDP tiêu chuẩn và các thuật toán điều khiển luồng đặc biệt được sử dụng. Ngày nay nó là một dự án nguồn mở, nó được Google tích cực duy trì và đang được phát triển.
WebRTC là một tập hợp các công nghệ để truyền âm thanh và video ngang hàng. Tức là, ví dụ, các trình duyệt người dùng sử dụng WebRTC có thể truyền dữ liệu trực tiếp cho nhau mà không cần sử dụng máy chủ từ xa để lưu trữ và xử lý dữ liệu. Tất cả thông tin cũng được xử lý bởi trình duyệt và ứng dụng di động của người dùng cuối.
Tính tiện lợi và khả năng mở rộng của công nghệ này đã được các nhà phát triển của tất cả các trình duyệt phổ biến đánh giá cao. Hiện tại, WebRTC được hỗ trợ trong Mozilla Firefox, Opera, Google Chrome (và tất cả các trình duyệt dựa trên Chromium), cũng như trong các ứng dụng di động chạy hệ điều hành này. Android và iOS.
Đối với tất cả những ưu điểm chắc chắn của nó, WebRTC có một số nhược điểm đáng kể.
Khó khăn của sự lựa chọn
Công nghệ WebRTC phức tạp hơn nhiều về mặt tương tác mạng do thực tế là nó nói về P2P. Rất khó để gỡ lỗi, kiểm tra và có thể hoạt động không thể đoán trước. Đồng thời, chúng ta cần vượt qua NAT và tường lửa, cần đảm bảo hoạt động trong các mạng bị chặn UDP.
Việc triển khai WebRTC của Google rất khó sử dụng. Thậm chí còn có cả một công ty cung cấp dịch vụ lắp ráp SDK. Ngoài ra, việc triển khai của Google rất khó tích hợp với hệ thống của chúng tôi nếu không mã hóa lại toàn bộ video.
Tuy nhiên, từ lâu, chúng tôi đã muốn mang đến cho người dùng cơ hội làm việc với video “trực tiếp” hoàn chỉnh và giảm thiểu độ trễ giữa hình ảnh trên màn hình và chính các sự kiện. Ngoài ra, chúng tôi mong muốn làm cho việc sử dụng camera PTZ, nơi độ trễ là rất quan trọng, trở nên thoải mái hơn.
Nhận thấy rằng các triển khai chống trễ khác vẫn có chức năng hạn chế và hoạt động kém hơn đáng kể, chúng tôi đã quyết định sử dụng WebRTC.
Chúng ta đã làm gì
Việc triển khai đúng nền tảng WebRTC không phải là một nhiệm vụ dễ dàng. Bất kỳ tính toán sai hoặc thiếu chính xác nào cũng có thể dẫn đến độ trễ trong quá trình truyền video không những không giảm so với các nền tảng khác mà thậm chí còn tăng lên.
Để WebRTC hoạt động chính xác, trước hết, cần phải tiến hành nâng cấp công nghệ ngăn xếp để làm việc với video trên web. Đó là những gì chúng tôi đã làm.
Đầu tiên, chúng tôi đã triển khai máy chủ giao thức báo hiệu WebRTC qua Websocket, đồng thời triển khai máy chủ ngang hàng WebRTC trên đám mây dựa trên SDK webrtc.org. Nhiệm vụ của nó là phân phối các luồng video tới các máy ngang hàng WebRTC của khách hàng ở định dạng H.264 + Opus/G.711 mà không cần chuyển mã video.
Chúng tôi chọn Websocket làm giao thức báo hiệu vì nó đã có hỗ trợ chất lượng cao trong tất cả các trình duyệt web phổ biến. Do đó, bạn có thể giảm đáng kể không chỉ chi phí phát triển mà còn tránh lãng phí thời gian và tài nguyên khi bắt tay TCP và TLS lặp đi lặp lại so với AJAX.
Thực tế là, theo mặc định, WebRTC không cung cấp giao thức báo hiệu cần thiết để định cấu hình, duy trì và chấm dứt giao tiếp video theo thời gian thực giữa ứng dụng nguồn và ứng dụng khách.
Và để triển khai độc lập công nghệ báo hiệu, chúng tôi cần phát triển máy chủ báo hiệu của riêng mình với sự hỗ trợ cho một số giao thức web (Websocet, WebRTC). Và với khả năng quản lý phiên và thông báo theo thời gian thực một cách an toàn, quản lý video, v.v.
Chúng tôi đã khắc phục những hạn chế của P2P bằng cách giảm độ trễ không phải thông qua P2P mà thông qua UDP và kiểm soát luồng để giảm độ trễ. Điều này cũng được tích hợp vào WebRTC, vì trường hợp sử dụng chính là các cuộc hội thoại p2p qua trình duyệt.
Trong ứng dụng khách dành cho thiết bị di động, chúng tôi đã triển khai trình phát bằng SDK webrtc.org, vì chỉ có trình phát này mới thực hiện kiểm soát luồng một cách chính xác, có tất cả các lược đồ Sửa lỗi chuyển tiếp (FEC) đã biết và triển khai chính xác cơ chế gửi lại gói cho tất cả các trình duyệt. Điều quan trọng nữa là SDK webrtc.org đang được Google tích cực phát triển.
Kết quả của việc triển khai WebRTC là gì?
Để xem video trực tiếp từ camera, chúng tôi đã thêm trình phát mới được tối ưu hóa dựa trên WebRTC vào tài khoản cá nhân của bạn. Nó cung cấp tốc độ tải video nhanh và loại bỏ hoàn toàn vấn đề tích tụ độ trễ khi thời gian xem tăng lên.
Sau khi giới thiệu hỗ trợ WebRTC trong dịch vụ đám mây Ivideon, chúng tôi có thể hoàn toàn tin tưởng rằng khách hàng của chúng tôi giờ đây có thể xem video trực tiếp đầy đủ. Giờ đây, độ trễ khi phát chuỗi video không vượt quá một giây! Để so sánh, công cụ HLS trước đây cung cấp khả năng phân phối video với độ trễ từ 5-7 giây. Sự khác biệt về tốc độ trình chiếu video là rất đáng kể và người dùng sẽ nhận thấy điều đó ngay sau khi bắt đầu làm việc với dịch vụ video của chúng tôi.
Đúng như chúng tôi mong đợi, việc triển khai trình phát mới đã cải thiện khả năng phản hồi của PTZ và giao tiếp bằng giọng nói với máy ảnh.
Chỉ có một điểm tinh tế mà chúng tôi muốn thu hút sự chú ý. Trình phát WebRTC mới hiện đang hoạt động ở chế độ thử nghiệm. Và đó là lý do tại sao chúng tôi không kích hoạt tính năng này cho tất cả khách hàng của mình theo mặc định. Nhưng bạn có thể tự kích hoạt nó bằng cách bật mục tương ứng trong cài đặt máy ảnh (để thực hiện việc này, hãy đi tới ).
Các tính năng của việc triển khai WebRTC trong dịch vụ Ivideon
WebRTC hiện vẫn là một công nghệ thử nghiệm. Hỗ trợ của nó chưa được triển khai chính xác trên tất cả các trình duyệt và thiết bị người dùng cũng như trên tất cả các máy ảnh.
Đây chính xác là lý do tại sao chúng tôi chưa đặt trình phát WebRTC làm trình phát mặc định cho tất cả người dùng.
Hiện tại, chúng tôi khuyên bạn chỉ nên sử dụng WebRTC trong trình duyệt Google Chrome. Các phiên bản mới nhất của Firefox và Safari cũng hỗ trợ công nghệ này, nhưng đáng tiếc là nó vẫn chưa ổn định.
Chúng tôi chưa triển khai hỗ trợ WebRTC cho trình duyệt trên thiết bị di động. Hiện tại, nếu bạn đăng nhập từ thiết bị di động và kích hoạt WebRTC, chế độ này sẽ không hoạt động. Tuy nhiên, WebRTC có sẵn trong các ứng dụng di động của chúng tôi dành cho и .
Và kết thúc câu chuyện về các tính năng triển khai WebRTC trong dịch vụ của chúng tôi, hãy lưu ý hai điểm tinh tế hơn.
Thứ nhất, công nghệ này tập trung vào việc phát video trực tiếp theo thời gian thực. Do đó, nếu kênh của bạn không có đủ băng thông để truyền video, bạn sẽ nhận thấy hiện tượng giảm khung hình (với HLS, bạn sẽ thấy video mờ dần và độ trễ tăng lên, nhưng sẽ không có hiện tượng giảm khung hình), nhưng video vẫn sẽ được phát ở chế độ thực. thời gian.
Thứ hai, vì công nghệ này được thiết kế để hoạt động cụ thể với video trực tiếp trong thời gian thực nên chúng tôi không sử dụng nó để hoạt động với dữ liệu video đã lưu trữ.
Những thay đổi khác đối với dịch vụ
Lúc này, Flash không còn tham gia vào cơ chế lựa chọn động cơ tự động nữa. Bạn vẫn có thể sử dụng trình phát như vậy, nhưng để thực hiện việc này, bạn cần chọn thủ công trong cài đặt tài khoản hoặc camera. Đây không phải là sự tôn vinh dành cho thời trang, chỉ là theo thống kê dịch vụ của chúng tôi, thực tế không còn người dùng nào làm việc với Flash nữa. Và cố gắng xác định xem trình duyệt của người dùng có hỗ trợ nó hay không, chúng tôi mất khoảng 2 giây thời gian quý báu.
Dưới đây là tổng quan ngắn gọn về những thay đổi đang chờ bạn trong hệ thống giám sát video trên đám mây và tài khoản cá nhân của chúng tôi. Ở lại với chúng tôi và theo dõi tin tức!
Nguồn: www.habr.com
