О поддержке HTML5 видео в современных браузерах

Искренне надеюсь, что именно 2010 год станет годом смерти Flash, и триумфа HTML5.

Мне кажется, вы забыли про браузер который нельзя называть с пока что наибольшей инсталляционной базой.
Пока не выйдёт его версия, которая поддерживает хотя-бы какой-нибудь html5, flash не умрёт.

H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.

Ну, мягко говоря, это спорный факт.

кстати не понятно, почему компании на «свободных» без патентных территориях не раздают кодеки вместе с пакетом сразу, или овчинка выделки не стоит?

Хорошо бы еще RTMP-потоки научились через HTML5 фигачить :-)

Я так и не понял, какая беда с хромом? Бета хрома в линуксе играет это видео. Хромиум с установленным chromium-codecs-ffmpeg-nonfree — тоже.

С одной стороны мне пофиг, поскольку я живу не в США, а Canonical может себе позволить держать в репозиториях нечистые по патентам компоненты. То есть если будет поддержка гстримера того же в браузерах, то всё будет пучком в моей убунте. Но с другой — мне глубоко пофиг на место на серверах гугла или ещё где. Какого лешего они позволяют себе пропихивать в общедоступный интернет закрытые разработки? Это, мягко говоря, ничего хорошего в пользу гугла не говорит. Надеюсь w3c таки примет как стандарт теору, тогда будет фиолетово что и где, лишь бы в браузере игралось. Я наивно верю в то, что главное — это качественные стандарты.

«Поддержка H.264 для бразеру нужна, и быстро, иначе есть большой риск остаться за бортом.»
… мог бы я подумать пару лет назад, что видео кодек будет необходим браузеру…

Чего-то я не совсем понял идею. Чтобы проиграть видео, нужно достать кодек. При этом кодек нельзя бесплатно распространять. Но путём махинаций с плагинами всё работает. Как?

Кодеки кодеки. Войны кодеков. Всю жизнь энд юзеры не парились и ставили какой-нибудь кодек-пак. И никто не знал что за кодеки использованы для сжатия видео.

Я вот под пытками даже не смогу сказать чем сжато видео на rutube, только если об этом напишут в газетах или растяжку на улице поставят «Rutube отныне использует кодек Бла-блабла».

А проблему «не играет видео», решалась из покон веков, простой схемой: поисковик->«не играет видео в ...»->скачиваю кодек пак и ставлю

Нисколько не сомневаюсь, что в 2010 году falsh не умрет, а вот то что с поддержкой HTML 5 все намучаются до смерти — как пользователи так и разработчики — в это верю. Ибо болезнь «совместимости» браузеров видимо никогда не будет излечена.

А с сафари что? Они тоже против гстримера?

Про Оперу не точно. Финальная 10.10 не поддерживает тег video. В 10.50 используется gstreamer. Версия под Mac и Windows тащит его вместе с собой, обрезанный для поддержки только нужных кодеков.

Таким образом, Opera поддерживает только OGG под Mac и Windows и любые установленные кодеки под Linux.

>Мы же не платим
Деньги сами генерируются из воздуха?

Важен не только трафик, но и требовательность к ресурсам. Особенно это важно на фоне массового использования смартфонов и нетбуков. H.264 в этом плане показывает себя не с лучшей стороны.

А почему flash должен умирать? Может flv?

не понятно почему ffmpeg не свободен в США а gstreamer свободен если они оба реализуют несвободный стандарт h.264 за который полагается платить отчисления?

Opera и внезапно? Вообще-то VIDEO/AUDIO теги — это прямая заслуга Opera Software. Да там половина HTML5 благодаря норвежцам появилось.

Щас я расплачусь, «нам выгодно». Мне не выгодно. Еще и «бедные жители не-столиц»… может им и дистрибутивы *nix качать нельзя, а проще на рынке болванку с виндой купить? Нужно помнить одно: интернет должен быть свободным, полностью. И позиция мозиллы мне нравится, видео в html5 не для того придумано, чтобы пропихнуть проприетарные кодэки, а для СВОБОДНОГО интернета, от проприетарного флеша. Если я захочу пользоваться интернетом в plan9, haiku, beos (любой другой ОС, которая мне нравится) я уверен что там будет поддержка открытых, доступных кодеков. А вам видите ли «выгодно», сказал бы матом. Из-за таких вот как вы интернет и заполнен говно-технологиями.

зы: еще и про баннеры кто-то ноет, это вообще палата №6.

Хорошая статья.
В ней есть некоторые неточности и спорные моменты, но изложено довольно технически грамотно и структурировано. В целом мне понравилось.

