Adaptive Streaming - избежать много ключевых кадров

Question

Контекст:

Я строит видеоплеер html5 с адаптивной потоковой передачи на основе протокола Source Extension СМИ. Я использую mp4.

Проблема:

У меня есть две версии одного и того же видео (скажем, высокий & плохое качество), и я хочу, чтобы иметь возможность переключаться между версиями с очень небольшой задержкой. Проблема в том, что при смене версии мне нужно иметь фрагмент, который начинается с ключевого кадра, а наличие ключевых кадров очень часто в видео очень плохо для полосы пропускания.

Я ищу способ отправить фрагмент, который начинается с ключевого кадра, когда пользователь изменяет версию, и фрагмент без ключевых кадров (я знаю о bug в Chromium о наличии фрагмента с нет ключевого кадра, но давайте проигнорируем, что на данный момент и он будет исправлен)

Я думал о дублировании каждого потока в видео с большим количеством ключевых кадров, а в другом без (за исключением первого кадра) только с использованием потока с ключевыми кадрами при переключении видео версии. Что-то, что будет выглядеть следующим образом:

// * 
// * represents a key frame; * represents a normal frame; a fragment has 4 frames 

      * 
Stream A.1 **** **** **** **** **** **** **** // version A with no key frames 

      * * * * * * * 
Stream A.2 **** **** **** **** **** **** **** // version A with key frames 
               // at the beginning of each fragment 


      . 
Stream B.1 .... .... .... .... .... .... .... 

      . . . . . . . 
Stream B.2 .... .... .... .... .... .... .... 


      *   . 
A -> B  **** **** .... .... .... .... .... 
from  A.1 A.2 B.1 B.2 B.2 B.2 B.2 

Таким образом, каждый кадр является либо ключевым кадром, или нормальным кадр предшественник которого может быть успешно декодирована. И это ограничило бы количество ключевых кадров, передаваемых по кабелю, до минимума.

Но эй! переключение с A1 на A2 понимает браузер как смену видеопотока и не работает с тех пор, как A2 не начинается с ключевого кадра.

У кого-нибудь есть умное представление о том, как можно достичь такого результата? Я сейчас думаю о том, чтобы переписать атомы moov и moof в клиенте, чтобы обмануть игрока, чтобы думать, что все так, как оно есть. Но я не знаю много о нем ...

Мотивация:

Я работаю на 360 игрока. 360 трудно, потому что большая часть видео, которое транслируется, но не отображается, а это означает, что при ограниченной пропускной способности часть отображаемого видео имеет гораздо более низкое качество, чем люди привыкли. Существуют инструменты и методы для создания нескольких версий видео, каждое из которых сосредоточено в другом направлении просмотра, а затем игрок решает, какая версия будет передаваться во время выполнения.

Поскольку пользователь может изменить направление просмотра в любое время, очень важно иметь возможность быстро реагировать на такие изменения, гораздо больше, чем при адаптации скорости передачи байтов. И поскольку цель этой вещи заключается в том, чтобы сэкономить пропускную способность, было бы неплохо начать с добавления много-много ключевых кадров!

Кроме того, поскольку iOS Safari не поддерживает встроенное видео, которое является ключевым для 360 игроков, я в полной мере полагаюсь на MSE, который не поддерживается iOS Safari (Серьезно, что делают эти парни?)

Answer 1

каждый фрагмент должен начинаться с ключевого кадра, поэтому переключение может произойти правильно; чтобы сделать эту работу вашего интервал ключевого кадра должен разделить поровну длительность фрагмента, например правильные комбинации:

• ключевых кадр каждые 2 секунды, длина фрагмента 6 секунд
• ключевой кадра каждые 4 секунды, длина фрагмента 8 секунд