LINUX.ORG.RU
Новости — Open Source  

Dirac 0.9.0


0

0
Dirac - это универсальный видеокодек, поддерживающий видео с разрешением от QCIF (176x144) до HDTV (1920x1080) с прогрессивной и чересстрочной разверткой. Dirac использует современные конкурентоспособные алгоритмы улучшения качества изображения.
Этот релиз полностью соответствует спецификации Dirac Bytestream 2.0.0, были усовершенствованы алгоритм компенсации движения и кодирование с постоянной скоростью потока. Исправлены ошибки в кодировании с постоянной скоростью потока, внесены изменения в API. Выпущены исправления для MPlayer и FFMpeg. Выпущена новая версия фильтра DirectShow, совместимая с Dirac 0.9.0.

Страница проекта: http://dirac.sourceforge.net/
Полный список изменений: http://sourceforge.net/project/showno...
Скачать Dirac 0.9.0: http://sourceforge.net/project/showfi...

>>> Источник

← Проект RUNA WFE - открытая система управления бизнес-процессами предприятия выпустил релиз версии 2.1
Успешное внедрение решения 1С 8.1 с Linux в масштабе крупного предприятия →
Оно лучше чем что-нибудь?
sid350 ★★★★★
()
Ответ на: комментарий от anonymous
>чем dvd-шки под вендой в него рипать?

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

Led ★★★☆☆
()
Ответ на: комментарий от Led
Зря смеётесь. DirectShow фильтр там есть. Но чем кодировать то под виндой - ни vfw ни отдельной программы не вижу.
anonymous
()
Когда заморозят апи?
Lumi ★★★★★
()
Ответ на: комментарий от animechaos
>допилят этот кодек до удобоваримого состояния.

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led
Сравнение размеров и скриншоты работы кодека vs другие в студию! На сайте проекта ничего нету. Кодек основан на вейвлет преобразованиях.
anonymous
()
Ответ на: комментарий от anonymous
>Сравнение размеров и скриншоты работы кодека vs другие в студию!

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

Led ★★★☆☆
()
Ответ на: комментарий от Led
>Зачем? Вы меня с кем-то путаете:)

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

anonymous
()
Ответ на: комментарий от Sikon
> А оно лучше Theora?

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

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

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

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq
вот сначала напиши эту поддержку или чип сваяй..

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

thresh ★★★
()
Читал о нём полгода назад. Неюзабельное говно. Таким и осталось.
Gharik ☆
()

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

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

А чего вы ожидали? Код библиотек кодирования и декодировани - на чистом 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 и будет потрачено на оптимизацию (?).

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

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

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

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

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

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

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

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

DNA_Seq ★★☆☆☆
()
Честно говоря, ребята неосиливают создание конкурентноспособного кодека. x264 (AVC) - сейчас занимает лидирующее положение по качеству картинки при одинаковом размере сжатого файла, а в свете появления носителей большого объёма и растущих вычислительных мощностей, Dirac'у просто не остаётся места в ряду видеокодеков.
anonymous
()
Ответ на: комментарий от Led
Насмешил. Да хоть на asm, если алгоритм имеет O(2^n) все равно будет тормоз. Смена языка компилируемого на компилируемый даёт линейный прирост, то есть будет на asm O(2^n)-const что однохерственно. А тут пишут что там именно алогритм хитрожопый, так что надо скорее алгоритм улучшать, а потом уже язык менять. Фанатики плин начинающие. :-)
alx_me ★★☆
()
Ответ на: комментарий от alx_me
Полностью согласен, только более быстрые алгоритмы скорее всего уже запатентованы и давно используются в других кодеках
frame ★★★
()
Ответ на: комментарий от alx_me
> Насмешил. Да хоть на asm, если алгоритм имеет O(2^n) все равно будет тормоз. Смена языка компилируемого на компилируемый даёт линейный прирост, то есть будет на asm O(2^n)-const что однохерственно. А тут пишут что там именно алогритм хитрожопый, так что надо скорее алгоритм улучшать, а потом уже язык менять. Фанатики плин начинающие. :-)

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

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

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от anonymous
>все равно 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.

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

black7 ★
()
Ответ на: комментарий от black7
> 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.

Это не то

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

Arceny ★★
()
Ответ на: комментарий от Arceny
видимо опять у красноглазых тёплое с мягким путается. они же ни венды ни линукса нихрена не знают. DirectShow фильтр CoreAVC - это для декодирования. почему он вообще упомянут в контексте линукса и прогрессивных кодеков - вообще непонятно. и чем им не нравится код который уже встроен в ffmpeg/mplayer (ffdshow под вендой).
anonymous
()
Ответ на: комментарий от anonymous
Замечательно. А теперь скажите причём тут кодек. CoreAVC это декодер. Проблемы с просмотром? Не замечал (ffdshow/mplayer). Проблемы с кодированием? Через x264.exe в венде страшное количество фильмов/аниме за[пере]кодировано.
anonymous
()
согласен, coreavc как декодер тут ни при чем. напоследок - 2 недостатка ffmpeg, над которыми никто из ffmpeg-devel пока не работает

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

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

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

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

Не надо лужи газифицировать.
Led ★★★☆☆
()
Ответ на: комментарий от Led
Ну, я хоть и сторонник ffmpeg'a, но скажу, что slice based практически безсмысленнен, т.к. так видео уже давно не кодируют. Один поток, один юзается при декодировании H.264 ffmpeg'ом.
timur_dav ☆☆☆☆☆
()
Ответ на: комментарий от Led
Неплохо было бы пробовать прежде чем говорить :)
timur_dav ☆☆☆☆☆
()
Ответ на: комментарий от timur_dav
> slice based практически безсмысленнен, т.к. так видео уже давно не кодируют.

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led
СОРРИ, читать надо было как

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проект RUNA WFE - открытая система управления бизнес-процессами предприятия выпустил релиз версии 2.1
Open Source
Успешное внедрение решения 1С 8.1 с Linux в масштабе крупного предприятия →