Однако, мне совершенно непонятно, что эта статья делает в блоге «Веб 2.0». Термином Web 2.0 традиционно называют интернет-сервисы нового поколения: социальные сети, блоги и т.п. Помещать сюда статью о веб-браузерах и веб-стандартах совсем не в тему.
Предлагаю перенести данный топик в блог Браузеры, а лучше даже в блог Веб-стандарты.

ffmpeg в данный момент используется почти повсеместно — например, в CCCP и K-Lite Codec Pack, а также в mplayer и VLC используется именно ffmpeg.

Здесь хотелось бы немного уточнить для тех, кто не в теме.
FFmpeg — это не просто кодек. FFmpeg — это целый опенсорсный проект, в рамках которого командами разработчиков разрабатывается множество мультимедийных компонентов:
libavcodec — библиотека для кодирования/декодирования аудио/видео с самыми разными форматами компрессии (MPEG-1, MPEG-2, MPEG-4 ASP, MPEG-4 AVC, Theora, MJPEG, SNOW, WMV1/2/3, MPEG-1 Layer3, FLAC, Vorbis, AAC, AC3/A52, WavPack, Monkey's Audio и др.);
libavformat — библиотека для мукса/демукса самых разных контейнерных форматов медиафайлов (AVI, ASF(WMV), Matroska, Ogg Media, MOV, MP4, FLV, MPEG-TS, MPEG-PS и др.).
А также библиотеки: libavutil, libpostproc, libswscale, libavfilter.
На базе этих библиотек в рамках того же проекта FFmpeg выпускаются также утилиты командной строки:
ffmpeg — утилита для перекодирования медиафайлов;
ffplay — утилита (плеер) для воспроизведения медиафайлов;
ffserver — утилита (сервер) для сетевой трансляции медиапотоков.

Наработки проекта FFmpeg, действительно, используются в огромном количестве других опенсорсных проектов: MPlayer/MEncoder, VLC, xine, ffdshow, SUPER, Blender, BeSweet и др. Полный список таких проектов есть здесь. В основном везде используют не утилиту ffmpeg, а именно библиотеки libavcodec и libavformat, поэтому лучше так и писать, что используется libavcodec из проекта FFmpeg (или просто писать «используются FFmpeg-библиотеки»).
Про использовании их в CCCP, K-Lite Codec Pack и прочих виндовых пакетах кодеков упоминать вообще как-то странно. Т.к. пакет кодеков — это не какая-то разработка плееров/кодеров/декодеров, это просто архив с инсталлятором куда упакованы множество чужих кодеков. Напрямую в пакет (архив) кодеков библиотека libavcodec не входит. Достаточно упомянуть про использование libavcodec в конкретных кодеках/плеерах из пакета (например, в ffdshow), а про использование ffmpeg-библиотек во всяких КодекПаках — это лишнее.

Если кратко, H.264 — лучше, но даже его open-source реализации не могут быть использованы свободно в странах, где действуют патенты на него.

То, что он лучше, это спорно. Тут и от конкретной реализации кодера/декодера зависит, и от параметров компрессии, да и по ресуркоёмкости во многих случаях он будет потяжелее, что может оказаться большим минусом. Но я сейчас не хочу сравнивать Ogg Theora и различные реализации H.264/AVC-совместимых кодеков. Это отдельный технический вопрос, предлагаю вынести его за рамки данного топика.

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

Начнём с того, что патенты на технологии H.264/AVC-компрессии выданы далеко не во всех странах. Например в России таких патентов нет, а вот в США есть (US Patent 5,452,104 и US Patent 5,576,76 — и действуют они там аж до 2028 года). Соответственно, подобные конфликты OpenSource-лицензий с патентами возможны только в США и некоторых других странах. [* Полный список стран, где выданы подобные патенты на технологию AVC/H.264-компрессии видео, я так и не нашёл. Если кто найдёт, скиньте линк.]
Во всех остальных странах таких проблем нет, там эти OpenSource-продукты могут распространятся свободно, согласно соответствующей лицензии.

Теперь, собственно, о самих опенсорсных лицензиях.
Мне известно только два опенсорсных кодека, которые могут работать с видеокомпрессией AVC/H.264:
1) libavcodec из проекта FFmpeg (лицензия LGPL v2.1)
2) x264 (лицензия GPL v2)
Есть ещё куча других опенсорсных проектов, но кодирование/декодирование AVC/H.264-видео там, как правило, реализовано именно через x264 и libavcodec.
Поэтому будем рассматривать вопрос разрешения конфликта с патентами именно для лицензий GPL/LGPL.

