Компания Cisco сдержала своё обещание и опубликовала под лицензией BSD исходные тексты библиотеки OpenH264 (https://github.com/cisco/openh264), предоставляющей средства для кодирования и декодирования потоков H.264 базового профиля (baseline profile) с качеством вплоть до уровня 5.2 (4096x2304). Одновременно введён в строй сайт проекта - openh264.org (http://www.openh264.org/).Из особенностей кодека отмечается поддержка цветовой модели YUV 4:2:0, возможность работы с контентом произвольного разрешения (не обязательно кратного 16x16), многопоточная обработка фрагментов, поддержка LTR-кадров, возможность использования 3-4 временных слоёв, предоставление средств для управления памятью (Memory Management Control Operation), поддержка применения нескольких ключевых кадров, динамическое изменение битрейта, частоты кадров и разрешения. Для ускорения работы кодека поддерживается использование инструкций MMX/SSE (Intel x86) и NEON (ARMv7). Среди поддерживаемых операционных систем: Windows, OS X, Linux x86, Linux ARM и Android ARM (в планах поддержка iOS).
Следует обратить внимание на то, что использование опубликованного кода, как и других реализаций H.264, требует выплаты отчислений организации MPEG-LA. Оплаты отчислений можно будет избежать используя официальную бинарную сборку кодека OpenH264, которая пока не доступна для загрузки. Бинарная сборка OpenH264 является продуктом Cisco и может быть задействована без каких-либо ограничений и отчислений, так как компания Cisco в данном случае выступает лицензиатом MPEG LA. Основной целью предоставления не требующей отчислений сборки H.264 является желание обеспеченить поддержку H.264 в API WebRTC, предназначенном для организации аудио и видео коммуникаций в режиме реального времени.
Проект Mozilla намерен включить поддержку сборки OpenH264 в свои продукты (кодек будет загружаться с сайта Cisco), что позволит предоставить пользователям Firefox возможность доступа к контенту, оформленному с использованием кодека H.264, в любых операционных системах, независимо от наличия системной поддержки H.264 (в настоящее время Firefox может использовать штатные кодеки Windows, Android и GStreamer). Основными мотивами поддержки H.264 является предоставление средств для работы с уже существующим накопленным в Сети контентом и обеспечение совместимости с другими браузерами, до момента широкого распространения свободного кодека Daala (http://www.opennet.me/opennews/art.shtml?num=37242).
URL: https://github.com/cisco/openh264
Новость: http://www.opennet.me/opennews/art.shtml?num=38662
Awesome!
> Awesome!
> Следует обратить внимание на то, что использование опубликованного кода, как и других реализаций H.264, требует выплаты отчислений организации MPEG-LA.Oooh, so awesome...
Действительно копирастов побили их же оружием? Всего один партнер сдал кодек в опенсорс и все остальные проприетарщики соснули...И пусть они выкладывают бинарные сборки, ведь код то тоже выкладывают. Проверить соответствие недолго...
> И пусть они выкладывают бинарные сборки, ведь код то тоже выкладывают. Проверить
> соответствие недолго...Эти бинарные сборки будут работать только под теми архитектурами/осями/браузерами, под которыми позволит циска. Попытка использовать собственные сборки - карается банальным изнасилованием.
Обалдеть как awesome, baseline профиль сольет даже VP8 который уже давно во всех браузерах.
>Основными мотивами поддержки H.264 является предоставление средств для работы с уже существующим накопленным в Сети контентомЭто ложь, например, на youtube.com ролики при включённом тестировании html5 https://www.youtube.com/html5 отдаются в свободном формате webm:
>video/webm; codecs="vp8.0, vorbis"а в Firefox 26 после добавления поддержки h.264 через пакет gstreamer0.10-ffmpeg эти же ролики стали отдаваться в проприетраном формате mp4 (h.264):
> video/mp4; codecs="avc1.42001E, mp4a.40.2"Т.е. все прежние ролики youtube.com, что раньше шли через свободный webm нам теперь впаривают через проприетарный h.264, при этом те ролики что без флеш-плеера не проигрывались, так до сих пор и не проигрываются.
Вообщем, создаётся впечатление, что корпорации в очередной раз рассказывают нам сказку про бесплатный сыр.
Типа, первая доза бесплатно.
WEBM -кодеки не поддерживаются аппаратной акселерацией, и не будут поддерживаться никогда.
А поддержка 264 (avc1), есть на всём современном железе.
Так что зря возмущаетесь.
>не будут поддерживаться никогдапруф?
более того, вы написали "акселерацией", а не "декодирование", что еще более глупо, т.к. "акселерация" - это перенос _частей_ вычислений на железо, а не полное хардварное декодирование.
Ложь. SoC некоторых смартфонов имеют аппаратную поддержку декодирования VP8. Думаю, данная поддержка будет добавлена и в видеоускорители для ПК.
> SoC некоторых смартфонов имеют аппаратную поддержку декодирования VP8.Не только смартфонов
# gst-inspect vpudec
Factory Details:
Long name: VPU-based video decoder
Class: Codec/Decoder/Video
Description: Decode compressed video to raw data by using VPU
Author(s): Multimedia Team <shmmmw@freescale.com>
Rank: primary + 1 (257)Plugin Details:
Name: vpu.imx
Description: VPU-based video codec
Filename: /usr/lib/gstreamer-0.10/libmfw_vpu.so
Version: 3.0.9
License: LGPL
Source module: gst-fsl-plugins
Binary package: Freescle Gstreamer Multimedia Plugins
Origin URL: http://www.freescale.comGObject
+----GstObject
+----GstElement
+----GstVpuDecPad Templates:
SINK template: 'sink'
Availability: Always
Capabilities:
video/mpeg
mpegversion: 4
video/x-h264
video/x-h263
video/mpeg
systemstream: false
mpegversion: { 1, 2 }
video/x-wmv
wmvversion: 3
format: WVC1
video/x-wmv
wmvversion: 3
video/x-xvid
---> video/x-vp8
image/jpeg
Интересное у Вас железо... А в качестве чего сей девайс юзаете?
> WEBM -кодеки не поддерживаются аппаратной акселерацией, и не будут поддерживаться никогда.Какой зачетный высер
сделать можно декодер на opencl.
> сделать можно декодер на opencl.Можно то оно можно, а смысл? Разработчики ffmpeg утверждают, что при кодировании видео особого ускорения от opencl ждать не стоит, по крайней мере для современных архитектур видеокарт и алгоритмов кодеков, поскольку тупая вычислительная мощность тут не поможет. "Accessing the gpu memory directly is very slow, because there's no possible synchronisation with the cpu caches. (Meaning they are disabled during such a memory access which really hurts)" (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-March/121983.html). А если для процессора, который CPU, то лучше (в плане быстродействия) писать сразу под него.
> мощность тут не поможет. "Accessing the gpu memory directly is very
> slow, because there's no possible synchronisation with the cpu caches.Поэтому нефиг напрямую лезть в память GPU. С GPU обычно работают так: втолкал блок данныз, он раздолбил - получили обратно. Память у GPU кстати очень быстрая. Только к ней надо из GPU соваться, а не из CPU.
> WEBM -кодеки не поддерживаются аппаратной акселерацией, и не будут
> поддерживаться никогда.То-то гугель лицензирует всем подряд аппаратные блоки кодировщика. Половина SoC уже умеет кстати.
> А поддержка 264 (avc1), есть на всём современном железе.Вот только...
1) К сабжевому кодеку это не относится.
2) Акселерация декодирования потока в 1-2 мегабита выглядит довольно забавной инициативой. А что, оно разве тормозило? :)> Так что зря возмущаетесь.
Не, мы просто обуеваем от аттракциона невиданной щедрости: baseline огрызки, без аппаратного декодирования, преподносятся как пи..ц какая доброта. А чем оно лучше VP8, который уже и так везде есть? :)
> Это ложь, например, на youtube.com ролики при включённом тестировании html5 https://www.youtube.com/html5 отдаются в свободном формате webmОни там всё повыкидывали, в webm оставили только 640x360.
> Они там всё повыкидывали, в webm оставили только 640x360.А пруф где?
>> Они там всё повыкидывали, в webm оставили только 640x360.
> А пруф где?
/G - это виндовое наследие?
> /G - это виндовое наследие?Нет, просто удобно.
> http://img24.imageshack.us/img24/3258/7hev.pngА ничего что это весьма от кодека завивит? Впрочем, возможно они ща сделают ход конем и в VP9 пожмут. Мозилла его включила таки в свой браузер :).
Так что пока H.265 "где-то там", VP9 уже встроен в 2 наиболее популярных браузера...
>> http://img24.imageshack.us/img24/3258/7hev.png
> А ничего что это весьма от кодека завивит? Впрочем, возможно они щаКакого кодека? На Ютубе сейчас доступен только такой webm, проверяйте на любом ролике. Прочие разрешения они недавно удалили.Так что вероятно webm будет ими же закопан потихоньку.
>а в Firefox 26 после добавления поддержки h.264 через пакет gstreamer0.10-ffmpeg эти же ролики стали отдаваться в проприетраном формате mp4 (h.264)Вполне ожидаемо - используется наилучший кодек из доступных.
>>а в Firefox 26 после добавления поддержки h.264 через пакет gstreamer0.10-ffmpeg эти же ролики стали отдаваться в проприетраном формате mp4 (h.264)
> Вполне ожидаемо - используется наилучший кодек из доступных.Из доступных наилучший - это VP9. Сравнительные тесты показали, что он жмёт лучше, чем HEVC.
От смены зондов ощущения не изменяются (адобе на циску)
Используешь h264? mpeg la имеет тебя. Не используешь? тоже имеет. Но во втором случае ты не поспособствовал его распространению.
>так как компания Cisco в данном случае выступает лицензиатом MPEG LAСкорее лицензиар т.к. патенты Cisco входят в пул MPEG LA и, собственно, в её копилку идёт часть средств с надоев. Неплохую свинью они подложили своим товарищам.
А с другой стороны теперь оно в браузерах пропишется надолго и затормозит распространение WebM. Всё продумано.
> А с другой стороны теперь оно в браузерах пропишется надолго и затормозит
> распространение WebM. Всё продумано.Тю, дяденька, мозилла VP9 в свой браузер включила. А гугль уже давно это сделал.
Ничего они никому не подкладывали. MPEG LA всеми силами пытается затормозить развитие свободной альтернативы. А не удивлюсь, если они собрались на сходку и сообща решили слить для пользователей браузеров далеко не лучшую реализацию кодека без каких-либо требований, только что-бы народ и дальше использовал только их формат. Ведь бабло не будут стричь только с простых пользователй. С предпринимателей, создающих видеосервисы(вроде YouTube) и с производителей железа(да и софта) они и дальше будут собирать денежку. А то, что хомячьё получит возможность смотреть ролики на YouTube в h264 особо на уровень отчислений в пользу MPEG LA не повлияет.
Только глупцы будут устанавливать себе блоб от Cisco. Ясно же, что это не самый лучший вариант декодера h264(ffmpeg предоставляет куда более оптимизированный вариант). Да ещё и не открытый(блоб и исходники, из которых он мог(предоположительно) быть собран - не одно и то же).
можно взять исходники, скомпилять, и проверить что выложенные бинарники соответствуют исходникам.
> можно взять исходники, скомпилять, и проверить что выложенные бинарники соответствуют
> исходникам.А как вы проверите? Если вы собирали хоть раз одно и то-же ПО на разных ПК, с разными версиями компилляторов, и вообще отличающимся окружением - вы должны быть в курсе, что на выходе получаются далеко не идентичные бинарники. А если я не могу сравнить два бинарника побитово, то как я узнаю что в блоб ничего не запихнули? Постоянно буду в вывод strace смотреть, что-бы подловить блоб на подозрительном поведении?
подбирать придется. Да легкой жизни никто не обещал, но это возможно.
> можно взять исходники, скомпилять, и проверить что выложенные бинарники соответствуют
> исходникам.Можно. А зачем тебе урезанный декодер baseline профайла от цыски, без хардварного ускорения? Не больно какой ценный артефакт по состоянию на конец 2013 года.
а есть умельцы кто уже сконпелял его и проверил? насколько он лучше или быстрее х264 кодека?или ффмпега?
Как замечательно. Эта штука умеет только базовый профиль, а аппаратный декодер amd только высокий.
> а аппаратный декодер amd только высокий.Кто вам такое сказал? Обычно если некто умеет high профайл - то и все более младшие умеет, что логично. Т.к. старшие профайлы - superset младших.
Все просто. Компания Cisco наряду с конкурентами продвигает B2C решения на основе своих продуктов UC. Все эти решения завязаны на использование аппаратных реализаций h264. Клиентам же предлагается использовать WebRTC, в котором как бы нету "стандартного" кодека из коробки. Данным продуктом они пытаются закрыть данную проблему.
> "стандартного" кодека из коробки. Данным продуктом они пытаются закрыть данную проблему.Кто виноват что в цыске работают слоупоки, которые не могут у гугли взять блок аппаратного декодера, заметьте, без роялтей даже.
Хардверные h264 решения у cisco появились задолго до появления VP8/9
Не нужно
