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