Нет, не требуется.

Netspirit, очень бы хотелось видеть stream, в принципе даже копией стандартного т.к навеска с конвертером не в состоянии переводить картинки быстро. Это кстати касается и стандартного tcp в режиме string. Пока происходит конвертация большая схема успевает накидать новую порцию на вход обоим в стринге и уже получаются задержки и кривые данные на выходе приема tcp обработать которые очень затруднительно или же не возможно. Да и звук сильно запаздывает на конверте. Приходится двумя вариантами tcp работать. Но хочется конечно полностью остаток схемы перевести на твой т.к гибкие возможности обработки ошибок даются которые исключают почти полностью все возможные ошибки работы с сетью. Если это допилить в компонент, можно смело выкидывать стандартный в среде.

На скорость работы компонентов влияет не только конвертация, а, например, скорость сети. Допустим, будет у тебя быстрая конвертация, все летает. А тут раз - и скорость сети немного просела, данные не успели отправиться, а уже новые идут. Что у тебя на этот случай в схеме предусмотрено?
А точно на конвертере, или на скорости сети? Звук и графику вообще-то компрессировать надо. Кроме того, у тебя для звука предусмотрен звуковой буфер - данные постоянно обновляются, те, которые не были вовремя прочитаны, пропадают - получаем пропуски в звуке. Такое же нужно на схеме, генерирующей графику: в некий буфер складываются целиком несколько картинок, по мере добавления новых старые удаляются. Отправляющая схема последовательно по мере отправки выбирает из буфера целую картинку и отправляет. Не успевает отправлять - получаем пропуск кадров. Тут удобно сделать какой-нибудь режим отправки, при котором данные для отправки постоянно запрашиваются с верхней точки. Стартуем отправку, данные начинают запрашиваться, пока отправка не будет остановлена.
------------ Дoбавленo в 13.03:
Вот как я себе это представляю:
Все блоки работают независимо/параллельно. Когда "битрейт сети" будет меньше "битрейта видео"+"битрейта звука" эта схема позволяет безпроблемно делать пропуск кадров и звука. Например, при временных просадках скорости.
Чтобы избежать пропуска, нужно:
- либо снимать данные со скоростью сети. Это тот же пропуск кадров/семплов, только на этапе получения звука/изображения
- либо понижать "битрейт" данных. Данные снимаются в реальном времени, но на основе высчитанной пропускной способности ("битрейта") сети применяется сжатие информации на нужный коэффициент (универсальное, типа zip; специальное, типа jpeg (+уменьшение разрешения кадра) и mp3 (+ уменьшение частоты дискретизаци))

Редактировалось 1 раз(а), последний 2018-11-12 12:22:12

........

пардон



пока реализовано прямо в tcp без доп. блок схем на случай просадки нет. 127 и локально 100 мегабит тестировал только.
ранее делал блок по отсечке подачи данных при потери связи но то показало не эффективность и для снижение нагрузки.


точно на конвертере. тесты локальные

согласен. да.


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

Чтобы нормально мониторить скорости приема и отправки (а ещё для каждого соединения в сервере), нужно придумывать что-то глобальное, типа отдельного компонента, который будет получать от сервера статистику (которую тот должен как-то вести).
Можно не ориентироваться на скорость сети, а наоборот, вычислить скорость генерации данных, и понизить её заведомо ниже скорости сети (применив сжатие, уменьшение размера/частоты кадров, частоты дискретизации звука).
Всё же, даже если есть конвертация, уверен, её скорость значительно быстрее, чем скорость сети. Там же нет никакой процессорной обработки, только выделение памяти и перемещение данных. А откуда у тебя данные поступают на отправку? Если компонент выдает в виде Stream - можно добавить свойство, указывающее выдавать в String.

Редактировалось 9 раз(а), последний 2022-09-20 00:13:59

[memorystream]

