Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

VideoDecoder output guarantees

Đang mở
  • Có gì không ổn?
#900 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Lĩnh vực
api, audio-video-rtc

Hướng nghiên cứu

Bắt đầu bằng cách đọc các phần của đặc tả VideoDecoder đề cập đến output, flush và optimizeForLatency. So sánh hành vi dự kiến của chúng với các cuộc thảo luận được liên kết trong các issue 650, 698 và 206, bao gồm cả câu hỏi về hardware acceleration. Công việc được xem là hoàn tất khi issue ghi lại liệu bên gọi có thể biết khi nào cần thêm các gói tin hay không, việc tối ưu hóa độ trễ ảnh hưởng đến đầu ra như thế nào và những đánh đổi hiệu năng liên quan nào tồn tại.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

My use case requires me to decode multiple video streams at the same time. The source files can be of extremely high bitrate, 4K videos, so I would like to be mindful of how I use the GPU.

My root issue is that I cannot find any guarantee of when I might receive a frame or when I need to send more data to the decoder. If I investigate the packets and check the P or B frames, I see no reason why a packet would not be sent to the output. When I call flush I receive frames in the output perfectly.

Based on that experience, I thought I could decode GOPs, then call flush. In terms of decoding the bare minimum it's far from optimal, but at least it gives me some guarantee of when I can receive a frame. However, this is not trivial to do either since I work with libav under the hood, what I consider a keyframe might not be accepted by WebCodecs. Same issue as described here. The idea of flush without invalidating whatever inner state it has seemed like a good idea to me.

The answer to my question could be the optimizeForLatency, as in the specification it seems to do exactly what I want. However, as I read the threads here, I am now confused on what it does and what it doesn't. As @dalecurtis mentioned here, in Chromium, this flag does not affect flush directly, just omits using threading which can hold back frames. According to another thread though, I got the impression this only applies to software decoders, not hardware-accelerated ones. Does this have an effect in hw-accelerated decoding? If so, what are the performance drawbacks to consider?

Very different in nature but what I love about FFmpeg/libav is that this is very trivial to do:

int ret = avcodec_receive_frame(decoder->codec_ctx, decoder->frame);
if (ret == AVERROR(EAGAIN)) {
  // I know the decoder needs more frames before it can give me something
}

To summarize, my question is how can I have a guarantee that I passed enough packets (or how can I know for sure that I didn't ) to the VideoDecoder to surely have an output? Ideally, I want to decode the smallest amount possible for a guaranteed output.

Ngôn ngữ chính
HTML
Star
1.3k
Fork
192
Merge trung bình
14 giờ 40 phút
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của w3c/webcodecs

Tất cả issue của w3c/webcodecs

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.