Пользователь
0,0
рейтинг
26 января 2010 в 16:20

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

Свершилось то, чего многие ожидали — крупнейшие видеосервисы (YouTube, Vimeo) предоставили в режиме бета-тестирования возможность воспроизводить ролики средствами HTML5. Казалось бы, всё прекрасно, и Flash-у пора уйти на заслуженный покой. Ан нет — оказалось всё не так гладко.

А разгадка одна — кодеки. Разработчики браузеров и поставщики контента не сошлись во мнении, какой кодек для видео использовать. На самом деле, эта проблема обсуждалась и ранее, и консенсуса по ней так и нет. В итоге из черновой спецификации 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, поэтому к остальным системам и браузерам неприменимо.

Суровая реальность


Теперь поговорим о поставщиках контента. Свобода, равенство, братство — это всё хорошо в теории, но на практике вопрос решается небольшими зеленоватыми бумажками с портретами американских президентов. 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).

Светлое будущее, наступит ли оно?


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.
Mad Fish @Mad_Fish
карма
95,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (114)

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


    Мне кажется, вы забыли про браузер который нельзя называть с пока что наибольшей инсталляционной базой.
    Пока не выйдёт его версия, которая поддерживает хотя-бы какой-нибудь html5, flash не умрёт.
    • +24
      чем вам flash то не угодил, пусть они оба живут flash для игр, а html5video для видео.
      • +14
        это уже добрая традиция
        если телефон с тачкрином, то убийца айфона, если там флеш плеер на JS или крутящаяся банка на CSS, то убийца флеша

        заголовок так громче звучит, хотя практика показывает, что все периодически убиваемые предметы и технологии и ныне прекрасно здравствуют и думаю долго еще здравствовать будут
        • +1
          мне вот интересно банеры тоже будут на html5видео
          • НЛО прилетело и опубликовало эту надпись здесь
            • +7
              Меньше баннеров — меньше сайтов.
              • +3
                Меньше сайтов — больше качественного контента? :)
                • +8
                  больше качественного контента — больше посетителей…
                  больше посетителей — больше рекламы…
                  больше рекламы — больше баннеров… бля…
                  • 0
                    вы абсолютно правы
          • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Video kill radio star… © 1979 The Buggles
      • 0
        обойдёмся без игр.
        • +2
          и заставить офисный планктон работать?!!! Вы что!!! Они же за месяц всю работу на два-три года вперед сделают… :)
        • 0
          а как же интерактив и анимация
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • +15
    H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.
    Ну, мягко говоря, это спорный факт.
    • 0
      Да, факт спорный =)
      Вот это сравнение показывает, что Теора заметно сливает x264.
      x264dev.multimedia.cx/?p=102

      В последнем сравнении от сообщества Ogg-сообщества, к сожалению, не указаны параметры, с которыми тестировалась Theora. А настройки для H.264 там явно выбраны с расчётом не на качество, а на скорость кодирования и декодирования. Так, видимо, Youtube выгоднее.
      • +3
        Пока вы привели 2 ссылки на сравнение на 2-х сайтах разработчиков. Оби они доказывают неоспоримое преимущество своего. Пока факт остается спорным.

        Было бы здорово увидеть картинку для обоих кодеков на одном качестве примерно одного времени кодирования.
        • 0
          Начали-то про качество/битрейт. Учет еще и времени — совсем другая история.
        • +3
          Пока что нет других сравнений. По крайней мере я не встречал.

          Может попробую на досуге собрать теору из исходников и сравнить самостоятельно, если никто этого до меня не сделает.
          • 0
            буду ждать, интересно
  • +1
    кстати не понятно, почему компании на «свободных» без патентных территориях не раздают кодеки вместе с пакетом сразу, или овчинка выделки не стоит?
  • +1
    Хорошо бы еще RTMP-потоки научились через HTML5 фигачить :-)
  • –5
    Кстати, в догонку пост (сегодняшний), который имеет отношение к HTML5 habrahabr.ru/blogs/webdev/82013/
    Это что-то вроде идеи CSS фреймворка (с хорошим отношением к HTML5 и CSS3)
  • 0
    Я так и не понял, какая беда с хромом? Бета хрома в линуксе играет это видео. Хромиум с установленным chromium-codecs-ffmpeg-nonfree — тоже.
    • +7
      nonfree кагбэ намекает
      • 0
        На что? В статье написано дословно «беда». Для меня, поставить несвободный кодек — не беда.
        • 0
          После такого сообщения вам ник смело можно менять на «TROL_1985» =)
        • 0
          Хромиум не играет html5 видео на ютубе. Не играл, по крайней мере пять дней назад, когда я это проверял.
          • 0
            работает и ютуб и вимео на ночном билде

            chromium-browser — 5.0.306.0~svn20100126r37082-0ubuntu2~ucd1~karmic
            chromium-codecs-ffmpeg-nonfree — 0.5+svn20091210r34297+36953+37055-0ubuntu1~ucd1~karmic
            • 0
              Они добавлили H.264? O_o Или гугл теперь вещает и в theora?
              • 0
                H.264. По умолчанию с хромиумом идет chromium-codecs-ffmpeg, а не chromium-codecs-ffmpeg-nonfree. Просто установите этот -nonfree пакет.
                • +1
                  Так ведь -nonfree и стоит… Попробуем обновится, а то я уж, грешным делом, на хром перешёл.
                  • 0
                    Правильно сделали.
  • +6
    С одной стороны мне пофиг, поскольку я живу не в США, а Canonical может себе позволить держать в репозиториях нечистые по патентам компоненты. То есть если будет поддержка гстримера того же в браузерах, то всё будет пучком в моей убунте. Но с другой — мне глубоко пофиг на место на серверах гугла или ещё где. Какого лешего они позволяют себе пропихивать в общедоступный интернет закрытые разработки? Это, мягко говоря, ничего хорошего в пользу гугла не говорит. Надеюсь w3c таки примет как стандарт теору, тогда будет фиолетово что и где, лишь бы в браузере игралось. Я наивно верю в то, что главное — это качественные стандарты.
  • +10
    «Поддержка H.264 для бразеру нужна, и быстро, иначе есть большой риск остаться за бортом.»
    … мог бы я подумать пару лет назад, что видео кодек будет необходим браузеру…
  • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      эээ хочешь сказать Safari не поддерживает православный aac, вместо этого умеет работаеть с унылым wav?
      не верю!
  • +1
    Чего-то я не совсем понял идею. Чтобы проиграть видео, нужно достать кодек. При этом кодек нельзя бесплатно распространять. Но путём махинаций с плагинами всё работает. Как?
    • +1
      О! Спросите у кретиновзаконодателей из США, благодаря которым мы имеем такую систему.
      • 0
        Это был чисто технический вопрос, лежащий вне юридической плоскости :)
        • 0
          Ну так технически всё просто: разрабы браузера делают просто возможность подключать к нему сторонние кодеки. А вся ответственность за использования сторонних кодеков лежит уже не на них.
          • +1
            А тот, кто выкладывает кодек — пират?
            • +1
              Смотря в какой стране он это делает :)
    • +1
      Потому что пользователь для своего личного использования может забить на патенты, и поставить всё, что ему угодно. На то и расчёт.
      • 0
        1) А откуда он поставит? В смысле, где возьмёт?

        2) Ну тогда получается, что можно спокойно принимать в качестве стандарта H264 — и всё в порядке? Кому надо, поставит.
        • 0
          Возьмет на сайте k-lite, например. Ну, или купит у производителя, если в Штатах. Откуда-то же люди кодеки берут…

          Проблема как раз в том, что разработчики firefox не хотят учить браузер искать себе кодек в системе. По не совсем понятной причине (дескать, тогда люди, у которых кодек не установлен, не смогут смотреть видео, это дискриминация, поэтому сделаем так, чтобы видео не смог смотреть никто)
          • +1
            Ну это, конечно, странный подход. Те, у кого компьютера нет, тоже не могут смотреть видео… Я уж молчу, что «мой брэндовый патентованный оптимизированный кодек с винчестера» лучше вашего фиг-знает-какого, и я хочу иметь теоретическую возможность подключить свой!
      • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Вот к тому времени Теора уже точно обгонит H.264 =)
      • +1
        Вот к тому времени Теора только хоть как то начнёт догонять H.264, а H.265 (H.264+) уже начнёт своё распространение =)
        • 0
          Вокруг H.265 уже ведётся работа.
          Только там проблемы с патентами повторятся. К тому же Теора тоже не будет стоять на месте, я надеюсь.
  • +2
    Кодеки кодеки. Войны кодеков. Всю жизнь энд юзеры не парились и ставили какой-нибудь кодек-пак. И никто не знал что за кодеки использованы для сжатия видео.

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

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

    • 0
      Очень слабо разбираюсь в кодеках, но когда только заговорили про поддержку кодеков в браузерах, я подумал: вот у меня есть видеоплеер и и он не проигрывает какойто файл, узнаю какой кодек ему нужен, устанавливаю и наслаждаюсь просмотром. Причём, другой видеоплеер тоже найдёт этот установленный кодек. Зачем вшивать кодеки в браузер?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        для того чтобы посмотреть видео на ютюбе я ставил флеш. Он как-то еще не входит в поставку в виндоусом. Я уже что-то ставлю. А от установки еще кодекпака не опухну, т.к опух на моменте установки флеша.
        • 0
          На правах зануды: флеш плеер пятой версии входит в поставку windows xp. Про остальные не знаю.
          • 0
            открывать и смотреть видео на ютюбе это не помогает )
            • 0
              Зато ютуб сам показывает, куда нажать, и рассказывает что надо сделать, чтобы помогло. Видеоплееры этому долго пытались научиться, но нормально не умеют до сих пор.
          • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А как же тонны медиа файлов в других форматах? Их всё равно придётся перекодировать c помощью H.264 или OGG, как сейчас приходится перегонять видео в flv. Или стандарт нацелен только на youtube и тд?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            А почему не всё? Все приложения стремятся в веб, каналы пухнут. Появляются Веб ОС, в которых я могу делать то, что мог делать локально на компьютере… А свой любимый фильм помотреть не могу. Мне его, видите ли, надо перекодировать.
            Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Браузер, конечно, не должен. Браузер вообще не должен встраивать кодеки. В конце топика написано про gstreamer, который ищет кодеки в системе. А в каком формате файл, это уже должно быть на совести разработчика. Если ты youtube, используй самый распространённый кодек. Если тебе плевать на линуксоидов, используй windows media video.
                • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  В конце топика написано про gstreamer, который ищет кодеки в системе.
                  Какое-то у вас странное представление о GStreamer, ничего он не «ищет в системе».
                  GStreamer — это такой мультимедийный framework, который организует в системе единое хранилище кодеков и с помощью стандартных интерфейсов предоставляет взаимодействие с ними любым приложениям. Таким образом каждому приложению не нужно таскать за собой свои собственные видеодекодеки, а все приложения могут пользоваться одними и теми же, если умеют работать с GStreamer.

                  По аналогии с ним можно рассмотреть встроенный в винду мультимедийный framework DirectShow (компонент DirectX). Сначала в систему устанавливаются любые DirectShow-декодеры, DirectShow-демультиплексоры и прочие DirectShow-фильтры. А потом любое приложение, умеющее работать с DirectShow, например, любые DirectShow-based медиаплееры типа Windows Media Player, Light Alloy, BSPlayer, Media Player Classic, Winamp и др. могут демуксить соответствующие медиафайлы и декодировать видеопотоки с соответствующей видеокомпрессией с помощью единых DS-фильтров.

                  С GStreamer работа происходит в общих чертах примерно так же. Тоже единое место хранения декодеров и единый интерфейс взаимодействия с ними.
                  • 0
                    Я писал выше, что очень плохо разбираюсь в кодеках:) Из топика впервые прочитал про gstreamer. Для меня главной идеей было то, что gstreamer «ищет», «хранит», «организует» кодеки в моей системе. Спасибо, что разъяснили подробности.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А с сафари что? Они тоже против гстримера?
    • +1
      Apple — причастные к H.264 лица, посему им не нужен никакой гстример и отчисления, чтобы прикрутить к сафари поддержку своего же формата.
    • 0
      Сафари использует quicktime, поэтому им всё равно, но всё работает.
  • +2
    Про Оперу не точно. Финальная 10.10 не поддерживает тег video. В 10.50 используется gstreamer. Версия под Mac и Windows тащит его вместе с собой, обрезанный для поддержки только нужных кодеков.

    Таким образом, Opera поддерживает только OGG под Mac и Windows и любые установленные кодеки под Linux.
    • 0
      10.10 не поддерживает? Я прямо перед публикацией проверил, Opera 10.10 в Linux, video работает. Для теста использовал вот эту страницу.
      • 0
        Может через флеш сработало?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Точно. Пардон.
    • 0
      Подправил статью с учётом факта про 10.10.
  • 0
    >Мы же не платим
    Деньги сами генерируются из воздуха?
  • 0
    Важен не только трафик, но и требовательность к ресурсам. Особенно это важно на фоне массового использования смартфонов и нетбуков. H.264 в этом плане показывает себя не с лучшей стороны.
    • +1
      В смартфонах H.264 уже давным давно поддерживается аппаратно, с нетбуками только у Atom N270 проблемы и то с HD, в новых процессорах уже тоже аппаратно умеет раскодироваться.
  • –3
    Немного влезу со своими 5 копеек, но Apple как не странно уже сильно нажимаеш с H.264 так как в iPhone уже есть его поддержка, я говорю о том что он видео с сайтов которые на HTML5 показывает :)
    Мне как обычному пользователю впринцепи всеравно что там он или другой кодек, да и я Chrome использую…
  • +2
    А почему flash должен умирать? Может flv?
  • –1
    Решение с системами кодеков дурацкое. Кодеки надо искать, ставить (а могут и троян подсунуть вместо кодека), они могут глючить и ломаться из-за необнаружимых записей в реестре, ломаться при установке новой программы. На Линуксе Gstreamer мягко говоря притормаживает — ну-ка, у кого за секунду запускается проигрывание видео?

    Я не вижу никакого адекватного решения и потому пользуюсь MPlayer (и да, он переносной, его не надо устанавливать и ему не нужны права рута). А кому нравится — пусть сами возятся с кодеками.

    Кстати, насчет видео в HTML 5: оно хуже, чем флешевское (не сглаженное, по крайней мере в Хроме) и ест по моему больше ресурсов процессора.
  • 0
    не понятно почему ffmpeg не свободен в США а gstreamer свободен если они оба реализуют несвободный стандарт h.264 за который полагается платить отчисления?
    • НЛО прилетело и опубликовало эту надпись здесь
  • +7
    Opera и внезапно? Вообще-то VIDEO/AUDIO теги — это прямая заслуга Opera Software. Да там половина HTML5 благодаря норвежцам появилось.
  • +6
    Щас я расплачусь, «нам выгодно». Мне не выгодно. Еще и «бедные жители не-столиц»… может им и дистрибутивы *nix качать нельзя, а проще на рынке болванку с виндой купить? Нужно помнить одно: интернет должен быть свободным, полностью. И позиция мозиллы мне нравится, видео в html5 не для того придумано, чтобы пропихнуть проприетарные кодэки, а для СВОБОДНОГО интернета, от проприетарного флеша. Если я захочу пользоваться интернетом в plan9, haiku, beos (любой другой ОС, которая мне нравится) я уверен что там будет поддержка открытых, доступных кодеков. А вам видите ли «выгодно», сказал бы матом. Из-за таких вот как вы интернет и заполнен говно-технологиями.

    зы: еще и про баннеры кто-то ноет, это вообще палата №6.
  • +2
    Хорошая статья.
    В ней есть некоторые неточности и спорные моменты, но изложено довольно технически грамотно и структурировано. В целом мне понравилось.

    Однако, мне совершенно непонятно, что эта статья делает в блоге «Веб 2.0». Термином Web 2.0 традиционно называют интернет-сервисы нового поколения: социальные сети, блоги и т.п. Помещать сюда статью о веб-браузерах и веб-стандартах совсем не в тему.
    Предлагаю перенести данный топик в блог Браузеры, а лучше даже в блог Веб-стандарты.
    • 0
      Перенёс.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +6
    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-библиотек во всяких КодекПаках — это лишнее.
  • +9
    Если кратко, 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-компрессией в любых странах.
    • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • –2
      получаем, что GPL/LGPL наступает на собственные же грабли из-за своего идиотизма.
    • +1
      Ленту ваших комментариев, можно читать как ленту блога :). Спасибо за информацию!
    • +2
      Один из немногих здравых комментариев к статье. Спасибо!

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

      Например, я решил создать программу, позволяющую записать видео на Android'е, потом быстро его обработать (вырезать части, добавить всякие визуальные метки), а потом выложить в wordpress-блоге. Допустим, я — американский разработчик, и не имею права поставить кодек. А программа разрабатывается не в коммерческих целях. Я не смогу написать программу, потому что должен буду лицензировать закрытую технологию?! Ох, неправы ребята из Google. Сильно неправы!

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

      Мне кажется, мы сейчас наглядно видим ещё один такой провал. Ради достижения сиюминутных целей, компании-гиганты готовы отказаться от развития технологии, которую сами же могли улучшить для своих целей. А кроме того, пресекают нормальное развитие массы разнообразного ПО, которое, в перспективе, могло принести им же куда большую экономию и прибыли, чем нынешняя «экономия свободного места на дисках».
    • 0
      >Таким образом, у производителей браузеров будет такой выбор:
      >1) отказаться вообще от поддержки декодирования H.264/AVC;
      >2) сделать декодер для H.264/AVC опциональным <...>;
      >3) разработать или купить какой-то H.264/AVC-декодер <...>.

      GPL, как таковое, не отменяет действия патентов, а накладывает обязательство публикации исходных текстов. Или я ошибаюсь?
      Поэтому, если в самом патенте указан способ получения или кодирования информации, то его реализация все равно попадает под патент.
  • +5
    два кодека — 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-архивов).
    Аналогия понятна?
  • +1
    DirectShow является deprecated ещё со времён Vista. Его заменил Media Foundation. Как работавший с обеими технологиями могу сказать, что это шаг вперёд. EVR, DXVA 2.0, расширенное микширование, интеграция с WPF и DX10 и т.п. В любом случае, с ростом доли win7 уповать на то, что XP поддерживает только DS уже нельзя.

    Ну и кроме gstreamer есть ещё xine.
  • –3
    Если вы не понимаете, что такое флеш, что он еще умеет, помимо проигрывания видео и показа баннеров, то это говорит лишь о вашей слабой подготовке в этом вопросе, и, возможно, общей недалекости => не надо делать столь категоричных высказываний. Тем более, что в статье вы приводите данные, которые всем заинтересованным уже давно известны.
    • 0
      Минусуют походу поборники «открытых» «веб-стандартов», забывшие, что если бы не флеш, в интернете не было бы ни музыки, ни видео, ни вменяемых игр ДО СИХ ПОР, потому что W3C будет еще несколько лет разрабатывать HTML5, а люди хотят всем этим пользоваться сейчас. Смешные.
  • +1
    Кстати, в обсуждениях выбора форматов для тэгов <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-контейнер в качестве файлового формата, в который упакованы все эти потоки.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Вот ещё какую забавную штуку хотел заметить.
    Сейчас в стандарте HTML поддерживается тэг <img>. При этом ни браузерами, ни сайтами не выбрано одного единого формата для хранения и отображения изображений. Все сайты/браузеры без проблем представляют/отображают изображения в этом тэге в самых разных компрессивных форматах: JPEG, GIF, PNG (про качество поддержки PNG в IE тактично умолчим ;). А с JPEG и GIF в своё время тоже были предпосылки к патентным проблемам, но глобально от этих форматов ни один браузер так и не отказался.
    Сейчас никто не думает, плохо это или хорошо. Все уже привыкли и считают, что это в порядке вещей.

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

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

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

    Кроме того мы нашли кучу проблем и не со стыковок у контейнера mp4. (или неверное их создание многими программами)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Обычно видео отображается точно так же, как в случае картинок, добавленных с помощью тега img. Управление на базе Javascript интуитивно-понятное: video.pause(). Но в некоторых случаях браузер может обрабатывать тег video по-своему, например в iPhone видео не отображается на странице, а работает как ссылка, при нажатии на которую видео открывается в родном плеере со своими элементами управления.
  • +2
    … заканчивался 2011-й год.

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