So sánh WebRTC và Zoom

Tham khảo: https://bloggeek.me/webrtc-vs-zoom-video-quality/

Xem thêm: WebRTC (Web Real-Time Communication) là gì?

WebRTC so với Zoom? WebRTC thực sự khá tốt. Nhưng bạn đã biết điều đó rồi – phải không?

Tất cả chúng tôi đã được thông báo một lần nữa rằng nhà cung cấp hội nghị truyền hình này hoặc nhà cung cấp hội nghị truyền hình đó hoạt động tốt. Họ cung cấp chất lượng tốt nhất. Kinh nghiệm tốt nhất. Họ làm việc trong những điều kiện mà những người khác không.

Tôi thậm chí đã có cuộc gọi một lần với một doanh nhân giải thích cho tôi cách anh ta sẽ cung cấp một dịch vụ có chất lượng video 1: 1 tốt hơn Skype và Google Hangouts. Và anh ấy sẽ làm điều đó với WebRTC. Tôi đã dành phần tốt hơn của cuộc gọi đó để khiến anh ấy thoát khỏi ý tưởng đó (điều gì đó về logic của anh ấy đã nằm ngoài đó).

Như nhiều người khác, tôi đã được nói đi nghe lại nhiều lần về cách Zoom tuyệt vời. Làm thế nào mặc dù thực tế là nó không hoạt động trong trình duyệt và buộc bạn phải tải xuống ứng dụng khách của nó (một số người thậm chí coi nó như một loại vi-rút), nó vẫn được thu hút và sử dụng. Có cảm giác đây là trò chơi hay nhất trong thị trấn. Và sau đó họ đề cập đến những lý do:

  1. Nó miễn phí (cho đến khi không phải vậy, đó là một mô hình kinh doanh tuyệt vời nếu bạn có thể làm cho nó hoạt động và Zoom đang làm cho nó hoạt động)
  2. Nó có chất lượng video tốt hơn đối thủ. Đặc biệt là WebRTC

Vì vậy, họ đã lấy một thiết bị Mac, đặt nó trên mạng WiFi, thêm một giới hạn mạng để họ có thể tìm hiểu cấu hình mạng và thực hiện cuộc gọi 1: 1. Một lần với Zoom. Và một lần với WebRTC.

Xem thêm   WebRTC (Web Real-Time Communication) là gì?

Ý tưởng là thế này – bắt đầu với băng thông nhiều như mong muốn của cuộc gọi điện video. Sau đó, giới hạn nó ở 500kbps. Kiểm tra xem cần bao nhiêu thời gian để thích nghi. Xóa bỏ giới hạn và thay đổi thời gian cần thiết để thích nghi trở lại. 

Về cơ bản – kiểm tra các điều kiện mạng này:

Các khu vực được đánh dấu càng lâu, người dùng càng có trải nghiệm tồi tệ hơn.

Và đoán xem? Thu phóng kém hơn WebRTC. Không phải là ít, mà còn tệ hơn rất nhiều.

Việc thích ứng hoàn toàn để giới hạn băng thông mất 20 giây WebRTC. Zoom mất 156 giây (!).

Tăng trở lại 2mbps mất 32 giây WebRTC. Thu phóng mất 62 giây.

Bây giờ đây là phân tích của tôi về điều này.

WebRTC

Yap. nó thực sự làm.

Ảnh chụp màn hình từ bài đăng blog Zoom đã được Jitsi dán vào?

Nói rằng “web-RTC là một giải pháp rất hạn chế sẽ không cho phép chúng tôi cung cấp tất cả các tính năng tuyệt vời mà người dùng của chúng tôi mong đợi từ chúng tôi”?

Đó là từ năm 2015.

Kể từ đó, rất nhiều điều đã được cải thiện trong WebRTC, nếu như lời giải thích đó thậm chí còn đúng vào năm 2015.

Hầu hết chúng ta không cần phải làm gì cả, chúng ta đang nhận được bản cập nhật cho một công cụ truyền thông hàng đầu dưới dạng WebRTC bên trong các trình duyệt mà chúng ta sử dụng. Mã được sử dụng trong Chrome có nguồn mở, vì vậy tất cả mọi người đều có thể truy cập để nhúng mã vào các ứng dụng của riêng mình.

