Chrome 47 WebRTC: Ghi nội dung nghe nhìn, Nguồn gốc an toàn và Xử lý proxy

Chrome 47 bao gồm một số bản cập nhật và cải tiến quan trọng về WebRTC.

Quay video từ các ứng dụng web

API MediaStreamRecorder từ lâu luôn là yêu cầu hàng đầu của chromium.org, với hơn 2500 sao. Bản ghi nội dung nghe nhìn hiện đã được thêm vào Chrome sau cờ tính năng Nền tảng web thử nghiệm — mặc dù hiện tại bản ghi nội dung đa phương tiện chỉ dành cho máy tính để bàn. Quyền này cho phép bạn quay và phát lại hoặc tải video xuống. Có một bản minh hoạ đơn giản về kho lưu trữ mẫu WebRTC và bạn có thể tìm hiểu thêm trong thông báo thảo luận về webrtc. Bạn có thể xem một ứng dụng Chrome mẫu để quay video từ tính năng chụp ảnh màn hình có tại github.com/niklasenbom/RecordingApp. Đây là những cách triển khai hoàn toàn mới và có thể vẫn còn lỗi cần khắc phục: vui lòng báo cáo sự cố vào kho lưu trữ nếu bạn gặp sự cố.

Ảnh chụp màn hình bản minh hoạ MediaRecorder trên kho lưu trữ mẫu WebRTC GitHub

Lựa chọn thiết bị đầu ra âm thanh

Phát hành MediaDevices.enumerateDevices(). Bạn có thể xem thêm thông tin chi tiết trong vấn đề về Chromium 504280. Giờ đây, bạn có thể liệt kê các thiết bị đầu ra âm thanh ngoài thiết bị đầu vào âm thanh và video mà MediaStreamTrack.getSources() đã cung cấp. Bạn có thể tìm hiểu thêm về cách sử dụng công cụ này trong nội dung cập nhật này.

Hỗ trợ thiết bị trên Windows

Chúng tôi hiện đã thêm tính năng hỗ trợ thiết bị liên lạc mặc định trên Windows. Điều này có nghĩa là khi liệt kê các thiết bị âm thanh trên Windows, sẽ có một mục bổ sung cho thiết bị liên lạc có mã nhận dạng là "communications" (giao tiếp).

Mã thiết bị cho thiết bị âm thanh mặc định (và các giao tiếp trên Windows) sẽ không được băm nữa (Vấn đề 535980). Thay vào đó, hai mã nhận dạng dành riêng là "mặc định" và "thông tin giao tiếp" được hỗ trợ và giống nhau trên mọi nguồn gốc bảo mật. Nhãn thiết bị sẽ được dịch sang ngôn ngữ của trình duyệt, vì vậy, nhà phát triển không nên kỳ vọng nhãn sẽ có một giá trị được xác định trước. Độ chính xác của quá trình kết xuất video đã được cải thiện bằng cách truyền đi dấu thời gian quay cho đến thuật toán kết xuất, trong đó, dựa trên đó, bạn có thể chọn vsync phù hợp. Đối với nền tảng Windows, dấu thời gian chụp cũng chính xác hơn trong Chrome 47.

Xử lý proxy

Chrome 47 bổ sung một lựa chọn ưu tiên mới để buộc gửi lưu lượng truy cập WebRTC qua một máy chủ proxy cục bộ (nếu bạn đã định cấu hình) máy chủ này. Đây là điều quan trọng đối với một số người dùng duyệt web qua VPN. Điều này có nghĩa là ứng dụng WebRTC sẽ chỉ thấy địa chỉ IP của proxy. Hãy lưu ý rằng việc này sẽ ảnh hưởng đến hiệu suất của ứng dụng và sẽ không hoạt động trừ khi ứng dụng hỗ trợ TURN/TCP hoặc ICE-TCP. Hãy sớm tìm phiên bản mới của Tiện ích giới hạn mạng WebRTC để cung cấp giao diện người dùng cho tùy chọn này. Có thêm thông tin về "rò rỉ" địa chỉ IP trong phần Sự kiện tiếp theo cho WebRTC.

Tiện ích của Chrome Trình giới hạn mạng WebRTC

...Và nhiều số liệu khác

Thông lượng kênh dữ liệu đã được cải thiện đáng kể cho các kết nối có độ trễ cao.

Chúng tôi sẽ từng bước triển khai dịch vụ hỗ trợ cho DTLS 1.2 trong khung thời gian của Chrome 47.

Mặc dù cả VP9 và H.264 đều không được hỗ trợ trong bản phát hành này, nhưng chúng tôi vẫn tiếp tục nỗ lực cải thiện các tính năng này. Chúng tôi hy vọng có thể hỗ trợ VP9 và phiên bản ban đầu của H.264 (phía sau cờ) trong Chrome 48.

Thông báo dịch vụ công cộng

  • Kể từ Chrome 47, các yêu cầu getUserMedia() chỉ được cho phép từ các nguồn gốc bảo mật: HTTPS hoặc localhost.
  • Chúng tôi đã ngừng hỗ trợ kênh dữ liệu RTP. Mọi ứng dụng còn lại vẫn sử dụng kênh dữ liệu RTP nên sử dụng các kênh dữ liệu tiêu chuẩn.

Giống như tất cả các bản phát hành, chúng tôi khuyến khích các nhà phát triển dùng thử Chrome trên kênh Canary, Dev và Beta và báo cáo mọi sự cố phát hiện được. Sự giúp đỡ chúng tôi nhận được là vô giá. Để biết hướng dẫn về cách gửi một báo cáo lỗi hiệu quả, vui lòng xem trang lỗi WebRTC.

Bản thu thử

Tìm hiểu thêm