А оно лучше Theora?

> А оно лучше Theora?

+1?

http://ieeexplore.ieee.org/iel5/11153/35811/01698469.pdf?isnumber=35811&p... в общем всё круто

Он лучше H.264?

Оно лучше чем что-нибудь?

нет

Каменты жгут :)

чем dvd-шки под вендой в него рипать?

>чем dvd-шки под вендой в него рипать?

Windows Media Player'ом. Только кряк найти нужно и реестр подправить. В общем - как обычно всё:)

Зря смеётесь. DirectShow фильтр там есть. Но чем кодировать то под виндой - ни vfw ни отдельной программы не вижу.

Когда заморозят апи?

Лучше пусть жгут всех этих "комментаторов".

Надеюсь допилят этот кодек до удобоваримого состояния.

>допилят этот кодек до удобоваримого состояния.

а какое состояние у кодека считается удобоворимым?

>Зря смеётесь. DirectShow фильтр там есть. Но чем кодировать то под виндой - ни vfw ни отдельной программы не вижу.

Хорошо, не буду смеяться. Под вендой кодировать точно так же, как и под Linux.

Сравнение размеров и скриншоты работы кодека vs другие в студию! На сайте проекта ничего нету. Кодек основан на вейвлет преобразованиях.

>Сравнение размеров и скриншоты работы кодека vs другие в студию!

Зачем? Вы меня с кем-то путаете:)

>Зачем? Вы меня с кем-то путаете:)

Спокойно, это не Вам. :]

> А оно лучше Theora?

вообще по качеству при заданном битрейте даже mpeg4 asp лучше theora, не говоря уж о любых современных кодеках вроде mpeg4 avc, vc-1, vp6/7, а так же кодеках переходного периода h263p, sorenson3, rv40..

theora aka слегка проагпрейженый vp3 - кодек уровня mpeg1.

dirac _в теории_ лучше всего перечисленного из-за принципиально более крутых алгоритмов, заложеных в него, но на практике он в первую очередь такой жуткий тормоз, что в отличие от всего вышеперечисленного совершенно неюзабелен. Даже для SD, а уж для HD так чисто академические исследования, ни одна совеременная система даже близко не подходит к тому, чтобы декодировать 1080p dirac в реалтайме.

>ни одна совеременная система даже близко не подходит к тому, чтобы декодировать 1080p dirac в реалтайме.

А при использовании ресурсов видеокарты или специализированного чипа?

вот сначала напиши эту поддержку или чип сваяй..

учитывая, что bbc забило на dirac, я бы не был сколь-либо оптимистичен насчет судьбы этого кодека

Читал о нём полгода назад. Неюзабельное говно. Таким и осталось.

а я этим делом когда то занимался

были реализации грамотных(векторных) кодеков но времени нет. хоть бы одна собака сделала аналог SourceForge только для ИДЕЙ. типа "Я хочу выложить следующую идею для использования только в GPL/BSD/и т.д" конечно реально так сделать невозможно в РФ, но в СШП покатит, а тогда песедц мелокософтам

Нереальный тормоз... хотя, к тому времени, как оно зарелизится, может мощностей уже и будет хватать. :)

>Нереальный тормоз...

А чего вы ожидали? Код библиотек кодирования и декодировани - на чистом C++, без каких бы то ни было асм-вставок (те же xvid/x264/ffmpeg4 - сильно оптимизированы на асме (MMX/SSE/Altivec/etc).

>хотя, к тому времени, как оно зарелизится, может мощностей уже и будет хватать. :)

Насколько я понял 0.9.0 вышла как полная реализация "Dirac Bytestream Specification Ver 2.0.0 and 1.0.0". Возможно, как раз после полной реализации спецификаций в 0.9 до 1.0 и будет потрачено на оптимизацию (?).

> были реализации грамотных(векторных) кодеков но времени нет. хоть бы одна собака сделала аналог SourceForge только для ИДЕЙ.

так ведь времени нет такой аналог делать!

А чем тебе плох SourceForge? Создавай проект, описывай, а люди к тебе подтянуться ))

В прошлый раз когда была новость скачивал, учил матчасть, но так и не юзал. Сейчас тоже не вижу смысла

Dirac - есть неплохой кодек, меня смущает только C++ и его скорость, а так он даёт очень даже хорошие результаты. Но snow мне больше нравится, правда что-то подзабили на него в последнее время и спеки на него, как бы это сказать, смешные чтоли. Кажется, они (WV кодеки) могли бы спокойно сделать H.264. Осталось их качественно и своевременно реализовать.

>вот сначала напиши эту поддержку или чип сваяй..

На CUDA это реализовать реально или слишком жёсткие ограниечия у GPU?

>учитывая, что bbc забило на dirac

Жаль. Очень жаль.

Честно говоря, ребята неосиливают создание конкурентноспособного кодека. x264 (AVC) - сейчас занимает лидирующее положение по качеству картинки при одинаковом размере сжатого файла, а в свете появления носителей большого объёма и растущих вычислительных мощностей, Dirac'у просто не остаётся места в ряду видеокодеков.

