Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 114
Искренне надеюсь, что именно 2010 год станет годом смерти Flash, и триумфа HTML5.
Мне кажется, вы забыли про браузер
Пока не выйдёт его версия, которая поддерживает хотя-бы какой-нибудь html5, flash не умрёт.
чем вам flash то не угодил, пусть они оба живут flash для игр, а html5video для видео.
это уже добрая традиция
если телефон с тачкрином, то убийца айфона, если там флеш плеер на JS или крутящаяся банка на CSS, то убийца флеша
заголовок так громче звучит, хотя практика показывает, что все периодически убиваемые предметы и технологии и ныне прекрасно здравствуют и думаю долго еще здравствовать будут
если телефон с тачкрином, то убийца айфона, если там флеш плеер на JS или крутящаяся банка на CSS, то убийца флеша
заголовок так громче звучит, хотя практика показывает, что все периодически убиваемые предметы и технологии и ныне прекрасно здравствуют и думаю долго еще здравствовать будут
обойдёмся без игр.
H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.Ну, мягко говоря, это спорный факт.
Да, факт спорный =)
Вот это сравнение показывает, что Теора заметно сливает x264.
x264dev.multimedia.cx/?p=102
В последнем сравнении от сообщества Ogg-сообщества, к сожалению, не указаны параметры, с которыми тестировалась Theora. А настройки для H.264 там явно выбраны с расчётом не на качество, а на скорость кодирования и декодирования. Так, видимо, Youtube выгоднее.
Вот это сравнение показывает, что Теора заметно сливает x264.
x264dev.multimedia.cx/?p=102
В последнем сравнении от сообщества Ogg-сообщества, к сожалению, не указаны параметры, с которыми тестировалась Theora. А настройки для H.264 там явно выбраны с расчётом не на качество, а на скорость кодирования и декодирования. Так, видимо, Youtube выгоднее.
Пока вы привели 2 ссылки на сравнение на 2-х сайтах разработчиков. Оби они доказывают неоспоримое преимущество своего. Пока факт остается спорным.
Было бы здорово увидеть картинку для обоих кодеков на одном качестве примерно одного времени кодирования.
Было бы здорово увидеть картинку для обоих кодеков на одном качестве примерно одного времени кодирования.
Начали-то про качество/битрейт. Учет еще и времени — совсем другая история.
Пока что нет других сравнений. По крайней мере я не встречал.
Может попробую на досуге собрать теору из исходников и сравнить самостоятельно, если никто этого до меня не сделает.
Может попробую на досуге собрать теору из исходников и сравнить самостоятельно, если никто этого до меня не сделает.
буду ждать, интересно
Уже готово.
habrahabr.ru/blogs/video/82544/
habrahabr.ru/blogs/video/82544/
кстати не понятно, почему компании на «свободных» без патентных территориях не раздают кодеки вместе с пакетом сразу, или овчинка выделки не стоит?
Хорошо бы еще RTMP-потоки научились через HTML5 фигачить :-)
Кстати, в догонку пост (сегодняшний), который имеет отношение к HTML5 habrahabr.ru/blogs/webdev/82013/
Это что-то вроде идеи CSS фреймворка (с хорошим отношением к HTML5 и CSS3)
Это что-то вроде идеи CSS фреймворка (с хорошим отношением к HTML5 и CSS3)
Я так и не понял, какая беда с хромом? Бета хрома в линуксе играет это видео. Хромиум с установленным chromium-codecs-ffmpeg-nonfree — тоже.
На что? В статье написано дословно «беда». Для меня, поставить несвободный кодек — не беда.
После такого сообщения вам ник смело можно менять на «TROL_1985» =)
Хромиум не играет html5 видео на ютубе. Не играл, по крайней мере пять дней назад, когда я это проверял.
С одной стороны мне пофиг, поскольку я живу не в США, а Canonical может себе позволить держать в репозиториях нечистые по патентам компоненты. То есть если будет поддержка гстримера того же в браузерах, то всё будет пучком в моей убунте. Но с другой — мне глубоко пофиг на место на серверах гугла или ещё где. Какого лешего они позволяют себе пропихивать в общедоступный интернет закрытые разработки? Это, мягко говоря, ничего хорошего в пользу гугла не говорит. Надеюсь w3c таки примет как стандарт теору, тогда будет фиолетово что и где, лишь бы в браузере игралось. Я наивно верю в то, что главное — это качественные стандарты.
«Поддержка H.264 для бразеру нужна, и быстро, иначе есть большой риск остаться за бортом.»
… мог бы я подумать пару лет назад, что видео кодек будет необходим браузеру…
… мог бы я подумать пару лет назад, что видео кодек будет необходим браузеру…
Чего-то я не совсем понял идею. Чтобы проиграть видео, нужно достать кодек. При этом кодек нельзя бесплатно распространять. Но путём махинаций с плагинами всё работает. Как?
О! Спросите у кретиновзаконодателей из США, благодаря которым мы имеем такую систему.
Потому что пользователь для своего личного использования может забить на патенты, и поставить всё, что ему угодно. На то и расчёт.
1) А откуда он поставит? В смысле, где возьмёт?
2) Ну тогда получается, что можно спокойно принимать в качестве стандарта H264 — и всё в порядке? Кому надо, поставит.
2) Ну тогда получается, что можно спокойно принимать в качестве стандарта H264 — и всё в порядке? Кому надо, поставит.
Возьмет на сайте k-lite, например. Ну, или купит у производителя, если в Штатах. Откуда-то же люди кодеки берут…
Проблема как раз в том, что разработчики firefox не хотят учить браузер искать себе кодек в системе. По не совсем понятной причине (дескать, тогда люди, у которых кодек не установлен, не смогут смотреть видео, это дискриминация, поэтому сделаем так, чтобы видео не смог смотреть никто)
Проблема как раз в том, что разработчики firefox не хотят учить браузер искать себе кодек в системе. По не совсем понятной причине (дескать, тогда люди, у которых кодек не установлен, не смогут смотреть видео, это дискриминация, поэтому сделаем так, чтобы видео не смог смотреть никто)
Кодеки кодеки. Войны кодеков. Всю жизнь энд юзеры не парились и ставили какой-нибудь кодек-пак. И никто не знал что за кодеки использованы для сжатия видео.
Я вот под пытками даже не смогу сказать чем сжато видео на rutube, только если об этом напишут в газетах или растяжку на улице поставят «Rutube отныне использует кодек Бла-блабла».
А проблему «не играет видео», решалась из покон веков, простой схемой: поисковик->«не играет видео в ...»->скачиваю кодек пак и ставлю
Я вот под пытками даже не смогу сказать чем сжато видео на rutube, только если об этом напишут в газетах или растяжку на улице поставят «Rutube отныне использует кодек Бла-блабла».
А проблему «не играет видео», решалась из покон веков, простой схемой: поисковик->«не играет видео в ...»->скачиваю кодек пак и ставлю
Очень слабо разбираюсь в кодеках, но когда только заговорили про поддержку кодеков в браузерах, я подумал: вот у меня есть видеоплеер и и он не проигрывает какойто файл, узнаю какой кодек ему нужен, устанавливаю и наслаждаюсь просмотром. Причём, другой видеоплеер тоже найдёт этот установленный кодек. Зачем вшивать кодеки в браузер?
для того чтобы посмотреть видео на ютюбе я ставил флеш. Он как-то еще не входит в поставку в виндоусом. Я уже что-то ставлю. А от установки еще кодекпака не опухну, т.к опух на моменте установки флеша.
А как же тонны медиа файлов в других форматах? Их всё равно придётся перекодировать c помощью H.264 или OGG, как сейчас приходится перегонять видео в flv. Или стандарт нацелен только на youtube и тд?
А почему не всё? Все приложения стремятся в веб, каналы пухнут. Появляются Веб ОС, в которых я могу делать то, что мог делать локально на компьютере… А свой любимый фильм помотреть не могу. Мне его, видите ли, надо перекодировать.
Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
Браузер, конечно, не должен. Браузер вообще не должен встраивать кодеки. В конце топика написано про gstreamer, который ищет кодеки в системе. А в каком формате файл, это уже должно быть на совести разработчика. Если ты youtube, используй самый распространённый кодек. Если тебе плевать на линуксоидов, используй windows media video.
В конце топика написано про 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 работа происходит в общих чертах примерно так же. Тоже единое место хранения декодеров и единый интерфейс взаимодействия с ними.
Нисколько не сомневаюсь, что в 2010 году falsh не умрет, а вот то что с поддержкой HTML 5 все намучаются до смерти — как пользователи так и разработчики — в это верю. Ибо болезнь «совместимости» браузеров видимо никогда не будет излечена.
А с сафари что? Они тоже против гстримера?
Про Оперу не точно. Финальная 10.10 не поддерживает тег video. В 10.50 используется gstreamer. Версия под Mac и Windows тащит его вместе с собой, обрезанный для поддержки только нужных кодеков.
Таким образом, Opera поддерживает только OGG под Mac и Windows и любые установленные кодеки под Linux.
Таким образом, Opera поддерживает только OGG под Mac и Windows и любые установленные кодеки под Linux.
10.10 не поддерживает? Я прямо перед публикацией проверил, Opera 10.10 в Linux, video работает. Для теста использовал вот эту страницу.
Подправил статью с учётом факта про 10.10.
>Мы же не платим
Деньги сами генерируются из воздуха?
Деньги сами генерируются из воздуха?
Важен не только трафик, но и требовательность к ресурсам. Особенно это важно на фоне массового использования смартфонов и нетбуков. H.264 в этом плане показывает себя не с лучшей стороны.
Немного влезу со своими 5 копеек, но Apple как не странно уже сильно нажимаеш с H.264 так как в iPhone уже есть его поддержка, я говорю о том что он видео с сайтов которые на HTML5 показывает :)
Мне как обычному пользователю впринцепи всеравно что там он или другой кодек, да и я Chrome использую…
Мне как обычному пользователю впринцепи всеравно что там он или другой кодек, да и я Chrome использую…
А почему flash должен умирать? Может flv?
Решение с системами кодеков дурацкое. Кодеки надо искать, ставить (а могут и троян подсунуть вместо кодека), они могут глючить и ломаться из-за необнаружимых записей в реестре, ломаться при установке новой программы. На Линуксе Gstreamer мягко говоря притормаживает — ну-ка, у кого за секунду запускается проигрывание видео?
Я не вижу никакого адекватного решения и потому пользуюсь MPlayer (и да, он переносной, его не надо устанавливать и ему не нужны права рута). А кому нравится — пусть сами возятся с кодеками.
Кстати, насчет видео в HTML 5: оно хуже, чем флешевское (не сглаженное, по крайней мере в Хроме) и ест по моему больше ресурсов процессора.
Я не вижу никакого адекватного решения и потому пользуюсь MPlayer (и да, он переносной, его не надо устанавливать и ему не нужны права рута). А кому нравится — пусть сами возятся с кодеками.
Кстати, насчет видео в HTML 5: оно хуже, чем флешевское (не сглаженное, по крайней мере в Хроме) и ест по моему больше ресурсов процессора.
не понятно почему ffmpeg не свободен в США а gstreamer свободен если они оба реализуют несвободный стандарт h.264 за который полагается платить отчисления?
Opera и внезапно? Вообще-то VIDEO/AUDIO теги — это прямая заслуга Opera Software. Да там половина HTML5 благодаря норвежцам появилось.
Щас я расплачусь, «нам выгодно». Мне не выгодно. Еще и «бедные жители не-столиц»… может им и дистрибутивы *nix качать нельзя, а проще на рынке болванку с виндой купить? Нужно помнить одно: интернет должен быть свободным, полностью. И позиция мозиллы мне нравится, видео в html5 не для того придумано, чтобы пропихнуть проприетарные кодэки, а для СВОБОДНОГО интернета, от проприетарного флеша. Если я захочу пользоваться интернетом в plan9, haiku, beos (любой другой ОС, которая мне нравится) я уверен что там будет поддержка открытых, доступных кодеков. А вам видите ли «выгодно», сказал бы матом. Из-за таких вот как вы интернет и заполнен говно-технологиями.
зы: еще и про баннеры кто-то ноет, это вообще палата №6.
зы: еще и про баннеры кто-то ноет, это вообще палата №6.
Хорошая статья.
В ней есть некоторые неточности и спорные моменты, но изложено довольно технически грамотно и структурировано. В целом мне понравилось.
Однако, мне совершенно непонятно, что эта статья делает в блоге «Веб 2.0». Термином Web 2.0 традиционно называют интернет-сервисы нового поколения: социальные сети, блоги и т.п. Помещать сюда статью о веб-браузерах и веб-стандартах совсем не в тему.
Предлагаю перенести данный топик в блог Браузеры, а лучше даже в блог Веб-стандарты.
В ней есть некоторые неточности и спорные моменты, но изложено довольно технически грамотно и структурировано. В целом мне понравилось.
Однако, мне совершенно непонятно, что эта статья делает в блоге «Веб 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 этот код уже нельзя перелецинзировать под другой лицензией, то получается, что в случае такого патентного конфликта данный софт вообще нельзя будет распространять на территории данной страны.
Поэтому фраза:
Для распространения программы, использующей 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-компрессией в любых странах.
получаем, что GPL/LGPL наступает на собственные же грабли из-за своего идиотизма.
Ленту ваших комментариев, можно читать как ленту блога :). Спасибо за информацию!
Один из немногих здравых комментариев к статье. Спасибо!
Лично я болею за первые варианты — и для браузеров, и для видеохостингов. Вопрос тут действительно принципиальный — интернет должен быть построен на открытых технологиях. Иначе это уже не глобальная сеть, а набор феодальных княжеств. И явное торможение прогресса.
Например, я решил создать программу, позволяющую записать видео на Android'е, потом быстро его обработать (вырезать части, добавить всякие визуальные метки), а потом выложить в wordpress-блоге. Допустим, я — американский разработчик, и не имею права поставить кодек. А программа разрабатывается не в коммерческих целях. Я не смогу написать программу, потому что должен буду лицензировать закрытую технологию?! Ох, неправы ребята из Google. Сильно неправы!
Существует такой термин:
Мне кажется, мы сейчас наглядно видим ещё один такой провал. Ради достижения сиюминутных целей, компании-гиганты готовы отказаться от развития технологии, которую сами же могли улучшить для своих целей. А кроме того, пресекают нормальное развитие массы разнообразного ПО, которое, в перспективе, могло принести им же куда большую экономию и прибыли, чем нынешняя «экономия свободного места на дисках».
Лично я болею за первые варианты — и для браузеров, и для видеохостингов. Вопрос тут действительно принципиальный — интернет должен быть построен на открытых технологиях. Иначе это уже не глобальная сеть, а набор феодальных княжеств. И явное торможение прогресса.
Например, я решил создать программу, позволяющую записать видео на Android'е, потом быстро его обработать (вырезать части, добавить всякие визуальные метки), а потом выложить в wordpress-блоге. Допустим, я — американский разработчик, и не имею права поставить кодек. А программа разрабатывается не в коммерческих целях. Я не смогу написать программу, потому что должен буду лицензировать закрытую технологию?! Ох, неправы ребята из Google. Сильно неправы!
Существует такой термин:
Провал рынка — неспособность рыночных механизмов удовлетворительно решать важные для общества социально-экономические проблемы, несовершенство рыночных институтов и инструментов; фиаско рыночных отношений, не обеспечивающих рациональное распределение и использование ресурсов, свидетельствующее о необходимости государственного вмешательства в экономику.
Мне кажется, мы сейчас наглядно видим ещё один такой провал. Ради достижения сиюминутных целей, компании-гиганты готовы отказаться от развития технологии, которую сами же могли улучшить для своих целей. А кроме того, пресекают нормальное развитие массы разнообразного ПО, которое, в перспективе, могло принести им же куда большую экономию и прибыли, чем нынешняя «экономия свободного места на дисках».
>Таким образом, у производителей браузеров будет такой выбор:
>1) отказаться вообще от поддержки декодирования H.264/AVC;
>2) сделать декодер для H.264/AVC опциональным <...>;
>3) разработать или купить какой-то H.264/AVC-декодер <...>.
GPL, как таковое, не отменяет действия патентов, а накладывает обязательство публикации исходных текстов. Или я ошибаюсь?
Поэтому, если в самом патенте указан способ получения или кодирования информации, то его реализация все равно попадает под патент.
>1) отказаться вообще от поддержки декодирования H.264/AVC;
>2) сделать декодер для H.264/AVC опциональным <...>;
>3) разработать или купить какой-то H.264/AVC-декодер <...>.
GPL, как таковое, не отменяет действия патентов, а накладывает обязательство публикации исходных текстов. Или я ошибаюсь?
Поэтому, если в самом патенте указан способ получения или кодирования информации, то его реализация все равно попадает под патент.
два кодека — 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.
Ну и кроме 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-контейнер в качестве файлового формата, в который упакованы все эти потоки.
Сейчас на видеохостингах в качестве таких контейнерных форматов используют 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. Вы уж простите, что я так оккупировал топик. Просто что-то высказаться захотелось по данной теме.
Сейчас в стандарте 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. (или неверное их создание многими программами)
На малых битрейтах (точнее разрешениях) Theora даже показывает лучшие результаты чем h264 (оно и понятно, так как главная фича h264 это не фиксированный размер блока просто не применяется). Кроме того не надо забывать, что видео это ещё и аудио без звука мало кто будет смотреть, и в случае Ogg Theora применяют Vorbis который явно лучше чем то, что есть на Youtube(mp3 подобный вроде) и явно не проигрывает aac который так любят пихать в mp4. А так как Theora как бы свободна то я точно выбираю её.
Многие эти фичи я проверил у себя на сайте: mjv-art.org/jvvideo/view_posts/0 там собственно HTML5 видео на Theora (это только раздел сайта, там ещё обои есть).
Кроме того мы нашли кучу проблем и не со стыковок у контейнера mp4. (или неверное их создание многими программами)
Обычно видео отображается точно так же, как в случае картинок, добавленных с помощью тега img. Управление на базе Javascript интуитивно-понятное: video.pause(). Но в некоторых случаях браузер может обрабатывать тег video по-своему, например в iPhone видео не отображается на странице, а работает как ссылка, при нажатии на которую видео открывается в родном плеере со своими элементами управления.
… заканчивался 2011-й год.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О поддержке HTML5 видео в современных браузерах