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

Abierto
#1,099 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
electron, linux, typescript
Área
backend, desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
TypeScript
Estrellas
32.4k
Forks
2.6k
Merge medio
2 d 3 h
PR fusionados (30 d)
6

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de webadderallorg/Recordly

Todos los issues de webadderallorg/Recordly

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.