Может кто-то помочь поднять матчасть по HLS и около?

Докинь оперативы.

Ты запостил в толксы, так что считаю корректным такой ответ.

3840x3840 7680x3840

Попробуй выбрать другой кодек. Временно, это может решить проблему, если алгоритм кодека заточен на прямоугольники 2x1 (к примеру).

Это совет чисто по интуиции, когда-то приходилось разбираться с IFFT.

Под хлс один кодек - h264.

(3840x3840). Казалось бы, по «числу пикселей» они равны обычному 7680x3840

o_O

Вот видишь - насколько я тупой :)

Что себе позволяет этот виндузятник?

Что себе позволяет этот виндузятник?

Посоветуй ему нарéзать квадратные кадры видеопотока на прямоугольники.

лучше на круги

hls
ffmpeg
m3u8

Я не разбираюсь в этой теме, просто накидаю тебе линков, может что-то подскажет:
https://habr.com/ru/post/178267/
https://www.aicoosoft.com/m3u8-converter/ffmpeg-m3u8.html
https://dev.to/nodir_dev/transcode-video-source-to-hls-playlist-format-for-vi...

Из забавного: Нашел адовую проблему при сжатии «квадратных» файлов (3840x3840). 64гб памяти не хватает, чтоб сразу в 5 потоков запускать конвертацию (ядер то хватает с запасом - часть проца простаивает). Выжирается все, свап выжирается, и ффмпег падает. 4 потока тянет. В результате приходится разные наборы разрешений-битрейтов жать «по частям», а потом руками скрипты склеивать.

В соседнем проекте тоже что-то там ffmpeg'ом кодируют — жаловались, что на некоторых файлах он память жрет как не в себя.

Да это все понятно.

Я про практические нюансы применения. И создания плейлистов правильных сразу ффмпегом, а не «в блокноте».

нет правильного, зависит от задачи, ну и нарезать ровные сегменты желательно с красивым закрытым гопом ipbbpbbp… для этого отпинать через ffmpeg x264 так, чтобы он не мудрил с гопом

Эт тоже знаю :)

У меня насущных вопросов два главных:

• Правильное создание плейлистов. У меня даже average-bandwidth нет в них (лишь bandwidth и тот какой-то кажущийся некорректным немного)
• Как всеж осилить н265 для яблок отдельно пихать. Я нашел пару примеров (тема плохо гуглится), но не играет оно никак, хотя все рекомендации выполнил. Хочется еще немного кпд битрейта выжать.

• на первый и второй взгляд в исходники ffmpeg, в нем нет average-bandwidth, ну и mediastreamvalidator тут должен подмочь
• ведь есть mediastreamvalidator эпловский для проверки

Т.е. придется таки внешний парсер натравливать на лог ффмпега (или чего хуже - файлов россыпь замерять) и его выхлоп в плейлисты писать?

За утилиту пасиба. Чую я все ближе к покупке макбука для тестов всяких.

сначала validator натравить, мне понравился братишка https://www.martin-riedl.de/2020/04/17/using-ffmpeg-as-a-hls-streaming-server-overview/ без парсеров(?) справился, вдумчиво и рекомендации apple ознакомился

ну ничего страшного, виндой-то обмазан, об макбук не зашкваришься уже

и\или найми сишичника, пусть напатчит ffmpeg под твои нужды и в апстрим напихает доброты

Да, этого товарища читал. Один из самых адекватных, а не копипастер. Надо еще у него со структурой каталогов перенять опыт.

Да я бы с удовольствием нанял и оплатил такого сишника, но у меня не хватит ума выбрать адекватного. Да еще чтоб потом реально его патч приняли.

Из забавного:

• Входной файл 3840х3840.
• Жмется в 4 разных crf (с ограничениями потока). Указан «ресайз» в 3840х3840 (оставил так еще с той версии скрипта, когда разные ресайзы вместе делал, от мелкого до оригинального).
• И… фатально низкая производительность. Процессор простаивает. Рама выжрана под ноль. Очень медленно идет. Условно 1-1.5 фпс даже на пресете medium (что для 7950х просто нонсенс).
• Убрал из потоков «рейсайз из 3840х3840 в 3840х3840», внеся его как глобальный параметр для скрипта вообще - и получил буст более чем в 15 раз. Проц стал уже загружен на 80-90%. Памяти жрет чуть меньше.
• Выходит, что хотя и не требовался ресайз, то оно что-то жевало и тупило.

И самый бред:

• Описанный выше проблемный медленный скрипт… работал так на амд. А на интеле (9900к) он молотил шустрее, 2-2.5 фпс, при 100% загрузке процессора.
• КАК БЛЕАТЬ?! (т.е. 16с\32т 5ггц работал в 1.5 раза медленнее, чем 8с\16т 4ггц, на одном и том же скрипте физическом, одном и том же файле входном)

