Fixed: Discord H.264 video corrupted from Mac users, and Windows cameras not starting at all since Oct 28 (root cause + full guide)
I was having this problem and, with help from Claude and REA (a reverse-engineering toolkit by @morluto), I found the root cause by reading Discord's logs and statically analyzing its binaries. I'm writing the whole process here so anyone with the same issue can fix it.
TL;DR
- On Linux, Discord can only decode H.264 in software with OpenH264, because its bundled FFmpeg has no native H.264 decoder. OpenH264 mis-decodes video coming from macOS users. Fix: make the GPU decode it: VA-API with H.264 plus hardware acceleration enabled.
- Since Oct 28, 2026: Discord downloaded OpenH264 2.7.0 and deleted 2.5.1, but the desktop host (1.0.166) still loads 2.5.1 from a hardcoded path. Any H.264 stream that falls back to software decoding fails, so cameras show black. Fix: put Cisco's official 2.5.1 back and make the folder read-only.
My setup / who this may affect
- Fedora 44, Wayland, AMD Radeon 760M (iGPU) + NVIDIA RTX 2050
- I installed Discord with the RPM Fusion nonfree package (sudo dnf install discord, version 1.0.148). It then self-updates to host 1.0.166 in ~/.config/discord/app-1.0.166.
- I only verified this on my own install. The bug is in Discord's host and voice module, not in the package, so I'd expect it to affect any native Linux install (.deb, .tar.gz, RPM Fusion, probably Flatpak). Check your logs first (see below).
Symptoms
1. A friend on Mac looked pixelated, with smeared blocks and wrong colors, and kept freezing. It only happened for me: Windows friends saw him fine, and my phone did too. The network was fine (3 lost packets out of 26,036).
2. Later (Oct 28), my Windows friends' cameras stopped working completely: black tile, even though packets were arriving.
3. Restarting didn't help, and the updater said "Already up to date".
How Discord decodes video on Linux (what we found)
- The voice module (discord_voice.node) uses a PixelCappedDecoder:
- 640×360 or larger (230,400 px, 0x38400 in the binary): it tries the Electron/GPU decoder (VA-API).
- If that fails, or the stream is smaller: FFmpeg → OpenH264.
- Discord's bundled libffmpeg.so has no native H.264 decoder. The only H.264 decoder in it is ff_libopenh264_decoder, and webrtc::H264Decoder::Create returns nullptr. Turning off the "OpenH264" toggle in settings leaves you with no H.264 software decoder at all.
- On Windows, Discord enables enable-h264-mf (Media Foundation), which is OS hardware decoding. That's why Windows users don't see this.
How we found it
1. Read Discord's WebRTC log. It's at ~/.config/discord/logs/discord-webrtc_0. Every 10 s it prints per-user stats: codec, decoded frames and resolution.
# which decoder is used
grep -h 'Using libopenh264|Decoder implementation|ElectronVideoDecoder|High pixel count' \
~/.config/discord/logs/discord-webrtc_0 | sed 's/^[[^]]] [[0-9]] //' | sort | uniq -c
# per-user stats
grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -6
The Mac stream arrived almost lossless, and WebRTC counted 6114 of 6128 frames as "decoded", yet it rendered broken. The decoder was hiding the errors. Everything was going through Using libopenh264 decoder.
2. Why the GPU wasn't used. Every stream showed:
Constructing PixelCappedDecoder with electron, ffmpeg
ElectronVideoDecoder::Initialize failed. status: 5
High pixel count decoder failed to init, falling back to other decoder
Using libopenh264 decoder
Reverse engineering with REA showed that status: 5 = ElectronVideoStatus::Unsupported. It's returned when there are no GPU factories (hardware acceleration off) or the GPU doesn't support the config. In my case it was both:
- Hardware acceleration was off. In app.asar, that setting calls app.disableHardwareAcceleration().
- Fedora's Mesa ships VA-API without H.264 because of patents: only AV1, VP9 and JPEG. gst-inspect-1.0 va didn't list vah264dec.
3. Prior art. In Mozilla bug 1492038, OpenH264 mis-decoded H.264 from macOS senders, and Firefox fixed it by not using OpenH264 for decoding. Firefox on my Fedora, which also uses OpenH264 for WebRTC, showed the same artifacts from that friend.
4. Fix 1 applied. Streams of 640×360 or larger switched to implementation_name = 'electron', is_hardware_accelerated = true, and the Mac video became clean.
5. Next day: Windows cameras dead. The log showed thousands of packets received and 0 frames decoded:
Setting OpenH264 library path to: ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so
Using libopenh264 decoder
avcodec_open2 error: -1313558101
Failed to decode frame. Return code: -8 ... type: key, width: 896, height: 504
-1313558101 is AVERROR_UNKNOWN: FFmpeg couldn't open the library. The 2.5.1 file no longer existed. renderer_js.log explained why:
[MediaEngineStore] OpenH264 is ready ...
OpenH264 cleanup: Deleted unused file "libopenh264-2.5.1-linux64.7.so"
And the host's app-1.0.166/resources/app.asar has the path hardcoded:
let openh264Path = path.join(assetCachePath, "openh264", "libopenh264-2.5.1-linux64.7.so");
app.commandLine.appendSwitch("openh264-library-path", openh264Path)
So the web part of Discord moved to 2.7.0 and deletes 2.5.1 on every start, while the installed host still asks for 2.5.1. A newer host (1.0.167) exists, but the updater says "Already up to date".
Fix 1: let the GPU decode H.264 (AMD/Intel on Fedora)
On other distros, install whatever package enables H.264/H.265 in VA-API.
sudo dnf install mirrors.rpmfusion.org -E %fedora).noarch.rpm
sudo dnf install mesa-va-drivers-freeworld
If dnf wants to swap mesa-va-drivers, that's expected. Review it if it wants to touch other packages.
Check it:
rm -rf ~/.cache/gstreamer-1.0 # force GStreamer to rescan plugins
gst-inspect-1.0 va | grep -i 'h264|h265'
# should list vah264dec and vah265dec
Enable hardware acceleration in Discord (Settings → Advanced). If the option isn't there, quit Discord completely and run:
cp ~/.config/discord/settings.json ~/.config/discord/settings.json.bak
sed -i 's/"enableHardwareAcceleration": false/"enableHardwareAcceleration": true/' ~/.config/discord/settings.json
Open Discord from your app menu. Launching it from a sandboxed terminal (some IDE/app terminals) can leave it without camera access.
Fix 2: the deleted OpenH264 2.5.1 (since Oct 28, 2026)
Check whether you're affected:
ls ~/.config/discord/discord_asset_cache/openh264/
ps -eo args | grep -o 'openh264-library-path=[^ ]*' | sort -u
If Discord asks for 2.5.1 and only 2.7.0 is in the folder, you are. Download Cisco's official build and verify it:
mkdir -p ~/openh264-dl && cd ~/openh264-dl
curl -fO ciscobinary.openh264.org
curl -f ciscobinary.openh264.org
bunzip2 -k libopenh264-2.5.1-linux64.7.so.bz2
md5sum libopenh264-2.5.1-linux64.7.so
# must be bdd6e8a20ca745aadbd31c3d571f8a7f, same as Cisco's .md5.txt
Install it and make the folder read-only so Discord's cleanup can't delete it:
C=~/.config/discord/discord_asset_cache/openh264
install -m 644 libopenh264-2.5.1-linux64.7.so "$C/"
chmod u-w "$C"
Quit Discord completely (tray → Quit) and reopen it. renderer_js.log will now say OpenH264 cleanup: Failed to delete "libopenh264-2.5.1-linux64.7.so": EACCES. That means the protection works.
Don't symlink 2.5.1 to 2.7.0: they're different ABIs (.so.7 vs .so.8), and without the read-only folder Discord deletes the file again anyway.
Validate
Join a call with cameras and screen share on, then run:
grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -8 \
| grep -o '[[a-z]] Inbound|codec: [^,]|decoded: [0-9]|resolution: [^,]' | paste - - - -
My final result:
|Stream|Codec|Decoder|Resolution|Result|
|:-|:-|:-|:-|:-|
|Mac screen share|H.265|electron (GPU)|1108×718|OK, no loss|
|Mac camera|H.265|electron (GPU)|672×378|30 fps|
|Windows camera 1|H.264|electron (GPU)|672×378|OK|
|Windows camera 2|H.264|ffmpeg (OpenH264)|576×360|30 fps|
Windows camera 2 was below 640×360, so it went through OpenH264. That's why you need both fixes.
What didn't help
- Turning off the OpenH264 toggle: there's no other H.264 software decoder in Discord's FFmpeg.
- Installing system FFmpeg: Discord uses its own libffmpeg.so.
- chromiumSwitches in settings.json: it only passes keys without values.
- Restarting or reinstalling: the updater says "Already up to date", and 2.5.1 gets deleted again.
Limits / undo
- Streams smaller than 640×360 still use OpenH264, so a Mac user can look bad again when Discord lowers their quality.
- Twice, the GPU path rejected H.264 with VaapiVideoDecoder: failed initializing VaapiWrapper for profile h264 main. VA-API decoded H.264 main fine outside Discord, and it didn't happen again after a restart. Cause unknown. With Fix 2, that case falls back to OpenH264, so video still shows.
- Once Discord ships a host that uses 2.7.0, make the folder writable again.
Undo:
chmod u+w ~/.config/discord/discord_asset_cache/openh264
rm ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so
sudo dnf remove mesa-va-drivers-freeworld
cp ~/.config/discord/settings.json.bak ~/.config/discord/settings.json
Sources
- Mozilla bug 1492038: OpenH264 with macOS senders
- OpenH264 issues #2165 and #3479
- snapcrafters/discord #378: Discord's libffmpeg.so only has OpenH264 for H.264
- RPM Fusion: Multimedia
- Arch Wiki: Chromium hardware video acceleration
Formatted version of this guide, with copy buttons: <LINK, optional>
Thanks to @morluto for REA. Without it we couldn't have looked inside Discord's binaries.
claude.ai
8 comments
[Linux] Fixed: Discord H.264 video corrupted from Mac users, and Windows cameras not starting at all since Oct 28 (root cause + full guide)
I was having this problem and, with help from Claude and REA (a reverse-engineering toolkit by @morluto), I found the root cause by reading Discord's logs and statically analyzing its binaries. I'm writing the whole process here so anyone with the same issue can fix it.
TL;DR
- On Linux, Discord can only decode H.264 in software with OpenH264, because its bundled FFmpeg has no native H.264 decoder. OpenH264 mis-decodes video coming from macOS users. Fix: make the GPU decode it: VA-API with H.264 plus hardware acceleration enabled.
- Since Oct 28, 2026: Discord downloaded OpenH264 2.7.0 and deleted 2.5.1, but the desktop host (1.0.166) still loads 2.5.1 from a hardcoded path. Any H.264 stream that falls back to software decoding fails, so cameras show black. Fix: put Cisco's official 2.5.1 back and make the folder read-only.
My setup / who this may affect
- Fedora 44, Wayland, AMD Radeon 760M (iGPU) + NVIDIA RTX 2050
- I installed Discord with the RPM Fusion nonfree package (sudo dnf install discord, version 1.0.148). It then self-updates to host 1.0.166 in ~/.config/discord/app-1.0.166.
- I only verified this on my own install. The bug is in Discord's host and voice module, not in the package, so I'd expect it to affect any native Linux install (.deb, .tar.gz, RPM Fusion, probably Flatpak). Check your logs first (see below).
Symptoms
1. A friend on Mac looked pixelated, with smeared blocks and wrong colors, and kept freezing. It only happened for me: Windows friends saw him fine, and my phone did too. The network was fine (3 lost packets out of 26,036).
2. Later (Oct 28), my Windows friends' cameras stopped working completely: black tile, even though packets were arriving.
3. Restarting didn't help, and the updater said "Already up to date".
How Discord decodes video on Linux (what we found)
- The voice module (discord_voice.node) uses a PixelCappedDecoder:
- 640×360 or larger (230,400 px, 0x38400 in the binary): it tries the Electron/GPU decoder (VA-API).
- If that fails, or the stream is smaller: FFmpeg → OpenH264.
- Discord's bundled libffmpeg.so has no native H.264 decoder. The only H.264 decoder in it is ff_libopenh264_decoder, and webrtc::H264Decoder::Create returns nullptr. Turning off the "OpenH264" toggle in settings leaves you with no H.264 software decoder at all.
- On Windows, Discord enables enable-h264-mf (Media Foundation), which is OS hardware decoding. That's why Windows users don't see this.
How we found it
1. Read Discord's WebRTC log. It's at ~/.config/discord/logs/discord-webrtc_0. Every 10 s it prints per-user stats: codec, decoded frames and resolution.
# which decoder is used
grep -h 'Using libopenh264|Decoder implementation|ElectronVideoDecoder|High pixel count' \
~/.config/discord/logs/discord-webrtc_0 | sed 's/^[[^]]] [[0-9]] //' | sort | uniq -c
# per-user stats
grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -6
The Mac stream arrived almost lossless, and WebRTC counted 6114 of 6128 frames as "decoded", yet it rendered broken. The decoder was hiding the errors. Everything was going through Using libopenh264 decoder.
2. Why the GPU wasn't used. Every stream showed:
Constructing PixelCappedDecoder with electron, ffmpeg
ElectronVideoDecoder::Initialize failed. status: 5
High pixel count decoder failed to init, falling back to other decoder
Using libopenh264 decoder
Reverse engineering with REA showed that status: 5 = ElectronVideoStatus::Unsupported. It's returned when there are no GPU factories (hardware acceleration off) or the GPU doesn't support the config. In my case it was both:
- Hardware acceleration was off. In app.asar, that setting calls app.disableHardwareAcceleration().
- Fedora's Mesa ships VA-API without H.264 because of patents: only AV1, VP9 and JPEG. gst-inspect-1.0 va didn't list vah264dec.
3. Prior art. In Mozilla bug 1492038, OpenH264 mis-decoded H.264 from macOS senders, and Firefox fixed it by not using OpenH264 for decoding. Firefox on my Fedora, which also uses OpenH264 for WebRTC, showed the same artifacts from that friend.
4. Fix 1 applied. Streams of 640×360 or larger switched to implementation_name = 'electron', is_hardware_accelerated = true, and the Mac video became clean.
5. Next day: Windows cameras dead. The log showed thousands of packets received and 0 frames decoded:
Setting OpenH264 library path to: ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so
Using libopenh264 decoder
avcodec_open2 error: -1313558101
Failed to decode frame. Return code: -8 ... type: key, width: 896, height: 504
-1313558101 is AVERROR_UNKNOWN: FFmpeg couldn't open the library. The 2.5.1 file no longer existed. renderer_js.log explained why:
[MediaEngineStore] OpenH264 is ready ...
OpenH264 cleanup: Deleted unused file "libopenh264-2.5.1-linux64.7.so"
And the host's app-1.0.166/resources/app.asar has the path hardcoded:
let openh264Path = path.join(assetCachePath, "openh264", "libopenh264-2.5.1-linux64.7.so");
app.commandLine.appendSwitch("openh264-library-path", openh264Path)
So the web part of Discord moved to 2.7.0 and deletes 2.5.1 on every start, while the installed host still asks for 2.5.1. A newer host (1.0.167) exists, but the updater says "Already up to date".
Fix 1: let the GPU decode H.264 (AMD/Intel on Fedora)
On other distros, install whatever package enables H.264/H.265 in VA-API.
sudo dnf install mirrors.rpmfusion.org -E %fedora).noarch.rpm
sudo dnf install mesa-va-drivers-freeworld
If dnf wants to swap mesa-va-drivers, that's expected. Review it if it wants to touch other packages.
Check it:
rm -rf ~/.cache/gstreamer-1.0 # force GStreamer to rescan plugins
gst-inspect-1.0 va | grep -i 'h264|h265'
# should list vah264dec and vah265dec
Enable hardware acceleration in Discord (Settings → Advanced). If the option isn't there, quit Discord completely and run:
cp ~/.config/discord/settings.json ~/.config/discord/settings.json.bak
sed -i 's/"enableHardwareAcceleration": false/"enableHardwareAcceleration": true/' ~/.config/discord/settings.json
Open Discord from your app menu. Launching it from a sandboxed terminal (some IDE/app terminals) can leave it without camera access.
Fix 2: the deleted OpenH264 2.5.1 (since Oct 28, 2026)
Check whether you're affected:
ls ~/.config/discord/discord_asset_cache/openh264/
ps -eo args | grep -o 'openh264-library-path=[^ ]*' | sort -u
If Discord asks for 2.5.1 and only 2.7.0 is in the folder, you are. Download Cisco's official build and verify it:
mkdir -p ~/openh264-dl && cd ~/openh264-dl
curl -fO ciscobinary.openh264.org
curl -f ciscobinary.openh264.org
bunzip2 -k libopenh264-2.5.1-linux64.7.so.bz2
md5sum libopenh264-2.5.1-linux64.7.so
# must be bdd6e8a20ca745aadbd31c3d571f8a7f, same as Cisco's .md5.txt
Install it and make the folder read-only so Discord's cleanup can't delete it:
C=~/.config/discord/discord_asset_cache/openh264
install -m 644 libopenh264-2.5.1-linux64.7.so "$C/"
chmod u-w "$C"
Quit Discord completely (tray → Quit) and reopen it. renderer_js.log will now say OpenH264 cleanup: Failed to delete "libopenh264-2.5.1-linux64.7.so": EACCES. That means the protection works.
Don't symlink 2.5.1 to 2.7.0: they're different ABIs (.so.7 vs .so.8), and without the read-only folder Discord deletes the file again anyway.
Validate
Join a call with cameras and screen share on, then run:
grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -8 \
| grep -o '[[a-z]] Inbound|codec: [^,]|decoded: [0-9]|resolution: [^,]' | paste - - - -
My final result:
|Stream|Codec|Decoder|Resolution|Result|
|:-|:-|:-|:-|:-|
|Mac screen share|H.265|electron (GPU)|1108×718|OK, no loss|
|Mac camera|H.265|electron (GPU)|672×378|30 fps|
|Windows camera 1|H.264|electron (GPU)|672×378|OK|
|Windows camera 2|H.264|ffmpeg (OpenH264)|576×360|30 fps|
Windows camera 2 was below 640×360, so it went through OpenH264. That's why you need both fixes.
What didn't help
- Turning off the OpenH264 toggle: there's no other H.264 software decoder in Discord's FFmpeg.
- Installing system FFmpeg: Discord uses its own libffmpeg.so.
- chromiumSwitches in settings.json: it only passes keys without values.
- Restarting or reinstalling: the updater says "Already up to date", and 2.5.1 gets deleted again.
Limits / undo
- Streams smaller than 640×360 still use OpenH264, so a Mac user can look bad again when Discord lowers their quality.
- Twice, the GPU path rejected H.264 with VaapiVideoDecoder: failed initializing VaapiWrapper for profile h264 main. VA-API decoded H.264 main fine outside Discord, and it didn't happen again after a restart. Cause unknown. With Fix 2, that case falls back to OpenH264, so video still shows.
- Once Discord ships a host that uses 2.7.0, make the folder writable again.
Undo:
chmod u+w ~/.config/discord/discord_asset_cache/openh264
rm ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so
sudo dnf remove mesa-va-drivers-freeworld
cp ~/.config/discord/settings.json.bak ~/.config/discord/settings.json
Sources
- Mozilla bug 1492038: OpenH264 with macOS senders
- OpenH264 issues #2165 and #3479
- snapcrafters/discord #378: Discord's libffmpeg.so only has OpenH264 for H.264
- RPM Fusion: Multimedia
- Arch Wiki: Chromium hardware video acceleration
Formatted version of this guide, with copy buttons: <LINK, optional>
Thanks to @morluto for REA. Without it we couldn't have looked inside Discord's binaries.
8 comments
@mewset @davepl1968 Still used in libsrtp tests.
github.com/cisco/libsrtp/blob/7071fba734fe93979af…
5 views
Mentions
Fixed: Discord H.264 video corrupted from Mac users, and Windows cameras not starting at all since Oct 28 (root cause + full guide) I was having this problem and, with help from Claude and REA (a reverse-engineering toolkit by @morluto), I found the root cause by reading Discord's logs and statically analyzing its binaries. I'm writing the whole process here so anyone with the same issue can fix it. TL;DR - On Linux, Discord can only decode H.264 in software with OpenH264, because its bundled FFmpeg has no native H.264 decoder. OpenH264 mis-decodes video coming from macOS users. Fix: make the GPU decode it: VA-API with H.264 plus hardware acceleration enabled. - Since Oct 28, 2026: Discord downloaded OpenH264 2.7.0 and deleted 2.5.1, but the desktop host (1.0.166) still loads 2.5.1 from a hardcoded path. Any H.264 stream that falls back to software decoding fails, so cameras show black. Fix: put Cisco's official 2.5.1 back and make the folder read-only. My setup / who this may affect - Fedora 44, Wayland, AMD Radeon 760M (iGPU) + NVIDIA RTX 2050 - I installed Discord with the RPM Fusion nonfree package (sudo dnf install discord, version 1.0.148). It then self-updates to host 1.0.166 in ~/.config/discord/app-1.0.166. - I only verified this on my own install. The bug is in Discord's host and voice module, not in the package, so I'd expect it to affect any native Linux install (.deb, .tar.gz, RPM Fusion, probably Flatpak). Check your logs first (see below). Symptoms 1. A friend on Mac looked pixelated, with smeared blocks and wrong colors, and kept freezing. It only happened for me: Windows friends saw him fine, and my phone did too. The network was fine (3 lost packets out of 26,036). 2. Later (Oct 28), my Windows friends' cameras stopped working completely: black tile, even though packets were arriving. 3. Restarting didn't help, and the updater said "Already up to date". How Discord decodes video on Linux (what we found) - The voice module (discord_voice.node) uses a PixelCappedDecoder: - 640×360 or larger (230,400 px, 0x38400 in the binary): it tries the Electron/GPU decoder (VA-API). - If that fails, or the stream is smaller: FFmpeg → OpenH264. - Discord's bundled libffmpeg.so has no native H.264 decoder. The only H.264 decoder in it is ff_libopenh264_decoder, and webrtc::H264Decoder::Create returns nullptr. Turning off the "OpenH264" toggle in settings leaves you with no H.264 software decoder at all. - On Windows, Discord enables enable-h264-mf (Media Foundation), which is OS hardware decoding. That's why Windows users don't see this. How we found it 1. Read Discord's WebRTC log. It's at ~/.config/discord/logs/discord-webrtc_0. Every 10 s it prints per-user stats: codec, decoded frames and resolution. # which decoder is used grep -h 'Using libopenh264|Decoder implementation|ElectronVideoDecoder|High pixel count' \ ~/.config/discord/logs/discord-webrtc_0 | sed 's/^[[^]]] [[0-9]] //' | sort | uniq -c # per-user stats grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -6 The Mac stream arrived almost lossless, and WebRTC counted 6114 of 6128 frames as "decoded", yet it rendered broken. The decoder was hiding the errors. Everything was going through Using libopenh264 decoder. 2. Why the GPU wasn't used. Every stream showed: Constructing PixelCappedDecoder with electron, ffmpeg ElectronVideoDecoder::Initialize failed. status: 5 High pixel count decoder failed to init, falling back to other decoder Using libopenh264 decoder Reverse engineering with REA showed that status: 5 = ElectronVideoStatus::Unsupported. It's returned when there are no GPU factories (hardware acceleration off) or the GPU doesn't support the config. In my case it was both: - Hardware acceleration was off. In app.asar, that setting calls app.disableHardwareAcceleration(). - Fedora's Mesa ships VA-API without H.264 because of patents: only AV1, VP9 and JPEG. gst-inspect-1.0 va didn't list vah264dec. 3. Prior art. In Mozilla bug 1492038, OpenH264 mis-decoded H.264 from macOS senders, and Firefox fixed it by not using OpenH264 for decoding. Firefox on my Fedora, which also uses OpenH264 for WebRTC, showed the same artifacts from that friend. 4. Fix 1 applied. Streams of 640×360 or larger switched to implementation_name = 'electron', is_hardware_accelerated = true, and the Mac video became clean. 5. Next day: Windows cameras dead. The log showed thousands of packets received and 0 frames decoded: Setting OpenH264 library path to: ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so Using libopenh264 decoder avcodec_open2 error: -1313558101 Failed to decode frame. Return code: -8 ... type: key, width: 896, height: 504 -1313558101 is AVERROR_UNKNOWN: FFmpeg couldn't open the library. The 2.5.1 file no longer existed. renderer_js.log explained why: [MediaEngineStore] OpenH264 is ready ... OpenH264 cleanup: Deleted unused file "libopenh264-2.5.1-linux64.7.so" And the host's app-1.0.166/resources/app.asar has the path hardcoded: let openh264Path = path.join(assetCachePath, "openh264", "libopenh264-2.5.1-linux64.7.so"); app.commandLine.appendSwitch("openh264-library-path", openh264Path) So the web part of Discord moved to 2.7.0 and deletes 2.5.1 on every start, while the installed host still asks for 2.5.1. A newer host (1.0.167) exists, but the updater says "Already up to date". Fix 1: let the GPU decode H.264 (AMD/Intel on Fedora) On other distros, install whatever package enables H.264/H.265 in VA-API. sudo dnf install mirrors.rpmfusion.org -E %fedora).noarch.rpm sudo dnf install mesa-va-drivers-freeworld If dnf wants to swap mesa-va-drivers, that's expected. Review it if it wants to touch other packages. Check it: rm -rf ~/.cache/gstreamer-1.0 # force GStreamer to rescan plugins gst-inspect-1.0 va | grep -i 'h264|h265' # should list vah264dec and vah265dec Enable hardware acceleration in Discord (Settings → Advanced). If the option isn't there, quit Discord completely and run: cp ~/.config/discord/settings.json ~/.config/discord/settings.json.bak sed -i 's/"enableHardwareAcceleration": false/"enableHardwareAcceleration": true/' ~/.config/discord/settings.json Open Discord from your app menu. Launching it from a sandboxed terminal (some IDE/app terminals) can leave it without camera access. Fix 2: the deleted OpenH264 2.5.1 (since Oct 28, 2026) Check whether you're affected: ls ~/.config/discord/discord_asset_cache/openh264/ ps -eo args | grep -o 'openh264-library-path=[^ ]*' | sort -u If Discord asks for 2.5.1 and only 2.7.0 is in the folder, you are. Download Cisco's official build and verify it: mkdir -p ~/openh264-dl && cd ~/openh264-dl curl -fO ciscobinary.openh264.org curl -f ciscobinary.openh264.org bunzip2 -k libopenh264-2.5.1-linux64.7.so.bz2 md5sum libopenh264-2.5.1-linux64.7.so # must be bdd6e8a20ca745aadbd31c3d571f8a7f, same as Cisco's .md5.txt Install it and make the folder read-only so Discord's cleanup can't delete it: C=~/.config/discord/discord_asset_cache/openh264 install -m 644 libopenh264-2.5.1-linux64.7.so "$C/" chmod u-w "$C" Quit Discord completely (tray → Quit) and reopen it. renderer_js.log will now say OpenH264 cleanup: Failed to delete "libopenh264-2.5.1-linux64.7.so": EACCES. That means the protection works. Don't symlink 2.5.1 to 2.7.0: they're different ABIs (.so.7 vs .so.8), and without the read-only folder Discord deletes the file again anyway. Validate Join a call with cameras and screen share on, then run: grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -8 \ | grep -o '[[a-z]] Inbound|codec: [^,]|decoded: [0-9]|resolution: [^,]' | paste - - - - My final result: |Stream|Codec|Decoder|Resolution|Result| |:-|:-|:-|:-|:-| |Mac screen share|H.265|electron (GPU)|1108×718|OK, no loss| |Mac camera|H.265|electron (GPU)|672×378|30 fps| |Windows camera 1|H.264|electron (GPU)|672×378|OK| |Windows camera 2|H.264|ffmpeg (OpenH264)|576×360|30 fps| Windows camera 2 was below 640×360, so it went through OpenH264. That's why you need both fixes. What didn't help - Turning off the OpenH264 toggle: there's no other H.264 software decoder in Discord's FFmpeg. - Installing system FFmpeg: Discord uses its own libffmpeg.so. - chromiumSwitches in settings.json: it only passes keys without values. - Restarting or reinstalling: the updater says "Already up to date", and 2.5.1 gets deleted again. Limits / undo - Streams smaller than 640×360 still use OpenH264, so a Mac user can look bad again when Discord lowers their quality. - Twice, the GPU path rejected H.264 with VaapiVideoDecoder: failed initializing VaapiWrapper for profile h264 main. VA-API decoded H.264 main fine outside Discord, and it didn't happen again after a restart. Cause unknown. With Fix 2, that case falls back to OpenH264, so video still shows. - Once Discord ships a host that uses 2.7.0, make the folder writable again. Undo: chmod u+w ~/.config/discord/discord_asset_cache/openh264 rm ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so sudo dnf remove mesa-va-drivers-freeworld cp ~/.config/discord/settings.json.bak ~/.config/discord/settings.json Sources - Mozilla bug 1492038: OpenH264 with macOS senders - OpenH264 issues #2165 and #3479 - snapcrafters/discord #378: Discord's libffmpeg.so only has OpenH264 for H.264 - RPM Fusion: Multimedia - Arch Wiki: Chromium hardware video acceleration Formatted version of this guide, with copy buttons: <LINK, optional> Thanks to @morluto for REA. Without it we couldn't have looked inside Discord's binaries. claude.ai
[Linux] Fixed: Discord H.264 video corrupted from Mac users, and Windows cameras not starting at all since Oct 28 (root cause + full guide) I was having this problem and, with help from Claude and REA (a reverse-engineering toolkit by @morluto), I found the root cause by reading Discord's logs and statically analyzing its binaries. I'm writing the whole process here so anyone with the same issue can fix it. TL;DR - On Linux, Discord can only decode H.264 in software with OpenH264, because its bundled FFmpeg has no native H.264 decoder. OpenH264 mis-decodes video coming from macOS users. Fix: make the GPU decode it: VA-API with H.264 plus hardware acceleration enabled. - Since Oct 28, 2026: Discord downloaded OpenH264 2.7.0 and deleted 2.5.1, but the desktop host (1.0.166) still loads 2.5.1 from a hardcoded path. Any H.264 stream that falls back to software decoding fails, so cameras show black. Fix: put Cisco's official 2.5.1 back and make the folder read-only. My setup / who this may affect - Fedora 44, Wayland, AMD Radeon 760M (iGPU) + NVIDIA RTX 2050 - I installed Discord with the RPM Fusion nonfree package (sudo dnf install discord, version 1.0.148). It then self-updates to host 1.0.166 in ~/.config/discord/app-1.0.166. - I only verified this on my own install. The bug is in Discord's host and voice module, not in the package, so I'd expect it to affect any native Linux install (.deb, .tar.gz, RPM Fusion, probably Flatpak). Check your logs first (see below). Symptoms 1. A friend on Mac looked pixelated, with smeared blocks and wrong colors, and kept freezing. It only happened for me: Windows friends saw him fine, and my phone did too. The network was fine (3 lost packets out of 26,036). 2. Later (Oct 28), my Windows friends' cameras stopped working completely: black tile, even though packets were arriving. 3. Restarting didn't help, and the updater said "Already up to date". How Discord decodes video on Linux (what we found) - The voice module (discord_voice.node) uses a PixelCappedDecoder: - 640×360 or larger (230,400 px, 0x38400 in the binary): it tries the Electron/GPU decoder (VA-API). - If that fails, or the stream is smaller: FFmpeg → OpenH264. - Discord's bundled libffmpeg.so has no native H.264 decoder. The only H.264 decoder in it is ff_libopenh264_decoder, and webrtc::H264Decoder::Create returns nullptr. Turning off the "OpenH264" toggle in settings leaves you with no H.264 software decoder at all. - On Windows, Discord enables enable-h264-mf (Media Foundation), which is OS hardware decoding. That's why Windows users don't see this. How we found it 1. Read Discord's WebRTC log. It's at ~/.config/discord/logs/discord-webrtc_0. Every 10 s it prints per-user stats: codec, decoded frames and resolution. # which decoder is used grep -h 'Using libopenh264|Decoder implementation|ElectronVideoDecoder|High pixel count' \ ~/.config/discord/logs/discord-webrtc_0 | sed 's/^[[^]]] [[0-9]] //' | sort | uniq -c # per-user stats grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -6 The Mac stream arrived almost lossless, and WebRTC counted 6114 of 6128 frames as "decoded", yet it rendered broken. The decoder was hiding the errors. Everything was going through Using libopenh264 decoder. 2. Why the GPU wasn't used. Every stream showed: Constructing PixelCappedDecoder with electron, ffmpeg ElectronVideoDecoder::Initialize failed. status: 5 High pixel count decoder failed to init, falling back to other decoder Using libopenh264 decoder Reverse engineering with REA showed that status: 5 = ElectronVideoStatus::Unsupported. It's returned when there are no GPU factories (hardware acceleration off) or the GPU doesn't support the config. In my case it was both: - Hardware acceleration was off. In app.asar, that setting calls app.disableHardwareAcceleration(). - Fedora's Mesa ships VA-API without H.264 because of patents: only AV1, VP9 and JPEG. gst-inspect-1.0 va didn't list vah264dec. 3. Prior art. In Mozilla bug 1492038, OpenH264 mis-decoded H.264 from macOS senders, and Firefox fixed it by not using OpenH264 for decoding. Firefox on my Fedora, which also uses OpenH264 for WebRTC, showed the same artifacts from that friend. 4. Fix 1 applied. Streams of 640×360 or larger switched to implementation_name = 'electron', is_hardware_accelerated = true, and the Mac video became clean. 5. Next day: Windows cameras dead. The log showed thousands of packets received and 0 frames decoded: Setting OpenH264 library path to: ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so Using libopenh264 decoder avcodec_open2 error: -1313558101 Failed to decode frame. Return code: -8 ... type: key, width: 896, height: 504 -1313558101 is AVERROR_UNKNOWN: FFmpeg couldn't open the library. The 2.5.1 file no longer existed. renderer_js.log explained why: [MediaEngineStore] OpenH264 is ready ... OpenH264 cleanup: Deleted unused file "libopenh264-2.5.1-linux64.7.so" And the host's app-1.0.166/resources/app.asar has the path hardcoded: let openh264Path = path.join(assetCachePath, "openh264", "libopenh264-2.5.1-linux64.7.so"); app.commandLine.appendSwitch("openh264-library-path", openh264Path) So the web part of Discord moved to 2.7.0 and deletes 2.5.1 on every start, while the installed host still asks for 2.5.1. A newer host (1.0.167) exists, but the updater says "Already up to date". Fix 1: let the GPU decode H.264 (AMD/Intel on Fedora) On other distros, install whatever package enables H.264/H.265 in VA-API. sudo dnf install mirrors.rpmfusion.org -E %fedora).noarch.rpm sudo dnf install mesa-va-drivers-freeworld If dnf wants to swap mesa-va-drivers, that's expected. Review it if it wants to touch other packages. Check it: rm -rf ~/.cache/gstreamer-1.0 # force GStreamer to rescan plugins gst-inspect-1.0 va | grep -i 'h264|h265' # should list vah264dec and vah265dec Enable hardware acceleration in Discord (Settings → Advanced). If the option isn't there, quit Discord completely and run: cp ~/.config/discord/settings.json ~/.config/discord/settings.json.bak sed -i 's/"enableHardwareAcceleration": false/"enableHardwareAcceleration": true/' ~/.config/discord/settings.json Open Discord from your app menu. Launching it from a sandboxed terminal (some IDE/app terminals) can leave it without camera access. Fix 2: the deleted OpenH264 2.5.1 (since Oct 28, 2026) Check whether you're affected: ls ~/.config/discord/discord_asset_cache/openh264/ ps -eo args | grep -o 'openh264-library-path=[^ ]*' | sort -u If Discord asks for 2.5.1 and only 2.7.0 is in the folder, you are. Download Cisco's official build and verify it: mkdir -p ~/openh264-dl && cd ~/openh264-dl curl -fO ciscobinary.openh264.org curl -f ciscobinary.openh264.org bunzip2 -k libopenh264-2.5.1-linux64.7.so.bz2 md5sum libopenh264-2.5.1-linux64.7.so # must be bdd6e8a20ca745aadbd31c3d571f8a7f, same as Cisco's .md5.txt Install it and make the folder read-only so Discord's cleanup can't delete it: C=~/.config/discord/discord_asset_cache/openh264 install -m 644 libopenh264-2.5.1-linux64.7.so "$C/" chmod u-w "$C" Quit Discord completely (tray → Quit) and reopen it. renderer_js.log will now say OpenH264 cleanup: Failed to delete "libopenh264-2.5.1-linux64.7.so": EACCES. That means the protection works. Don't symlink 2.5.1 to 2.7.0: they're different ABIs (.so.7 vs .so.8), and without the read-only folder Discord deletes the file again anyway. Validate Join a call with cameras and screen share on, then run: grep 'Inbound stats for user' ~/.config/discord/logs/discord-webrtc_0 | tail -8 \ | grep -o '[[a-z]] Inbound|codec: [^,]|decoded: [0-9]|resolution: [^,]' | paste - - - - My final result: |Stream|Codec|Decoder|Resolution|Result| |:-|:-|:-|:-|:-| |Mac screen share|H.265|electron (GPU)|1108×718|OK, no loss| |Mac camera|H.265|electron (GPU)|672×378|30 fps| |Windows camera 1|H.264|electron (GPU)|672×378|OK| |Windows camera 2|H.264|ffmpeg (OpenH264)|576×360|30 fps| Windows camera 2 was below 640×360, so it went through OpenH264. That's why you need both fixes. What didn't help - Turning off the OpenH264 toggle: there's no other H.264 software decoder in Discord's FFmpeg. - Installing system FFmpeg: Discord uses its own libffmpeg.so. - chromiumSwitches in settings.json: it only passes keys without values. - Restarting or reinstalling: the updater says "Already up to date", and 2.5.1 gets deleted again. Limits / undo - Streams smaller than 640×360 still use OpenH264, so a Mac user can look bad again when Discord lowers their quality. - Twice, the GPU path rejected H.264 with VaapiVideoDecoder: failed initializing VaapiWrapper for profile h264 main. VA-API decoded H.264 main fine outside Discord, and it didn't happen again after a restart. Cause unknown. With Fix 2, that case falls back to OpenH264, so video still shows. - Once Discord ships a host that uses 2.7.0, make the folder writable again. Undo: chmod u+w ~/.config/discord/discord_asset_cache/openh264 rm ~/.config/discord/discord_asset_cache/openh264/libopenh264-2.5.1-linux64.7.so sudo dnf remove mesa-va-drivers-freeworld cp ~/.config/discord/settings.json.bak ~/.config/discord/settings.json Sources - Mozilla bug 1492038: OpenH264 with macOS senders - OpenH264 issues #2165 and #3479 - snapcrafters/discord #378: Discord's libffmpeg.so only has OpenH264 for H.264 - RPM Fusion: Multimedia - Arch Wiki: Chromium hardware video acceleration Formatted version of this guide, with copy buttons: <LINK, optional> Thanks to @morluto for REA. Without it we couldn't have looked inside Discord's binaries.
@mewset @davepl1968 Still used in libsrtp tests. github.com/cisco/libsrtp/blob/7071fba734fe93979af…