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

Linux Lightning (Beta) export fails with `_resourceType and H.264 Annex B error despite working libx264 support

オープン
#1,099 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
electron, linux, typescript
領域
backend, desktop

調査の方向性

Start by tracing the Lightning export path and its WebCodecs/WebGPU-to-Breeze H.264 fallback; the issue does not identify source files or tests. Reproduce on Linux with the reported configuration and inspect why Annex B encoding is rejected despite bundled FFmpeg advertising libx264. Done means the export failure is understood and the Lightning path works or falls back appropriately.

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

説明

Hi, I'm experiencing a reproducible export failure with Recordly 1.4.0 on Linux when using the Lightning (Beta) export pipeline. The export consistently fails with Cannot read properties of undefined (reading '_resourceType'), followed by Breeze fallback: H.264 Annex B encoding is not supported. The system is running Parrot OS / Debian 13, x86_64, with an AMD Ryzen 5 3500U and Radeon Vega Mobile Graphics, at 1366×768. The initial Recordly log also reports WebCodecs/WebGPU being used for the export.

I tested multiple export configurations, including different quality levels, 24/30 FPS, 1280×720 and 1366×768, and different encoding speeds. I also tested launching the AppImage with --ozone-platform=x11 and --ozone-platform=x11 --disable-gpu, but neither resolved the problem. The error remains specifically associated with the Lightning (Beta) pipeline. The relevant error is: Cannot read properties of undefined (reading '_resourceType') followed by Breeze fallback: H.264 Annex B encoding is not supported.

I also verified that H.264 support is available both system-wide and inside the Recordly AppImage. System FFmpeg is 7.1.5-0+deb13u1 and provides libx264, libx264rgb, h264_vaapi, h264_vulkan, and h264_v4l2m2m. After extracting the AppImage, I found resources/app.asar.unpacked/node_modules/ffmpeg-static/ffmpeg, and its encoder list also contains libx264, libx264rgb, and h264_v4l2m2m. Therefore, this does not appear to be caused by a missing H.264 encoder. I also checked the extracted application files for H264_ENC, AAC_ENC, x264enc, avenc_aac, and libx264; there are no references to those GNOME Network Displays environment variables or GStreamer encoders.

The behavior appears very similar to the Linux Lightning/WebCodecs issue where _resourceType occurs during export. Could you please investigate the Lightning/WebCodecs/WebGPU/Breeze H.264 encoding path on Linux, particularly why the fallback reports that H.264 Annex B is unsupported even though libx264 is available in both the system and bundled FFmpeg? It would also be useful to know whether Lightning can fall back to the normal/Legacy export pipeline on Linux when this WebCodecs path fails.

Image
主要言語
TypeScript
スター
32.4k
フォーク
2.6k
平均マージ
1日 19時間
マージ済み PR(30日)
17

環境構築

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

はじめの一歩

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

webadderallorg/Recordly のほかの issue

webadderallorg/Recordly の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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