не хватает просто горы информации, что за файл, какой контейнер, что внутри, какая конкретно царь строчка запускалась, какой окружение(тут не только билд винды, но и шапка ffmpeg, он зря по умолчанию каждый раз вываливает)

на вскидку ресайз это не только лишь изменение геометрии, но и изменение pix_fmt если ffmpeg посчитал это нужным или указано в параметрах, внутри swscale мощное макрокомбо посыпанное для разных специальных случаев раным асмом для оптимизации; навыки чтения -v debug также не помешают

Я понимаю, не стал грузить деталями. Все равно никто не побежит проверять и смысла нет. Это иллюстрация на тему граблей по которым хожу. Речь про то, где в скрипте указан -vf scale=3840:-1. Оказывается, перестановка этих слагаемых имеет значение.

pix_fmt был одинаков на входе и выходе и задавался ранее при создании мастер копии. (и вообще всегда явно задается)

Но как один бинарник по разному отработал на интел\амд у меня теорий нет.

Под хлс один кодек - h264.

HLS-плейлист ссылается на ts-чанки, которые могут содержать любой кодек. Другое дело, какие кодеки поддерживает целевой клиент

Вообще ни разу не видел реализаций hls на vp9 (ну кроме решений гугла на ютубе). Я ошибаюсь?

зачем теории, зачем столько удивления, полностью уверен, что в виндовсе как и в линуксе достаточно инструментов, которые точно ответят на вопрос почему ffmpeg в каком то конкртеном случае тормозит, в другом кушает память… (если только не старый виндовс) ; другое дело, что трейсить сишечку трудоемко

HLS-плейлист ссылается на ts-чанки

не только лишь на «ts» чанки

Другое дело, какие кодеки поддерживает целевой клиент

как максимум, то что можно напихать в mpegts, кроме h264 и h265 ничего не мертвого или распространенного

При этом н265 кроме яблок (и окулусов, внезапно) ничего считай и не играет. Так понимаю из-за лицензионных проблем.

Вообще ни разу не видел реализаций hls на vp9

для начала проверить, как vp9 эплоюзерам пихать

ну кроме решений гугла на ютубе

там hls? выглядит больше как dash

Слушай, можешь кратко пояснить механизм адаптивности по ширине канала клиента? Неужели оно и правда решает какой ширины поток кушать просто на анализе скорости скачивания первого чанка нижнего уровня плейлист? Даже если он весит несчастные пару сотен кб?

А что происходит потом? Плеер следит за «скоростью загрузки» последующих чанков и думает не понижать ли поток (битрейт)?

И совсем глупый вопрос (т.к. тут надо уже конкретный хлс плеер смотреть и его работу), но в среднем по больнице: Пусть есть потоки:

• 4к 5мбит
• 4к 3мбит
• 3к 4мбит
• 3к 2мбит

Плеер будет ориентироваться только на битрейт? Т.е. если канал не переваривает 5мбит, то он будет пробовать сначала «3к 4мбит», и лишь потом «4к 3мбит»?

как бы не понимаю почему андроидам не играть? тут скорее виндовс судя по википедии отличилась, сначала внедрила потом выкинула, не договорилась

поэтому следующая итерация h266 запиливает сразу профайл по которому они обещают не трогать за попу потентами, как baseline в h264; av1 животворящий

6к\8к я в своих поделиях (360 видеопанорамы в браузере, единым файлом, без hls) отдаю как раз в vp9. Кроме сафари на десктопе все жрут и радуются.

там hls? выглядит больше как dash

Хорошее замечание. Надо копнуть. И вообще DASH посмотреть. Тут хлс как метафора был.

Я состарюсь, пока av1 реально станет повсеместным %)

… т.к. тут надо уже конкретный хлс плеер смотреть и его работу

но ведь это детали реализации плеера, особенно для apple они одни остались с закрытым браузером, зато играют в айфоне hls из коробки, только вот если не играют, ручек для отлдаки конечно не дают

для всего остального внтури все юзают hls.js, он то открытый и достаточно документированный

Кроме сафари на десктопе все жрут и радуются.

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

hls.js и прикручиваем к проекту, да.

С ним все хорошо кроме того, что на ios нет адаптивности )) Т.е. грузит максимальный уровень и все. В результате мне приходится для яблок городить отдельный комплект файлов. Оптимизированный (сжатый) по самое нибалуйся.

Да, я поржал со знакомых маководов, что ни один из них сафари не юзает, кроме как для загрузки хрома.

разве на ios hls.js работает? насколько себе представляю, там нативное проигрывание hls в video, а значит сражение с ios, а значит validator пожалуйста, сначала, чтобы он не жаловался

Да. Играет на ios. Но без адаптивности. Но все равно лучше, чем единый файл гонять.

