Closed ArtsemKurantsou closed 1 year ago
Hi @sauwming , @nanangizz Could you please help with the issue or add an appropriate member to the issue? Thanks in advance
Hi @sauwming @nanangizz Could you please help with this issue?
Unfortunately I don't see any other possible cause other than the packet loss. If the problem doesn't happen with fewer number of calls, then it's a resource/network issue.
Hi @sauwming Sometimes it happens even for a single call. The phone is connected to 5Gh WiFi and has a high-speed connection. The calling device also has a good connection so it doesn't look like the issue is that the connection is slow. Another thing is that packets dump analysis also doesn't show the packet loss. So it looks like the problem is that PjSip drops the packets for some reason.
BTW sometimes when it happens I get openh264.cpp Unpacketize error: Ignored (PJ_EIGNORED)
.
Could you please give me advice on where should I take a look and how I can be sure that all the incoming packets are handled by PjSip?
Hi, @sauwming. Could you please check my previous message?
You can try to do some debugging: https://developer.android.com/studio/debug
Based on the info you provided, some places to look into:
Hi @sauwming. I tried to profile the app and I think I have an idea why I see the issue. In the profiler, I see that one thread is folded with work when I start 3 video calls simultaneously. I think that the problem is with ioqueue using a single thread for sockets polling (please correct me if I'm wrong). I tried to use epoll version but it didn't help. I also tried to use AMediacodec decoder and it helps but with 3 calls this thread also has a pretty high load. Are there any configurations or other things that I can try to fix the problem? Thanks in advance
In my opinion, the video processing is the more likely cause, especially if using a high res and/or fps (such as 1280x720, 25 fps as in the log). You can check by changing the decode to no-op and/or the encode to no-op, to find out how much CPU those need. When both are set to no-op, and audio is disabled, the remaining CPU is the one used by polling. If it's still high, then yes, it's because of the polling as you suspected. But if it's low, then it is the video.
Hi @sauwming
I've commented out everything in decode_h264
in the and_vid_mediacodec.c
and checked with it and load seems to be a bit less but still looks a bit too high.
Is there any way to have a separate thread for each call? Another thing is overall CPU load is less than 50% so it looks like the device should be able to handle this load.
Describe the bug When I try to start several video calls simultaneously on Android I get partially (or even completely) grey picture on some of them. At the end of the call, I also dump statistics for the call and it shows really huge packet loss but when I try to analyze packets using Wireshark I don't see that huge packet loss. I tried to dig deep in the code to see what can lead to such issues but haven't spotted anything that can cause such issues to me. Is there any chance that packets got lost by ioqueue?
To Reproduce Steps to reproduce the behavior:
Expected behavior The video should not be corrupted (if all packets are reaching the device) and packet loss should be correct.
Logs/Screenshots Here are screenshots of the wireshark analyze and statistics from the dump of 3 simultaneous video calls: 1.
2.
3.
Desktop/Smartphone (please complete the following information):
configure
script params: ARGET_ABI=armeabi-v8a APP_PLATFORM=android-21 ./configure-android --use-ndk-cflags --with-opus=$opus_path --with-openh264=$h264_path --with-ssl=$open_ssl_pathconfig_site.h
contents: ...Smartphone (please also complete the following information):