Аудио и видео в виндовой виртуалке

Victor Sudakov написал(а) к Eugene Muzychenko в May 20 16:16:54 по местному времени:

Dear Eugene,

24 May 20 07:47, you wrote to me:

EM>>> потребуется приличная (сотни миллисекунд) буферизация, иначе
EM>>> периодически будет трещать и рваться.

VS>> Это неизбежно, но хороший кодек в состоянии эту проблему в
VS>> значительной степени смягчить.

EM> Каким образом, и за счет чего, эту проблему мог бы смягчить кодек?

За счет хитрых алгоритмов сжатия и избыточности. Более развернуто ответить не смогу, потому что не знаю теории, а имею только личный опыт.

На прошлой работе мы с телефонистами испытывали разные телефонные станции и VoIP-шлюзы на предмет потери качества голоса при потерях и задержках (которые мы эмулировали с помощью ipfw). И знаешь что, если на тупых кодеках типа G.711 проблемы начинаются сразу, то продвинутые кодеки (G.729, G.722 насколько я помню) небольшие потери и задержки маскировали удивительно удачно. Не спрашивай, как это реализовано математически.

VS>> Ну и зря. Представь, как удобно было бы иметь возможность
VS>> передать по сети любой звук с/на машину, а не только звук от
VS>> избранных, умеющих транслировать и принимать звук приложений.

EM> Удобно-то удобно, но геморроя при этом возникает немеряно. Нужно
EM> знать, как это работает, и уметь с ним бороться. А подавляющее
EM> большинство в этом вообще не разбирается, но хочет, чтоб все работало
EM> ровно и четко, само по себе. Если что-то не так - сразу поднимается
EM> вой "мы вам заплатили, вы нас обманули". :)

Это да, даже авторы совершенно бесплатного софта порой вынуждены такое выслушивать.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20170303-b20170303

Eugene Muzychenko написал(а) к Victor Sudakov в May 20 22:01:07 по местному времени:

Привет!

24 May 20 16:16, you wrote to me:

EM>> Каким образом, и за счет чего, эту проблему мог бы смягчить
EM>> кодек?

VS> За счет хитрых алгоритмов сжатия и избыточности.

Все эти алгоритмы в любом случае требуют определенного запаса звукового материала, чтобы подставлять в случае выпадений, как это делает тот же CD-проигрыватель. Но проигрыватель может вычитывать диск наперед, а приемник потока реального времени так делать не может, он может только задержать поток, чтобы сформировать этот запас. А при передаче по нелокальной сети, без гарантированной полосы и времени доставки пакета, придется держать минимум полсекунды при очень хорошей связи, и несколько секунд - при типовой.

Посмотри на тот же ютуб, на сколько времени он залезает вперед, чтобы компенсировать спонтанные затыки канала.

VS> продвинутые кодеки (G.729, G.722 насколько я помню) небольшие потери и
VS> задержки маскировали удивительно удачно.

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

Тебе ж наверняка приходилось работать с удаленными системами через telnet/ssh. Часто видел, чтобы скорость набора текста или перемещения курсора была такой же, как и в локальной системе? А ведь на каждое нажатие отправлются/принимаются жалкие сотни байт, и нажатий этих ты делаешь максимум единицы в секунду. А MP3 даже на 128 кбит/с - это 16 килобайт/с непрерывным потоком. Вот и считай.

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

--- GoldED+/W32-MSVC 1.1.5-b20170303

Eugene Grosbein написал(а) к Victor Sudakov в May 20 00:26:00 по местному времени:

24 мая 2020, воскресенье, в 16:16 NOVT, Victor Sudakov написал(а):

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

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

http://www.en.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, SDН)
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)

Eugene Grosbein написал(а) к Eugene Muzychenko в May 20 00:33:26 по местному времени:

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)

Eugene Muzychenko написал(а) к Eugene Grosbein в May 20 08:39:22 по местному времени:

Привет!

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

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

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

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

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

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

--- GoldED+/W32-MSVC 1.1.5-b20170303

Eugene Grosbein написал(а) к Eugene Muzychenko в May 20 10:48:31 по местному времени:

25 мая 2020, понедельник, в 08:39 NOVT, Eugene Muzychenko написал(а):

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

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

Eugene
--
Choose no life
--- slrn/1.0.3 (FreeBSD)

Олег Певзнер написал(а) к All в Jun 20 22:40:30 по местному времени:

Нello!

