Медиа-сервер для прямой трансляции

Question

Доброе время суток, я нахожусь в процессе замены Twitch для кодировщиков, чтобы они могли свободно выбирать / создавать категорию, в которую они хотят попасть, и избегать людей, которые выращивают "траву" на Twitch вКатегория «Наука и технологии».

Я начал с nginx-rtmp-module , и строю свой интерфейс с учетом этого модуля, однако проблемы и ограничения, с которыми я столкнулсяна этапе разработки, или на самом деле, на этапе тестирования я думал о переходе на другой продукт.
В частности, нет простого (или даже невозможного) способа скрыть закрытый ключ потока от пользователей (тех, кто собирается смотреть поток).), но это не единственный.

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

Я пробовал Ant Media Server, но опять же, большинствопростые функции, такие как аутентификация, включены только в версию программного обеспечения Enterprise.

Не поймите меня неправильно, я знаю, что на более поздней стадии «производства» мне придется подумать о переходе на что-то более «корпоративное»ориентированный, однако, прямо сейчас, я просто ищу продукт, который:

1. Поддерживает события (поток запущен, поток закончен, поток обновлен) - nginx-rtmp-module делает это уже, но какя уже говорил, он имеет некоторые ограничения
2. Поддерживает REST (или, по крайней мере, представляет данные читателю, который представляет собой скрипт для извлечения информации)
3. Лучше всего, еслион имеет открытый исходный код или бесплатен для стадии разработки

И что этот коммуникационный сервер должен уметь:

1. Принимать RTMP / RTMPS какsource
2. Создание действительных манифестов DASH / HLS (в некоторых случаях nginx-rtmp-module не удается это сделать)
3. Отлично, но сейчас не нужно, поддержка адаптивной потоковой передачи

Втчто я уже тестировал:

1. nginx-rtmp-сервер (и его вилки)
2. Nimble Streamer
3. Ant Media Server
4. OSSRS / srs - возникла проблема даже с его правильной настройкой, поэтому появляется много предупреждений о новых типах ОС

Если кто-нибудь знает о некоторых медиа-серверах, которые поддерживают как минимум 2/3 упомянутых вещей, ябудет очень рад услышать о них.

Спасибо за ваше время.

ОБНОВЛЕНИЕ

У меня есть следующая конфигурация:

    application live {
        deny play all;      

        live on;
        dash on;

        on_publish http://app.local/api/stream/start;
        on_publish_done http://app.local/api/stream/stop;
        on_update http://app.local/api/stream/update;

        dash_repetition on;
        dash_fragment 5s;
        dash_playlist_length 60s;
        dash_cleanup on;
        dash_nested on;
        dash_clock_compensation http_head;
        dash_clock_helper_uri http://live.local/time;
        dash_path /tmp/dash/stream-dash;
    }

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

Почему на странице статистики отображается поток с открытым ключом, но данные по-прежнему записываются в папку с именем закрытого ключа?

PS А вот логика генерации нового открытого ключа, написанная на PHP

1. Извлечение application и name из запроса
2. Проверьте, действительно ли запрос имеет эти значения (ожидая получить два, поэтому считая их)
3. Plucking $ key (имя) и $ app (приложение) из результирующего массива
4. Кэширование информации о канале (здесь мы проверяем, существует ли канал с этим ключом потоковой передачи и существует ли он, кэшируя его в Redis)
5. Проверка, если модель null , если это так, то предоставляется неверный ключ потока
6. Извлечение Пользователь , связанный с Канал
7. Проверка, если Пользователь запрещен для потоковой передачи
8. Создание новой записи Поток (со всеми данными, связанными с RTMPпоток и статус в реальном времени)
9. Формирование ключа кэша из модели (для исключения дальнейших запросов к базе данных)
10. Обновление потокового кэша с информацией по умолчанию (все установлено на null )
11. Отправка события в браузер, что поток начался
12. Возвращение ответа 301 и установка Местоположение в хэш SHA-512 потока UUID

Ключ, полученный на шаге 12, фактически является новым открытым ключом, и, как вы можете видеть, страница статистики фактически возвращает этот точный ключ, однако данные по-прежнему записываются в папку с именем ключа, полученным на шаге 3

ОБНОВЛЕНИЕ № 2. Упрощенная версия алгоритма генерации ключей

/**
     * Start stream
     * @return Response
     */
    public function start() : Response
    {
        $requiredStreamKey = 'live_1_B562zv8D6agoozRcXHiiYlvJ1EVVqkF7Q2GBYVE6XkqCsUCH';
        $request = array_values(request()->only(['name', 'app']));
        if (\count($request) < 2) {
            return $this->sendError(Response::HTTP_BAD_REQUEST);
        }
        [$key, $app] = $request;

        if ($requiredStreamKey !== $key) {
                return response('', Response::HTTP_NOT_FOUND);
        }

        $exampleUUID = 'fcefd01c-f379-414c-95f8-c4e6e2b0ffc7';
        $hash = hash('sha512', $exampleUUID);
        return response('Generic Response', Response::HTTP_MOVED_PERMANENTLY)->withHeaders([
            'Location' => sprintf('%s', $hash)
        ]);
    }