ну тоесть, можно было сразу в топике сообщить, что собираю из ffmpeg и палок hls и он не играется адаптивно на ios, а везде вокргу на hls.js работает и улыбается и ответ был бы ровно один - сходи и посмотри в mediastreamvalidator

и не нужен никакой ментор по hls

Да нужен практик с опытом… нужен.

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

Сколько уровней «качества» может быть в плейлисте главном. Како-того явного требования\ограничения я не вижу ни в доках яблочников, ни в рфц на хлс. Но пару раз натыкался, что типа максимум 9 (с чего вдруг…). Есть ли какая-то практическая рекомендация?

Или из-за чего может плеер не брать «максимальное» качество из четырех доступных. Битрейт ни разу не конский, канал до тестового сервера находящегося в метре - 10 гигабит.

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

Завтра буду втыкать в выхлоп https://hls-js.netlify.app/demo/ своими видосами, и пытаться опытном путем выяснять разное.

Какие ответы интересно ожидаются тут, какие то простые которые решают все проблемы чем-то односложным, типа выбирай 42 секунды и будет все хорошо?

Если посмотреть тред то исходной информации для ответа на некоторый из этих вопросов крупицы, для других нет вообще. Ну и все они достойны заведения тикетов и работы над ними. Мимо проходящий я практик не вижу конструктивности. Выглядит как просто некие крики души, чтобы сбросить напряжение, как звонить в службу поддержки провайдера и ругатся, сообщая только «ничего не работает, ни единного разрыва» и не отвечать даже номер договора.

Если это максимум конструктиваности, то может проще пойти и купить готовое решение с саппортом, там инженеры прибегут и настроят, ты вместо упражнений вокруг ffmpeg, кодеков, контейнеров, плееров пойдешь заниматься профильным чем нибудь, снимать там видео или откуда оно там

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

Ты перегибаешь в другую сторону уже.

Изначальный запрос был «кому бы из практиков дать денег за попытки разумных ответов на мои не очень разумные вопросы».

«Практик» и скажет про длину чанка и т.п.

Опытный человек экономит кучу времени неопытному.

Ты в фотографии сильно понимаешь? Если нет, я твою матчать мог бы резко поднять буквально за 1-2 часа. Сэкономив тебе недели и месяцы. Ну вот так и тут.

Купить мне нечего (кроме времени такого практика частника). Ибо сервисы заточенные на онлайн не подходят совсем. Все должно быть свое и офлайн.

Беда в том, что я не могу сам выбрать адекватного погромиста под это все. А те, кому просто доверяю - они с таким не работают и не берутся.

так понятнее, не можешь найти человека, купи готовое решение и занимайся фотографией

Делал такое в 2018м году, но для музыки. Не конвертировал, просто делал copy, так как большинство музыки уже было mp3. Из «сложного» в плане кодирование, главное проверять, есть ли такой файл уже перекодирован или нет, иначе можно вызвать 100500 процессов ffmpeg, если работать с ним напрямую, ну и там были еще доставания с ipfs, трекинг какую часть тянут и много других тонкостей не связанных с кодированием как таковым. Вопрос размера всех сегментов вообще тогда не стоял, главное чтобы сегмент был небольшим для юзера с мобилки.

Кодирование: https://github.com/Musicoin/a.musicoin.org/blob/820baebba49ccbb2c366c6fa25a10d56a60fe31b/src/app/internal/tx-daemon.ts

Плеер: https://github.com/Musicoin/a.musicoin.org/blob/820baebba49ccbb2c366c6fa25a10d56a60fe31b/src/views/player/simple-player.ejs

Так объяви сдельную работу - починить фичу, если человек справился - найми. Но не уверен, что это в принципе чинится.

Где? Я люблю платить деньги за инструменты и решения. Но не вижу.

wowza - наверняка, прекрасна. Но мне не подходит.

Плюс у меня поверх хлс.жс еще свои надстройки.

Дай совет. По спеке «битрейт» (максимальный) - «обязателен» в плейлисте. А «средний битрейт» - «желателен». Есть ли смысл его вручную добавлять? (ффмпег не умеет, надо скрипт писать для замера и записи). Тестами на демо hls.js я не вижу разница от рисования разной дичи в среднем битрейте.

Уже как месяца 2-3 Chrome умеет в hevc, но он хочет его в .mp4 контейнере, а не .ts

Ты все еще про hls?

Ну 2-3 месяца мало. Надо хотя бы год-два. Не все обновляются.

Ага, про hls. Но актуально и для dash(тоже fragmented mp4 контейнер), да и наверное вообще все, что гоняется в через mse в подобном контейнере.

Не все обновляются

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

Дашь чего почитать?

Не знать, можно поискать что-то нужное вот тут

https://github.com/krzemienski/awesome-video#hls

здесь хз по какому принципу автор накидал все подряд.