Arch Linux

I have the same problem, but it only started happening after i worked around https://bugs.archlinux.org/task/73965 which broke audio during voice calls for me by setting the OpenAL driver to pulse in the OpenAL config file as described in the wiki here: https://wiki.archlinux.org/title/Telegram#Audio_backend

I'm able to reproduce. I'm going to try a few things with the build.

Welp, nothing worked. Open for any suggestions.

If you have some time, can you build telegram in debug and do some poking with gdb?

I've got this bug. When the software crashes, one is shown as having joined the call. (it may help to localize the segmentation fault, which is I think a misuse of memory)

What would help if someone could build telegram with debug symbols and post the trace here so we can at least know which object the problem occurs in. I will get to it once I have some time but it'd help tremendously if someone could do it before.

Maybe it worth to downgrade to 3.5.x as a temporary measure?

The strange thing is i've compiled myself 3.5.1, 3.5.2, 3.6.0 and 3.6.1 versions and none of them worked (videocalls)

3.5.2 version from arch repo worked, so you can downgrade now to restore videocalls function: sudo pacman -U https://archive.archlinux.org/packages/t/telegram-desktop/telegram-desktop-3.5.2-1-x86_64.pkg.tar.zst

Seems it crashed in ffmpeg4.4:
```
(gdb) bt
#0 0x00007f3318f35074 in av_buffer_get_opaque () at /usr/lib/libavutil.so.56
#1 0x0000564c9ed1f91e in webrtc::H264DecoderImpl::Decode(webrtc::EncodedImage const&, bool, long) ()
#2 0x0000564c9f1032eb in webrtc::VCMGenericDecoder::Decode(webrtc::VCMEncodedFrame const&, webrtc::Timestamp) ()
#3 0x0000564c9edb53f7 in webrtc::internal::VideoReceiveStream2::HandleEncodedFrame(std::unique_ptr<webrtc::EncodedFrame, std::default_delete<webrtc::EncodedFrame> >) ()
#4 0x0000564c9edb5637 in std::_Function_handler<void (std::unique_ptr<webrtc::EncodedFrame, std::default_delete<webrtc::EncodedFrame> >), webrtc::internal::VideoReceiveStream2::StartNextDecode()::{lambda(std::unique_ptr<webrtc::EncodedFrame, std::default_delete<webrtc::EncodedFrame> >)#1}>::_M_invoke(std::_Any_data const&, std::unique_ptr<webrtc::EncodedFrame, std::default_delete<webrtc::EncodedFrame> >&&) ()
#5 0x0000564c9ef4b10e in webrtc::webrtc_repeating_task_impl::RepeatingTaskImpl<webrtc::video_coding::FrameBuffer::StartWaitForNextFrameOnQueue()::{lambda()#1}>::RunClosure() ()
#6 0x0000564c9ee63ea8 in webrtc::webrtc_repeating_task_impl::RepeatingTaskBase::Run() ()
#7 0x0000564c9ee63115 in std::_Function_handler<void (), webrtc::(anonymous namespace)::TaskQueueStdlib::TaskQueueStdlib(std::basic_string_view<char, std::char_traits<char> >, rtc::ThreadPriority)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
#8 0x0000564c9ebf9782 in rtc::(anonymous namespace)::RunPlatformThread(void*) ()
#9 0x00007f331630b5c2 in start_thread () at /usr/lib/libc.so.6
#10 0x00007f3316390584 in clone () at /usr/lib/libc.so.6
```

I tried to apply the patch from https://github.com/TelegramMessenger/tgcalls/commit/e89d9ca78abf7dc4fe7c832c07917696eb993868 and built telegram-desktop with ffmpeg5.0 after removing the workarounds in PKGBUILD from ffmpeg4.4 .
It did not crash, yet whenever I enter a video chat it uses 100% of one of my cpu cores. This persists even if I leave the video chat.

> It did not crash, yet whenever I enter a video chat it uses 100% of one of my cpu cores. This persists even if I leave the video chat.
Apparently I can't reproduce this anymore..

Anyway, here's an alternative version of the patch which uses `av_stream_get_first_dts` which was patched back in arch's ffmpeg for chromium. I have no idea about the internals of either ffmpeg or telegram, and I can now longer reproduce the 100% usage on my cpu in either of the patches, so I'm not sure which is better.

Well the cpu 100% problem doesn't seem to be caused by using ffmpeg5
Edit: Well I take that back, seems to cause problems with webm stickers.

Thanks, patch works fine for me and I'm unable to repro the crash nor the 100% CPU usage afterwards.