10973109721097110970...1>>
#109721From:Eugene Grosbein
To:Victor Sudakov
Date:25-05-2020 00:26:00
Subj:Re: Аудио и видео в виндовой виртуалке
24 мая 2020, воскресенье, в 16:16 NOVT, Victor Sudakov написал(а):

 EM>>>> потребуется приличная (сотни миллисекунд) буферизация, иначе
EM>>>> периодически будет трещать и рваться.
 VS>>> Это неизбежно, но хороший кодек в состоянии эту проблему в
VS>>> значительной степени смягчить.
 EM>> Каким образом, и за счет чего, эту проблему мог бы смягчить _кодек_?
 VS> За счет хитрых алгоритмов сжатия и избыточности. Более развернуто ответить не
VS> смогу, потому что не знаю теории, а имею только личный опыт.

Кодеком в данном случае называется конкретная реализация,
обычно применяющаяя для смягчения проблемы jitter buffer
(а ещё интерполяцию для восстановления малых потерь
и, возможно, некоторую избыточность опять же против потерь).

****://******.*****.voipforo.com/QoS/QoS_Jitter.php

CAUSES:

Jitter is a typical problem of the connectionless networks or
packet switched networks. Due to the information is divided
into packets each packet can travel by a different path
from the emitter to the receiver.

Jitter is technically the measure of the variability over time
of the latency across a network.

Real time communications (for example VoIP) usually have quality problems
due to this effect. In general, it is a problem in slow-speed links or
with congestion. It is hoped that the increase of QoS
(quality of the service) mechanisms like priority buffers, bandwidth
reservation or high-speed connections (100Mb Ethernet, E3/T3, SDH)
can reduce jitter problem in the future although it will keep on being
a problem for a long time.

RECOMMENDED VALUES:

Jitter between the starting and final point of the communication
should be less than 100 ms. If jitter value is smaller than 100 ms
it can be solved. If not must be reduced.

SOLUTIONS:

The best solution is to use jitter buffers. A jitter buffer is
basically to assign a small buffer to receive the packets and give it
to the receiver with a small delay. If some packet is not in the buffer
(it is lost or it has still not arrived) when it is necessary
it is not taking into account. Usually in IP telephones
(hardware and software) buffer lengths can be modified.
If jitter buffer is increased turns out in less packet
loss but more delay. A reduction turns out in less delay
but more packet loss.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 50/16 109 221/0 6 240/1120 250/25 341/66 463/68 466/50 467/70 888
SEEN-BY: 5000/14 111 5001/100 5003/17 5005/49 5006/1 9 5010/352 5015/42 46
SEEN-BY: 5020/113 400 545 715 814 830 846 1042 1436 2038 2047 2123 2140 4441
SEEN-BY: 5021/29 5025/3 75 5026/14 5027/12 5030/115 1957 2404 5033/21 5035/85
SEEN-BY: 5050/57 151 5051/36 44 5052/4 5053/54 55 57 400 5054/1 8 89 5055/37
SEEN-BY: 5063/3 5064/54 56 5066/18 5068/10 45 5080/68 102 245 5083/1 444
SEEN-BY: 5085/13 5095/20 6001/10 6078/80 6090/1 14
PATH: 5006/1 5080/102 5020/545 221/6 5020/1042 6090/1
#109722From:Eugene Grosbein
To:Eugene Muzychenko
Date:25-05-2020 00:33:13
Subj:Re: Аудио и видео в виндовой виртуалке
24 мая 2020, воскресенье, в 22:01 NOVT, Eugene Muzychenko написал(а):

 EM> Эти кодеки работают с очень узкополосным монофоническим сигналом, позволяющим
EM> создать большой запас по пропускной способности. И все равно: я давно и часто
EM> пользуюсь VoIP/SIP с телефона, и разговор через любое мобильное соединение
EM> мучителен. Через проводное - на порядок лучше.

Через проводное ты голос идёт по коммутации каналов
и на время разговора коммутатор предоставляет тебе эксклюзивную линию,
а VoIP экономит на каналах, переходя на коммутацию пакетов в канале.

Мучительно получается только в том случае, если оператор связи
не обеспечивает твоему VoIP-трафику приоритезацию и вообще QoS.

Если обеспечивает, то никаких мучений нет. Я даже тестировал
реализацию QoS в некоторых железках одним простым способом:
добавлял в такой разделяемый канал "флудилку", которая
фигачила в канал "мусорными" пакетами на скорости линка этого самого
канала (100M для примера, для 1G та же фигня) во время разговора.

Если QoS для подобного трафика с требованиями real-time не включён,
то как только флудилка включается, полезный трафик моментально
"затыкается", тишина. Тот же эксперимент со включенным QoS
по трассе и включение неприоритезированной флудилки не оказывает
никакого влияния на приоритетный трафик "на слух", хотя наблюдение
за портом показывает, что он забит полностью. А это был недорогой
управляемый коммутатор D-Link второго уровня.

