Info

Download ZIP (4.3 MB)

Testing and Issues

You can test this entry and submit issues during the testing period of the VoIP Contest, Round 1 contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

22
by rating

Issues

Fair Wombat Nov 14, 2019 at 11:12
The submitted tgvoiprate app got a score of 1228 which means it is less precise than the solution that always returned 3.0 as the result. Unfortunately, this is not good enough to compete for the prize.
10
Caring Monkey Nov 14, 2019 at 20:56
Very strange result, that it exactly = 1228, like always returned 3.0. Does test results always reprodusable? Are you sure, that you use exactly correct binaries? I used PESQ like some overs.
This is not a good idea for encoding and writing data to an ogg file inside a blocking callback in a single thread - avcodec_encode_audio2 and av_interleaved_write_frame can take a lot of time, especially in the case of variable data rates .
The receive cycle is locked until the page is written - so it increases the temporal latency and you loose some data. You must exit this handler as soon as it possible to not affect receiving process - save data to the buffer(pipe) which is being processed by asynchronous task.
Debian GNU/Linux 10
8
Caring Monkey Oct 29, 2019 at 07:36
Yes, you are right! This is my omission. But may be ffmpeg has internal threads for write files? I hope this does not affect much.
B
Borik Bobrujskov Oct 28, 2019 at 15:15
Maybe not an issue, but in compare to other submissions very high CPU usage
Debian GNU/Linux 10 \n \l
Caring Monkey Oct 28, 2019 at 16:40
Transcoding occurs on the maximum speed without simultaneous file IO. So it is normal behavior for this code.
Also please compare the time to process one file. And the moments then cpu usage are big or small.
Fair Wombat Nov 4, 2019 at 12:07
Can't manage to make tgvoipcall work on Buster. Every time ends with

error connecting with params:
caller> tag_hex = 'ba7201826967456c4c090d70a4ae365b'
caller> encryption_key_hex = '2297537d8196e1c9008fff319eeaa2d461be76fa591b2b66bb6318efef53abc801ef3d82d16c51ae29c0ba8760268551c86f8f189de7f6deae54ce6ca06c8d648cf7fa....redacted
caller> sound_in = '/home/user/voip/samples/file.ogg'
caller> sound_out = 'out.ogg'
caller> config = '/home/user/voip/tests/config.json'
caller> role = 'caller'

Same for callee. Tcpdump shows traffic both to and from reflector.
Is libtgvoip linked statically? Any way to enable libtgvoip debug output?
Debian GNU/Linux 10 (buster)
Caring Monkey Nov 4, 2019 at 15:12
Could you provide your ogg files, used in tests and config.json? I want to test exactly with your input parameters. Libtgvoip linked statically.
Also, did you use VPN? From Russia I observed problems without VPN.
Fair Wombat Nov 4, 2019 at 18:50
The ogg file was sample15_4a30a6c03e108b963d0afe692558e3ec.ogg from provided samples, both ways. Tried other files as well.

Here is the config:
https://pastebin.com/raw/29fQSfGF

VPN is not used, because the relector is on the same network, so blockings etc can't affect.
Debian GNU/Linux 10 (buster)
Caring Monkey Nov 5, 2019 at 07:10
Sorry, my fail. I have tested only on VM with one CPU, and I have never tested on bare metal server with Multi-CPU. So, I handled incorrectly multithreading while tgvoipcall started/stopped.

The repository on GitHub is opened:
https://github.com/allright/tgvoipcontest

Commit diffs:
https://github.com/allright/tgvoipcontest/commit/0a9abbdc83cf3ffe1f820c5f58c1f7ef90dfa1ac

ReBuilded submission with hotfix (commit 0a9abbd
) here:
https://yadi.sk/d/iXq1XMe-XTZaWA
Please retest this submission and give me feedback if possible. 🙏

P.S. If you want to build submission from sources, use ./src/scripts/build_submission.sh
But you need Docker to be installed.
Nobody added any issues yet...