Вторая стратегия называется интерливингом (interleaving — чередование). Этот подход базируется на смешивании или интерливинге порядка медиа перед передачей и сортировке или деинтерливинге при его получении. Таким образом, благодаря перемешиванию не будет потеряно следующих друг за другом пакетов, и один большой разрыв при проигрывании медиа не образуется. Например, пакет может содержать 220 сэмплов стерео, в каждом по паре 16-битных чисел, чего обычно достаточно для 5 мс проигрывания музыки. Если эти образцы были посланы по порядку, потеря пакета повлечет перерыв в проигрывании на 5 мс. Вместо этого передача осуществляется так, как показано на рис. 7.29. Все четные сэмплы интервала в 10 мс посылаются в одном пакете, а нечетные во втором. Теперь потеря третьего пакета означает не пропуск в музыке в 5 мс, а чередование пустых и заполненных музыкой коротких промежутков в течение 10 мс. С потерей можно легко справиться, если плеер использует интерполяцию, учитывая предыдущий и следующий образцы. В результате мы получим временную потерю в разрешении на 10 мс, но значительного прерывания не будет.
Эта схема интерливинга работает только при отсутствии сжатия. Однако схема интерливинга (для промежутков времени, а не отдельных сэмплов) может также применяться после сжатия, если есть возможность обнаружить границы сэмплов в сжатом потоке. RFC 3119 предлагает схему, которая работает со сжатым аудио.
Интерливинг является привлекательной техникой, так как при его использовании не требуется дополнительной пропускной способности канала пропускания в отличие от FEC. Однако он, так же как и FEC, провоцирует увеличение времени ожидания, так как необходимо ожидать доставки нескольких пакетов (для того чтобы сэмплы можно было выстроить по порядку).
Рис. 7.29. Когда в пакетах передаются только четные или нечетные примеры, потеря пакета временно ухудшает разрешение, но не создает перерыва
Третья задача медиаплеера — восстановление сжатых данных. Хотя эта задача интенсивна в плане вычислений, она достаточно проста. Сложность заключается лишь в декодировании медиа, если сетевой протокол не исправляет ошибки при передаче. Во многих схемах сжатия более поздние данные не могут быть декодированы, если не декодированы более ранние, использованные при их сжатии. При передаче данных на основе UDP пакеты могут теряться. Таким образом, процесс кодирования должен быть разработан так, чтобы позволить декодирование, несмотря на потерю пакетов. Именно из-за этого требования используются I-, P- и B-кадры. Каждый I-кадр может быть декодирован независимо от других, чтобы преодолеть потерю любого из предыдущих кадров.
Четвертая задача — это устранение джиттера, бича всех систем, работающих в реальном времени. Общее решение, которое мы описали в разделе 6.4.3, заключается в использовании буфера. Все потоковые системы начинают с буферизации 5-10 с медиа перед началом проигрывания, как показано на рис. 7.30. При проигрывании медиа регулярно извлекается из буфера, таким образом, чтобы аудио было отчетливым, а видео не подрагивало. Задержка на старте дает буферу шанс не опуститься ниже нижнего предела (low-water mark). Смысл состоит в том, что теперь данные должны приходить достаточно регулярно для того, чтобы буфер никогда не оказывался пустым. Если же это случится и буфер опустеет, проигрывание будет остановлено. Плюс буферизации состоит в том, что если новые данные запаздывают из-за заторов, буферизованные медиаданные позволят продолжить нормальное воспроизведение, пока не подоспели новые данные и буфер не пополнился.
То, сколько информации должно быть буферизовано и как быстро медиасервер наполняет буфер, зависит от сетевых протоколов. Есть много вариантов. Важным фактором реализации является то, какой транспорт используется, на основе TCP или UDP.
Предположим, что используется транспорт на основе UDP, такой как RTP. Далее предположим, что ширина полосы пропускания достаточна для передачи пакетов с медиасервера на медиаплеер с небольшими потерями и также небольшим количеством дополнительной информации. В этом случае пакеты могут пересылаться с той же скоростью, с которой проигрывается медиа. Каждый пакет будет передаваться по сети и после задержки при начале воспроизведения прибывать в нужное время, чтобы медиаплеер мог проигрывать медиа. Необходимо буферизовать лишь небольшую часть информации, так как задержка постоянна. Если используется интерливинг или FEC, требуется буферизовать несколько большую часть, по крайней мере, набор пакетов, которые невозможно декодировать по отдельности. Однако количество буферизованной информации увеличится лишь незначительно.
Рис. 7.30. Медиаплеер буферизует входную информацию с медиасервера и проигрывает медиа из буфера, а не напрямую из сети
К сожалению, этот сценарий нереален по двум причинам. Во-первых, из-за того, что ширина канала варьируется в зависимости от сетевых маршрутов, так что для медиасервера не очевидно, достаточна ли ширина полосы пропускания, пока не начнется передача. Простое решение заключается в кодировании медиа в нескольких разрешениях и предоставление пользователю возможности выбора разрешения, которое больше подходит для скорости его Интернета. Часто существуют только два уровня: высокое качество, скажем, 1,5 Мбит/с или больше, и низкое качество, скажем, в 512 Кбит/с или меньше.
Во-вторых, будет небольшой джиттер, или разница в том, сколько времени уходит у части медиа на то, чтобы пройти путь от передающего сервера до медиаплеера. Этот джиттер происходит по двум причинам. В сети часто передается несколько потоков, соревнующихся за место под солнцем. Это происходит из-за того, что пользователь продолжает просматривать веб-страницы, смотря фильм на одной из них. Такой трафик вызовет колебания в скорости получения медиа. Более того, нам важна доставка видеокадров и отрезков аудио, а не пакетов. Благодаря компрессии видеокадры могут быть больше или меньше в зависимости от их содержания. На передачу движения обычно требуется больше бит, чем на передачу спокойного пейзажа. Если пропускная способность сети постоянна, количество доставленного медиа за определенный временной период может варьироваться. Чем больше джиттер или варьирование задержки, тем больше информации должно храниться в буфере.
Теперь предположим, что транспорт, основанный на TCP, такой как HTTP, используется для отсылки медиа. При помощи повторных передач и ожидания доставки пакетов, чтобы выстроить их по порядку, TCP увеличит джиттер в медиаплеере, возможно даже значительно. В результате нужен буфер большего размера и большее количество хранящейся в нем информации. Однако в этом есть и преимущество. TCP будет отсылать данные с той скоростью, с которой они могут передаваться по сети. Иногда воспроизведение может быть приостановлено, если при передаче возникли потери. Но в большей части случаев сеть сможет доставить медиа быстрее, чем плеер проигрывает файл. В эти периоды будет заполняться буфер, что поможет справиться с задержками в дальнейшем. Если сеть значительно быстрее, чем требуется для проигрывания медиа, а часто так и бывает, буфер быстро заполнится при запуске медиаплеера и вскоре ему уже не будет грозить опустошение.
При использовании TCP или UPD и скорости передачи, которая выше скорости, требуемой для воспроизведения, вопрос состоит в том, насколько большую часть медиафайла плеер подгрузит в буфер. Часто загружается весь файл целиком.
Однако загрузка такой большой части не является необходимостью, требует много места для хранения и не обязательно предотвращает опустошение буфера. Когда это нежелательно, решением является установка проигрывателем верхнего предела (high-water mark) заполнения буфера. Суть в том, что сервер выдает данные лишь до тех пор, пока буфер не заполнится до верхнего предела. После этого проигрыватель просит сервер приостановить передачу. Поскольку данные будут продолжать прибывать в течение времени передачи запроса приостановки, расстояние между верхним пределом и концом буфера должно быть больше некоторого X — количества данных, которые успеют передаться за этот промежуток времени. X соответствует задержкам в канале, возникающим вследствие ограниченной пропускной способности (то есть произведению пропускной способности на задержку). После приостановки сервера буфер начнет опустошаться. Когда количество данных в нем достигнет нижнего предела, проигрыватель попросит сервер мультимедиа возобновить передачу. Чтобы предотвратить опустошение буфера, при расчете нижнего предела также должно приниматься во внимание произведение пропускной способности на задержку, и в соответствии с ним должен рассчитываться момент, когда на сервер нужно отослать запрос на возобновление передачи.