Eugene
--
Чтобы всё как у всех, но чтоб при этом - не так, как они.
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 50/16 109 221/0 6 240/1120 250/25 341/66 463/68 466/50 467/70 888
SEEN-BY: 5000/14 111 5001/100 5003/17 5005/49 5006/1 5010/352 5015/42 46
SEEN-BY: 5020/113 400 545 715 814 830 846 1042 1436 2038 2047 2123 2140 4441
SEEN-BY: 5021/29 5025/3 75 5026/14 5027/12 5030/115 1957 2404 5033/21 5035/85
SEEN-BY: 5050/57 151 5051/36 44 5052/4 5053/54 55 57 400 5054/1 8 89 5055/37
SEEN-BY: 5063/3 5064/54 56 5066/18 5068/10 45 5080/68 102 245 5083/1 444
SEEN-BY: 5085/13 5095/20 6001/10 6078/80 6090/1 14
PATH: 5006/1 5080/102 5020/545 221/6 5020/1042 6090/1
#109723From:Eugene Muzychenko
To:Eugene Grosbein
Date:25-05-2020 08:39:11
Subj:Аудио и видео в виндовой виртуалке
Привет!

25 May 20 00:33, you wrote to me:

 EG> Через проводное ты голос идёт по коммутации каналов
EG> и на время разговора коммутатор предоставляет тебе эксклюзивную линию,

Это тебе показалось, что под "проводным" я имел в виду традиционный кабельный телефон. А я говорил о проводном Интернет-подключении. Впрочем, даже не обязательно проводном - хороший стационарный радиоканал с пингом в единицы миллисекунд, как у нас в деревне, тоже годится. Телефон по WiFi зацеплен к простому домашнему маршрутизатору, тот через шлюз по радиоканалу подключен к концентратору, дальше оптика.

 EG> Мучительно получается только в том случае, если оператор связи
EG> не обеспечивает твоему VoIP-трафику приоритезацию и вообще QoS.

Ты когда-нибудь видел оператора мобильной связи, который обеспечивает приоритизацию левого VoIP-трафика? :) Hайдешь - покажи пальцем, я возьму на заметку. :)

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Fox Tracks, Servoz, France (2:5000/14)
SEEN-BY: 46/49 50/109 221/6 240/1120 250/25 341/66 455/19 463/68 466/50
SEEN-BY: 467/888 4500/1 5000/14 111 5001/100 5005/49 5010/352 5015/42 46
SEEN-BY: 5019/40 42 5020/113 400 545 715 814 830 846 848 1042 2038 2047 2123
SEEN-BY: 5020/2140 4441 12000 5021/29 5022/128 5025/3 75 5027/12 5030/115 1081
SEEN-BY: 5030/1957 2404 5033/21 5035/85 5036/2 5050/57 151 5051/36 5052/4
SEEN-BY: 5053/54 55 57 400 5054/1 8 89 5055/37 5063/3 5064/54 56 5066/18
SEEN-BY: 5068/10 45 5080/68 102 5083/1 444 5085/13 5095/20 6001/10 6035/4
SEEN-BY: 6078/80 6090/1 14
PATH: 5000/14 5020/545 4441 1042 6090/1
#109724From:Eugene Grosbein
To:Eugene Muzychenko
Date:25-05-2020 10:48:15
Subj:Re: Аудио и видео в виндовой виртуалке
25 мая 2020, понедельник, в 08:39 NOVT, Eugene Muzychenko написал(а):

 EG>> Мучительно получается только в том случае, если оператор связи
EG>> не обеспечивает твоему VoIP-трафику приоритезацию и вообще QoS.
 EM> Ты когда-нибудь видел оператора мобильной связи, который обеспечивает
EM> приоритизацию левого VoIP-трафика? :) Hайдешь - покажи пальцем, я возьму на
EM> заметку. :)

Hет, но я видел оператора SIP-связи, который использует собственную
опорную оптоволоконную сеть для предоставления услуги VoIP по SIP
с приоритезацией. Это я сам :-)

Eugene
--
Choose no life
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 46/49 50/16 109 221/6 240/1120 250/25 341/66 455/19 463/68 466/50
SEEN-BY: 467/70 888 4500/1 5000/14 111 5001/100 5003/17 5005/49 5006/1 9
SEEN-BY: 5010/352 5015/42 46 5019/40 42 5020/113 400 545 715 814 830 846 848
SEEN-BY: 5020/1042 1436 2038 2047 2123 2140 4441 12000 5021/29 5022/128 5025/3
SEEN-BY: 5025/75 5026/14 5027/12 5030/115 1081 1957 2404 5033/21 5035/85
SEEN-BY: 5036/2 5050/57 151 5051/36 44 5052/4 5053/54 55 57 400 5054/1 8 89
SEEN-BY: 5055/37 5063/3 5064/54 56 5066/18 5068/10 45 5080/68 102 245 5083/1
SEEN-BY: 5083/444 5085/13 5095/20 6001/10 6035/4 6078/80 6090/1 14
PATH: 5006/1 5080/102 5020/545 4441 1042 6090/1
10973109721097110970...1>>