Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Warn when a video input declares alpha but decodes fully opaque

オープン
  • 何か問題がありますか？
#3,226 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
typescript
領域
audio-video-rtc

調査の方向性

Start by tracing the existing video-probing path around VideoMetadata.hasAlpha and the libvpx-vp9 alpha extraction mentioned in the issue. Use the provided ffmpeg alphaextract command to compare decoded alpha, and decide whether to inspect the first frame or a sample. Done means a warning identifies declared-but-fully-opaque alpha without blocking rendering.

索引モデルが issue の本文から書いたものです。

説明

triage/needs-triage
Problem

A video whose container says it has alpha, but whose alpha plane decodes fully opaque, composites as a solid black rectangle over whatever is beneath it. We render it correctly — there is nothing to see through — but nothing anywhere tells the user their file is the problem, so it presents as a rendering bug.

#3220 is the worked example. The reporter built a repro repository with an opaque control clip, tested both the local CLI and the cloud renderer, and verified alpha_mode=1 with ffprobe before filing. They still could not reach the answer, because the tag they checked is exactly the thing that lies.

alpha_mode=1 is metadata and can outlive the alpha it describes. A remux can preserve the tag while dropping the BlockAdditional sidecar that carries the alpha plane, so the file keeps promising transparency it no longer contains.

Why this is cheap for us to catch

We already probe every video input, and VideoMetadata.hasAlpha already exists (pixelFormatHasAlpha(pixelFormat) || alphaMode === "1"). We also already extract alpha-capable codecs to PNG through libvpx-vp9, so a decoded frame with an alpha channel is in hand on this path anyway.

The missing step is noticing that the alpha channel is uniformly opaque and saying so.

Proposed

When a video input declares alpha but its decoded alpha plane is uniformly 255, emit a warning naming the file, something to the effect of:

avatar.webm declares an alpha channel but decodes fully opaque. Transparency will not composite. If this should be transparent, re-export with -pix_fmt yuva420p and avoid remuxing afterward, which can drop the alpha sidecar while keeping the tag.

Warning only, never an error. An opaque video used as a full-frame background is perfectly legitimate, so this cannot block a render.

Worth deciding: whether to check the first frame only (cheap, catches the common case) or sample a few (catches a clip that is opaque at the head and transparent later). First-frame-only is probably the right trade, but it should be a decision rather than an accident.

Verification

Users can already check by hand, and the warning should agree with this:

ffmpeg -c:v libvpx-vp9 -i in.webm -vf alphaextract -frames:v 1 out.png

Uniformly white means no transparency. Black and white means real alpha.

Filed off #3220.

— Rames Jusso

主要言語
TypeScript
スター
54.1k
フォーク
4.9k
平均マージ
7時間 2分
マージ済み PR（30日）
782

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

heygen-com/hyperframes のほかの issue

heygen-com/hyperframes の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。