Технический анализ видео кодеков Flash: Sorenson Spark

Представляем вашему вниманию цикл статей, в которых производится технический анализ видео кодеков, используемых в Flash Player, с точки зрения международных стандартов. Первая статья посвящена кодеку Sorenson Spark.

Начиная с Flash Player 6 (2002), Macromedia оснащала свой плагин аудио и видео кодеками. Первым видео кодеком был Spark, предоставляемый компанией Sorenson. Он представлял первое поколение технологии Flash Video. Проигрыватель имеет, даже сейчас, поддержку как кодирования так и декодирования при помощи этого кодека.

Однако Flash Player 6 имел ограничение использования его видео возможностей только в потоковом режиме, с необходимостью в дорогой лицензии на Flash Communication Server (теперь Flash Media Server) даже для проигрывания простых видео клипов. В начале это ограничение было причиной очень медленной скорости проникновения на рынок.

Flash Player 7 (конец 2003) расширил использование Spark видео введением режима прогрессивной загрузки. С прогрессивной загрузкой видео файлов FLV Flash начал становиться очень интересной платформой для доставки видео в сети. Повсеместное проникновение проигрывателя, возможность интеграции видео с пользовательскими интерфейсами и эффективность прогрессивной загрузки оказались теми свойствами, которых ожидали разработчики.

Третья часть этой истории – это внедрение новой усовершенствованной видео технологии начиная с Flash Player 8 (сентябрь 2005). Видео технология второго поколения называется VP6 и предоставляется On2, компанией, специализирующейся на видео кодеках. На этот раз, однако, Macromedia решила включить во Flash Player только декодер, оставляя возможность кодировать видео в реальном времени только при помощи старого кодека Spark. Поэтому реализация VP6 является не настоящим «кодеком», а просто «декодером».

Давайте теперь проанализируем свойства этих двух видео технологий. Мы сравним методы, используемые Spark и VP6 с используемыми в международных стандартах кодирования видео.

Sorenson Spark

Sorenson Spark – это видео кодек, производный от стандарта H.263. Этот кодек занимает немного памяти (приблизительно 100 кБ), что является важным свойством для интернет-плагина, который должен быть настолько небольшим, насколько возможно.

Spark поддерживает только подмножество основных свойств H.263. В частности, он не поддерживает арифметическое кодирование (режим SAC), B-кадры (режим PB) и Режим усовершенствованного предсказания (Advanced Prediction Mode). Эти свойства, вероятно, были слишком дорогими с точки зрения мощности обработки и сложности кодека, чтобы их можно было включить в маленький кодек; кроме того, B-кадры хороши для предварительно записанного видео, но не для потоковой передачи в реальном времени.

B-кадры приводят к задержкам и удваивают требования к производительности. Кодек Spark заменяет B-кадры D-кадрами (disposable frames, разовые кадры). D-кадры по существу являются B-кадрами с исключительно прямым предсказанием (B-кадр использует в качестве ссылок предыдущий и следующий P или I кадр, тогда как D-кадр использует только предыдущий P или I кадр). Когда кодек использует D-кадры, он получает меньшую компрессию, но обладает способом в реальном времени регулировать ширину канала, требуемую для потоковой передачи видео, поскольку D-кадры являются «выгружаемыми», как B-кадры, без необходимости пересинхронизации со следующим опорным кадром.

При использовании для сжатия видео для Flash Media Server, Spark-кодек Flash Player всегда использует D-кадры и видео поток представляется в виде последовательности кадров вроде этой:

I-D-P-D-P-D-P-…-D-P-I-D-P….(I=опорный кадр, D=разовый кадр, P=предсказывающий кадр)

Когда видео кодируется в Spark в оффлайне при помощи специального приложения, используются только I и P кадры.

Spark по умолчанию поддерживает режим UMV(Unrestricted Motion Vector, Неограниченный вектор движения) и допускает произвольные размеры кадров. Кроме того, он поддерживает режим деблокирующего фильтра, похожий на имеющийся в H.263+.

Обладая этими свойствами, кодек Spark технически на 20-30% менее эффективен, чем оптимальный кодек MPEG4, основанный на H.263+, с точки зрения отношения качества к ширине канала. В первые годы применения это была хорошая производительность, но в настоящее время с каждым днём она становится всё менее приемлемой. Несмотря на это, закодированные при помощи Spark FLV-файлы даже сегодня широко используются благодаря бесплатным, эффективным и очень быстрым кодировщикам типа FFMPEG.

Возможности сжатия в реальном времени

Как видно из сказанного выше, «теоретические» возможности сжатия у кодека Spark не являются шедевральными, но вполне приемлемы. Если вы используете специализированное приложение типа Flash Video Importer, Sorenson Squeeze, FlixPro или даже FFMPEG для производства отдельного FLV файла из хорошего источника видео, то вы можете получить хороший результат.

Положение полностью изменяется, когда дело доходит до использования Flash movie для получения и отсылки видео потока на Flash Media Server для записи или доставки в реальном времени. В этом случае сжатие производится в реальном времени самим Flash movie и окончательный результат в большинстве случаев может быть далёким от оптимального.

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

Для любого отдельно взятого кодека может существовать большое отличие в эффективности между различной реализацией сжатия видео. Алгоритмы сжатия разные и отличаются друг от друга с точки зрения требуемой производительности, памяти и длины кода. Программисты Macromedia в коде Flash Player решили реализовать только простейшие алгоритмы сжатия, чтобы сохранить требования к памяти и производительности на очень низком уровне.

Анализируя окончательный закодированный поток, возможно распознать приемлемую потерю качества в сравнении с тем же источником, сжатым в офлайне, и это происходит со всеми включёнными настройками для кодирования в реальном времени. Для улучшения производительности кодирования Flash Player в реальном времени существует специальный набор методов оптимизации, которые нужно рассматривать отдельно.