- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
package com.company;
public class Main {
public static void main(String[] args) {
int answer = 0;
for (int i = 100; i < 1000; i++){
for (int j = 100; j < 1000; j++){
int result = i * j;
String str = String.valueOf(result); //convert
String revers = new StringBuffer(str).reverse().toString(); //revers
int newb = Integer.parseInt(revers); //convert
if (newb == result){
int answer001 = result;
if (answer001 > answer) answer = answer001;
}
}
}
System.out.println(answer);
}
}
Follow us!
Лучше уж напитонячить тогда: там это будет не так ужасно
Подтверждаю. Не отклоняясь от изначального алгоритма:
Видимо, внутренний линтер зависит от языка
Зачем? Зачем? В общем-то и в версии ОПа можно было остановиться на str == revers.
В общем, создавать буферы в цикле бы точно не хотелось
Именно поэтому я за пхп.
P.S. И ведь хрен ты придумаешь более красивое и наглядное решение.
Можно оптимизировать (например, прекращать вычисления, когда оба множителя меньше наименьшего из предыдущей найденной пары), но мне лень.
Побочные эффекты посреди выражений!? Бля, это серьёзно завезли в питон? ЗАЧЕМ? ЗАЧЕМ?
Подтверждаю.
Какой анскилл (((
Царская функция дробит числа, а как числодробилка нативный «Питон» работает до крайности хуёво.
На жабе троже
В 10 раз, в 10 блядь раз
С учётом прибавления и отнимания '0' и трёх аллокаций выглядит совсем неплохо. Я думал хуже будет.
Но в кучу анскильный вариант срёт знатно, конечно
Зацени
https://postimg.cc/xXQynRK5
Ненормально было бы если бы понимал.
Ты платишь фиксированную цену за запуск гц и обход стека каждые N мегабайт. Но мертвые объекты же недостижимы, их двигать не надо.
На мелких временных аллокациях джава в клочья сишку порвёт, имхо. Если сишник не будет читерить с переменными на стеке, конечно.
Хуета.
Полная хуета.
>Если сишник не будет читерить с переменными на стеке, конечно.
Царь даже без стека эту хуйню сольёт.
Если я хуйну SLAB-аллокацию или заранее выделю себе mmapом мегабайты памяти, как это делает Йажа, то она опять сольётся в хламину.
Йажа-сектанты часто пишут бенчи в стиле: Сишные malloc+free vs преаллоциорованный гиг памяти в Йажа, причём бенчмарк заканчивается ещё до первой сборки. См. -Xmx 1Gb
После чего делаются многозначительные выводы и пишутся статьи для хабархабра: «Придуман новый язык, быстрее чем Си».
Инты в ЙАЖЕ как раз хранятся на стеке, если их в коробки не завернули. В отличие от «Python», в котором каждая арифметическая операция — это создание нового объекта с соответствующим дёрганьем кучи. Собственно, почему он так и тормозит на царском алгоритме.
Есть, до 255-и, кажется. Или поменьше, не помню.
Нет, необходимости не было.
А ещё к «Питону» можно прикрутить «JIT»: https://numba.pydata.org/. Говорят, помогает.
В 8.7 раз быстрее максимально ускоренной анскильной (см. ниже) на первом запуске, в 43 раза быстрее на последующих.
Бамп отсосу «JavaScript»!
Вот тебе и преждевременная оптимизация.
Слайсы ебошит нативная сишка. А деления анскильный Питух.
Лалки обсирали jsую идиому str.split('').reverse().join('')
Однако же:
Я к тому что этот метод довольно долгое время был самым быстрым.
Похоже в браузерах пустые сплиты/джойны шли по отдельному оптимизированному пути.
Я вот думаю они и тут без перебора решили.
Я про софт, который у стримера стоит. Захват видео, кодирование, передача.
Типа хуета это всё?
Дык что его разрабатывать, он уже в опенсорсе есть: https://github.com/obsproject/obs-studio.
Какой высокотехнологичный стартап )))
> Нахуй плодить сущности?
- как будто ты не знаешь про nih
А это будет тяжелейшим выстрелом в ногу. Абсолютное большинство крупных стримеров (т.е. все те, кто приносят «Твичу» бабло) стримят не напрямую, а через что-то типа https://restream.io/ — штуковины, которая размножает поток на несколько платформ с опциональным добавлением всяких межплатформенных фишек. И работает это потому, что протоколы для стриминга открыты и стандартизованы.
Так что я бы скорее подумал, что им этот рестрим поперёк горла
Ну да, он у них зрителей отнимает. Но жёстко с ним бороться они не могут просто потому, что тогда от них уйдут стримеры, а это куда больнее.
- как говорится, если в жизни мало секса, иди понастраивай IPTV
*Клиент у «Твича», на самом деле, имеется, но он нужен только для просмотра каналов и сбора дополнительных данных пользователей.
Бууэээ. На курятнике писать энкодер для AV1. Твич поставил на rav1e.
https://github.com/xiph/rav1e
Который наглухо сливает всем сишноплюсовым (aom, SVT-AV1) конкурентам и по скорости и по зожатию.
При том что по времени они все начали писать их примерно одновременно.
Хотя я не уверен, возможно, и это тоже должно быть на компе сделано.
ИМХО, самое интересное там — это сетевая рахитектура, которая должна раскидывать гигантское количество трафика с минимальными задержками (2 секунды отставания от стримера, например).
Я могу ошибаться, но по-моему low-res потоки тоже на компе стримера создаются. Ща проверю.
> сетевая рахитектура
Я не думаю, что там прям что-то гениальное... Скорее всего обычное дерево с датацентром в каждом регионе.
А на задержку там всем похуй на самом деле, ну ответит тебе стример на 5 секунд позже, не помрёшь.
Для ~ реалтайма надо тащить вебсокет/вебртц
Стримить не через сервер вообще сложновато. Ты что, предлагаешь стримеру отправлять копию видеопотока десятку-другому тысяч зрителей напрямую?
Ну мы же сейчас не про скайп, а про раздачу потока тысячам зрителей. Никто в здравом уме там не будет напрямую коннектица, у стримера комп и без этого перегружен.
Х.з., исторически сложилось. Там же "протокол" у этих DASH и HLS - это тупо плейлист из чанков. Можешь закинуть их на сервер статикой и смотреть. Можешь в реалтайме отдавать.
Ну если ты готов терпеть постоянно рассыпающийся видеопоток ради снижения задержки на десяток-другой секунд…
А, пацаны. Это хуйня всё. Вы не шарите. Эти проблемы давным-давно решены несколькими различными способами.
Почитайте про intra-refresh. Он волной макроблоки обновляет. Был ещё в x264.
Periodic Intra Refresh instead of keyframes, which enables each frame to be capped to the same size enabling each slice to be immediately transmitted in a single UDP or TCP packet and on arrival immediately decoded.
Periodic Intra Refresh can replace keyframes by using a column of intra blocks that move across the video from one side to the other, thereby "refreshing" the image. In effect, instead of a big keyframe, the keyframe is "spread" over many frames. The video is still seekable: a special header, called the SEI Recovery Point, tells the decoder to "start here, decode X frames, and then start displaying the video." This hides the refresh effect from the user while the frame loads. Motion vectors are restricted so that blocks on one side of the refresh column don't reference blocks on the other side, effectively creating a demarcation line in each frame.
Может пара кадров проебаться, но буфер весьма быстро восстановится.
Вертикальная полоска за 5-10 кадров сделает полный self-refresh. И не надо ждать I-frame.
Ценой этого чуть более низкое зожатие.
Смысл в том, что в P-кадре или B-кадре могут быть I-блоки, которые ни от чего не зависят.
Потому что так потери пакетов работают. У тебя просто постоянно теряется N процентов пакетов.
> У меня помеха пошла по docsis на N ms.
При чём тут «DOCSIS»-то? Мы про «Ethernet» говорим.
> а в TCP я тупо отстал навсегда, хоть и не потерял кадр
Да, при этом чем больше отставание — тем меньше вероятности, что следующие потери истощат буфер.
> Оно того стоит?
В массовом сегменте — да.
Совершенно да.
> Если у меня временные проблемы, то почему они должны быть всегда?
Это не временные трудности, это постоянные проблемы. В обычном интернете у тебя всегда теряется какая-то часть пакетов, иногда больше, иногда меньше.
> Интернету же пофиг, поврех чего работать.
Интернету пофиг, но сейчас он работает поверх «Ethernet» и оптики. Или ты предлагаешь все кабели в Интернете поменять?
> если мне нормально отстать на три секунды, но при этом НЕ потерять ни одного видеокадра
Да. Смотреть видео с постоянными перерывами — это пиздец как раздражает, пользователи этим заниматься не будут.
А может быть и не временным. Заранее ты не угадаешь. Но один артефакт/буферинг зритель потерпит. На втором начнёт плеваться и уйдёт на другой сервис у которого с задержкой но стабильно.
И ты не объяснишь человеку, что это его личная проблема с интернетом. Другие сервисы же нормально идут, лол.
В своё время ЮТуб был диким тормозом, но народ на какой-нибудь Vimeo массово не побежал.
Вопрос в контенте и позиционировании. А стандарты качества у массового пользователя упали, к сожалению
Для любования на квадраты через «UDP» тебе не нужна потеря половины пакетов, тебе достаточно терять сотые/тысячные доли процента. А это — вполне нормальный режим работы Интернета.
Особенно если рядом торрент качается, лол.
Собственно на 10% я уже позвонил провайдеру.
То, потери пакетов в обычном режиме очень небольшие, сотая доля процентов, например. Простым пингом на четыре пакеты ты их, разумеется, не увидишь.
Типичный стрим — это постоянный видеопоток примерно на 5 мегабайт в секунду полезных данных (40 мегабит). Путём несложных грубых вычислений можно убедиться, что 5 мегабайт в секунду с MSS 1400 — это как минимум 5* 1024**2 // 1400 = 3744 IP-пакета в секунду. То есть, если у тебя теряется 0.003% (три тысячных доли процента) пакетов, то наблюдать квадратики ты будешь раз в десять секунд. Через «TCP», в свою очередь, ты таких потерь в принципе не заметишь.
> Да ну? А поверх 11n он не работает, когда ты внутри ESS переключился на другую станцию, и в этот момент проебал пакет?
Я вообще-то про магистрали, но да ладно, похуй.
Ну что ж такое, мы же это уже выяснили.
>>> Таким образом, я сосу болта до следующего ключевого кадра, верно?
Ты будешь смотреть на квадратики по одной-двум секундам раз в десять секунд (я — на квадратики по одной-двум секундам раз в пол-секунды, ага).
> Разве пользователь сидит не дома?
Потому что пакеты теряются далеко не только на линии между пользователем и оборудованием провайдера. Они теряются на всём пути от сервера «Твича» и до компьютера пользователя.
Не выезжая из Москвы
Это означает, что пользователь будет смотреть на чёрный квадрат/месиво из квадратиков. Не заметить такое можно только когда ты отвернулся от экрана.
P. S. Минус нечаянно въебал, извини.
Два потерянных пакета на 6293 посланных. То есть, в примере с пятимегабайтным потоком, я буду наблюдать квадратики примерно два раза в секунду.
(Тут я минуту держал вместо пяти)
Ну можно ещё килобатными пакетами попинговать для большего приближения к реальности, ну да это неважно.
> Проеблось 3 пакета из 38164
То есть примерно каждые три секунды ты будешь наблюдать квадратики. Именно для этого и нужен «TCP».
Зависит от кодека, но никак не меньше нескольких (возможно, десятков) кадров. Повторюсь, не заметить такое сложно.
> Надо еще учитывать, что ya.ru это не видеохостинг, и отвечать мне на ping они вообще не обязаны.
Для любых других серверов картина ничуть не лучше. Постоянная небольшая потеря пакетов — это зло, от которого избавиться в принципе невозможно. Ну, разве что провести оптику от твоего компа к серверу «Твича».
Кстати, я совершенно забыл упомянуть, что порядок прихода пакетов в «UDP» не гарантирован. Поэтому для передачи видео по «UDP» тебе в любом случае придётся реализовывать подмножество «TCP» с сегментами и их буфером.
> TCP более предпочтителен: он забуферизирует данные, сделав процесс smooth для пользователя: он будет перепосылать сегменты, пока пользователь смотрит видео.
На самом деле не совсем. Существует два буфера: системного уровня, который заполняется ядром (драйвером TCP/IP), и буфер браузера. В первом хранятся сегменты TCP, во второй браузер складывает кадры видео.
«TCP» гарантирует, что последовательность байт, отправленная с сервера, обязательно дойдёт до клиента без изменений и в правильном порядке (что тоже крайне важно, кстати). Буферизация видео браузером, в свою очередь, обеспечивает пользователю плавное воспроизведение даже тогда, когда приход очередной порции байт с сервера задерживается (драйвером TCP/IP) из-за потерь пакетов.
> Однако, TCP это бОльшая нагрузка на CPU.
По сравнению с декодированием 60@FHD видео — это настолько мелкие копейки, что ими нужно пренебречь.
> Итого: если мы уверены в более-ли-менее качественном интернет-соединении, то имеет смысл использовать UDP.
Да, но такое будет только если сервер и клиент соединены напрямую одним кабелем. И даже в этом случае пользователь может поставить качаться торрент и получить багор.
Увы, Интернет — крайне непредсказуемое говно, поэтому получить по-настоящему надёжное соединение до удалённого сервера, к сожалению, невозможно. Возвращаясь к примеру выше, чтобы надёжно передавать видеопоток через «UDP» и получать квадраты хотя бы не чаще раза в минуту, нужно терять не больше одного пакета из 224640.
Настолько мизерные крохи ресурсов, что ими можно и нужно пренебречь. Там одно только TLS-шифрование потока сожрёт на два порядка больше ресурсов, чем обработка «TCP».
> Тогда почему у меня нормально работает IPTV по мультикасту от провайдера?
Нужно смотреть протокол и кодирование. Я же не говорю, что по «UDP» в принципе нельзя передать видео, я говорю о том, что это очень сложно и геморройно. Можно жать кадры по отдельности, тогда небольшая потеря пакетов действительно не будет заметна. Можно впендюрить десяток-другой процентов избыточности. Ещё как-нибудь извратиться.
Спокойной ночи.
Там такая дикая зависимость между кадрами, что всё на квадратики рассыпется до следующего ключевого. Не особо лучше чёрного экрана.
Тем, что «buffering» тебе покажется один раз. Потом буфер разработается и никакой буферизации у тебя не будет.
извините, я не смог не
> ты проебал пакет, и получит передачу всего говна
Что? Какого говна?
Не совсем правда.
Можно удачно проебать B-frame, на который никто не ссылается.
Можно проебать P-frame, но на следующем обновить.
Кодеки очень адаптивные и резистетные к ошибкам на самом деле.
Очень сильно зависит от настроек адаптивности энтропии и кодека.
Не, на него хуй забьют. buffering будет пока буфер не наполнится на безопасную для твоего канала глубину.
Нет. Потеряться может только IP-фрейм (1500 байт брутто). В таком случае «TCP» просто передаст этот фрейм ещё раз.
> Рассмотрим ситуацю, когда ты потерял НЕ ключевой кадр.
> В UDP ты этого не заметишь
Нет, не так. Если я потерял НЕ ключевой кадр, то у меня ВСЕ последующие НЕ-ключевые кадры превратятся в квадратики. То есть, в зависимости от кодека, я буду эдак секунду-другую (точное время надо у кодировочных петухов спрашивать) смотреть на квадраты.
> в TCP ты будешь вынужден смотреть на "buffering", пока ты не переполучишь кусок с потерянным кадром, нет?
Нет, см. первый абзац.
Перепутал с «Ethernet».
> TCP передаст сегмент целиком, не?
Да. При этом сегменты запихиваются в IP-пакеты, поэтому один сегмент — это не больше 1500 байт. См. «MSS».
> Разве не ключевой кадр это не diff к предыдущему ключевому?
Ключевой кадр — это, грубо говоря, просто пожатая стандартными алгоритмами картинка, JPEG. Диффы последующих не-ключевых кадров считаются от него. То есть (опять же, очень грубо говоря, видеопетухи поправят) тебе передаётся (key_frame, data_1, data_2, ...); frame_1 = diff(key_frame, data_1), frame_2 = diff(frame_1, data_2), frame_3 = diff(frame_2, data_3), etc. Каждый последующий не-ключевой кадр зависит от предыдущего, как в «AES CBC».
Да.
> я или смотрю на квадратики до следующего ключ кадра, или смотрю на "buffering"
Нет. Ключевая разница в том, что в «TCP» ты смотришь на «buffering» один раз, после чего буфер у тебя разрабатывается, и дальше ты видишь только плавную картинку без единого разрыва.
> то ключевой кадр может быть размазан на несколько пакетов
Не знаю, не видел этой технологии.
Т.е. если у тебя буфер 10 секунд, то у тебя есть почти 10 секунд на загрузку каждого чанка. Ну и собственно отстаёшь от реалтайма ты на эти самые 10 секунд. TCP за это время без проблем успевает всё перепослать и переполучить.
Ну а если канал пиздец хуёвый и не успевает - значит будешь жить с буфером в 20 секунд. Хотя обычно после такого просто качество скидывают.
Ты качаешь по хттп плейлист и по хттп начинаешь качать чанки. Понимая, что плейлист - активный стрим, ты перезапрашиваешь плейлист раз в эн секунд, чтобы узнать о новых свежих чанках, которые тоже будешь сливать с сервера по хттп.
Плеер твой может догадаться, или ты сам, о том, что твой канал говно, он не успевает вовремя качать, все тормозит и дёргается - есть возможность переключиться на качество похуже (чанки будут за те же промежутки времени, но по размеру меньше заметно).
Вот в этой схеме задержку менее 15 секунд практически нереально получить (потому что чанк должен быть не на 1 секунду), а оптимально - 60 секунд.
Когда ты смотришь футбол онлайн, это норм, когда смотришь куранты с путиным на новый год - это тоже приемлемо.
А вот для диалога - нет.
Впрочем, для этих целей наверняка лучше использовать вменяемые текстовые трансляции.
Интересно, какая задержка при ТВ-трансляции
если спутник
Да. И это гнусно что HLS кругом.
Впрочем на твиче лайф-стримы. Для них это как раз вполне нормально.
И они их могут ворецировать как пожелают, адаптивно меняя качество под скорость канала пользователя.
> Чтобы можно было быстро переключаться на хуёвое качество и обратно.
Это называется SVC.
Хз как на твитче. Но вряд ли. Т.к. в я не видел толковых реализаций в промышленных энкодерах.
>Чтобы можно было быстро переключаться на хуёвое качество и обратно.
Одно я знаю наверняка. Твитчовцы (и это их заслуга) для этих целей пролоббировали в AV1 совершенно потрясную штуку.
Называется S-frames.
https://www.youtube.com/watch?v=o5sJX6VA34o
https://thebroadcastknowledge.com/2020/04/15/video-s-frame-in-av1-enabling-better-compression-for-low-latency-live-streaming/
Да нет, они в последнее время серьёзно за её уменьшением гонятся (как и «Ютуб», кстати). Две секунды задержки от компьютера стримера — это реальный пример.
Ффмпег ебаный это уже секунда, даже если ты такой охуевший и в полуреальном времени срешь на клиенты по вебсокету (а не мпег-даш/хлс), 2 секунды и массовость звучат фантастично
(И главное, зачем? Что плохого в задержке, например, 30с?)
Я прост далёк от блогиров, но тема интернет вещания регулярно возвращается в контекст
Не знаю, я на «Твиче» специализируюсь. Реальный пример: https://i.imgur.com/DGN5EK0.png.
Правда, меня смущает размер буфера: если буфер 2.06 секунд, а задержка — 2.09, получается, мне от стримера кадры приходят за 30 миллисекунд?..
Наверное, «Твич» всё таки запутался в терминах, и реальная задержка (отставание часов на экране стрима от моих локальных) там 4.15 секунды.
> И главное, зачем? Что плохого в задержке, например, 30с?
Ну типа мгновенная реакция на чат, все дела.
Диалог в конфе овер, скажем, 50, вести сложновато.
Ну разве что в твиче модный блогир типа тоже диалог ведёт, с текстовым чатом. Ясно
Подтверждаю. Интерактивность.
Сорянчик, что вмешиваюсь в экспертную беседу со своим профанизмом.
https://youtu.be/LsF5bHRxC_M?t=234
В принципе там довольно подробное описание работы твитча.
Да. И Экселя не знает. Ну его нахуй.
https://govnokod.ru/25131
А там такое:
CDF — энтропийное кодирование.
За сим иду спать. Доброй ночи.
1. Взять ffmpeg+x264 зожать.
2. Пропустить через какой-нибудь tc с заданным дропом.
3. Воспроизвести полученный файл ffplay.
только man tc-netem вроде)
Если видео записано заранее, то лучше всего взять Adaptive bit rate, когда сервер разбивает всё на кусочки, а клиент выбирает следующий чанк нужного размера.
Если клиент сидит на iPhone через сотовую сеть, то он выберет кусочек с худшим качеством (и худшего размера)
А если у него телек на пол стены по гигабиту, то может позволить себе чанк по лучше
Все эти проты работают по TCP, и это понятно: клиент может накачать себе чанков за щеку, как хомяк, и их показывать.
А если видео стримается в реальном времени? Если это видеокамера с улицы?
Я не смогу наполнять буфер быстрее, чем я его опустошаю, какой же тут толк от TCP по сравнению с UDP?
Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Можно конечно забуферизировать данные, и показывать камеру с отставанием, но если это видеозвонок или прямой эфир, и туда можно звонить? Тогда отставать мне нельзя.
А зачем? Ты открываешь стрим, браузер закачивает две секунды стрима и начинает тебе его показывать, параллельно закачивая следующие две секунды потока. В «UDP» будет то же самое: тебе так же надо организовать буфер в несколько секунд видеопотока, чтобы, во-первых, восстановить порядок UDP-пакетов (они к тебе придут перемешанные), а во-вторых — не раздражать пользователя из-за флуктуаций пинга (видео, в котором каждый кадр показывается с задержкой +- пару миллисекунд от номинальной будет выглядеть очень… своеобразно).
> Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Только в том случае, если у тебя теряется порядка процента и больше пакетов, и то только ОДИН РАЗ. После этого одного раза буфер разработается и buffering не будет, за счёт увеличения задержки.
Помню, как на стороне заказчика юные телекомщики с восторгом рассказывали, как они поменяли с TCP на UDP и всё полетело.
Думал, что в видеостриминге в принципе это норма, но вы меня переубедили.
OpenVPN может по udp, чтобы не делать накладных расходов
Точно, про него забыл. В «OpenVPN» запилен свой протокол, обеспечивающий надёжность передачи данных, поэтому гонять его по «TCP» — практически бессмысленное занятие.
А зачем VPN надежность? Интернет же ненадежен, и поверх него работают другие проты. VPN вполне себе может эмулировать такой вот ненадежный Интернет
Да, и про это забыл. Пускаем «VPN» на 443-й порт и течём.
> А зачем VPN надежность?
Надо читать протокол. Могу предположить, что он у них завязан на последовательное получение сегментов (типа «AES CBC»), тогда любая потеря пакета приведёт к разрыву соединения.
>восстановить порядок UDP-пакетов
Пришедший в неверном порядке пакет можно же просто отбросить?
Если браузер всё равно имеет свой буфер, то зачем мне еще и буфер tcp?
>После этого одного раза буфер разработается и buffering не будет, за счёт увеличения задержки.
А как это всё будет работать с прямым эфиром или видеозвонком?
Да.
> Пришедший в неверном порядке пакет можно же просто отбросить?
Можно. Тогда у тебя останется примерно половина пакетов, может даже меньше.
> Если браузер всё равно имеет свой буфер, то зачем мне еще и буфер tcp?
Потому что это два разных буфера с разными функциями. Буфер «TCP» нужен для восстановления исходного потока байт с сервера, буфер браузера — для обеспечения плавного воспроизведения видео без прерываний.
> А как это всё будет работать с прямым эфиром или видеозвонком?
Для прямого эфира это совершенно непринципиально (так, например, многие играющие в онлайн-игры стримеры специально выставляют задержку в одну-две минуты, чтобы противники не могли подсмотреть стрим и получить преимущество). Для видеозвонков используются либо более мелкие буфера, либо какие-то формы избыточности (возможно, в связке с «UDP», надо смотреть протоколы).
А есть какая-то статистика на этот счет?
>Потому что это два разных буфера с разными функциями.
То-есть TCP нам нужен исключительно для восстановления порядка?
>для видеозвонков
Ну вот skype используе UDP
https://support.skype.com/en/faq/FA148/which-ports-need-to-be-open-to-use-skype-on-desktop
Если ты утверждаешь, что половина пакетов у меня потеряется или придет в неверном порядке, то как же эту проблему решает скайп?
Сам восстнавливает порядок пакетов?
Проблема не столько в порядке, сколько в джиттере - задержку постоянно "трясёт". Поэтому точно так же поток приходит кусками и какое-то время отстаивается в буфере.
Так буфер у них свой, выполнящий и буферизацию, и восстановление порядка, итд, а сами они по udp?
Большой оверхед для такого мелкого буфера?
А если большая задержка допустима, то мы уже можем реализовать повторы. И здесь, чтобы не изобретать велосипед, можно взять TCP.
Нет, только эмпирические наблюдения за «tcpdump».
> То-есть TCP нам нужен исключительно для восстановления порядка?
Для восстановления порядка и восстановления потерянных пакетов.
> то как же эту проблему решает скайп?
Изобретением своего велосипеда. Поверх «UDP» написан охулиард протоколов разной степени надёжности, в той или иной мере копирующих «TCP». См. «RDP», «RUDP», «ENet», «GameNetworkingSockets», тысячи их.
Надо бы проверить. Почему половина пакетов идет в другм порядке? Потому что разными путями идут?
RDP работает и поверх UDP и поверх TCP, кстати
Когда хорошее подключение, он мигрирует на UDP))
Вопрос: почему же WebRTC, Skype, RTP и пр не использовали tcp?
> RTP
>>> В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.
Здравствуйте, мы изобрели «TCP».
> WebRTC
>>> Finally, a special error-concealment algorithm is used to hide the negative effects of network jitter and packet loss
Здравствуйте, мы изобрели «TCP».
> Skype
>>> The Skype team anticipated some jitter and packet loss, and therefore have algorithms that can deal with these problems.
Здравствуйте, мы изобрели «TCP».
https://www.gsx.com/resources/blog/udp-vs-tcp-what-is-really-best-for-skype-for-business-voice/
Ну и ещё есть «NIH».
>>> Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
Иногда и от последующих, лол.
но посмотри уже наконец, пожалуйста, как пишется "то есть", а то кровь из глаз
A dynamic jitter buffer and error concealment algorithm used for concealing the negative effects of network jitter and packet loss. Keeps latency as low as possible while maintaining the highest voice quality.
Но у меня нет соблазна сравнивать это с TCP
Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
Зачем им изобретать TCP, пусть даже оптимизированный, как ты говоришь, если TCP уже есть? Это оверинжениринг
Ну так это и есть изобретение велосипеда. В данном случае, конечно, оправданное: велосипед у них получился специализированный и более подходящий для решения их задачи, вот такой: https://www.youtube.com/watch?v=PIoUKPeWVjQ.
Интересно, Борманд так и не заинтересовался Твитчем и видеостримингом после этих всех бесед? По-моему, такое широкое минное поле для байтоёба!)
Стрим с камеры, задержка ~30 секунд