Re: ProgTV + HTTPAceProxy + timeout

#46
О! И еще , кроме отсутствия видео на каналах и наличия звука .. .Очень часто при старте наблюдается вот такое "кино"
Image
Image
Часто если стартануть повторно тот же канал то стартует .. правда при этом видео может не быть ...

Re: ProgTV + HTTPAceProxy + timeout

#47
по состоянию на этот момент алгоритм работы такой :
1) При старте трансляции пытаемся "паковать" в буфер трансляции по максимуму сколько движок отдает по текущему каналу чанками по 8192 байта....
2) На клиента сразу начинаем выдавать чанки из буфера трансляции без всякой задержки ... параллельно наполняя буфер трансляции чанками.... Если буфер наполнился до 1000 чанков .... ставим заполнение буфера на "паузу" (по умолчанию 5 сек) и ждем пока клиент от-туда скачет и освободит место ... и снова стараемся "допаковать" буфер по максимуму ..... и так в вечном цикле. Если буфер опустошается в ноль, то ждем максимум 60 сек до появления хотя бы одного чанка и сразу отдаем его на плеер
3) Если на этот же канал подключается следующий клиент - то он получает текущий буфер данной трансляции в 1000 чанков максимум (как правило - максимум) ... и далее работает по п2

Все траблы возникают в progTV если он первый клиент ... если подключать его к уже созданной трансляции - НОЛЬ ПРОБЛЕМ ...
Как вариант чтобы победить траблу если progTV - первый клиент данной трансляции ... то можно сделать предварительную буфферизацию , аля prebuff у движка .... Но тут вопрос сколько необходимо чанков ? И сколько времени будет затрачено пока движок "набъет" это кол-во чанков необходимое для старта первой трансляции без "провала" или отвалов по timeout progTV ...

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

Re: ProgTV + HTTPAceProxy + timeout

#48
Подзапустил тему.
1. В схему работы - самое главное что бы прокси имея хотя бы один байт, тут же его отдал клиенту. Ничего не буферил. Остальное не так важно.
2. HLS же прокси формирует? Почему от "hls или ts" зависит аудио?

Re: ProgTV + HTTPAceProxy + timeout

#49
Prog wrote:
Tue May 15, 2018 6:29 pm
Подзапустил тему.
1. В схему работы - самое главное что бы прокси имея хотя бы один байт, тут же его отдал клиенту. Ничего не буферил. Остальное не так важно.
2. HLS же прокси формирует? Почему от "hls или ts" зависит аудио?
1) так и есть .. байт в байт , как только получили - сразу отдали .. Если получается читать от движка быстрее , то набивается в буфер
2) Да поддерживается ffmpeg , можно "перегонять" в любе ... Доступен весь функционал ffmpeg ...
Вопрос о "hls или ts" и зависимоти наличия аудиодорожек - это к родной проксе движка ... В случае с HTTPAceProxy - как зададите строку транскодирования для "исходящего" потока, то и получите... Кол-во правил - неограниченно ...

Re: ProgTV + HTTPAceProxy + timeout

#51
Я просто не совсем понимаю почему на hls проблемы с несколькими аудио дорожками?
Так это от прокси не зависит абсолютно.... Это AceStream, если у него в настройках установлен hls отдаёт только одну дорожку... если стоит original или http (что в принципе одно и то же) то отдаёт так как есть в источнике, тоесть с всеми дорожками... Как я понимаю здесь особенности работы движка AceStream.
Так же в движе AceStream есть возможность запрашивать тип потока не через настройки, а через API, что и делает прокся, если у неё поставить в настройках hls...
Тоесть, в настройках движка стоит http, а прокся просит у него hls, движек будет отдавать в hls.

Попробуйте у себя в настройках AceStream поставить HLS и увидите, что на тех каналах где было несколько дорожек, осталась одна, и это не зависит от прокси.
cron