Здравствуйте, Farsight, Вы писали:
F>c 2022 как минимум 3.1 core должна идти, если мне память не изменяет, или даже 5.0. А 6.0, по идее, должна была долететь с апдейтами.
Возможно, так и было. Просто я с C# уже лет десять как не работаю и не обратил внимания, что теперь есть два разных типа консольных проектов — один мультиплатформенный, другой чисто под винду. И в этих проектах предлагается разный набор фреймворков — под винду максимальный 4.8, а в мультиплатформенном есть и 5.0, и 6.0. Только я это увидел уже после того, как поставил 6.0 руками. Вполне возможно, что он был и до этого.
--
Re[5]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C>?>Сравнивают юникод (utf8) с юникодом (utf16). То, что C# не умеет в эффективные строки — это его проблема, никто не обязан специально ухудшать C++-код из-за этого. C>Исходные данные — текст, в котором есть как числа, так и строки. Так что писать/читать файл как юникод — единственный разумный вариант. Ну а если тебе хочется сначала перекодировать числа в анси, то вперед и с песней.
Если исходные данные текст, то откуда у вас строки с цифрами для конвертации в числа? Зачем промежуточное копирование с выделением памяти? В C++ для таких ситуаций следует использовать std::basic_string_view, раз скорость важна.
И каждый день — без права на ошибку...
Re[6]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, B0FEE664, Вы писали:
BFE>Если исходные данные текст, то откуда у вас строки с цифрами для конвертации в числа? Зачем промежуточное копирование с выделением памяти? В C++ для таких ситуаций следует использовать std::basic_string_view, раз скорость важна.
Вообще да, но руки не дошли.
Ад пуст, все бесы здесь.
Re[7]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, reversecode, Вы писали:
R>>печаль, я думал вы собаку съедите и свою имплементацию напишите после ваших громких заявлений R>>о том что вы и mp4 сами можете собрать разобрать и rtp нужные нарезать и dash перемолотить
V>Собака оказалась не вкусной и меня постигло разочарование. Поле изучения оказалось, что WebRTC это никакой не протокол и не стандарт, а прибитая гвоздями на коленке композиция уже известных технологий, где всё зависит друг от друга, шаг влево, шаг в право — расстрел, которую Google создал под свои конкретные нужды. Кстати, это повсеместная тенденция, которая сильно расстраивает. Теперь понятно почему всякие openwebrtc загибаются и загнивают — просто невозможно оперативно копировать работу, по сути, внутренностей Chrome который их меняет так, как ему заблагорассудится.
знаю много webrtc имплементации на разных языках
но видимо openwebrtc совсем древняя
по факту libwebrtc гугловский пользуют только всякие стартапы или android/apple формощлепищики
для бекенд серверов пишут свои имплементации
и да там не так уж и сложно
весь зоопарк там не нужен
R>>все свелось к банальному подключению гугловского libwebrtc
V>Ну собрать под студию, что бы были все PDB, были подключены все нужные либы внутри, уже не легкая задача. Сигнальный сервер свой пришлось делать, Web сокеты свои, разбираться во всякими mDNS, SDP, свой энкодер писать и подключать — это не мало. Заодно посмотрел как внутри устроен хвалёный Chrome, какое там наслоение копролитов, работы с голыми указателями, мешанина стилей оформления и разных подходов к передаче ссылок на объекты
sdp итд енкодеры это вообще мизер
самый цимес как раз в протокольной части
Re[5]: [performance] чего-то я не понимаю в этой жизни
V>WebRTC же был в прошлом году разобран и реализован. Пришлось собирать половину хрома (webrtc.lib) под MSVC для возможности дебага и добавления своих реализаций кодеков и отладки всего этого дела. Ты говорил что ICE сервер обязательно нужен для работы в локальной сети, а он не нужен абсолютно, всё и так работает. В общем грузанул ты меня кучей ненужных деталей, а конкретики не дал никакой, вот я и обиделся и не стал дальше продолжать тему
я конечно не любитель искать что я там говорил
но если это как то и было в моих словах то видимо я устал либо все же вы не так поняли
ice сервера не бывает
насколько я помню я точно говорил о том что есть последовательность до поднятие srtp потока
и без этапа ice/stun->dtsl->srtp ее не обойти
хотя вроде был какойто спец флаг а гуглхроме при котором можно было поднять сессию без srtp
т.е. ice/stun->rtp
но то ли ее выпилили то ли мало кто знает
в остальном если клиент виден сервер напрямую в одной сети, то сервер уже будет выполнять роль stun/ice и доп stun сервер не нужен
Re[16]: [performance] чего-то я не понимаю в этой жизни
Да это я виноват — повелся на демагогию "яблоки-апельсины". На самом деле, не было никакого резона скатываться на использование std::wstring. То, что в C# нет типа, равноценного std::string — это проблема C#.
Здравствуйте, rg45, Вы писали:
r> R>https://quick-bench.com/q/BkthbLzUkWA0ks41YKBknGR9U7Y r> R>а то вы сильно углубились во все кастомное
r> Да это я виноват — повелся на демагогию "яблоки-апельсины". На самом деле, не было никакого резона скатываться на использование std::wstring. То, что в C# нет типа, равноценного std::string — это проблема C#.
А то, что плюсы не вывозят при использовании wstring это проблемы плюсов
Здравствуйте, rudzuk, Вы писали:
R>А то, что плюсы не вывозят при использовании wstring это проблемы плюсов
И я еще хотел бы отметить одну деталь — то падение производительности, которое мы видели на этом примере, обусловлено не собственно языком С++, а реализацией типа wstring в стандартной библиотеке (неоптимальные аллокаторы, чувствительные ограничения по использованию SSO). Что лишний раз указывает на то, что wstring просто нафиг не нужна.
sdp итд енкодеры это вообще мизер