Xem thêm   WebRTC (Web Real-Time Communication) là gì?

Các bản sửa lỗi bảo mật? Codec mới? Các thuật toán phương tiện được cải thiện? Chúng chỉ “xảy ra”. Ngoài không khí loãng. Cho phần lớn chúng ta.

Zoom

Nếu tôi nhìn vào nó từ quan điểm của Zoom, ngoài thực tế là một người chơi thống trị trên thị trường có hoặc không có WebRTC, đây là những thách thức với một kịch bản thử nghiệm như vậy:

  • Nó đã được thực hiện một lần, hoặc một vài lần. Nhưng nó vẫn chỉ là một kịch bản
  • Đó không phải là một kịch bản đời thực. Chỉ là một cái gì đó được pha chế cho điều này. Jitsi có thể đã gian lận và chỉnh sửa nó để WebRTC tỏa sáng, nhưng trong đời thực, điều đó không xảy ra và tại Zoom, chúng tôi đang tối ưu hóa cho các tình huống thực tế.
    • (Điều đó không thực sự như vậy. Từ kinh nghiệm và kiến ​​thức của tôi về nhóm Jitsi, tôi ước tính họ đã cố gắng RẤT cẩn thận ở đây để không rơi vào cái bẫy đó)
    • (và kịch bản thực tế cuộc sống là gì?)
  • Giới hạn mạng đã sử dụng thay đổi hành vi theo những cách không đủ gần với thực tế
    • (mà tôi có thể hiểu và sống cùng. Chúng tôi thấy sự tiếp thu nhanh hơn của cùng một loại kịch bản cho WebRTC tại testRTC – sẽ có thêm thông tin về điều đó sau)
  • Zoom có ​​thể đang hoạt động thông qua các máy chủ từ xa bên ngoài cho cùng phiên đó trong khi WebRTC sẽ ngang hàng trên mạng cục bộ. Máy chủ hoạt động khác với máy khách, vì vậy kết quả có vẻ hơi “lệch”
  • Trong các tình huống khác, Zoom có ​​thể thực sự tốt hơn WebRTC
Xem thêm   WebRTC (Web Real-Time Communication) là gì?

Điều này dẫn chúng ta đến thực tế là cần phải có nhiều thử nghiệm hơn để biết cái nào là tốt nhất và trong các tình huống nào.

Điều này bắt đầu giống như so sánh chất lượng VP8 và H.264 trước đây (tôi không bao giờ có thể nhận ra sự khác biệt).

Cơ sở hạ tầng

Với WebRTC, tất cả đều nằm ở cơ sở hạ tầng. Ai triển khai tốt hơn sẽ giành chiến thắng trong trò chơi chất lượng.

  1. Bạn có ngang hàng trong các phiên 1: 1 và chuyển đổi liền mạch sang kiến trúc SFU khi nhiều người tham gia hơn không?
  2. Máy chủ media của bạn được đặt ở đâu?
  3. Bạn có sắp xếp phiên trên các máy chủ đa phương tiện để cải thiện chất lượng không?
  4. Bạn có cung cấp phản hồi cho người dùng về các điều kiện mạng không?
  5. Bạn có tắt video khi không có đủ băng thông không?
  6. Bạn đang quản lý những thứ như FEC , simulcast , SVC ,… như thế nào?
  7. Còn về hỗ trợ ứng dụng gốc và di động?

Và danh sách được tiếp tục.

Với các nhà cung cấp sử dụng codec và giao thức truyền tải độc quyền, điều này còn tăng gấp đôi, vì họ cần cung cấp cho trình duyệt khi họ tiếp cận với WebRTC. Vì vậy, mặc dù các ứng dụng gốc của họ có thể được tối ưu hóa, nhưng tất cả đều có thể đi xuống sau khi họ chuyển mã hoặc chỉ “dịch” để truy cập trình duyệt bằng cách sử dụng WebRTC.

Viết một bình luận