[Bug]: H.264 WebM export fails with ambiguous codec name

[bernardopg]

Search existing issues

• I have searched the existing issues

Describe the bug

Exporting an H.264 recording stored in a WebM container can fail with:

VideoDecoder error: Unknown or ambiguous codec name

web-demuxer.getDecoderConfig("video") may return a bare or malformed codec string such as h264, avc1, or avc1.2420032. Both StreamingVideoDecoder.decodeAll() and ForwardFrameSource.startDecoder() currently pass that value directly to VideoDecoder.configure().

This is the same codec-normalization failure fixed in the archived OpenScreen project by siddharthvaddem/openscreen#501, but the normalization and H.264 fallback are not present in Recordly's current decoder paths.

Expected behavior

The decoder should normalize bare codec names and fall back to a valid H.264 WebCodecs codec string when the demuxer-provided avc1 configuration is unsupported.

To Reproduce

1. Record a screen on Linux where Chromium MediaRecorder produces H.264 in WebM.
2. Open the recording in Recordly.
3. Export it as MP4.
4. The export fails while configuring VideoDecoder.

The source recording is otherwise readable and decodes successfully with FFmpeg.

OS

Linux

OS Version

Arch Linux, Wayland/Hyprland

Additional context

A shared decoder-config helper should cover both exporter paths and normalize at least:

• h264 and bare avc1 to a valid AVC codec string
• vp08 to vp8
• vp09 to vp9

For malformed or unsupported avc1.* strings, checking VideoDecoder.isConfigSupported() before configuration allows a fallback to avc1.640033.