Парни, спасибо всем, кто откликнулся на мой вопрос. Я сейчас тут бываю крайне нечасто, поэтому
заранее извиняюсь за запоздалую реакцию. В общем, саму по себе задачу прокидывания звука и видео в
vmware workstation я в конце концов действительно поборол без особых проблем. Как выяснилось,
последние версии Варьки все же не слишком качественно работают со звуком в серверных гостевых системах, а вот в клиентских (8.1/10, включая самые последние обновления 10-ки) с этим все хорошо, звук и видео
пробрасываются, причем достаточно качественно. Но есть и проблемные вещи, о которых можно было бы
поговорить.
Если коротко, строю небольшую ноду, которая должна в условиях карантина и прочих дистанционок
обеспечить удаленную работу преподавателей кафедры в количестве порядка 15-20 человек, при этом
одновременно могут работать 5-10 преподавателей. Каждый преподаватель в ходе своей работе использует
свою обучающую платформу (Moodle, Zoom, Webex и т.п.), а также собственную обучающую среду (например,
Cisco Packet Tracer) и, соответственно, свою операционную систему. В плане выбора ОС выбор может быть
весьма широким: от винды с разными линуксами до всевозможной экзотики типа MacOS, Android и других
специализированных продуктов, но на первом этапе рассматриваются только винда и линуксы. Ну и вот тут
начинается интересное.
Каждому преподавателю в этой системе выделяется собственная виртуальная машина, в которой он строит
свой обучающий курс. А теперь представим себе, что одновременно с десяток этих самых преподов начинают
что-то вещать каждый в свой микрофон и передавать что-то в свою камеру через Zoom, Skype и т.п. Тут
дай Бог реальному процессору все это выдержать и не сдохнуть, а каково все это делать в виртуальной
серед? Конечно, нода там не слабенькая, несколько процессоров стоит, ядер много и т.п., но все равно
качество аудио и видео в таком режиме под большим вопросом. Вот и хотелось бы услышать, кто что думает по этому поводу и какие у кого могут быть предложения.
Спасибо заранее всем откликнувшимся. Здесь сейчас бываю очень редко, поэтому не сочтите за труд,
кто захочет, написать мне на мой E-Mail: omp<собака>omp<точка>dp<точка>ua. Обязательно отзовусь и
с благодарностью отвечу каждому, кто пришлет свои мысли, идеи, соображения и критику. Ну и еще раз,
всем приветы тут! :-)
---
WBR, Олег Певзнер.

--- wfido

Eugene Muzychenko написал(а) к Олег Певзнер в Jun 20 15:41:18 по местному времени:

Привет!

02 Jun 20 22:40, you wrote to All:

ОП> представим себе, что одновременно с десяток этих самых преподов
ОП> начинают что-то вещать каждый в свой микрофон и передавать что-то в
ОП> свою камеру через Zoom, Skype и т.п. Тут дай Бог реальному процессору
ОП> все это выдержать и не сдохнуть

Ничего подобного. От звука вообще нагрузка мизерная: от микрофона идут максимум 16-разрядные отсчеты на 48000 - это 96 кб/с, на динамики идут максимум 24-разрядные на 96000 - это 288 кб/с. Это килобайт в секунду. Для записи, воспроизведения и простой обработки нескольких таких потоков по уши достаточно 386SX с ISA, а уж первопня с PCI - для нескольких десятков.

Вот от видео идет на порядок-два больше, там быстродействие уже достаточно критично.

ОП> а каково все это делать в виртуальной серед? Конечно, нода там не
ОП> слабенькая, несколько процессоров стоит, ядер много и т.п., но все
ОП> равно качество аудио и видео в таком режиме под большим вопросом.

Сразу скажу, что видео может быть и субъективно приличным, поскольку небольшие колебания частоты кадров для глаза совершенно незаметны, если не показывается что-нибудь специально калиброванное. Звук же будет ужасен. Более того, живой звук в виртуалке чаще все бывает ужасен даже при единичном потоке, и чем старше версия гостевой системы, тем хуже. В гостевой 2k/XP можно было разговаривать через скайп, в семерке - уже с трудом, а в десятках - только если сильно повезет. Во всем виноваты внутренние тормоза и глюки как винды (и хостовой, и гостевой), так и VMM, причем почти нет разницы между VMware, VirtualBox или встроенным десяточным.

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

--- GoldED+/W32-MSVC 1.1.5-b20170303

Andrew Kant написал(а) к Victor Sudakov в Jun 20 09:40:31 по местному времени:

Нello Victor!

Friday May 22 2020 21:54, Victor Sudakov wrote to Eugene Muzychenko:

VS>>> Интересно, бывает ли в Windows виртуальная сетевая карта,
VS>>> работающая по сети? Типа юниксовых NAS (Network Audio System),
VS>>> Pulseaudio и проч. (ну конечно не совсем такое, но идея).

EM>> Ты имеешь в виду - звуковая?

VS> Звуковая конечно. Описка.

Есть протокол SPICE - передает видео и аудио от виртуалки на клиента (в данном случае клиент - это удаленный комп, который управляет твоей виртуалкой), обратно клаву, мышь и аудио-захват.

Но он не в госте, а в хосте, на сколько я понимаю. Хотя, возможны варианты...

Кстати, обычный RDP тоже это делает.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7