Valid `AudioEncoderConfig` algorithm for unsupported codecs with codec-specific steps
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- html
- Lĩnh vực
- audio-video-rtc, documentation
Hướng nghiên cứu
Bắt đầu với thuật toán AudioEncoderConfig hợp lệ và các bước xử lý của configure(), sau đó xem xét các yêu cầu của codec registry và các issue liên quan #861 và #826. Xác định cách đặc tả nên xử lý việc validation dành riêng cho codec đối với các codec không được hỗ trợ; issue được hoàn tất khi hành vi mang tính quy chuẩn được giải quyết và phản ánh rõ ràng trong đặc tả WebCodecs.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The algorithm that checks whether an object is a valid AudioEncoderConfig asks user agents to run possible codec-specific validation steps defined in the registrations listed in the registry. That seems wrong:
- User agents can choose the codecs they support, it seems strange to ask them to implement validation steps for codecs they chose not to support. For example, when an application calls
configure()with an invalid config for a codec that is not supported by a user agent (either because the user agent decided not to support it or because the codec was added to the registry recently), the spec still requires that the user agent know about any codec-specific extension, run possible validation steps defined in the underlying registration document, and throw aTypeErrorif the configuration is invalid. How can the user agent know anything about a codec it does not (want to) know anything about? - A registry is meant to be completed over time, even when it's stable. That's its purpose. Normative algorithms cannot set requirements over such a moving target (also see Specifications that reference registries in the W3C Process). If we expect user agents to implement extra validation steps, they should be integrated into the WebCodecs specification itself.
(Noting #861 and #826 as open issues somewhat related to this)
- Ngôn ngữ chính
- HTML
- Star
- 1.3k
- Fork
- 192
- Merge trung bình
- 21 giờ 7 phút
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của w3c/webcodecs
-
privacy-needs-resolution
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
editorial
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
w3c/webcodecs#973 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
w3c/webcodecs#972 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
w3c/webcodecs#971 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của w3c/webcodecs
Issue tương tự
-
original-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Buffer.writeRTX drops the RTCP returned by calc, so NACKs for other lost packets are never sentĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Candlestickers/Candlestick#255 ·
Maintainer thường phản hồi trong vòng 1 ngày