Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
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);
}
}
Хочется сделать массив в памяти, разбить число на цифры с помощью оператора % 1[многонолей], заполнить этот массив, потом собрать число обратно с помощью умножения и сложения, и таким образом его перевернуть?
def reverse_num(x):
x_reverse = 0
while x > 0:
x_reverse *= 10
x_reverse += x % 10
x //= 10
return x_reverse
def mults(start, end, step):
for i in range(start, end, step):
for j in range(i, end, step):
if (x := i*j) == reverse_num(x):
yield x
max(mults(999, 99, -1)) # 906609 == 913*993
Можно оптимизировать (например, прекращать вычисления, когда оба множителя меньше наименьшего из предыдущей найденной пары), но мне лень.
Сложно объяснить. У меня даже и мысли бы не родилось переворачивать число через строку, тем более на джаве, где есть нормальный int, а ты бы так и написал?
def reverse_num_tsar(x):
x_reverse = 0
while x > 0:
x_reverse *= 10
x_reverse += x % 10
x //= 10
return x_reverse
def reverse_num_unskill(x):
return int(str(x)[::-1])
def mults_tsar(start, end, step):
for i in range(start, end, step):
for j in range(i, end, step):
if (x := i*j) == reverse_num_tsar(x):
yield x
def mults_unskill(start, end, step):
for i in range(start, end, step):
for j in range(i, end, step):
if (x := i*j) == reverse_num_unskill(x):
yield x
print(timeit.timeit('max(mults_tsar(999, 99, -1))', globals=globals(), number=10)) # 3.716285999980755 секунд
print(timeit.timeit('max(mults_unskill(999, 99, -1))', globals=globals(), number=10)) # 1.8206677000271156 секунд
public class Main {
public static void main(String[] args) {
int answer = 0;
long now = System.currentTimeMillis();
for (int i = 100; i < 1000; i++) {
for (int j = 100; j < 1000; j++) {
int result = i * j;
int newb = reverseLikeTsar(result);
// Use reverseLikeUnskilledPetuz to test ptih
if (newb == result) {
int answer001 = result;
if (answer001 > answer) answer = answer001;
}
}
}
System.out.println(answer);
System.out.println(System.currentTimeMillis() - now); //unskilled: 120, tsar: 17
}
private static int reverseLikeUnskilledPetuz(int toReverse) {
String str = String.valueOf(toReverse); //convert
String revers = new StringBuffer(str).reverse().toString(); //revers
return Integer.parseInt(revers);
}
private static int reverseLikeTsar(int toReverse) {
int result = 0;
while (toReverse > 0) {
result *= 10;
result += toReverse % 10;
toReverse /= 10;
}
return result;
}
}
Да не будут они дороже. Эти буфера очень мало живут, их в последующие поколения даже не копируют. Поэтому хоть аллокаций и дохуя но они шустрые, по сути за О(1).
Во-первых не бесплатные, если там финалайзер (почти никогда нет его, конечно)
Во-вторых под платностью я имел ввиду сам запуск GC.
Например, с малюсеньким xmx на этом коде я получаю просед перформанса для анскильной версии
Вот тут видно, что даже минорный GC что-то стоит (хотя смешно конечно про это говорить про такие числа в йажа).
Но может быть у меня просто GC хреновый (запускал на дефолтном на восьмере, надо у шипилёши почитать про виды GC и освежить) https://postimg.cc/G8Z8mLsY
> На мелких временных аллокациях джава в клочья сишку порвёт, имхо.
Хуета.
Полная хуета.
>Если сишник не будет читерить с переменными на стеке, конечно.
Царь даже без стека эту хуйню сольёт.
Если я хуйну SLAB-аллокацию или заранее выделю себе mmapом мегабайты памяти, как это делает Йажа, то она опять сольётся в хламину.
Йажа-сектанты часто пишут бенчи в стиле: Сишные malloc+free vs преаллоциорованный гиг памяти в Йажа, причём бенчмарк заканчивается ещё до первой сборки. См. -Xmx 1Gb
После чего делаются многозначительные выводы и пишутся статьи для хабархабра: «Придуман новый язык, быстрее чем Си».
Полагаю, Броманд имел ввиду, что аллокация в джаве бесплатна (потому что ты просто берешь следующий кусок уже выделенной памяти, и не думаешь про фрагментацию), а работа minor gc не такая уж и долгая.
Это может оказаться реально быстрее, чем вручную делать malloc сишного рантайма (запрашивая у ОС память) и возвращать ее обратно через free.
>Царь даже без стека эту хуйню сольёт.
куууик (кинул какашку в JVM: в .NET можно хранить объекты на стеке, а в JVM -- нет, если только JIT не намутит).
>Если я хуйну SLAB-аллокацию
Это когда ты заранее выделяешь массив в памяти, где каждая ячейка размером с объект, и потом сам его заполняешь?
>или заранее выделю себе mmapом мегабайты памяти
Ну да, в обоих случаях ты откажешься от услуг менеджера памяти, и возьмешь это на себя, как и делает джава.
Видал багры людей, которые запускают простое приложение, и ноют, что оно занимает 8 гигов.
А там на самом деле xms такой.
>Йажа-сектанты часто пишут бенчи
Ну это конечно на совсем лоха должно быть расчитано:)
Это как я возьму кредит у банка, и скажу "я миллионер", а как его отдавать не покажу
> в .NET можно хранить объекты на стеке, а в JVM -- нет
Инты в ЙАЖЕ как раз хранятся на стеке, если их в коробки не завернули. В отличие от «Python», в котором каждая арифметическая операция — это создание нового объекта с соответствующим дёрганьем кучи. Собственно, почему он так и тормозит на царском алгоритме.
Ну да, какой в «Питоне» перформанс? Стандартный способ борьбы с тормозами в «Питоне»: либо выкинуть «Питон» и всё перевести на сишку, либо перевести на сишку только тормозящий мудуль.
from numba import jit
@jit(nopython=True)
def mults(start, end, step):
min_i = min(start, end)
for i in range(start, end, step):
if i < min_i:
return
for j in range(i, end, step):
x = i * j
x_orig = x
x_reverse = 0
while x > 0:
x_reverse *= 10
x_reverse += x % 10
x //= 10
if x_orig == x_reverse:
min_i = max(min_i, j)
yield x_orig
break
print(timeit.timeit('max(mults(999, 99, -1))', globals=globals(), number=100))
# 0.1662201 секунд первый запуск, 0.0333973 последующие
В 8.7 раз быстрее максимально ускоренной анскильной (см. ниже) на первом запуске, в 43 раза быстрее на последующих.
def mults(start, end, step):
for i in range(start, end, step):
for j in range(i, end, step):
x = i * j
x_str = str(x)
if x_str == x_str[::-1]:
yield x
break
print(timeit.timeit('max(mults(999, 99, -1))', globals=globals(), number=10)) # 0.8841240999754518 секунд
def mults(start, end, step):
min_i = min(start, end)
for i in range(start, end, step):
if i < min_i:
return
for j in range(i, end, step):
x = i * j
x_str = str(x)
if x_str == x_str[::-1]:
# Нашли очередной палиндром x = i * j;
# Палиндромы с i меньше текущего j проверять не имеет смысла:
# они гарантированно меньше найденного
min_i = max(min_i, j)
yield x
break
# N.B.: в 10 раз больше, чем в предыдущих вореантах
print(timeit.timeit('max(mults(999, 99, -1))', globals=globals(), number=100)) # 1.45771029999014 секунд
А с делениями тоже все под вопросом. У питона же бигнумы. И сишный конвертер бигнума в строку всяко шустрее чем отдельные деления на бигнумах. Даже с житом.
На самом деле, я на эйлере часто закидывал наивное говно просто чтобы почитать как другие чуваки применяют какой-нибудь гениальный матан и решают за О(1).
Генеришь 5-6 значные палиндромы, их меньше тысячи, факторизуешь их начиная с самого большого и смотришь можно ли склеить множители в группы меньше 1000.
Эм, а зачем им свой клиент? Есть платный xsplit, есть бесплатный obs. Можешь ими хоть на твич, хоть на ютуб хоть в порночатики стримить. Нахуй плодить сущности?
> - как будто ты не знаешь про nih
А это будет тяжелейшим выстрелом в ногу. Абсолютное большинство крупных стримеров (т.е. все те, кто приносят «Твичу» бабло) стримят не напрямую, а через что-то типа https://restream.io/ — штуковины, которая размножает поток на несколько платформ с опциональным добавлением всяких межплатформенных фишек. И работает это потому, что протоколы для стриминга открыты и стандартизованы.
> Так что я бы скорее подумал, что им этот рестрим поперёк горла
Ну да, он у них зрителей отнимает. Но жёстко с ним бороться они не могут просто потому, что тогда от них уйдут стримеры, а это куда больнее.
Ну конкретно в моем случае провайдер стримал IPTV мультикастом, и давал плейлист с адресами, так что VLC работал, если воткнуться напрямую.
Для локалки пришлось подымать IGMP Proxy на роутере (чтобы запросы о вступлении в группу приходили к провайдеру), а далее выяснилось, что телевизор может только unicast, и пришлось ставить на роутере udpxy, который мультикаст преобразует в unicast.
Но тем не менее, всё завелось)
Это сподвигло меня прочитать главу про multicast на хабре в туториале "сети для самых маленьких": так я узнал про PIM, рандеву поинт, и про много других страшных слов)
Ну да, а зачем он* ему нужен? «OBS» может по простым стандартизированным протоколам стримить хоть на «Твич», хоть на «Ютуб», хоть чёрту в ступу. Проприетарное пятое колесо никому нахуй не нужно.
*Клиент у «Твича», на самом деле, имеется, но он нужен только для просмотра каналов и сбора дополнительных данных пользователей.
Который наглухо сливает всем сишноплюсовым (aom, SVT-AV1) конкурентам и по скорости и по зожатию.
При том что по времени они все начали писать их примерно одновременно.
Не, поток там, ЕМНИП, ужимается в несколько потоков поменьше (ну как в «Ютубе» качество можно выбирать).
Хотя я не уверен, возможно, и это тоже должно быть на компе сделано.
ИМХО, самое интересное там — это сетевая рахитектура, которая должна раскидывать гигантское количество трафика с минимальными задержками (2 секунды отставания от стримера, например).
> Если я за натом, и ты за натом, то мне трудно показать тебе видео не через сервер.
Стримить не через сервер вообще сложновато. Ты что, предлагаешь стримеру отправлять копию видеопотока десятку-другому тысяч зрителей напрямую?
Десятку тысяч -- нет, это я согласен.
Придется стримать на сервер, а он должен настримать на другие сервера (близжайшие к потребителям), а уже оттуда питухам.
Причем если все эти сервера в твоей сети, то между ними как раз можно запустить PIM
Ну мы же сейчас не про скайп, а про раздачу потока тысячам зрителей. Никто в здравом уме там не будет напрямую коннектица, у стримера комп и без этого перегружен.
Х.з., исторически сложилось. Там же "протокол" у этих DASH и HLS - это тупо плейлист из чанков. Можешь закинуть их на сервер статикой и смотреть. Можешь в реалтайме отдавать.
А эти кадры ещё не старые, они только выстраиваются в очередь к показу. И если ты успеваешь их выкачать со второй-третьей попытки - юзер вообще никаких проблем не заметит. Чем больше буфер - тем больше шансов что всё будет выкачано к дедлайну.
> А если я пишу "чувак, что ты делаешь?!", а он уже давно этот уровень прошел, разве это не багор?>
Ну если ты готов терпеть постоянно рассыпающийся видеопоток ради снижения задержки на десяток-другой секунд…
В «Твиче» синк происходит то ли после минутного буфера, то ли вообще после двухминутного. Если у тебя канал настолько плох — через «UDP» ты вообще ничего не увидишь.
>Вряд ли навсегда, скорее там в какой-то момент произойдёт синк и ты всё равно проебёшь
А, пацаны. Это хуйня всё. Вы не шарите. Эти проблемы давным-давно решены несколькими различными способами.
Почитайте про 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.
Тогда я буду какое-то время смотреть только на лицо* в случае UDP.
В случае TCP же я увижу даму целиком, но не скоро.
И гост с бормандом мне говорят, что второй вариант предпочтительнее?
*
>лицо
--А вы с русалкой жить смогли бы?
Чтоб верх от бабы, низ от рыбы?
--Уверен, масса предпочла бы
Чтоб верх от рыбы, низ от бабы (С)
> Да почему постоянно?
Потому что так потери пакетов работают. У тебя просто постоянно теряется N процентов пакетов.
> У меня помеха пошла по docsis на N ms.
При чём тут «DOCSIS»-то? Мы про «Ethernet» говорим.
> а в TCP я тупо отстал навсегда, хоть и не потерял кадр
Да, при этом чем больше отставание — тем меньше вероятности, что следующие потери истощат буфер.
>У тебя просто постоянно теряется N процентов пакетов.
Совершенно нет.
Если у меня временные проблемы, то почему они должны быть всегда?
>При чём тут «DOCSIS»-то? Мы про «Ethernet» говорим.
DOCSIS просто та самая технология, ты ты можешь на пару секунд потерять связь, а потом вернуть её в полном объеме.
Интернету же пофиг, поврех чего работать.
>В массовом сегменте — да.
Ну, может быть, что я неверно понимаю бизнес-задачу: если мне нормально отстать на три секунды, но при этом НЕ потерять ни одного видеокадра, то ок
> Если у меня временные проблемы, то почему они должны быть всегда?
Это не временные трудности, это постоянные проблемы. В обычном интернете у тебя всегда теряется какая-то часть пакетов, иногда больше, иногда меньше.
> Интернету же пофиг, поврех чего работать.
Интернету пофиг, но сейчас он работает поверх «Ethernet» и оптики. Или ты предлагаешь все кабели в Интернете поменять?
> если мне нормально отстать на три секунды, но при этом НЕ потерять ни одного видеокадра
Да. Смотреть видео с постоянными перерывами — это пиздец как раздражает, пользователи этим заниматься не будут.
>Совершенно да.
Да ну нет же. Я живой аффидевит пример того, у кого были во времена docsis временные проблемы. Часть пакетов могла теряться в течении секунды, а потом всё ок.
>В обычном интернете у тебя всегда теряется какая-то часть пакетов, иногда больше, иногда меньше.
Тут я тебя не понял. Если бы они терялись в TCP, то можно было бы сказать, что их восстанавливают, и я этого не вижу.
Но вот я пингую ya.ru, и у меня 0% loss.
Если и были какие проблемы, то их починил физический уровень.
Что не так?
>Интернету пофиг, но сейчас он работает поверх «Ethernet» и оптики.
Да ну? А поверх 11n он не работает, когда ты внутри ESS переключился на другую станцию, и в этот момент проебал пакет?
А поверх присноблядьпамятного docsis, когда у тебя помеха пошла по одному из каналов, и у тебя на три секунды 80% потерялось, а потом снова ок?
> Смотреть видео с постоянными перерывами
Я понял, в чем наше непонимание именно тут:
Ты считаешь, что если у меня проебался пакет, то у меня хуйвый интернет, и я всегда буду проебывать N% пакетов, верно?
В таком случае у меня выбор: задержаться на секунду, или сомтреть на квадратики. Ты выбираешь первое, и это логично.
Я же опровергаю в том утверждаю, что потеря пакета может быть временным явлением.
А может быть и не временным. Заранее ты не угадаешь. Но один артефакт/буферинг зритель потерпит. На втором начнёт плеваться и уйдёт на другой сервис у которого с задержкой но стабильно.
И ты не объяснишь человеку, что это его личная проблема с интернетом. Другие сервисы же нормально идут, лол.
> Если у меня всегда проебывается половина пакетов -- я звоню провайдеру
Для любования на квадраты через «UDP» тебе не нужна потеря половины пакетов, тебе достаточно терять сотые/тысячные доли процента. А это — вполне нормальный режим работы Интернета.
Кстати, я недавно жил с 1% потерь и вообще не замечал их. Потоковое видео шло без проблем. В браузере странички иногда подтупливали но грузились. TCP очень неплохо с этим справляется на самом деле.
Я тебе скажу, что мне в последнее время и с 15 процентами приходится сталкиваться, ничего, почти не мешает. Только иногда запросы тупят, ну и похоже 4-ым Героям это не очень нравится лол
> Что не так?
То, потери пакетов в обычном режиме очень небольшие, сотая доля процентов, например. Простым пингом на четыре пакеты ты их, разумеется, не увидишь.
Типичный стрим — это постоянный видеопоток примерно на 5 мегабайт в секунду полезных данных (40 мегабит). Путём несложных грубых вычислений можно убедиться, что 5 мегабайт в секунду с MSS 1400 — это как минимум 5* 1024**2 // 1400 = 3744 IP-пакета в секунду. То есть, если у тебя теряется 0.003% (три тысячных доли процента) пакетов, то наблюдать квадратики ты будешь раз в десять секунд. Через «TCP», в свою очередь, ты таких потерь в принципе не заметишь.
> Да ну? А поверх 11n он не работает, когда ты внутри ESS переключился на другую станцию, и в этот момент проебал пакет?
Я вообще-то про магистрали, но да ладно, похуй.
> Я не уверен, что замечу квадратики в одном кадре раз в десять секунд
Ну что ж такое, мы же это уже выяснили.
>>> Таким образом, я сосу болта до следующего ключевого кадра, верно?
Ты будешь смотреть на квадратики по одной-двум секундам раз в десять секунд (я — на квадратики по одной-двум секундам раз в пол-секунды, ага).
> Разве пользователь сидит не дома?
Потому что пакеты теряются далеко не только на линии между пользователем и оборудованием провайдера. Они теряются на всём пути от сервера «Твича» и до компьютера пользователя.
Достаточно подключить беспроводной безлимитный интернет Йота, чтобы за 1400р/месяц получить пинг 8.8.8.8 по 500мс стабильно и с потерей 10%+.
Не выезжая из Москвы
> "сосу болта" означает "софт не будет иметь информации для отображения", это совсем не значит, что я, как пользователь, обращу на это внимание
Это означает, что пользователь будет смотреть на чёрный квадрат/месиво из квадратиков. Не заметить такое можно только когда ты отвернулся от экрана.
> В течение какого времени?
Зависит от кодека, но никак не меньше нескольких (возможно, десятков) кадров. Повторюсь, не заметить такое сложно.
> Надо еще учитывать, что ya.ru это не видеохостинг, и отвечать мне на ping они вообще не обязаны.
Для любых других серверов картина ничуть не лучше. Постоянная небольшая потеря пакетов — это зло, от которого избавиться в принципе невозможно. Ну, разве что провести оптику от твоего компа к серверу «Твича».
Кстати, я совершенно забыл упомянуть, что порядок прихода пакетов в «UDP» не гарантирован. Поэтому для передачи видео по «UDP» тебе в любом случае придётся реализовывать подмножество «TCP» с сегментами и их буфером.
Если у пользователя постоянно теряется часть пакетов, то TCP более предпочтителен: он забуферизирует данные, сделав процесс smooth для пользователя: он будет перепосылать сегменты, пока пользователь смотрит видео.
UDP же ничего не буферизирует, соответственно потерянные пакеты это квадраты до следующего ключевого кадра.
В случае же, если у пользователя потеря пакетов случается редко, но метко (в течение пары секунд теряется 100%, а потом всё ок) то разницы между TCP и UDP нет.
Однако, TCP это бОльшая нагрузка на CPU.
Если у видеопровайдера есть пиринг с оборудованием провайдера, то пакеты скорее всего ПОЧТИ не будут теряться вовсе (внутри провайдера они не теряются, иначе IPTV мультикастом бы у меня не работал, все же понимают, что мультикаст это UDP, правда?).
Если же связь с провайдером у него через какие-то tier 1 сети, то проеб может быть.
Итого: если мы уверены в более-ли-менее качественном интернет-соединении, то имеет смысл использовать UDP.
Если нет, то TCP, так как он успеет забуферизировать видео прежде, чем буффер опустишится, и пользователь увидит хуй.
> TCP более предпочтителен: он забуферизирует данные, сделав процесс smooth для пользователя: он будет перепосылать сегменты, пока пользователь смотрит видео.
На самом деле не совсем. Существует два буфера: системного уровня, который заполняется ядром (драйвером TCP/IP), и буфер браузера. В первом хранятся сегменты TCP, во второй браузер складывает кадры видео.
«TCP» гарантирует, что последовательность байт, отправленная с сервера, обязательно дойдёт до клиента без изменений и в правильном порядке (что тоже крайне важно, кстати). Буферизация видео браузером, в свою очередь, обеспечивает пользователю плавное воспроизведение даже тогда, когда приход очередной порции байт с сервера задерживается (драйвером TCP/IP) из-за потерь пакетов.
> Однако, TCP это бОльшая нагрузка на CPU.
По сравнению с декодированием 60@FHD видео — это настолько мелкие копейки, что ими нужно пренебречь.
> Итого: если мы уверены в более-ли-менее качественном интернет-соединении, то имеет смысл использовать UDP.
Да, но такое будет только если сервер и клиент соединены напрямую одним кабелем. И даже в этом случае пользователь может поставить качаться торрент и получить багор.
Увы, Интернет — крайне непредсказуемое говно, поэтому получить по-настоящему надёжное соединение до удалённого сервера, к сожалению, невозможно. Возвращаясь к примеру выше, чтобы надёжно передавать видеопоток через «UDP» и получать квадраты хотя бы не чаще раза в минуту, нужно терять не больше одного пакета из 224640.
>По сравнению с декодированием 60@FHD видео
Я говорю с точки зрения провайдера: он может стримать UDP, и это позволит ему сэкономить ресурсы.
>Да, но такое будет только если сервер и клиент соединены напрямую одним кабелем.
Тогда почему у меня нормально работает IPTV по мультикасту от провайдера?
У меня есть роутер, есть роутер провайдера, и есть сеть до стримающего сервера (через тот самый рандеву поинт).
Я включаю телек, секунды три смотрю на "wait" (жду подключения, начала стрима, и ключевого кадра?) и дальше видео работает без квадратиков
Видимо, нужно читать спеку по кодеку, а я уже пьяный. Спокойной ночи))
> Я говорю с точки зрения провайдера: он может стримать UDP, и это позволит ему сэкономить ресурсы.
Настолько мизерные крохи ресурсов, что ими можно и нужно пренебречь. Там одно только TLS-шифрование потока сожрёт на два порядка больше ресурсов, чем обработка «TCP».
> Тогда почему у меня нормально работает IPTV по мультикасту от провайдера?
Нужно смотреть протокол и кодирование. Я же не говорю, что по «UDP» в принципе нельзя передать видео, я говорю о том, что это очень сложно и геморройно. Можно жать кадры по отдельности, тогда небольшая потеря пакетов действительно не будет заметна. Можно впендюрить десяток-другой процентов избыточности. Ещё как-нибудь извратиться.
Да. Но обычно отстать на 10-15 секунд и смотреть красивое стабильное видео людям приятнее чем говно которое пидорасит каждые полсекунды зато без лагов.
> TCP передаст тебе большой кусок, если ты потерял из него хоть один пакет.
Нет. Потеряться может только IP-фрейм (1500 байт брутто). В таком случае «TCP» просто передаст этот фрейм ещё раз.
> Рассмотрим ситуацю, когда ты потерял НЕ ключевой кадр.
> В UDP ты этого не заметишь
Нет, не так. Если я потерял НЕ ключевой кадр, то у меня ВСЕ последующие НЕ-ключевые кадры превратятся в квадратики. То есть, в зависимости от кодека, я буду эдак секунду-другую (точное время надо у кодировочных петухов спрашивать) смотреть на квадраты.
> в TCP ты будешь вынужден смотреть на "buffering", пока ты не переполучишь кусок с потерянным кадром, нет?
Нет, см. первый абзац.
> Стоп. Давай определимся с терминологией: IP пакет размером 1500 байт, что такое фрейм?
Перепутал с «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».
>frame_2 = diff(frame_1, data_2),
Вот где собака порыта.
Таким образом, я сосу болта до следующего ключевого кадра, верно?
Получается, что если ключевой кадр примерно синхронизирован с границей сегмента, то разницы между TCP и UDP нет: я или смотрю на квадратики до следующего ключ кадра, или смотрю на "buffering"
Однако, если я верно понял Пи и Десктопа, то ключевой кадр может быть размазан на несколько пакетов, и тогда я могу потерять синхронизацию для части изображения, и в случае TCP я буду смотреть на "buffering", а в случе UDP я буду смотерь на верхнюю половину экрана (снизу будут квадратики), так?
> Таким образом, я сосу болта до следующего ключевого кадра, верно?
Да.
> я или смотрю на квадратики до следующего ключ кадра, или смотрю на "buffering"
Нет. Ключевая разница в том, что в «TCP» ты смотришь на «buffering» один раз, после чего буфер у тебя разрабатывается, и дальше ты видишь только плавную картинку без единого разрыва.
> то ключевой кадр может быть размазан на несколько пакетов
Не знаю, не видел этой технологии.
> Ключевая разница в том, что в «TCP» ты смотришь на «buffering» один раз, после чего буфер у тебя разрабатывается
..и ты смотришь всё, с отставанием в N секунд?
Если у меня больше нет потерь, то я и на UDP все вижу
Если они есть, то я еще много раз увижу "buffering", и в итоге отстану на много секунд
Буферинг ты видишь не после каждой потери пакета, а только после тех потерь, которые не удалось устранить за длину буфера.
Т.е. если у тебя буфер 10 секунд, то у тебя есть почти 10 секунд на загрузку каждого чанка. Ну и собственно отстаёшь от реалтайма ты на эти самые 10 секунд. TCP за это время без проблем успевает всё перепослать и переполучить.
Ну а если канал пиздец хуёвый и не успевает - значит будешь жить с буфером в 20 секунд. Хотя обычно после такого просто качество скидывают.
Я говорил про достаточно серьезные продолбы, чтобы буфер опустишился, и я увидел буфферинг. В таком случае я могу нехило отстатать.
Похоже, что разница всё таки в формате проеба: если он постоянный, то TCP гарантирует мне smooth видео (хотя и с отставанием, если я не успею заполнить буфер), если он временный, то в TCP я отстану без всякой причины: лучше бы посмотрел кубики 2 сеу
Почитай как работает хлс/даш. Ты клиент хттп, ты сам по хттп забираешь все чанки. Сервер же готовит на сервере к готовности плейлисты (перечень чанков) и сами чанки в нескольких разрешениях сразу (качестве).
Ты качаешь по хттп плейлист и по хттп начинаешь качать чанки. Понимая, что плейлист - активный стрим, ты перезапрашиваешь плейлист раз в эн секунд, чтобы узнать о новых свежих чанках, которые тоже будешь сливать с сервера по хттп.
Плеер твой может догадаться, или ты сам, о том, что твой канал говно, он не успевает вовремя качать, все тормозит и дёргается - есть возможность переключиться на качество похуже (чанки будут за те же промежутки времени, но по размеру меньше заметно).
Вот в этой схеме задержку менее 15 секунд практически нереально получить (потому что чанк должен быть не на 1 секунду), а оптимально - 60 секунд.
Когда ты смотришь футбол онлайн, это норм, когда смотришь куранты с путиным на новый год - это тоже приемлемо.
Да ну не 15, меньше обычно, что-то в пределах 10 с чанками в пару секунд. Но для диалога это не особо пригодно, да. Как с луной разговариваешь, даже если обратный канал через текстовый чатик.
Щас много ебанутых, которые играют на ставках, для них минута задержки это может быть критично: в популярном матче за это время котировки могут прыгнуть несколько раз.
Впрочем, для этих целей наверняка лучше использовать вменяемые текстовые трансляции.
Была программа «rtmpdump», чтобы тырить данные с видеосервисов, которые отображают кинцо через «Плоть». Например, с «Rutube» только так можно было снять поток.
Ну, например, чтобы не ебаться с потерей пакетов, попутно изобретая свой собственный «TCP» поверх «UDP». Видеопоток — это же не просто кучка отдельных кадров, это закодированная кучка кадров. После потери полутора килобайт данных их придётся либо пересылать (изобретаем «TCP»), либо показывать пользователю секунду-другую пустоты, до следующего ключевого кадра (любой пользователь с дропрейтом > 0.00..01% будет смотреть на чёрный экран).
>О, может ты знаешь, там же high-res поток как дельта от low-res потока кодируется?
> Чтобы можно было быстро переключаться на хуёвое качество и обратно.
Это называется SVC.
Хз как на твитче. Но вряд ли. Т.к. в я не видел толковых реализаций в промышленных энкодерах.
>Чтобы можно было быстро переключаться на хуёвое качество и обратно.
Одно я знаю наверняка. Твитчовцы (и это их заслуга) для этих целей пролоббировали в AV1 совершенно потрясную штуку.
Если стример стримит через OBS, который сам сжимает как ему надо, то в случае, который ты описал, Твитч сначала декодирует, потом кодирует заново что ли? Или как это происходит?
> А на задержку там всем похуй на самом деле, ну ответит тебе стример на 5 секунд позже, не помрёшь.
Да нет, они в последнее время серьёзно за её уменьшением гонятся (как и «Ютуб», кстати). Две секунды задержки от компьютера стримера — это реальный пример.
Тащимто реальный пример человека, который занимается перформансом в нетфликсе: http://www.brendangregg.com/linuxperf.html ровно по причине того, что даже самая "правильная" архитектура имеет много проблем, когда ты нетфликс
Как на Ютюбе 2 секунды получить?
Ффмпег ебаный это уже секунда, даже если ты такой охуевший и в полуреальном времени срешь на клиенты по вебсокету (а не мпег-даш/хлс), 2 секунды и массовость звучат фантастично
(И главное, зачем? Что плохого в задержке, например, 30с?)
Я прост далёк от блогиров, но тема интернет вещания регулярно возвращается в контекст
> Как на Ютюбе 2 секунды получить?
Не знаю, я на «Твиче» специализируюсь. Реальный пример: https://i.imgur.com/DGN5EK0.png.
Правда, меня смущает размер буфера: если буфер 2.06 секунд, а задержка — 2.09, получается, мне от стримера кадры приходят за 30 миллисекунд?..
Наверное, «Твич» всё таки запутался в терминах, и реальная задержка (отставание часов на экране стрима от моих локальных) там 4.15 секунды.
> И главное, зачем? Что плохого в задержке, например, 30с?
Ну типа мгновенная реакция на чат, все дела.
Да никак он не отвечает, в лучшем случае в паузе что-то почитает. Ты же видел типичный поток комментов на твиче? Там его бот с ИИ не успеет распарсить, не то что человек.
$ aomenc --help
--global-error-resilient=< Enable global error resiliency features
--error-resilient=<arg> Enable error resilient features (0: false (default), 1: true)
--cdf-update-mode=<arg> CDF update mode for entropy coding (0: no CDF update; 1: update CDF on all frames(default); 2: selectively update CDF on some frames
Если видео записано заранее, то лучше всего взять Adaptive bit rate, когда сервер разбивает всё на кусочки, а клиент выбирает следующий чанк нужного размера.
Если клиент сидит на iPhone через сотовую сеть, то он выберет кусочек с худшим качеством (и худшего размера)
А если у него телек на пол стены по гигабиту, то может позволить себе чанк по лучше
Все эти проты работают по TCP, и это понятно: клиент может накачать себе чанков за щеку, как хомяк, и их показывать.
А если видео стримается в реальном времени? Если это видеокамера с улицы?
Я не смогу наполнять буфер быстрее, чем я его опустошаю, какой же тут толк от TCP по сравнению с UDP?
Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Можно конечно забуферизировать данные, и показывать камеру с отставанием, но если это видеозвонок или прямой эфир, и туда можно звонить? Тогда отставать мне нельзя.
> Я не смогу наполнять буфер быстрее, чем я его опустошаю
А зачем? Ты открываешь стрим, браузер закачивает две секунды стрима и начинает тебе его показывать, параллельно закачивая следующие две секунды потока. В «UDP» будет то же самое: тебе так же надо организовать буфер в несколько секунд видеопотока, чтобы, во-первых, восстановить порядок UDP-пакетов (они к тебе придут перемешанные), а во-вторых — не раздражать пользователя из-за флуктуаций пинга (видео, в котором каждый кадр показывается с задержкой +- пару миллисекунд от номинальной будет выглядеть очень… своеобразно).
> Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Только в том случае, если у тебя теряется порядка процента и больше пакетов, и то только ОДИН РАЗ. После этого одного раза буфер разработается и buffering не будет, за счёт увеличения задержки.
Там, где небольшие (сотые/тысячные доли процента) потери данных не важны, либо из-за избыточности, либо из-за переизобретённого «TCP», при этом «TCP» в чистом виде не подходит (увеличение задержки, оверхед на установку соединения, принципиальная невозможность установки соединения как в мультикастовом «IPTV»). То же видео может передаваться по «UDP», когда задержки в единицы секунд крайне критичны (видеозвонки, конференции: см. «RTMFP», кажется, «Скайп» работал по «UDP»). Многие мультиплеерные игры, требовательные к задержке (шутеры там всякие), тоже ходят по «UDP».
> OpenVPN может по udp, чтобы не делать накладных расходов
Точно, про него забыл. В «OpenVPN» запилен свой протокол, обеспечивающий надёжность передачи данных, поэтому гонять его по «TCP» — практически бессмысленное занятие.
> По TCP можно косплеить https, чтобы обманывать админа, например.
Да, и про это забыл. Пускаем «VPN» на 443-й порт и течём.
> А зачем VPN надежность?
Надо читать протокол. Могу предположить, что он у них завязан на последовательное получение сегментов (типа «AES CBC»), тогда любая потеря пакета приведёт к разрыву соединения.
> То-есть я всегда буду отставать на 2 секунды?
Да.
> Пришедший в неверном порядке пакет можно же просто отбросить?
Можно. Тогда у тебя останется примерно половина пакетов, может даже меньше.
> Если браузер всё равно имеет свой буфер, то зачем мне еще и буфер tcp?
Потому что это два разных буфера с разными функциями. Буфер «TCP» нужен для восстановления исходного потока байт с сервера, буфер браузера — для обеспечения плавного воспроизведения видео без прерываний.
> А как это всё будет работать с прямым эфиром или видеозвонком?
Для прямого эфира это совершенно непринципиально (так, например, многие играющие в онлайн-игры стримеры специально выставляют задержку в одну-две минуты, чтобы противники не могли подсмотреть стрим и получить преимущество). Для видеозвонков используются либо более мелкие буфера, либо какие-то формы избыточности (возможно, в связке с «UDP», надо смотреть протоколы).
Если ты утверждаешь, что половина пакетов у меня потеряется или придет в неверном порядке, то как же эту проблему решает скайп?
Сам восстнавливает порядок пакетов?
Да, у звонилок тоже есть буфер, просто он там десятки-сотни миллисекунд а не десятки секунд как у лайв стримов.
Проблема не столько в порядке, сколько в джиттере - задержку постоянно "трясёт". Поэтому точно так же поток приходит кусками и какое-то время отстаивается в буфере.
Ну да, кусочки вставляются в буфер по мере их получения. И равномерно выгребаются на воспроизведение. Если пришёл слишком старый кусок - выбрасывется нахуй. Если пришло время воспроизводить, а нужного куска так и нет - ну не судьба, посмотрим на квадратики или послушаем тишину.
Для просмотра стрима я могу позволить себе задержку в 100ms, а для разговора -- нет, иначе собеседник подумает, что я тормоз из анекдота "дяденька, я не тормоз"
> А есть какая-то статистика на этот счет?
Нет, только эмпирические наблюдения за «tcpdump».
> То-есть TCP нам нужен исключительно для восстановления порядка?
Для восстановления порядка и восстановления потерянных пакетов.
> то как же эту проблему решает скайп?
Изобретением своего велосипеда. Поверх «UDP» написан охулиард протоколов разной степени надёжности, в той или иной мере копирующих «TCP». См. «RDP», «RUDP», «ENet», «GameNetworkingSockets», тысячи их.
> Вопрос: почему же 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».
Основной недостаток «TCP» — это оверхед на соединение (SYN, ACK, SYN-ACK), так что, скорее всего, в нём. От стейтфул соединений нагрузка слишком низка, чтобы её можно было заметить.
Да, потому что «TCP» не знает, как твой протокол работает, и что старые данные тебе не нужны.
>>> Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
Я сказал, что TCP не знает, какой кадр у тебя ключевой, и вообще ничего о кадрах не знает, потому будет заставлять тебя обрабатывать все пакеты, даже те, которые можно потерять, ценой задержки.
Правда, я не учел, что для обычного видео (не видеозвонков) задержка не важна
зы: ну и при diff кадров я думал неверно, так как считал, что они все диффятся от ключевого кадра, а не от предыдущего
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.
> Keeps latency as low as possible while maintaining the highest voice quality.
Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
> реализовали часть его фишек вообще на другом уровне абстракции
Ну так это и есть изобретение велосипеда. В данном случае, конечно, оправданное: велосипед у них получился специализированный и более подходящий для решения их задачи, вот такой: https://www.youtube.com/watch?v=PIoUKPeWVjQ.
Мне аудиозвонков хватило. Одно дело просто попиздеть про всё это, и совсем другое - поддерживать совместимость со всяким кривым говном, с которым это всё должно будет работать.
MAKAKA # 0
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
Лучше уж напитонячить тогда: там это будет не так ужасно
bormand # 0 ⇈
MAKAKA # 0 ⇈
gost # 0 ⇈
Подтверждаю. Не отклоняясь от изначального алгоритма:
MAKAKA # 0 ⇈
Видимо, внутренний линтер зависит от языка
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
Зачем? Зачем? В общем-то и в версии ОПа можно было остановиться на str == revers.
MAKAKA # 0 ⇈
В общем, создавать буферы в цикле бы точно не хотелось
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
Именно поэтому я за пхп.
P.S. И ведь хрен ты придумаешь более красивое и наглядное решение.
warzon131 # 0 ⇈
gost # 0 ⇈
Можно оптимизировать (например, прекращать вычисления, когда оба множителя меньше наименьшего из предыдущей найденной пары), но мне лень.
bormand # 0 ⇈
guest # 0 ⇈
Ужос джава кода даже не столько в буфферах, сколько в том, что автор с числами не умеет работать, не?
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
Побочные эффекты посреди выражений!? Бля, это серьёзно завезли в питон? ЗАЧЕМ? ЗАЧЕМ?
guest # 0 ⇈
Уже обосрали же три раза
Хочеш, еще раз обосрем?
bormand # 0 ⇈
guest # 0 ⇈
3.14159265 # 0 ⇈
Подтверждаю.
gost # 0 ⇈
Какой анскилл (((
guest # 0 ⇈
Могу на 81% сказать, шо в жабе будет наоборот
gost # 0 ⇈
Царская функция дробит числа, а как числодробилка нативный «Питон» работает до крайности хуёво.
gost # 0 ⇈
MAKAKA # 0 ⇈
gost # 0 ⇈
MAKAKA # 0 ⇈
На жабе троже
В 10 раз, в 10 блядь раз
bormand # 0 ⇈
С учётом прибавления и отнимания '0' и трёх аллокаций выглядит совсем неплохо. Я думал хуже будет.
MAKAKA # 0 ⇈
Но в кучу анскильный вариант срёт знатно, конечно
Зацени
https://postimg.cc/xXQynRK5
bormand # 0 ⇈
guest # 0 ⇈
Впрочем, нещщасные буфера держат в памяти 4 метра чаров
А еще 23 держит сама джава.
Зы: аллокации в JVM бесплатные (не считая коснтруктора) а вот удаление-то нет
ззы: на 64 jDK не поставить слишком мелкий xmx, нужна 32-х битная йажа, чтобы проверить, лол
warzon131 # 0 ⇈
3.14159265 # 0 ⇈
Ненормально было бы если бы понимал.
guest # 0 ⇈
Спрашивай, объясним
bormand # 0 ⇈
Ты платишь фиксированную цену за запуск гц и обход стека каждые N мегабайт. Но мертвые объекты же недостижимы, их двигать не надо.
На мелких временных аллокациях джава в клочья сишку порвёт, имхо. Если сишник не будет читерить с переменными на стеке, конечно.
guest # 0 ⇈
Во-вторых под платностью я имел ввиду сам запуск GC.
Например, с малюсеньким xmx на этом коде я получаю просед перформанса для анскильной версии
Вот тут видно, что даже минорный GC что-то стоит (хотя смешно конечно про это говорить про такие числа в йажа).
Но может быть у меня просто GC хреновый (запускал на дефолтном на восьмере, надо у шипилёши почитать про виды GC и освежить)
https://postimg.cc/G8Z8mLsY
3.14159265 # 0 ⇈
Хуета.
Полная хуета.
>Если сишник не будет читерить с переменными на стеке, конечно.
Царь даже без стека эту хуйню сольёт.
Если я хуйну SLAB-аллокацию или заранее выделю себе mmapом мегабайты памяти, как это делает Йажа, то она опять сольётся в хламину.
Йажа-сектанты часто пишут бенчи в стиле: Сишные malloc+free vs преаллоциорованный гиг памяти в Йажа, причём бенчмарк заканчивается ещё до первой сборки. См. -Xmx 1Gb
После чего делаются многозначительные выводы и пишутся статьи для хабархабра: «Придуман новый язык, быстрее чем Си».
guest # 0 ⇈
Полагаю, Броманд имел ввиду, что аллокация в джаве бесплатна (потому что ты просто берешь следующий кусок уже выделенной памяти, и не думаешь про фрагментацию), а работа minor gc не такая уж и долгая.
Это может оказаться реально быстрее, чем вручную делать malloc сишного рантайма (запрашивая у ОС память) и возвращать ее обратно через free.
>Царь даже без стека эту хуйню сольёт.
куууик (кинул какашку в JVM: в .NET можно хранить объекты на стеке, а в JVM -- нет, если только JIT не намутит).
>Если я хуйну SLAB-аллокацию
Это когда ты заранее выделяешь массив в памяти, где каждая ячейка размером с объект, и потом сам его заполняешь?
>или заранее выделю себе mmapом мегабайты памяти
Ну да, в обоих случаях ты откажешься от услуг менеджера памяти, и возьмешь это на себя, как и делает джава.
Видал багры людей, которые запускают простое приложение, и ноют, что оно занимает 8 гигов.
А там на самом деле xms такой.
>Йажа-сектанты часто пишут бенчи
Ну это конечно на совсем лоха должно быть расчитано:)
Это как я возьму кредит у банка, и скажу "я миллионер", а как его отдавать не покажу
gost # 0 ⇈
Инты в ЙАЖЕ как раз хранятся на стеке, если их в коробки не завернули. В отличие от «Python», в котором каждая арифметическая операция — это создание нового объекта с соответствующим дёрганьем кучи. Собственно, почему он так и тормозит на царском алгоритме.
guest # 0 ⇈
Даже java.awt.Point
А в питоне всё по референсу, даже число, это правда.
А там нету пула для литералов чисел кстати, как в йаже?
Кстати, так что именно томрозит?
Деление бигнумов? Не верю, что дело реально в куче
gost # 0 ⇈
Есть, до 255-и, кажется. Или поменьше, не помню.
guest # 0 ⇈
А почему так попидарски, кстати? Почему иммутабельную хуйню маленькую не хранить на стеке?
gost # 0 ⇈
guest # 0 ⇈
*помнишь нашу беседу про .net?:)
gost # 0 ⇈
guest # 0 ⇈
Ты юзал какие-нить продвинутые средства профилирования кроме timeit и cprofile?
Просто на фоне даже yourkit или apple instruments там всё как-то грустно, имхо
gost # 0 ⇈
Нет, необходимости не было.
guest # 0 ⇈
gost # 0 ⇈
А ещё к «Питону» можно прикрутить «JIT»: https://numba.pydata.org/. Говорят, помогает.
guest # 0 ⇈
А ты пробова cython? Говорят, удобно переписать на няшной что-то оставаясь в рамках питона
gost # 0 ⇈
gost # 0 ⇈
В 8.7 раз быстрее максимально ускоренной анскильной (см. ниже) на первом запуске, в 43 раза быстрее на последующих.
gost # 0 ⇈
Бамп отсосу «JavaScript»!
bormand # 0 ⇈
Вот тебе и преждевременная оптимизация.
gost # 0 ⇈
gost # 0 ⇈
gost # 0 ⇈
3.14159265 # 0 ⇈
Слайсы ебошит нативная сишка. А деления анскильный Питух.
Лалки обсирали jsую идиому str.split('').reverse().join('')
Однако же:
guest # 0 ⇈
Так-то деления ебошит CPU, и думается мне, что если бы питон умел в JIT, то всё было бы хорошо, не?
bormand # 0 ⇈
guest # 0 ⇈
А если бы был честный int 32х битный, то сработало бы?
3.14159265 # 0 ⇈
Я к тому что этот метод довольно долгое время был самым быстрым.
Похоже в браузерах пустые сплиты/джойны шли по отдельному оптимизированному пути.
bormand # 0 ⇈
Я вот думаю они и тут без перебора решили.
guest # 0 ⇈
Myxa # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
Desktop # 0 ⇈
Я про софт, который у стримера стоит. Захват видео, кодирование, передача.
Типа хуета это всё?
gost # 0 ⇈
Дык что его разрабатывать, он уже в опенсорсе есть: https://github.com/obsproject/obs-studio.
Desktop # 0 ⇈
Какой высокотехнологичный стартап )))
bormand # 0 ⇈
Desktop # 0 ⇈
> Нахуй плодить сущности?
- как будто ты не знаешь про nih
gost # 0 ⇈
А это будет тяжелейшим выстрелом в ногу. Абсолютное большинство крупных стримеров (т.е. все те, кто приносят «Твичу» бабло) стримят не напрямую, а через что-то типа https://restream.io/ — штуковины, которая размножает поток на несколько платформ с опциональным добавлением всяких межплатформенных фишек. И работает это потому, что протоколы для стриминга открыты и стандартизованы.
Desktop # 0 ⇈
Так что я бы скорее подумал, что им этот рестрим поперёк горла
gost # 0 ⇈
Ну да, он у них зрителей отнимает. Но жёстко с ним бороться они не могут просто потому, что тогда от них уйдут стримеры, а это куда больнее.
guest # 0 ⇈
Вы стримаете игрушки?
gost # 0 ⇈
Desktop # 0 ⇈
guest # 0 ⇈
Я только телевизор по IPTV запускал, на этом мои знания стриминга заканчиваются. Но там был мультикаст в пределах сетки провайдера
Desktop # 0 ⇈
- как говорится, если в жизни мало секса, иди понастраивай IPTV
guest # 0 ⇈
Для локалки пришлось подымать IGMP Proxy на роутере (чтобы запросы о вступлении в группу приходили к провайдеру), а далее выяснилось, что телевизор может только unicast, и пришлось ставить на роутере udpxy, который мультикаст преобразует в unicast.
Но тем не менее, всё завелось)
Это сподвигло меня прочитать главу про multicast на хабре в туториале "сети для самых маленьких": так я узнал про PIM, рандеву поинт, и про много других страшных слов)
gost # 0 ⇈
*Клиент у «Твича», на самом деле, имеется, но он нужен только для просмотра каналов и сбора дополнительных данных пользователей.
bormand # 0 ⇈
3.14159265 # 0 ⇈
Бууэээ. На курятнике писать энкодер для AV1. Твич поставил на rav1e.
https://github.com/xiph/rav1e
Который наглухо сливает всем сишноплюсовым (aom, SVT-AV1) конкурентам и по скорости и по зожатию.
При том что по времени они все начали писать их примерно одновременно.
Desktop # 0 ⇈
gost # 0 ⇈
Хотя я не уверен, возможно, и это тоже должно быть на компе сделано.
ИМХО, самое интересное там — это сетевая рахитектура, которая должна раскидывать гигантское количество трафика с минимальными задержками (2 секунды отставания от стримера, например).
bormand # 0 ⇈
Я могу ошибаться, но по-моему low-res потоки тоже на компе стримера создаются. Ща проверю.
> сетевая рахитектура
Я не думаю, что там прям что-то гениальное... Скорее всего обычное дерево с датацентром в каждом регионе.
А на задержку там всем похуй на самом деле, ну ответит тебе стример на 5 секунд позже, не помрёшь.
guest # 0 ⇈
А потом ты контрибутишь в ядро в районе реализации ip, не?
bormand # 0 ⇈
guest # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
defecate-plusplus # 0 ⇈
Для ~ реалтайма надо тащить вебсокет/вебртц
guest # 0 ⇈
https://en.wikipedia.org/wiki/UDP_hole_punching
gost # 0 ⇈
guest # 0 ⇈
Если я за натом, и ты за натом, то мне трудно показать тебе видео не через сервер.
Алсо, TCP плохо дружит с реалтаймом. Для видео проёб кадра не так страшен, как задержка же.
Идеальная картина, это когда я стримлю UDP тебе напрямую
gost # 0 ⇈
Стримить не через сервер вообще сложновато. Ты что, предлагаешь стримеру отправлять копию видеопотока десятку-другому тысяч зрителей напрямую?
guest # 0 ⇈
Придется стримать на сервер, а он должен настримать на другие сервера (близжайшие к потребителям), а уже оттуда питухам.
Причем если все эти сервера в твоей сети, то между ними как раз можно запустить PIM
bormand # 0 ⇈
Ну мы же сейчас не про скайп, а про раздачу потока тысячам зрителей. Никто в здравом уме там не будет напрямую коннектица, у стримера комп и без этого перегружен.
guest # 0 ⇈
Зачем TCP видеостриму?
bormand # 0 ⇈
Х.з., исторически сложилось. Там же "протокол" у этих DASH и HLS - это тупо плейлист из чанков. Можешь закинуть их на сервер статикой и смотреть. Можешь в реалтайме отдавать.
guest # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
gost # 0 ⇈
Ну если ты готов терпеть постоянно рассыпающийся видеопоток ради снижения задержки на десяток-другой секунд…
guest # 0 ⇈
У меня помеха пошла по docsis на N ms. В UDP я ее пережил с квадратами, а в TCP я тупо отстал навсегда, хоть и не потерял кадр
Оно того стоит?
Desktop # 0 ⇈
gost # 0 ⇈
Desktop # 0 ⇈
3.14159265 # 0 ⇈
А, пацаны. Это хуйня всё. Вы не шарите. Эти проблемы давным-давно решены несколькими различными способами.
Почитайте про 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.
guest # 0 ⇈
Так а что будет, если я проебу часть?
Desktop # 0 ⇈
guest # 0 ⇈
Тогда я буду какое-то время смотреть только на лицо* в случае UDP.
В случае TCP же я увижу даму целиком, но не скоро.
И гост с бормандом мне говорят, что второй вариант предпочтительнее?
*
>лицо
--А вы с русалкой жить смогли бы?
Чтоб верх от бабы, низ от рыбы?
--Уверен, масса предпочла бы
Чтоб верх от рыбы, низ от бабы (С)
3.14159265 # 0 ⇈
Может пара кадров проебаться, но буфер весьма быстро восстановится.
Вертикальная полоска за 5-10 кадров сделает полный self-refresh. И не надо ждать I-frame.
Ценой этого чуть более низкое зожатие.
Смысл в том, что в P-кадре или B-кадре могут быть I-блоки, которые ни от чего не зависят.
bormand # 0 ⇈
gost # 0 ⇈
Потому что так потери пакетов работают. У тебя просто постоянно теряется N процентов пакетов.
> У меня помеха пошла по docsis на N ms.
При чём тут «DOCSIS»-то? Мы про «Ethernet» говорим.
> а в TCP я тупо отстал навсегда, хоть и не потерял кадр
Да, при этом чем больше отставание — тем меньше вероятности, что следующие потери истощат буфер.
> Оно того стоит?
В массовом сегменте — да.
guest # 0 ⇈
Совершенно нет.
Если у меня временные проблемы, то почему они должны быть всегда?
>При чём тут «DOCSIS»-то? Мы про «Ethernet» говорим.
DOCSIS просто та самая технология, ты ты можешь на пару секунд потерять связь, а потом вернуть её в полном объеме.
Интернету же пофиг, поврех чего работать.
>В массовом сегменте — да.
Ну, может быть, что я неверно понимаю бизнес-задачу: если мне нормально отстать на три секунды, но при этом НЕ потерять ни одного видеокадра, то ок
gost # 0 ⇈
Совершенно да.
> Если у меня временные проблемы, то почему они должны быть всегда?
Это не временные трудности, это постоянные проблемы. В обычном интернете у тебя всегда теряется какая-то часть пакетов, иногда больше, иногда меньше.
> Интернету же пофиг, поврех чего работать.
Интернету пофиг, но сейчас он работает поверх «Ethernet» и оптики. Или ты предлагаешь все кабели в Интернете поменять?
> если мне нормально отстать на три секунды, но при этом НЕ потерять ни одного видеокадра
Да. Смотреть видео с постоянными перерывами — это пиздец как раздражает, пользователи этим заниматься не будут.
guest # 0 ⇈
Да ну нет же. Я живой аффидевит пример того, у кого были во времена docsis временные проблемы. Часть пакетов могла теряться в течении секунды, а потом всё ок.
>В обычном интернете у тебя всегда теряется какая-то часть пакетов, иногда больше, иногда меньше.
Тут я тебя не понял. Если бы они терялись в TCP, то можно было бы сказать, что их восстанавливают, и я этого не вижу.
Но вот я пингую ya.ru, и у меня 0% loss.
Если и были какие проблемы, то их починил физический уровень.
Что не так?
>Интернету пофиг, но сейчас он работает поверх «Ethernet» и оптики.
Да ну? А поверх 11n он не работает, когда ты внутри ESS переключился на другую станцию, и в этот момент проебал пакет?
А поверх присноблядьпамятного docsis, когда у тебя помеха пошла по одному из каналов, и у тебя на три секунды 80% потерялось, а потом снова ок?
> Смотреть видео с постоянными перерывами
Я понял, в чем наше непонимание именно тут:
Ты считаешь, что если у меня проебался пакет, то у меня хуйвый интернет, и я всегда буду проебывать N% пакетов, верно?
В таком случае у меня выбор: задержаться на секунду, или сомтреть на квадратики. Ты выбираешь первое, и это логично.
Я же опровергаю в том утверждаю, что потеря пакета может быть временным явлением.
bormand # 0 ⇈
А может быть и не временным. Заранее ты не угадаешь. Но один артефакт/буферинг зритель потерпит. На втором начнёт плеваться и уйдёт на другой сервис у которого с задержкой но стабильно.
И ты не объяснишь человеку, что это его личная проблема с интернетом. Другие сервисы же нормально идут, лол.
Desktop # 0 ⇈
В своё время ЮТуб был диким тормозом, но народ на какой-нибудь Vimeo массово не побежал.
Вопрос в контенте и позиционировании. А стандарты качества у массового пользователя упали, к сожалению
guest # 0 ⇈
Ок, ты этого не знаешь.
Если у пользователя всегда теряется 10% пакетов (вариант Госта), то действительно лучше взять TCP, а не смотреть на квадраты
Если же у тебя временный проеб, то я не понимаю, зачем TCP.
Вы хотите сказать, что "вариант госта" с постоянным проёбом N% более распостранен, чем мой вариант с временным проебом ?
Мне это странно, правда.
Когда у меня в течение секунды нет интернета -- я не считаю это проблемой
Если у меня всегда проебывается половина пакетов -- я звоню провайдеру
gost # 0 ⇈
Для любования на квадраты через «UDP» тебе не нужна потеря половины пакетов, тебе достаточно терять сотые/тысячные доли процента. А это — вполне нормальный режим работы Интернета.
bormand # 0 ⇈
Особенно если рядом торрент качается, лол.
bormand # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
Собственно на 10% я уже позвонил провайдеру.
gost # 0 ⇈
То, потери пакетов в обычном режиме очень небольшие, сотая доля процентов, например. Простым пингом на четыре пакеты ты их, разумеется, не увидишь.
Типичный стрим — это постоянный видеопоток примерно на 5 мегабайт в секунду полезных данных (40 мегабит). Путём несложных грубых вычислений можно убедиться, что 5 мегабайт в секунду с MSS 1400 — это как минимум 5* 1024**2 // 1400 = 3744 IP-пакета в секунду. То есть, если у тебя теряется 0.003% (три тысячных доли процента) пакетов, то наблюдать квадратики ты будешь раз в десять секунд. Через «TCP», в свою очередь, ты таких потерь в принципе не заметишь.
> Да ну? А поверх 11n он не работает, когда ты внутри ESS переключился на другую станцию, и в этот момент проебал пакет?
Я вообще-то про магистрали, но да ладно, похуй.
guest # 0 ⇈
Тем не менее, я не понимаю, почему
>Я вообще-то про магистрали
Разве пользователь сидит не дома?
gost # 0 ⇈
Ну что ж такое, мы же это уже выяснили.
>>> Таким образом, я сосу болта до следующего ключевого кадра, верно?
Ты будешь смотреть на квадратики по одной-двум секундам раз в десять секунд (я — на квадратики по одной-двум секундам раз в пол-секунды, ага).
> Разве пользователь сидит не дома?
Потому что пакеты теряются далеко не только на линии между пользователем и оборудованием провайдера. Они теряются на всём пути от сервера «Твича» и до компьютера пользователя.
guest # 0 ⇈
>Потому что пакеты теряются далеко не только на линии между пользователем и оборудованием провайдера
Ну вот я пинганул яндекс комментом ниже.
Я не живу в сервеной Яндекса, честно.
При этом
Sent = 600, Received = 600, Lost = 0 (0% loss),
bormand # 0 ⇈
guest # 0 ⇈
defecate-plusplus # 0 ⇈
Не выезжая из Москвы
bormand # 0 ⇈
gost # 0 ⇈
Это означает, что пользователь будет смотреть на чёрный квадрат/месиво из квадратиков. Не заметить такое можно только когда ты отвернулся от экрана.
P. S. Минус нечаянно въебал, извини.
bormand # 0 ⇈
gost # 0 ⇈
gost # 0 ⇈
Два потерянных пакета на 6293 посланных. То есть, в примере с пятимегабайтным потоком, я буду наблюдать квадратики примерно два раза в секунду.
guest # 0 ⇈
Мы живем с тобой в разных мирах, видимо.
guest # 0 ⇈
gost # 0 ⇈
guest # 0 ⇈
Сейчас перезапущу с нормальной
gost # 0 ⇈
(Тут я минуту держал вместо пяти)
guest # 0 ⇈
Проеблось 3 пакета из 38164
gost # 0 ⇈
Ну можно ещё килобатными пакетами попинговать для большего приближения к реальности, ну да это неважно.
> Проеблось 3 пакета из 38164
То есть примерно каждые три секунды ты будешь наблюдать квадратики. Именно для этого и нужен «TCP».
guest # 0 ⇈
В течение какого времени?
Надо еще учитывать, что ya.ru это не видеохостинг, и отвечать мне на ping они вообще не обязаны.
gost # 0 ⇈
Зависит от кодека, но никак не меньше нескольких (возможно, десятков) кадров. Повторюсь, не заметить такое сложно.
> Надо еще учитывать, что ya.ru это не видеохостинг, и отвечать мне на ping они вообще не обязаны.
Для любых других серверов картина ничуть не лучше. Постоянная небольшая потеря пакетов — это зло, от которого избавиться в принципе невозможно. Ну, разве что провести оптику от твоего компа к серверу «Твича».
Кстати, я совершенно забыл упомянуть, что порядок прихода пакетов в «UDP» не гарантирован. Поэтому для передачи видео по «UDP» тебе в любом случае придётся реализовывать подмножество «TCP» с сегментами и их буфером.
guest # 0 ⇈
Если у пользователя постоянно теряется часть пакетов, то TCP более предпочтителен: он забуферизирует данные, сделав процесс smooth для пользователя: он будет перепосылать сегменты, пока пользователь смотрит видео.
UDP же ничего не буферизирует, соответственно потерянные пакеты это квадраты до следующего ключевого кадра.
В случае же, если у пользователя потеря пакетов случается редко, но метко (в течение пары секунд теряется 100%, а потом всё ок) то разницы между TCP и UDP нет.
Однако, TCP это бОльшая нагрузка на CPU.
Если у видеопровайдера есть пиринг с оборудованием провайдера, то пакеты скорее всего ПОЧТИ не будут теряться вовсе (внутри провайдера они не теряются, иначе IPTV мультикастом бы у меня не работал, все же понимают, что мультикаст это UDP, правда?).
Если же связь с провайдером у него через какие-то tier 1 сети, то проеб может быть.
Итого: если мы уверены в более-ли-менее качественном интернет-соединении, то имеет смысл использовать UDP.
Если нет, то TCP, так как он успеет забуферизировать видео прежде, чем буффер опустишится, и пользователь увидит хуй.
gost # 0 ⇈
> TCP более предпочтителен: он забуферизирует данные, сделав процесс smooth для пользователя: он будет перепосылать сегменты, пока пользователь смотрит видео.
На самом деле не совсем. Существует два буфера: системного уровня, который заполняется ядром (драйвером TCP/IP), и буфер браузера. В первом хранятся сегменты TCP, во второй браузер складывает кадры видео.
«TCP» гарантирует, что последовательность байт, отправленная с сервера, обязательно дойдёт до клиента без изменений и в правильном порядке (что тоже крайне важно, кстати). Буферизация видео браузером, в свою очередь, обеспечивает пользователю плавное воспроизведение даже тогда, когда приход очередной порции байт с сервера задерживается (драйвером TCP/IP) из-за потерь пакетов.
> Однако, TCP это бОльшая нагрузка на CPU.
По сравнению с декодированием 60@FHD видео — это настолько мелкие копейки, что ими нужно пренебречь.
> Итого: если мы уверены в более-ли-менее качественном интернет-соединении, то имеет смысл использовать UDP.
Да, но такое будет только если сервер и клиент соединены напрямую одним кабелем. И даже в этом случае пользователь может поставить качаться торрент и получить багор.
Увы, Интернет — крайне непредсказуемое говно, поэтому получить по-настоящему надёжное соединение до удалённого сервера, к сожалению, невозможно. Возвращаясь к примеру выше, чтобы надёжно передавать видеопоток через «UDP» и получать квадраты хотя бы не чаще раза в минуту, нужно терять не больше одного пакета из 224640.
guest # 0 ⇈
Я говорю с точки зрения провайдера: он может стримать UDP, и это позволит ему сэкономить ресурсы.
>Да, но такое будет только если сервер и клиент соединены напрямую одним кабелем.
Тогда почему у меня нормально работает IPTV по мультикасту от провайдера?
У меня есть роутер, есть роутер провайдера, и есть сеть до стримающего сервера (через тот самый рандеву поинт).
Я включаю телек, секунды три смотрю на "wait" (жду подключения, начала стрима, и ключевого кадра?) и дальше видео работает без квадратиков
Видимо, нужно читать спеку по кодеку, а я уже пьяный. Спокойной ночи))
gost # 0 ⇈
Настолько мизерные крохи ресурсов, что ими можно и нужно пренебречь. Там одно только TLS-шифрование потока сожрёт на два порядка больше ресурсов, чем обработка «TCP».
> Тогда почему у меня нормально работает IPTV по мультикасту от провайдера?
Нужно смотреть протокол и кодирование. Я же не говорю, что по «UDP» в принципе нельзя передать видео, я говорю о том, что это очень сложно и геморройно. Можно жать кадры по отдельности, тогда небольшая потеря пакетов действительно не будет заметна. Можно впендюрить десяток-другой процентов избыточности. Ещё как-нибудь извратиться.
Спокойной ночи.
gost # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
Там такая дикая зависимость между кадрами, что всё на квадратики рассыпется до следующего ключевого. Не особо лучше чёрного экрана.
guest # 0 ⇈
Чем "buffering.." лучше квадратиков?
А TCP ведь нагрузка на CPU
gost # 0 ⇈
Тем, что «buffering» тебе покажется один раз. Потом буфер разработается и никакой буферизации у тебя не будет.
guest # 0 ⇈
В UDP же ты будешь переодически смотреть на квадраты, но не отстанешь
нет?
bormand # 0 ⇈
guest # 0 ⇈
Это спорно: я не хочу отстать на 10 секунд от игры в дум.
Но если им правда приятнее, то ок
Fike # 0 ⇈
извините, я не смог не
gost # 0 ⇈
> ты проебал пакет, и получит передачу всего говна
Что? Какого говна?
3.14159265 # 0 ⇈
Не совсем правда.
Можно удачно проебать B-frame, на который никто не ссылается.
Можно проебать P-frame, но на следующем обновить.
Кодеки очень адаптивные и резистетные к ошибкам на самом деле.
Очень сильно зависит от настроек адаптивности энтропии и кодека.
guest # 0 ⇈
UDP не передаст, и если ты потерял ключевой кадр, то будут квадратики, верно?
Рассмотрим ситуацю, когда ты потерял НЕ ключевой кадр.
В UDP ты этого не заметишь
в TCP ты будешь вынужден смотреть на "buffering", пока ты не переполучишь кусок с потерянным кадром, нет?
bormand # 0 ⇈
Не, на него хуй забьют. buffering будет пока буфер не наполнится на безопасную для твоего канала глубину.
guest # 0 ⇈
gost # 0 ⇈
Нет. Потеряться может только IP-фрейм (1500 байт брутто). В таком случае «TCP» просто передаст этот фрейм ещё раз.
> Рассмотрим ситуацю, когда ты потерял НЕ ключевой кадр.
> В UDP ты этого не заметишь
Нет, не так. Если я потерял НЕ ключевой кадр, то у меня ВСЕ последующие НЕ-ключевые кадры превратятся в квадратики. То есть, в зависимости от кодека, я буду эдак секунду-другую (точное время надо у кодировочных петухов спрашивать) смотреть на квадраты.
> в TCP ты будешь вынужден смотреть на "buffering", пока ты не переполучишь кусок с потерянным кадром, нет?
Нет, см. первый абзац.
guest # 0 ⇈
Стоп. Давай определимся с терминологией: IP пакет размером 1500 байт, что такое фрейм?
TCP передаст сегмент целиком, не?
>. Если я потерял НЕ ключевой кадр, то у меня ВСЕ последующие НЕ-ключевые кадры превратятся в квадратики
Тут я видимо плохо понимают видеокодеки.
Разве не ключевой кадр это не diff к предыдущему ключевому?
В чем тогда разница между ключевым и обычным? В том, что ключевой ни от чего не зависит>?
gost # 0 ⇈
Перепутал с «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».
guest # 0 ⇈
Вот где собака порыта.
Таким образом, я сосу болта до следующего ключевого кадра, верно?
Получается, что если ключевой кадр примерно синхронизирован с границей сегмента, то разницы между TCP и UDP нет: я или смотрю на квадратики до следующего ключ кадра, или смотрю на "buffering"
Однако, если я верно понял Пи и Десктопа, то ключевой кадр может быть размазан на несколько пакетов, и тогда я могу потерять синхронизацию для части изображения, и в случае TCP я буду смотреть на "buffering", а в случе UDP я буду смотерь на верхнюю половину экрана (снизу будут квадратики), так?
gost # 0 ⇈
Да.
> я или смотрю на квадратики до следующего ключ кадра, или смотрю на "buffering"
Нет. Ключевая разница в том, что в «TCP» ты смотришь на «buffering» один раз, после чего буфер у тебя разрабатывается, и дальше ты видишь только плавную картинку без единого разрыва.
> то ключевой кадр может быть размазан на несколько пакетов
Не знаю, не видел этой технологии.
guest # 0 ⇈
..и ты смотришь всё, с отставанием в N секунд?
Если у меня больше нет потерь, то я и на UDP все вижу
Если они есть, то я еще много раз увижу "buffering", и в итоге отстану на много секунд
bormand # 0 ⇈
Т.е. если у тебя буфер 10 секунд, то у тебя есть почти 10 секунд на загрузку каждого чанка. Ну и собственно отстаёшь от реалтайма ты на эти самые 10 секунд. TCP за это время без проблем успевает всё перепослать и переполучить.
Ну а если канал пиздец хуёвый и не успевает - значит будешь жить с буфером в 20 секунд. Хотя обычно после такого просто качество скидывают.
guest # 0 ⇈
Похоже, что разница всё таки в формате проеба: если он постоянный, то TCP гарантирует мне smooth видео (хотя и с отставанием, если я не успею заполнить буфер), если он временный, то в TCP я отстану без всякой причины: лучше бы посмотрел кубики 2 сеу
defecate-plusplus # 0 ⇈
Ты качаешь по хттп плейлист и по хттп начинаешь качать чанки. Понимая, что плейлист - активный стрим, ты перезапрашиваешь плейлист раз в эн секунд, чтобы узнать о новых свежих чанках, которые тоже будешь сливать с сервера по хттп.
Плеер твой может догадаться, или ты сам, о том, что твой канал говно, он не успевает вовремя качать, все тормозит и дёргается - есть возможность переключиться на качество похуже (чанки будут за те же промежутки времени, но по размеру меньше заметно).
Вот в этой схеме задержку менее 15 секунд практически нереально получить (потому что чанк должен быть не на 1 секунду), а оптимально - 60 секунд.
Когда ты смотришь футбол онлайн, это норм, когда смотришь куранты с путиным на новый год - это тоже приемлемо.
А вот для диалога - нет.
bormand # 0 ⇈
Desktop # 0 ⇈
Впрочем, для этих целей наверняка лучше использовать вменяемые текстовые трансляции.
Интересно, какая задержка при ТВ-трансляции
defecate-plusplus # 0 ⇈
если спутник
Myxa # 0 ⇈
gost # 0 ⇈
guest # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
defecate-plusplus # 0 ⇈
3.14159265 # 0 ⇈
Да. И это гнусно что HLS кругом.
Впрочем на твиче лайф-стримы. Для них это как раз вполне нормально.
3.14159265 # 0 ⇈
И они их могут ворецировать как пожелают, адаптивно меняя качество под скорость канала пользователя.
bormand # 0 ⇈
3.14159265 # 0 ⇈
> Чтобы можно было быстро переключаться на хуёвое качество и обратно.
Это называется 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/
Desktop # 0 ⇈
gost # 0 ⇈
Да нет, они в последнее время серьёзно за её уменьшением гонятся (как и «Ютуб», кстати). Две секунды задержки от компьютера стримера — это реальный пример.
guest # 0 ⇈
defecate-plusplus # 0 ⇈
Ффмпег ебаный это уже секунда, даже если ты такой охуевший и в полуреальном времени срешь на клиенты по вебсокету (а не мпег-даш/хлс), 2 секунды и массовость звучат фантастично
(И главное, зачем? Что плохого в задержке, например, 30с?)
Я прост далёк от блогиров, но тема интернет вещания регулярно возвращается в контекст
gost # 0 ⇈
Не знаю, я на «Твиче» специализируюсь. Реальный пример: https://i.imgur.com/DGN5EK0.png.
Правда, меня смущает размер буфера: если буфер 2.06 секунд, а задержка — 2.09, получается, мне от стримера кадры приходят за 30 миллисекунд?..
Наверное, «Твич» всё таки запутался в терминах, и реальная задержка (отставание часов на экране стрима от моих локальных) там 4.15 секунды.
> И главное, зачем? Что плохого в задержке, например, 30с?
Ну типа мгновенная реакция на чат, все дела.
defecate-plusplus # 0 ⇈
Диалог в конфе овер, скажем, 50, вести сложновато.
Ну разве что в твиче модный блогир типа тоже диалог ведёт, с текстовым чатом. Ясно
gost # 0 ⇈
Подтверждаю. Интерактивность.
guest # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
Блядь, как хорошо, что я не блогер.
Я один раз в жизни давал ток, так что чуть не обосрался со страху от вопросов.
Как люди могут в реальном времени что-то отвечать -- я хз, надо QNX внутри иметь
> Ты же видел типичный поток комментов на твиче?
О сущестовании твитча я узнал час назад от вас
Desktop # 0 ⇈
bormand # 0 ⇈
3.14159265 # 0 ⇈
Сорянчик, что вмешиваюсь в экспертную беседу со своим профанизмом.
https://youtu.be/LsF5bHRxC_M?t=234
В принципе там довольно подробное описание работы твитча.
bormand # 0 ⇈
guest # 0 ⇈
Бесполезно
я пытался
Desktop # 0 ⇈
guest # 0 ⇈
больной ублюдок
3.14159265 # 0 ⇈
Да. И Экселя не знает. Ну его нахуй.
3.14159265 # 0
https://govnokod.ru/25131
3.14159265 # 0
А там такое:
CDF — энтропийное кодирование.
За сим иду спать. Доброй ночи.
Myxa # 0 ⇈
3.14159265 # 0 ⇈
3.14159265 # 0
1. Взять ffmpeg+x264 зожать.
2. Пропустить через какой-нибудь tc с заданным дропом.
3. Воспроизвести полученный файл ffplay.
MAKAKA # 0 ⇈
только man tc-netem вроде)
MAKAKA # 0
Если видео записано заранее, то лучше всего взять Adaptive bit rate, когда сервер разбивает всё на кусочки, а клиент выбирает следующий чанк нужного размера.
Если клиент сидит на iPhone через сотовую сеть, то он выберет кусочек с худшим качеством (и худшего размера)
А если у него телек на пол стены по гигабиту, то может позволить себе чанк по лучше
Все эти проты работают по TCP, и это понятно: клиент может накачать себе чанков за щеку, как хомяк, и их показывать.
А если видео стримается в реальном времени? Если это видеокамера с улицы?
Я не смогу наполнять буфер быстрее, чем я его опустошаю, какой же тут толк от TCP по сравнению с UDP?
Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Можно конечно забуферизировать данные, и показывать камеру с отставанием, но если это видеозвонок или прямой эфир, и туда можно звонить? Тогда отставать мне нельзя.
gost # 0 ⇈
А зачем? Ты открываешь стрим, браузер закачивает две секунды стрима и начинает тебе его показывать, параллельно закачивая следующие две секунды потока. В «UDP» будет то же самое: тебе так же надо организовать буфер в несколько секунд видеопотока, чтобы, во-первых, восстановить порядок UDP-пакетов (они к тебе придут перемешанные), а во-вторых — не раздражать пользователя из-за флуктуаций пинга (видео, в котором каждый кадр показывается с задержкой +- пару миллисекунд от номинальной будет выглядеть очень… своеобразно).
> Получится, что потерянные пакеты приведут или к замиранию картинки, или к buffering.
Только в том случае, если у тебя теряется порядка процента и больше пакетов, и то только ОДИН РАЗ. После этого одного раза буфер разработается и buffering не будет, за счёт увеличения задержки.
Desktop # 0 ⇈
gost # 0 ⇈
Desktop # 0 ⇈
Помню, как на стороне заказчика юные телекомщики с восторгом рассказывали, как они поменяли с TCP на UDP и всё полетело.
Думал, что в видеостриминге в принципе это норма, но вы меня переубедили.
MAKAKA # 0 ⇈
OpenVPN может по udp, чтобы не делать накладных расходов
gost # 0 ⇈
Точно, про него забыл. В «OpenVPN» запилен свой протокол, обеспечивающий надёжность передачи данных, поэтому гонять его по «TCP» — практически бессмысленное занятие.
MAKAKA # 0 ⇈
А зачем VPN надежность? Интернет же ненадежен, и поверх него работают другие проты. VPN вполне себе может эмулировать такой вот ненадежный Интернет
bormand # 0 ⇈
guest # 0 ⇈
gost # 0 ⇈
Да, и про это забыл. Пускаем «VPN» на 443-й порт и течём.
> А зачем VPN надежность?
Надо читать протокол. Могу предположить, что он у них завязан на последовательное получение сегментов (типа «AES CBC»), тогда любая потеря пакета приведёт к разрыву соединения.
MAKAKA # 0 ⇈
>восстановить порядок UDP-пакетов
Пришедший в неверном порядке пакет можно же просто отбросить?
Если браузер всё равно имеет свой буфер, то зачем мне еще и буфер tcp?
>После этого одного раза буфер разработается и buffering не будет, за счёт увеличения задержки.
А как это всё будет работать с прямым эфиром или видеозвонком?
gost # 0 ⇈
Да.
> Пришедший в неверном порядке пакет можно же просто отбросить?
Можно. Тогда у тебя останется примерно половина пакетов, может даже меньше.
> Если браузер всё равно имеет свой буфер, то зачем мне еще и буфер tcp?
Потому что это два разных буфера с разными функциями. Буфер «TCP» нужен для восстановления исходного потока байт с сервера, буфер браузера — для обеспечения плавного воспроизведения видео без прерываний.
> А как это всё будет работать с прямым эфиром или видеозвонком?
Для прямого эфира это совершенно непринципиально (так, например, многие играющие в онлайн-игры стримеры специально выставляют задержку в одну-две минуты, чтобы противники не могли подсмотреть стрим и получить преимущество). Для видеозвонков используются либо более мелкие буфера, либо какие-то формы избыточности (возможно, в связке с «UDP», надо смотреть протоколы).
MAKAKA # 0 ⇈
А есть какая-то статистика на этот счет?
>Потому что это два разных буфера с разными функциями.
То-есть TCP нам нужен исключительно для восстановления порядка?
>для видеозвонков
Ну вот skype используе UDP
https://support.skype.com/en/faq/FA148/which-ports-need-to-be-open-to-use-skype-on-desktop
Если ты утверждаешь, что половина пакетов у меня потеряется или придет в неверном порядке, то как же эту проблему решает скайп?
Сам восстнавливает порядок пакетов?
bormand # 0 ⇈
Проблема не столько в порядке, сколько в джиттере - задержку постоянно "трясёт". Поэтому точно так же поток приходит кусками и какое-то время отстаивается в буфере.
MAKAKA # 0 ⇈
Так буфер у них свой, выполнящий и буферизацию, и восстановление порядка, итд, а сами они по udp?
Desktop # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
Большой оверхед для такого мелкого буфера?
bormand # 0 ⇈
А если большая задержка допустима, то мы уже можем реализовать повторы. И здесь, чтобы не изобретать велосипед, можно взять TCP.
guest # 0 ⇈
TCP используют тогда, когда допустима задержка в несколько секунд, иначе используют UDP.
gost # 0 ⇈
guest # 0 ⇈
Для просмотра стрима я могу позволить себе задержку в 100ms, а для разговора -- нет, иначе собеседник подумает, что я тормоз из анекдота "дяденька, я не тормоз"
gost # 0 ⇈
gost # 0 ⇈
Нет, только эмпирические наблюдения за «tcpdump».
> То-есть TCP нам нужен исключительно для восстановления порядка?
Для восстановления порядка и восстановления потерянных пакетов.
> то как же эту проблему решает скайп?
Изобретением своего велосипеда. Поверх «UDP» написан охулиард протоколов разной степени надёжности, в той или иной мере копирующих «TCP». См. «RDP», «RUDP», «ENet», «GameNetworkingSockets», тысячи их.
MAKAKA # 0 ⇈
Надо бы проверить. Почему половина пакетов идет в другм порядке? Потому что разными путями идут?
RDP работает и поверх UDP и поверх TCP, кстати
Когда хорошее подключение, он мигрирует на UDP))
Вопрос: почему же WebRTC, Skype, RTP и пр не использовали tcp?
gost # 0 ⇈
> 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/
guest # 0 ⇈
Это правда не отвечает на вопрос "зачем"
Может быть дело в накладных расходах на TCP, стейтфул соединениях на уровне ОС итд?
gost # 0 ⇈
Ну и ещё есть «NIH».
guest # 0 ⇈
То-есть TCP дает мне то, без чего можно впринципе обойтись, и это не бесплатно
defecate-plusplus # 0 ⇈
guest # 0 ⇈
gost # 0 ⇈
>>> Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
guest # 0 ⇈
Я сказал, что TCP не знает, какой кадр у тебя ключевой, и вообще ничего о кадрах не знает, потому будет заставлять тебя обрабатывать все пакеты, даже те, которые можно потерять, ценой задержки.
Правда, я не учел, что для обычного видео (не видеозвонков) задержка не важна
зы: ну и при diff кадров я думал неверно, так как считал, что они все диффятся от ключевого кадра, а не от предыдущего
bormand # 0 ⇈
Иногда и от последующих, лол.
Desktop # 0 ⇈
но посмотри уже наконец, пожалуйста, как пишется "то есть", а то кровь из глаз
guest # 0 ⇈
Desktop # 0 ⇈
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
gost # 0 ⇈
Ну, то есть они изобрели «TCP», оптимизированный для их протокола и профиля использования. Тоже валидный кейс.
Desktop # 0 ⇈
Зачем им изобретать TCP, пусть даже оптимизированный, как ты говоришь, если TCP уже есть? Это оверинжениринг
gost # 0 ⇈
Ну так это и есть изобретение велосипеда. В данном случае, конечно, оправданное: велосипед у них получился специализированный и более подходящий для решения их задачи, вот такой: https://www.youtube.com/watch?v=PIoUKPeWVjQ.
Desktop # 0 ⇈
Интересно, Борманд так и не заинтересовался Твитчем и видеостримингом после этих всех бесед? По-моему, такое широкое минное поле для байтоёба!)
bormand # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
MAKAKA # 0 ⇈
guest # 0 ⇈
All of the processing is done directly by the browser
TCP тут не причем
Desktop # 0
Стрим с камеры, задержка ~30 секунд