Предыстория - это клиент, который хотел, чтобы видео в режиме реального времени воспроизводилось 24/7 со следующими требованиями:
- Если кто-то подключается к источнику и потокам, поднимите его
- Если источником является аудио, добавьте статическое изображение;если не воспроизводится как есть
- Если нет источника, проверьте предварительно запрограммированный «живой» поток
- Если существует предварительно запрограммированный поток, воспроизведите этот
- Если нетсуществует заранее запрограммированный поток, воспроизводите случайное видео из списка
Таким образом, в основном они хотят убедиться, что что-то всегда воспроизводится, когда кто-либо подключается к потоку.
Я сделал следующее:
[REAL LIVE]
- Установите модуль nginx-rtmp, который записывает файлы m3u8
[PROGRAMMED LIVE]
- Панель управления для добавления ресурсов в запрограммированный поток
- Запись информации о потоке в базу данных
[RANDOM LIVE]
- Скрипт для выбора случайного файла и его воспроизведения через
Тогда у меня есть центральный live.m3u8, который выполняет следующее (по порядку):
- Если m3u8 существует в папке nginx-rtmp, выполните потоковую передачу через
- Если! M3u8, проверьте базу данных на запрограммированный поток и запустите эту программу
- If!выберите случайный файл и выполните потоковую передачу через
- Если! видео, вставьте статическое изображение, иначе воспроизведите непосредственно
Моя таблица БД построена на том факте, что фиксированный старт время для first video должно быть выбрано при создании списка, и этот список всегда будет непрерывным и создает непрерывный 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-адресом, так как это подпискаобслуживание - и строго контролируется и защищается).