В тексте лицензий GPL и LGPL вполне явно, точно и однозначно определено, как быть, если GPL/LGPL-лицензированный софт затрагивает какие-то запатентованные технологии.
Если данный патент никак не ограничивает свободу распространения GPL/LGPL-лицензированного софта, то и фиг с ним, тогда никакого патентного конфликта нет, а значит пускай этот софт и дальше невозбранно беспрепятственно распространяется под GPL/LGPL.
Но как только действующий патент начинает хоть как-то вмешиваться в свободу распространения данного софта (например, требовать патентных отчислений за какие-то варианты распространения или использования), тогда лицензия GPL/LGPL строго запрещает далее распространять данную программу на территории действия такого патента под лицензией GPL/LGPL. А та как из-за строгостей GPL этот код уже нельзя перелецинзировать под другой лицензией, то получается, что в случае такого патентного конфликта данный софт вообще нельзя будет распространять на территории данной страны.
Поэтому фраза:

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

принципиально неверна.
В случае такого патентного конфликта нет варианта заплатить и продолжать распространять GPL/LGPL-лицензированный продукт. Лицензия GPL/LGPL такое запрещает всем, даже Гуглу. Тут либо распространять свободно, либо никак. «Свобода или смерть!» — таков GPL.

Но ограничение в странах с конфликтующим патентом будет только на дальнейшее распространение софта под лицензией GPL/LGPL. А использовать такой софт даже с возможностью модификации, но без распространения, лицензия GPL/LGPL никак не запрещает. Насколько я понял, требования патентных отчислений за использование запатентованной технологии AVC/H.264-компрессии тоже будут предъявляться не конечным пользователям, а только распространителям программных/аппаратных плееров (включая браузерные плееры), гаджетов и интернет-сервисов, работающих с H.264/AVC-компрессией.

Таким образом, у производителей браузеров будет такой выбор:
1) отказаться вообще от поддержки декодирования H.264/AVC;
2) сделать декодер для H.264/AVC опциональным (Например, по умолчанию его не включать и указывать, что если патент в вашей стране не запрещает, то можете скачать отсюда nonfree-компонент для декодирования. Или делать две разные версии браузера с декодером H.264/AVC и без, и для разных стран отдавать разные страницы закачки. Или выносить декодер H.264/AVC за пределы браузера в мулььимедийный framework типа DirectShow/GStreamer/QuickTime и др.);
3) разработать или купить какой-то H.264/AVC-декодер (точно не GPL/LGPL-лицензированный), заплатить патентные отчисления и встроить его в браузер, чтобы распространять независимо от страны.

А владельцам сервисов видеохостинга придётся тоже делать выбор:
1) отказаться вообще от выкладывания видео c H.264/AVC-компрессией, и перекодировать всё во что-то патентно-чистое типа Theora;
2) вывести свои серверы из патентно-зависимых стран (и возможно даже запретить доступ к видео из таких стран);
3) заплатить патентные отчисления и размещать видео c H.264/AVC-компрессией в любых странах.

два кодека — Ogg Theora и H.264

Ну сколько можно повторять… Theora и H.264 (он же MPEG-4 AVC) — это не кодеки, это форматы видеокомпрессии.
А кодек (кодер/декодер) — это конкретная программа, реализующая кодирование/декодирование данного формата компрессии.
Для H.264-компрессии есть, например, такие кодеры/декодеры: x264, CoreAVC, libavcodec (из проекта FFmpeg), Apple H.264, Nero Video Codec (бывший Ateme H.264), Moonlight/Elecard H.264 Codec, MainConcept H.264 Codec, Videosoft H.264 Codec.
Для Theora-компрессии есть, например, такие кодеры/декодеры: libtheora (от Xiph.Org Foundation), libavcodec (из проекта FFmpeg).

Вот наглядный пример из смежной области:
ZIP — это формат архивов (именно формат компрессии, а не конкретная программная реализация). А WinZIP, PKZIP, 7-zip — это названия конкретных программ-архиваторов, которые могут работать с форматом архивов ZIP (т.е. выполнять компрессию/декомпрессию ZIP-архивов).
Аналогия понятна?

DirectShow является deprecated ещё со времён Vista. Его заменил Media Foundation. Как работавший с обеими технологиями могу сказать, что это шаг вперёд. EVR, DXVA 2.0, расширенное микширование, интеграция с WPF и DX10 и т.п. В любом случае, с ростом доли win7 уповать на то, что XP поддерживает только DS уже нельзя.

Ну и кроме gstreamer есть ещё xine.

