У меня есть серверное приложение, которое транслирует 30-скоростной видеопоток FPS, затем кодирует и мультиплексирует его в режиме реального времени в WebM Byte Stream.
На стороне клиента страница HTML5 открывает на сервере WebSocket, который начинает генерировать поток, когда соединение принимается. После доставки заголовка каждый последующий кадр WebSocket состоит из одного WebM SimpleBlock. Ключевой кадр происходит каждые 15 кадров, и когда это происходит, начинается новый кластер.
Клиент также создает MediaSource, а при получении кадра из WS добавляет содержимое в активный буфер. <video>
начинает воспроизведение сразу после добавления первого кадра.
Все работает достаточно хорошо. Моя единственная проблема заключается в том, что сетевой джиттер заставляет позицию воспроизведения дрейфовать с фактического времени через некоторое время. Мое текущее решение - подключиться к событию updateend
, проверить разницу между video.currentTime
и временным кодом входящего кластера и вручную обновить currentTime
, если оно выходит за допустимый диапазон. К сожалению, это вызывает заметную паузу и скачок в воспроизведении, что довольно неприятно.
Решение также немного странно: я точно знаю, где находится последний ключевой кадр, но я должен преобразовать его в целую секунду (как по спецификации W3C), прежде чем я смогу передать его в currentTime
, где браузер предположительно, должен затем обойти и найти ближайший ключевой кадр.
Мой вопрос заключается в следующем: есть ли способ сообщить Media Element всегда искать доступный последний ключевой кадр или синхронизировать время воспроизведения с системным часовым временем?