Поддельный живой поток m3u8 из статического видео

Предыстория — это клиент, который хотел, чтобы видео в режиме реального времени воспроизводилось 24/7 в соответствии со следующими требованиями:

• Если кто-то подключается к источнику и потокам, поднимите его
• Если источником является аудио, добавьте статическое изображение; если не играть как есть
• Если нет источника, проверьте предварительно запрограммированный «живой» поток
• Если существует заранее запрограммированный поток, проиграйте
• Если предварительно запрограммированного потока не существует, воспроизведите случайное видео из списка

Так что в основном они хотят убедиться, что-то всегда играет, когда кто-то подключается к потоку.

Что я сделал, это:

[НАСТОЯЩИЙ ЖИВОЙ]

• Установите модуль nginx-rtmp, который записывает файлы m3u8

[ПРОГРАММИРОВАННАЯ ЖИЗНЬ]

• Панель управления для добавления активов в запрограммированный поток
• Записывает информацию о потоке в базу данных

[Случайный LIVE]

• Скрипт для выбора случайного файла и воспроизведения его через

Тогда у меня есть центральный live.m3u8, который делает следующее (по порядку):

1. Если m3u8 существует в папке nginx-rtmp, выполните потоковую передачу через
2. Если! M3u8, проверьте базу данных на запрограммированный поток и воспроизведите это
3. Если! Программа, выберите случайный файл и пропустите через
4. Если! Видео, вставьте статическое изображение, иначе воспроизведите напрямую

Моя таблица БД построена вокруг того факта, что фиксированная Начните время для первый видео должен выбирается при создании списка, и список всегда будет смежным, и создает непрерывный 24-часовой цикл вокруг этого. Например, если они выбирают 10 видео по 40 минут каждое, начиная с 1500 часов; затем я создам блоки по 400 минут вокруг этого 1500 — 1900 часового окна (0300-0700-1100-1500-1900-2300).

Это делается путем записи в базе данных времени начала каждого сегмента, поэтому моя таблица выглядит так:

id     order     extinf          start         file
112    100       10.000000       15:00:00      112.ts
113    101       10.000000       15:00:10      113.ts
114    102       10.000000       15:00:20      114.ts
300    103       12.000000       15:00:30      300.ts
301    104       12.000000       15:00:42      301.ts
302    105       12.000000       15:00:54      302.ts
303    106       12.000000       15:01:06      303.ts

Так что, когда пользователь запрашивает «живой» поток, мой запрос выглядит так:

SELECT
m3u8.order, m3u8.extinf, m3u8.file, m3u8.start
FROM
video_hls
WHERE
m3u8.start >= DATE_FORMAT(DATE_SUB(NOW(), INTERVAL 1 MINUTE),'%H:%i:%s') AND m3u8.start <= DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 3 MINUTE),'%H:%i:%s')
ORDER BY
m3u8.order ASC

Этот трюк выбора предыдущей минуты и следующих 3 минут, а также использование тега # EXT-X-DISCONTINUITY заставляет игроков думать, что они присоединились к текущему прямому эфиру, и обрабатывать их как таковые.

Теперь проблема в том, что всякий раз, когда кто-то смотрит на границу 23: 59: 59-00: 00: 00, он теряет поток и должен повторно подключиться, после этого все в порядке.

Столбец «start» представляет собой простое время, мой оператор SELECT имеет дело только с H: i: s, так что я ничего не вижу, чтобы это произошло, обслуживаемый файл m3u8 выглядит прекрасно (он работает для всех остальных 86398 секунд дня), и он не содержит никакой информации о дате, просто простые файлы один за другим.

Кажется, я не могу найти никакой причины для такого поведения … (я, к сожалению, не могу поделиться URL-адресом, так как это служба подписки — и тщательно контролируемая и защищенная).