Кстати, в обсуждениях выбора форматов для тэгов <audio> и <video> в стандарте HTML5 часто обсуждают только выбор единого формата аудиокомпрессии и единого формата видеокомпрессии. Но ведь эти сжатые медиапотоки не будут же выкладывать в голом raw-виде, их будут выкладывать в неком медиафайле. А значит нужно будет выбрать некий контейнерный формат медиафайла, в который будут упаковываться эти медиапотоки.

Сейчас на видеохостингах в качестве таких контейнерных форматов используют FLV или MP4 (MOV у Apple). Но в случае отказа от Flash Video, наверняка откажутся и от FLV-контейнера.
Сторонники выбора форматов MPEG-4 AAC/AVC наверняка захотят выбрать и соответствующий MP4-контейнер для них. А вот сторонники открытых стандартов выступают за выбор в качестве медиаконтейнера формата Ogg Media, т.к. MP4/MOV точно так же патентно-уязвимы, как и форматы аудио/видеокомпрессии MPEG-4 AAC/AVC.

Также упомяну, что современные контейнерные форматы медиафайлов кроме аудио/видео-потоков поддерживают также текстовый поток для субтитров. В MP4-контейнере обычно используют текстовый поток в формате MPEG-4 Timed Text, а в OggMedia-контейнере для субтитров обычно используют текстовый поток в формате Ogg Writ.

Поэтому, если смотреть комплексно, то для <video> в HTML5 выбор будет делаться не просто между двумя форматами видеокомпрессии (Theora vs H.264) а между целыми наборами решений.

С одной стороны:
MPEG-4 AAC — в качестве формата аудиокомпрессии;
MPEG-4 AVC — в качестве формата видеокомпрессии;
MPEG-4 Timed Text — в качестве формата субтитрового потока;
MP4-контейнер в качестве файлового формата, в который упакованы все эти потоки.

С другой стороны:
Ogg Vorbis — в качестве формата аудиокомпрессии;
Ogg Theora — в качестве формата видеокомпрессии;
Ogg Writ — в качестве формата субтитрового потока;
OggMedia-контейнер в качестве файлового формата, в который упакованы все эти потоки.

Вот ещё какую забавную штуку хотел заметить.
Сейчас в стандарте HTML поддерживается тэг <img>. При этом ни браузерами, ни сайтами не выбрано одного единого формата для хранения и отображения изображений. Все сайты/браузеры без проблем представляют/отображают изображения в этом тэге в самых разных компрессивных форматах: JPEG, GIF, PNG (про качество поддержки PNG в IE тактично умолчим ;). А с JPEG и GIF в своё время тоже были предпосылки к патентным проблемам, но глобально от этих форматов ни один браузер так и не отказался.
Сейчас никто не думает, плохо это или хорошо. Все уже привыкли и считают, что это в порядке вещей.

Так может и с компрессией аудио/видео-потоков для тэгов <audio> и <video> со временем получится так же? Т.е. в инете будет представлено видео и аудио с несколькими разными форматами компрессии, и все браузеры будут поддерживать разные форматы аудио/видео-компрессии. Будут сходу определять, какой в файле контейнерный формат и какие форматы аудио/видео-компрессии, чтобы автоматически использовать нужный демуксер и нужные аудио/видео-декодеры.

Если за использование запатентованных технологий не начнут резко требовать денег, то современем, наверное, так всё и будет.
Хотя я вполне понимаю стремление ряда пользователей и разработчиков прийти всё же к одному универсальному (и при этом желательно открытому) формату для медиаконтента в вебе. В такой унификации есть немалый смысл.

P.S. Вы уж простите, что я так оккупировал топик. Просто что-то высказаться захотелось по данной теме.

Я не согласен с утверждением, что h264 лучше Theora.
На малых битрейтах (точнее разрешениях) Theora даже показывает лучшие результаты чем h264 (оно и понятно, так как главная фича h264 это не фиксированный размер блока просто не применяется). Кроме того не надо забывать, что видео это ещё и аудио без звука мало кто будет смотреть, и в случае Ogg Theora применяют Vorbis который явно лучше чем то, что есть на Youtube(mp3 подобный вроде) и явно не проигрывает aac который так любят пихать в mp4. А так как Theora как бы свободна то я точно выбираю её.
Многие эти фичи я проверил у себя на сайте: mjv-art.org/jvvideo/view_posts/0 там собственно HTML5 видео на Theora (это только раздел сайта, там ещё обои есть).

Кроме того мы нашли кучу проблем и не со стыковок у контейнера mp4. (или неверное их создание многими программами)

… заканчивался 2011-й год.