Content
When watching a friend's stream using Vencord, the AV1 codec was successfully used for decoding.
However, when watching the same stream with Vesktop, the stream falls back to H.264 instead.
This suggests that AV1 decoding support works correctly in Vencord, but does not seem to be enabled or preferred in Vesktop. ( I think it doesn't work )
When I stream myself, only H.264 is used on both Vencord and Vesktop.
Even though I have an NVIDIA 4000 series GPU, AV1 encoding is not supported (most likely due to Discord limitations).
Additionally, Discord appears to prefer H.264 for streaming by default.
While using Vesktop, I tried disabling H.264 and some other codecs via JavaScript.
When I left only AV1 enabled, it didn't work — the stream would fail to play.
However, when I left only one of the other codecs (e.g. VP8, VP9), Discord would forcefully use that codec.
I also noticed that VP9 was not used unless it was the only remaining option.
Once I completely disabled H.264-VP8 stream support, Discord began falling back to VP9 for streams from friends who couldn't stream in AV1.
As a result, my own streams were encoded using VP9, and I was also able to force incoming streams to use VP9 as well.
This had benefits in both cases — better quality and lower bitrate compared to H.264.
It might be useful information for others too; I believe forcing codecs during streaming can have general advantages.
That brings up a question:
While Vencord is able to view AV1X streams, why does Vesktop always fall back to H.264 for all streams, including those that should be AV1X?
I’m unable to watch AV1X streams at all with Vesktop, even though the same system and hardware work fine with Vencord.
Both applications are unable to play H.265 (HEVC) videos in chat channels.
I’m aware that this issue currently has no solution and is a known limitation.
However, both Vencord and Vesktop can play AV1 .mp4 videos in chat without any problems.
I ran the same tests using the Flatpak builds, and the behavior was identical — no differences in codec handling or playback were observed.
Content
When watching a friend's stream using Vencord, the AV1 codec was successfully used for decoding.
However, when watching the same stream with Vesktop, the stream falls back to H.264 instead.
This suggests that AV1 decoding support works correctly in Vencord, but does not seem to be enabled or preferred in Vesktop. ( I think it doesn't work )
When I stream myself, only H.264 is used on both Vencord and Vesktop.
Even though I have an NVIDIA 4000 series GPU, AV1 encoding is not supported (most likely due to Discord limitations).
Additionally, Discord appears to prefer H.264 for streaming by default.
While using Vesktop, I tried disabling H.264 and some other codecs via JavaScript.
When I left only AV1 enabled, it didn't work — the stream would fail to play.
However, when I left only one of the other codecs (e.g. VP8, VP9), Discord would forcefully use that codec.
I also noticed that VP9 was not used unless it was the only remaining option.
Once I completely disabled H.264-VP8 stream support, Discord began falling back to VP9 for streams from friends who couldn't stream in AV1.
As a result, my own streams were encoded using VP9, and I was also able to force incoming streams to use VP9 as well.
This had benefits in both cases — better quality and lower bitrate compared to H.264.
It might be useful information for others too; I believe forcing codecs during streaming can have general advantages.
That brings up a question:
While Vencord is able to view AV1X streams, why does Vesktop always fall back to H.264 for all streams, including those that should be AV1X?
I’m unable to watch AV1X streams at all with Vesktop, even though the same system and hardware work fine with Vencord.
Both applications are unable to play H.265 (HEVC) videos in chat channels.
I’m aware that this issue currently has no solution and is a known limitation.
However, both Vencord and Vesktop can play AV1 .mp4 videos in chat without any problems.
I ran the same tests using the Flatpak builds, and the behavior was identical — no differences in codec handling or playback were observed.