в нее jpeg пишется по качеству установленным юзером и далее через dodata на dosend tcp (stream)
ставя конвертер в string вместо dodata получаю уже на клиентской рваную картинку. т.е окно отображает кадр в половину забитый цветными квадратами на подобии скоро наворачивающейся видеокарты в компьютере. кол-во квадратов заполняющих картинку завсит от качество сжатия. судя по всему либо там скорость либо длина строки.
т.е как я не крутил с мемористрим картинку прогоняется только в стриме =(
с саундом попроще, там стринг проходит но клиент получает легкий треск (на стриме его нет) и далее со временем треск переходит в пропуски
и тоже стрим работает там хорошо ...
я не знаю механизма tcp, но лишние блоки конвертации уже переводят столь отвратную по кол-ву кадров картинку и звук в совсем не приемлемое зрелище..
увы...
даже если поиграться со звуком и проводить его строкой через 2-5 минут виден рассинхрон.
одним tcp вроде тоже пробовал слать но блоки позволяющие упихать в один поток чересчур грузили систему и в итоге периодические затыки самого exe с размораживанием сводили смысл на нет

схема твоя верна на 100% для реализации но куда не приткни конвертер начинается лажа.
т.е строку бы без него получать как-то... там бы можно было проверить. но как ее получать с компонента звука или memorystream без участия конвертера я не представляю

удалите кто-нибудь верхний пост. нефига не понимаю как это делается в форумном движке.

Так проблема не в конверторе! Просто режим Stream в стандартных TCP компонентах реализован простеньким протоколом: отправляется длина данных, а затем сами данные. На принимающей стороне ожидаются 4 байта длины, затем выделяется требуемая память, в которую и записываются все поступающие данные до получения указанного количества. После получения данные выдаются и опять происходит ожидание 4 байт длины следующих данных.
При передачи же String, данные другая сторона получает порциями. Поэтому у тебя битая картинка. На принимающей стороне нужно дожидаться получения полной картинки. А как это сделать? Точно так же: сначала отправляется размер картинки, затем сама картинка:

На принимающей стороне накапливаешь данные до <разделителя> - получаешь размер картинки. Продолжаешь накапливать до получения требуемого количества - получаешь картинку. Потом опять начинаешь накапливать до следующего разделителя. На компонентах это сделать сложно, для чего я сделал DataAccumulator. И даже давал тебе схему по отправке файлов [url]forum.html?q=3&p=276327[/url]. Вместо файла отправляешь строку после StreamToStr - и все.

------------ Дoбавленo в 18.01:
Вот, конкретный пример передачи скриншотов по сети: picture over tcp 2015-05-17.zip
1) Запускаете Picture server, жмете Start server, потом Start sending
2) Запускаете несколько Picture client, жмете Connect

Обновлено 17.05.2015

Используется DataAccumulator

Редактировалось 3 раз(а), последний 2018-04-02 10:55:48

Обновление компонентов

Следующие исправления в сервере:
- поправлена работа метода doSendAllAsync для учитывания свойства OverSend
- исправлена ошибка совместного доступа к данным методом doSendAllAsync

Выше выложены поправленные примеры отправки скриншотов по сети.

Netspirit, расскажите пожалуйста подробнее о:

// Время ожидания потоками отправки следующих данных
SEND_WAITING_TIME = 10000;

этот параметр отвечает за отправку данных в 1 из сокетов? т.е. если за 10 секунд данные не успели отправится, то сразу начнется отправка данных следующему сокету?

Нет, что-то подобное делает SendTimeout, только звучит как "если за время SendTimeout противоположная сторона не примет данных, выдать ошибку 10060 и продолжить отправлять данные следующему соединению".

SEND_WAITING_TIME определяет, сколько времени будет активным отправляющий поток, когда все данные всем соединениям были отправлены. По истечении указанного времени поток завершится и при следующей отправке будет создан заново. Если за это время поступила следующая команда отправки - поток начнет отправлять данные. То есть, смысл в том, чтобы не создавать/завершать поток при каждой отправке, на что требуются ресурсы.

Netspirit, Спасибо) столько плюшек!!!!

Netspirit, как с вами можно связаться? ЛС не отправляется..

Есть почта в профиле, но просматриваю нерегулярно.