Насмешил. Да хоть на asm, если алгоритм имеет O(2^n) все равно будет тормоз. Смена языка компилируемого на компилируемый даёт линейный прирост, то есть будет на asm O(2^n)-const что однохерственно. А тут пишут что там именно алогритм хитрожопый, так что надо скорее алгоритм улучшать, а потом уже язык менять. Фанатики плин начинающие. :-)

Полностью согласен, только более быстрые алгоритмы скорее всего уже запатентованы и давно используются в других кодеках

> Насмешил. Да хоть на asm, если алгоритм имеет O(2^n) все равно будет тормоз. Смена языка компилируемого на компилируемый даёт линейный прирост, то есть будет на asm O(2^n)-const что однохерственно. А тут пишут что там именно алогритм хитрожопый, так что надо скорее алгоритм улучшать, а потом уже язык менять. Фанатики плин начинающие. :-)

Можно просто попробовать отключить asm оптимизации в x264/ffmpeg и сравнить эти кодеки с dirac в, так сказать, равных условиях (предполагая, что ассемблерные SIMD оптимизации в теории дают примерно одинаковый эффект для этих кодеков, хотя это может быть и не так). Кто возьмется это сделать?

Третья мировая смоет адвокатской и маркетологской кровью все эти патенты. >:-(

все равно coreavc under Linux (ожидается летом) круче будет, чем ffmpeg, dirac, theora вместе взятые

> Насмешил. Да хоть на asm, если алгоритм имеет O(2^n) все равно будет тормоз. Смена языка компилируемого на компилируемый даёт линейный прирост, то есть будет на asm O(2^n)-const что однохерственно. А тут пишут что там именно алогритм хитрожопый, так что надо скорее алгоритм улучшать, а потом уже язык менять. Фанатики плин начинающие. :-)

Узкие теоретики плин, знают только что O(2^n) тормознее O(n^2). asm = O(2^n)-const не однохерственно, а сильно зависит от этой const, если const позволит с приемлемой скоростью декодировать видеопоток, то потребителю как раз и наплевать будет какое там O() у алгоритма.

>Можно просто попробовать отключить asm оптимизации в x264/ffmpeg и сравнить эти кодеки с dirac в, так сказать, равных условиях (предполагая, что ассемблерные SIMD оптимизации в теории дают примерно одинаковый эффект для этих кодеков, хотя это может быть и не так). Кто возьмется это сделать?

Отключал и сравнивал x264 и xvid: в разы производительность падает.

Чем оно лучше x264?

>все равно coreavc under Linux (ожидается летом) круче будет, чем ffmpeg, dirac, theora вместе взятые

ага. за счет декодирования с ошибками "незаметными глазу". сам ешь такой кал.

An open source project hosted at Google Code CoreAVC-For-Linux, patches the dshow loader code in mplayer and allows it to connect to the win32 CoreAVC DirectShow filter. It does not include CoreAVC, but simply allows mplayer to make use of it.

тормоз еще тот будет

> An open source project hosted at Google Code CoreAVC-For-Linux, patches the dshow loader code in mplayer and allows it to connect to the win32 CoreAVC DirectShow filter. It does not include CoreAVC, but simply allows mplayer to make use of it.

Это не то

видимо речь идёт о нативной версии

видимо опять у красноглазых тёплое с мягким путается. они же ни венды ни линукса нихрена не знают. DirectShow фильтр CoreAVC - это для декодирования. почему он вообще упомянут в контексте линукса и прогрессивных кодеков - вообще непонятно. и чем им не нравится код который уже встроен в ffmpeg/mplayer (ffdshow под вендой).

речь идет о продукте

CorePlayer™ Professional for Linux

http://allrussian.info/thread.php?postid=1225752#post1225752

Замечательно. А теперь скажите причём тут кодек. CoreAVC это декодер. Проблемы с просмотром? Не замечал (ffdshow/mplayer). Проблемы с кодированием? Через x264.exe в венде страшное количество фильмов/аниме за[пере]кодировано.

согласен, coreavc как декодер тут ни при чем. напоследок - 2 недостатка ffmpeg, над которыми никто из ffmpeg-devel пока не работает

- неполноценный multithreading - h264 контент, который использует slice single coding проигрывается на одном ядре

- нет поддержки spatial direct mode для интерлейсного h264 видео

>неполноценный multithreading - h264 контент, который использует slice single coding проигрывается на одном ядре

FFmpeg/libavcodec:
......
    * Slice-based parallel H.264 decoding (-lavdopts fast:threads=N)
......

Не надо лужи газифицировать.

Ну, я хоть и сторонник ffmpeg'a, но скажу, что slice based практически безсмысленнен, т.к. так видео уже давно не кодируют. Один поток, один юзается при декодировании H.264 ffmpeg'ом.

Неплохо было бы пробовать прежде чем говорить :)

> slice based практически безсмысленнен, т.к. так видео уже давно не кодируют.

Вот утверждение, на которое я отвечал: "h264 контент, который использует slice single coding проигрывается на одном ядре".

Про то, что сейчас x264 кодирует в frame-base threading я в курсе:)

СОРРИ, читать надо было как

ffmpeg поддерживает multithreading только для h264 контента, который использует slice single coding

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-January/040587.html

AVCHD interlaced decoding AVCHD тоже не реализовано в ffmpeg

:)