938 читателей, 52 поста
Администрация
Модераторы
Блог о единственно правильном подходе к разработе сайтов
Веб-стандарты whois
- индекс
- 85,32
О поддержке HTML5 видео в современных браузерах
Свершилось то, чего многие ожидали — крупнейшие видеосервисы (YouTube, Vimeo) предоставили в режиме бета-тестирования возможность воспроизводить ролики средствами HTML5. Казалось бы, всё прекрасно, и Flash-у пора уйти на заслуженный покой. Ан нет — оказалось всё не так гладко.
А разгадка одна — кодеки. Разработчики браузеров и поставщики контента не сошлись во мнении, какой кодек для видео использовать. На самом деле, эта проблема обсуждалась и ранее, и консенсуса по ней так и нет. В итоге из черновой спецификации HTML5 были удалены упоминания о конкретном кодеке.
На звание кодека для HTML5 video в данный момент претендуют два кодека — Ogg Theora и H.264.
В основе Ogg Theora лежит кодек VP3, разработанный On2 Technologies. В 2002 году, On2 Technologies передали код VP3 под свободной BSD-подобной лицензией в руки Xiph.org Foundation, а также отказались от патентов на кодек (технически, не отказались, а просто передали право их использовать всем, но это по сути то же самое). С тех пор, Xiph.org продолжает развитие этого кодека.
Использовать Ogg Theora можно везде, всегда, без лицензионных или патентных отчислений.
H.264 — это лицензируемый стандарт сжатия видео. Его использование требует платы в странах, где действует патенты на него (в первую очередь, это США). Однако, на сегодняшний день, это один из самых лучших способов сжимать видео. Именно H.264 является стандартом де-факто сжатия HD-видео, к примеру. H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.
Если кратко, H.264 — лучше, но даже его open-source реализации не могут быть использованы свободно в странах, где действуют патенты на него.
Здесь я упоминаю только те браузеры, в которых HTML5 video работает уже сейчас.
Реализация использует библиотеку liboggplay, а это означает, что могут использоваться только Ogg Theora для видео и Ogg Vorbis для аудио. Т.е. кодек фиксирован, и чтобы сделать поддержку чего-то ещё, нужно по сути переписать реализацию.
Реализация использует статически привязанный ffmpeg. ffmpeg поддерживает кучу разных кодеков, включая и Ogg Theora, и H.264, и вообще практически всё, что сейчас реально используется.
К слову, ffmpeg в данный момент используется почти повсеместно — например, в CCCP и K-Lite Codec Pack, а также в mplayer и VLC используется именно ffmpeg.
Казалось бы, всё замечательно. Но! ffmpeg, хоть и open source, не может быть свободным в США. Для распространения программы, использующей ffmpeg, нужно платить отчисления. Google себе это может позволить, и имеет право выпускать билды со встроенным ffmpeg. Но совсем не такая ситуация с дистрибутивами Linux. Те из них, что выпускаются в США, не смогут включить в свои репозитории Chrome с поддержкой ffmpeg, так как это потребует платы отчислений. В первую очередь это касается такого небезызвестного дистрибутива, как Fedora.
Использует фреймворк QuickTime, что позволяет воспроизводить что угодно, если установлен соответствующий QuickTime-кодек.
Наверное, из современных реализаций эта наиболее правильная, т.к. имеет модульную архитектуру изначально. Но это всё сильно завязано на Mac OS, поэтому к остальным системам и браузерам неприменимо.
Теперь поговорим о поставщиках контента. Свобода, равенство, братство — это всё хорошо в теории, но на практике вопрос решается небольшими зеленоватыми бумажками с портретами американских президентов. Google-у как-то проще заплатить за лицензию на более эффективный кодек, чем платить больше за трафик, и место на серверах. Мало того, учитывая то, что у них и так всё видео хранится в H.264, было бы особенно глупо (с точки зрения бизнеса, естественно), перекодировать это всё в Ogg Theora. Так что решение использовать H.264 — это абсолютная, экономически оправданная, жизненная необходимость. YouTube не станет использовать Ogg Theora. Не выгодно. Точка.
А мало того, использование H.264 выгоднее и нам, конечным пользователям. Мы же не платим лицензионные отчисления, а, тем не менее, получаем лучшее качество видео при меньшем количестве загруженных данных (привет жителям не-столиц с хилыми каналами в интернеты).
Сейчас — да. Но! Есть выход. Для декодирования видео в браузере нужно использовать модульный подход, не привязываясь к определённому кодеку. Мало того, в каждой операционной системе уже и так есть модульная инфраструктура кодеков. В Windows — это DirectShow, в Mac OS X — это QuickTime, в Linux — это gstreamer. А gstreamer ещё и кроссплатформенный, между прочим, и уже используется в кроссплатформенных программах, к примеру, Songbird для воспроизведения музыки использует именно gstreamer на всех платформах.
Использование gstreamer решит все проблемы с кодеками в браузерах один раз и навсегда. В частности, не будет никаких проблем с патентами, так как браузер будет распространятся без защищённых патентами кодеков, но на системе пользователя он сможет найти установленный плагин для этого кодека, и использовать его.
А мало того, в gstreamer предусмотрена возможность использовать кодеки, установленные в родном для данной системы фреймворке (для Windows — DirectShow, для Mac OS — QuickTime).
Собственно, вот. Но, судя по комментариям там, сейчас такая интеграция планируется только для Fennec. Честно говоря, я искренее недоумеваю по этому поводу. Поддержка H.264 для Firefox нужна, и быстро, иначе есть большой риск остаться за бортом.
Я не знаю, как довести до разработчиков Firefox мысль о том, что модульная архитектура необходима прямо сейчас. Всё, что пришло в голову — проголосовать за этот баг, и оставить отзыв о неработающем веб-сайте (Help — Report Broken Web Site...) по адресу youtube.com/html5 со ссылкой на этот баг.
Беда. Я пытался вникнуть в причину отказа, но она мне показалось не слишком веской. В принципе, тут нечего добавить. Можно почитать обсуждение, оно довольно жаркое. Ещё можно проголосовать за этот баг (отметить звёздочкой). Мало ли…
Внезапно, маленькая, но очень упорная, норвежская компания показывает себя с очень хорошей стороны. Читаем, радуемся.
Неповоротливые гиганты легко могут оказаться позади маленьких, почти не используемых в широких массах браузеров, таких как Epiphany, Midori, Aurora. Все они используют WebKit. Epiphany и Midori используют GtkWebKit, в нём планируется (или уже сделана) поддержка HTML5 video через gstreamer. Aurora использует QtWebKit, в нём для HTML5 планируется (или уже частично сделано) использование Phonon, который, с свою очередь, может использовать разные бэкэнды, в том числе и gstreamer.
Однако, на текущий момент, ни в одном из них работающей поддержки HTML5 нет. Остаётся верить в их скорое светлое будущее, ведь оно вполне реально.
Искренне надеюсь, что именно 2010 год станет годом смерти Flash, и триумфа HTML5.
А разгадка одна — кодеки. Разработчики браузеров и поставщики контента не сошлись во мнении, какой кодек для видео использовать. На самом деле, эта проблема обсуждалась и ранее, и консенсуса по ней так и нет. В итоге из черновой спецификации HTML5 были удалены упоминания о конкретном кодеке.
Кодеки
На звание кодека для HTML5 video в данный момент претендуют два кодека — Ogg Theora и H.264.
Ogg Theora
В основе Ogg Theora лежит кодек VP3, разработанный On2 Technologies. В 2002 году, On2 Technologies передали код VP3 под свободной BSD-подобной лицензией в руки Xiph.org Foundation, а также отказались от патентов на кодек (технически, не отказались, а просто передали право их использовать всем, но это по сути то же самое). С тех пор, Xiph.org продолжает развитие этого кодека.
Использовать Ogg Theora можно везде, всегда, без лицензионных или патентных отчислений.
H.264
H.264 — это лицензируемый стандарт сжатия видео. Его использование требует платы в странах, где действует патенты на него (в первую очередь, это США). Однако, на сегодняшний день, это один из самых лучших способов сжимать видео. Именно H.264 является стандартом де-факто сжатия HD-видео, к примеру. H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.
Если кратко, H.264 — лучше, но даже его open-source реализации не могут быть использованы свободно в странах, где действуют патенты на него.
Реализации в современных браузерах
Здесь я упоминаю только те браузеры, в которых HTML5 video работает уже сейчас.
Mozilla Firefox
Реализация использует библиотеку liboggplay, а это означает, что могут использоваться только Ogg Theora для видео и Ogg Vorbis для аудио. Т.е. кодек фиксирован, и чтобы сделать поддержку чего-то ещё, нужно по сути переписать реализацию.
Google Chrome
Реализация использует статически привязанный ffmpeg. ffmpeg поддерживает кучу разных кодеков, включая и Ogg Theora, и H.264, и вообще практически всё, что сейчас реально используется.
К слову, ffmpeg в данный момент используется почти повсеместно — например, в CCCP и K-Lite Codec Pack, а также в mplayer и VLC используется именно ffmpeg.
Казалось бы, всё замечательно. Но! ffmpeg, хоть и open source, не может быть свободным в США. Для распространения программы, использующей ffmpeg, нужно платить отчисления. Google себе это может позволить, и имеет право выпускать билды со встроенным ffmpeg. Но совсем не такая ситуация с дистрибутивами Linux. Те из них, что выпускаются в США, не смогут включить в свои репозитории Chrome с поддержкой ffmpeg, так как это потребует платы отчислений. В первую очередь это касается такого небезызвестного дистрибутива, как Fedora.
Safari
Использует фреймворк QuickTime, что позволяет воспроизводить что угодно, если установлен соответствующий QuickTime-кодек.
Наверное, из современных реализаций эта наиболее правильная, т.к. имеет модульную архитектуру изначально. Но это всё сильно завязано на Mac OS, поэтому к остальным системам и браузерам неприменимо.
Суровая реальность
Теперь поговорим о поставщиках контента. Свобода
А мало того, использование H.264 выгоднее и нам, конечным пользователям. Мы же не платим лицензионные отчисления, а, тем не менее, получаем лучшее качество видео при меньшем количестве загруженных данных (привет жителям не-столиц с хилыми каналами в интернеты).
Всё плохо?
Сейчас — да. Но! Есть выход. Для декодирования видео в браузере нужно использовать модульный подход, не привязываясь к определённому кодеку. Мало того, в каждой операционной системе уже и так есть модульная инфраструктура кодеков. В Windows — это DirectShow, в Mac OS X — это QuickTime, в Linux — это gstreamer. А gstreamer ещё и кроссплатформенный, между прочим, и уже используется в кроссплатформенных программах, к примеру, Songbird для воспроизведения музыки использует именно gstreamer на всех платформах.
Использование gstreamer решит все проблемы с кодеками в браузерах один раз и навсегда. В частности, не будет никаких проблем с патентами, так как браузер будет распространятся без защищённых патентами кодеков, но на системе пользователя он сможет найти установленный плагин для этого кодека, и использовать его.
А мало того, в gstreamer предусмотрена возможность использовать кодеки, установленные в родном для данной системы фреймворке (для Windows — DirectShow, для Mac OS — QuickTime).
Светлое будущее, наступит ли оно?
Mozilla Firefox
Собственно, вот. Но, судя по комментариям там, сейчас такая интеграция планируется только для Fennec. Честно говоря, я искренее недоумеваю по этому поводу. Поддержка H.264 для Firefox нужна, и быстро, иначе есть большой риск остаться за бортом.
Я не знаю, как довести до разработчиков Firefox мысль о том, что модульная архитектура необходима прямо сейчас. Всё, что пришло в голову — проголосовать за этот баг, и оставить отзыв о неработающем веб-сайте (Help — Report Broken Web Site...) по адресу youtube.com/html5 со ссылкой на этот баг.
Google Chrome
Беда. Я пытался вникнуть в причину отказа, но она мне показалось не слишком веской. В принципе, тут нечего добавить. Можно почитать обсуждение, оно довольно жаркое. Ещё можно проголосовать за этот баг (отметить звёздочкой). Мало ли…
Opera
Внезапно, маленькая, но очень упорная, норвежская компания показывает себя с очень хорошей стороны. Читаем, радуемся.
Другие браузеры
Неповоротливые гиганты легко могут оказаться позади маленьких, почти не используемых в широких массах браузеров, таких как Epiphany, Midori, Aurora. Все они используют WebKit. Epiphany и Midori используют GtkWebKit, в нём планируется (или уже сделана) поддержка HTML5 video через gstreamer. Aurora использует QtWebKit, в нём для HTML5 планируется (или уже частично сделано) использование Phonon, который, с свою очередь, может использовать разные бэкэнды, в том числе и gstreamer.
Однако, на текущий момент, ни в одном из них работающей поддержки HTML5 нет. Остаётся верить в их скорое светлое будущее, ведь оно вполне реально.
Вместо послесловия
Искренне надеюсь, что именно 2010 год станет годом смерти Flash, и триумфа HTML5.
комментарии (112)
Мне кажется, вы забыли про браузер
который нельзя называтьс пока что наибольшей инсталляционной базой.Пока не выйдёт его версия, которая поддерживает хотя-бы какой-нибудь html5, flash не умрёт.
если телефон с тачкрином, то убийца айфона, если там флеш плеер на JS или крутящаяся банка на CSS, то убийца флеша
заголовок так громче звучит, хотя практика показывает, что все периодически убиваемые предметы и технологии и ныне прекрасно здравствуют и думаю долго еще здравствовать будут
больше посетителей — больше рекламы…
больше рекламы — больше баннеров… бля…
Вот это сравнение показывает, что Теора заметно сливает x264.
x264dev.multimedia.cx/?p=102
В последнем сравнении от сообщества Ogg-сообщества, к сожалению, не указаны параметры, с которыми тестировалась Theora. А настройки для H.264 там явно выбраны с расчётом не на качество, а на скорость кодирования и декодирования. Так, видимо, Youtube выгоднее.
Было бы здорово увидеть картинку для обоих кодеков на одном качестве примерно одного времени кодирования.
Может попробую на досуге собрать теору из исходников и сравнить самостоятельно, если никто этого до меня не сделает.
habrahabr.ru/blogs/video/82544/
Это что-то вроде идеи CSS фреймворка (с хорошим отношением к HTML5 и CSS3)
chromium-browser — 5.0.306.0~svn20100126r37082-0ubuntu2~ucd1~karmic
chromium-codecs-ffmpeg-nonfree — 0.5+svn20091210r34297+36953+37055-0ubuntu1~ucd1~karmic
… мог бы я подумать пару лет назад, что видео кодек будет необходим браузеру…
не верю!
кретиновзаконодателей из США, благодаря которым мы имеем такую систему.2) Ну тогда получается, что можно спокойно принимать в качестве стандарта H264 — и всё в порядке? Кому надо, поставит.
Проблема как раз в том, что разработчики firefox не хотят учить браузер искать себе кодек в системе. По не совсем понятной причине (дескать, тогда люди, у которых кодек не установлен, не смогут смотреть видео, это дискриминация, поэтому сделаем так, чтобы видео не смог смотреть никто)
Только там проблемы с патентами повторятся. К тому же Теора тоже не будет стоять на месте, я надеюсь.
Я вот под пытками даже не смогу сказать чем сжато видео на rutube, только если об этом напишут в газетах или растяжку на улице поставят «Rutube отныне использует кодек Бла-блабла».
А проблему «не играет видео», решалась из покон веков, простой схемой: поисковик->«не играет видео в ...»->скачиваю кодек пак и ставлю
Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
GStreamer — это такой мультимедийный framework, который организует в системе единое хранилище кодеков и с помощью стандартных интерфейсов предоставляет взаимодействие с ними любым приложениям. Таким образом каждому приложению не нужно таскать за собой свои собственные видеодекодеки, а все приложения могут пользоваться одними и теми же, если умеют работать с GStreamer.
По аналогии с ним можно рассмотреть встроенный в винду мультимедийный framework DirectShow (компонент DirectX). Сначала в систему устанавливаются любые DirectShow-декодеры, DirectShow-демультиплексоры и прочие DirectShow-фильтры. А потом любое приложение, умеющее работать с DirectShow, например, любые DirectShow-based медиаплееры типа Windows Media Player, Light Alloy, BSPlayer, Media Player Classic, Winamp и др. могут демуксить соответствующие медиафайлы и декодировать видеопотоки с соответствующей видеокомпрессией с помощью единых DS-фильтров.
С GStreamer работа происходит в общих чертах примерно так же. Тоже единое место хранения декодеров и единый интерфейс взаимодействия с ними.
Таким образом, Opera поддерживает только OGG под Mac и Windows и любые установленные кодеки под Linux.
Деньги сами генерируются из воздуха?
Мне как обычному пользователю впринцепи всеравно что там он или другой кодек, да и я Chrome использую…
Я не вижу никакого адекватного решения и потому пользуюсь MPlayer (и да, он переносной, его не надо устанавливать и ему не нужны права рута). А кому нравится — пусть сами возятся с кодеками.
Кстати, насчет видео в HTML 5: оно хуже, чем флешевское (не сглаженное, по крайней мере в Хроме) и ест по моему больше ресурсов процессора.
зы: еще и про баннеры кто-то ноет, это вообще палата №6.
В ней есть некоторые неточности и спорные моменты, но изложено довольно технически грамотно и структурировано. В целом мне понравилось.
Однако, мне совершенно непонятно, что эта статья делает в блоге «Веб 2.0». Термином Web 2.0 традиционно называют интернет-сервисы нового поколения: социальные сети, блоги и т.п. Помещать сюда статью о веб-браузерах и веб-стандартах совсем не в тему.
Предлагаю перенести данный топик в блог Браузеры, а лучше даже в блог Веб-стандарты.
Внезапно?? Как интересно…
С очень хорошей стороны?? А когда они показывали себя с плохой??
И уж точно меньше всех меня интересует отсосный Chrome, который куда ни кинь — ни того, ни другого не умеет, глючит… А лезет еще куда-то… =\ Ппц %)
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/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 этот код уже нельзя перелецинзировать под другой лицензией, то получается, что в случае такого патентного конфликта данный софт вообще нельзя будет распространять на территории данной страны.
Поэтому фраза:
принципиально неверна.
В случае такого патентного конфликта нет варианта заплатить и продолжать распространять 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-компрессией в любых странах.
Это не вот этот ли список (ссылка из комментариев к заметке Роберта О'Каллахана из Мозиллы)?
Судя по ссылке, которую я привел выше, вполне себе есть (и в базе РосПатента они действительно значатся) и сроки на них истекут ~2017-2023 (из пары случайно взятых патентов). Невесело…
Лично я болею за первые варианты — и для браузеров, и для видеохостингов. Вопрос тут действительно принципиальный — интернет должен быть построен на открытых технологиях. Иначе это уже не глобальная сеть, а набор феодальных княжеств. И явное торможение прогресса.
Например, я решил создать программу, позволяющую записать видео на Android'е, потом быстро его обработать (вырезать части, добавить всякие визуальные метки), а потом выложить в wordpress-блоге. Допустим, я — американский разработчик, и не имею права поставить кодек. А программа разрабатывается не в коммерческих целях. Я не смогу написать программу, потому что должен буду лицензировать закрытую технологию?! Ох, неправы ребята из Google. Сильно неправы!
Существует такой термин:
Мне кажется, мы сейчас наглядно видим ещё один такой провал. Ради достижения сиюминутных целей, компании-гиганты готовы отказаться от развития технологии, которую сами же могли улучшить для своих целей. А кроме того, пресекают нормальное развитие массы разнообразного ПО, которое, в перспективе, могло принести им же куда большую экономию и прибыли, чем нынешняя «экономия свободного места на дисках».
>1) отказаться вообще от поддержки декодирования H.264/AVC;
>2) сделать декодер для H.264/AVC опциональным <...>;
>3) разработать или купить какой-то H.264/AVC-декодер <...>.
GPL, как таковое, не отменяет действия патентов, а накладывает обязательство публикации исходных текстов. Или я ошибаюсь?
Поэтому, если в самом патенте указан способ получения или кодирования информации, то его реализация все равно попадает под патент.
А кодек (кодер/декодер) — это конкретная программа, реализующая кодирование/декодирование данного формата компрессии.
Для 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-архивов).
Аналогия понятна?
Ну и кроме gstreamer есть ещё xine.
Сейчас на видеохостингах в качестве таких контейнерных форматов используют 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-контейнер в качестве файлового формата, в который упакованы все эти потоки.
Обычно… Я видел всего одно видео в контейнере Ogg, которое использовало субтитры и самое забавное, что формат субтитров был не от Xiph (у которого их и так 3, если не ошибаюсь).
Сейчас в стандарте HTML поддерживается тэг <img>. При этом ни браузерами, ни сайтами не выбрано одного единого формата для хранения и отображения изображений. Все сайты/браузеры без проблем представляют/отображают изображения в этом тэге в самых разных компрессивных форматах: JPEG, GIF, PNG (про качество поддержки PNG в IE тактично умолчим ;). А с JPEG и GIF в своё время тоже были предпосылки к патентным проблемам, но глобально от этих форматов ни один браузер так и не отказался.
Сейчас никто не думает, плохо это или хорошо. Все уже привыкли и считают, что это в порядке вещей.
Так может и с компрессией аудио/видео-потоков для тэгов <audio> и <video> со временем получится так же? Т.е. в инете будет представлено видео и аудио с несколькими разными форматами компрессии, и все браузеры будут поддерживать разные форматы аудио/видео-компрессии. Будут сходу определять, какой в файле контейнерный формат и какие форматы аудио/видео-компрессии, чтобы автоматически использовать нужный демуксер и нужные аудио/видео-декодеры.
Если за использование запатентованных технологий не начнут резко требовать денег, то современем, наверное, так всё и будет.
Хотя я вполне понимаю стремление ряда пользователей и разработчиков прийти всё же к одному универсальному (и при этом желательно открытому) формату для медиаконтента в вебе. В такой унификации есть немалый смысл.
P.S. Вы уж простите, что я так оккупировал топик. Просто что-то высказаться захотелось по данной теме.
На малых битрейтах (точнее разрешениях) Theora даже показывает лучшие результаты чем h264 (оно и понятно, так как главная фича h264 это не фиксированный размер блока просто не применяется). Кроме того не надо забывать, что видео это ещё и аудио без звука мало кто будет смотреть, и в случае Ogg Theora применяют Vorbis который явно лучше чем то, что есть на Youtube(mp3 подобный вроде) и явно не проигрывает aac который так любят пихать в mp4. А так как Theora как бы свободна то я точно выбираю её.
Многие эти фичи я проверил у себя на сайте: mjv-art.org/jvvideo/view_posts/0 там собственно HTML5 видео на Theora (это только раздел сайта, там ещё обои есть).
Кроме того мы нашли кучу проблем и не со стыковок у контейнера mp4. (или неверное их создание многими программами)