LINUX.ORG.RU

Комитет IETF стандартизировал кодек Opus

 , , ,


2

3

Internet Engineering Task Force (IETF) опубликовал стандарт открытого аудиокодека с потерями Opus, распространяемого под трехусловной лицензией BSD. Этот кодек разработан в первую очередь для интерактивных интернет-приложений, включая VoIP, телеконференции, игровые чаты.

Основные возможности Opus:

  • битрейт от 6 до 512 кбит/с;
  • кодирование голоса и музыки;
  • поддержка моно и стерео;
  • дискретизация от 8 до 48 кГц;
  • продолжительность кадров от 2,5 до 60 мс;
  • поддержка постоянного и переменного битрейта;
  • поддержка многоканального звука (до 255 каналов).

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

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от anonymous

Неееет, не надо еще одного велосипеда в зоопарк форматов муз. файлов! mp3/ogg/wma и так уже слишком.

КОгда говорят, что Opus пригоден для музыки, имеют в виду диапазон битрейта, на котором внутренне подключается CELT. Так вот, преимущества CELT выражаются в оптимизации под передачу звука по сети и низкой алгоритмической задержке, что теоретически даже позволяет музыкантам играть вместе, находясь физически в разных местах (но лично мне этот вариант кажется весьма сомнительным). Никто им заменять mp3/vorbis/etc не собирается, применение у него другое.

m0rph ★★★★★
()
Ответ на: комментарий от anonymous

Где купить билет на концерт Курта Кобейна или Джимми Хендрикса? Да и не хватит у тебя бабла и времени по концертам ходить каждый день.

anonymous
()
Ответ на: комментарий от anonymous

Дурак - это ты. Перечисленное - форматы с потерями, пустая башка.

anonymous
()
Ответ на: комментарий от Pavval

Надо им рассказать, а то мож не знают...

Зачем? Глядишь таким макаром 32-битные ЦАПы прикрутят, и дельта-сигма модуляцию запилят... А то все ИКМ, да ИКМ...

Кроме шуток, man передискретизация, man шум дискретизации, man алиасинг. Да... Горек аудиофильский хлебушек.

Macil ★★★★★
()

Нет, нет, только не для музыки. Голосовой чат? Вот и чудненько.

UNiTE ★★★★★
()

s/трехусловной/трехпунктовой/

annulen ★★★★★
()
Ответ на: комментарий от Pavval

а всё Hi-End audio обрабатывается в 192

1) обработка и воспроизведение это разные вещи

2) пути аудиофильские неисповедимы.

Короче, походи по ссылочкам в этом треде.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

обработка и воспроизведение это разные вещи

Я отвечал на тему «192 нинужно» в жироком смысле.

Короче, походи по ссылочкам в этом треде.

А то я все это в свое время не учил.

Pavval ★★★★★
()
Ответ на: комментарий от Macil

Кроме шуток, man передискретизация, man шум дискретизации, man алиасинг. Да... Горек аудиофильский хлебушек.

Ты думаешь я что-то из этого не знаю?

Pavval ★★★★★
()

Я бы сказал что на what.cd обсудили почти 2 месяца назад, но боюсь меня закидают сапогами.

bhfq ★★★★★
()
Ответ на: комментарий от Pavval

Я отвечал на тему «192 нинужно» в жироком смысле.

ты спросил почему в кодеке с потерями нет 192.

true_admin ★★★★★
()
Ответ на: CPU от mmarkk

едро и инитрд все как жали gzipом так и жмут

С разморозкой! Давно LZMA задействовали. Памяти требуется побольше, но за счёт меньшего размера образа читается с диска быстрее.

anonymous
()
Ответ на: комментарий от YAR

>>How do I use 44.1 kHz or some other sampling rate not directly supported by Opus?

Какой же это универсальный, если даже наиболее популярный формат без ресемплинга он не поддерживает? Я уж не говорю про HiRes-дорожки.

Кстати да, пробовал им музычку кодировать, 44.1 kHz перефигачивает в 48 kHz, без вариантов(, так что пока vorbis.

anonymous
()
Ответ на: комментарий от anonymous

если сравнить libgsm и сабж для голоса - кто получше будет при том же битрейте ?

«Я не специалист, но отвечу». Мне кажется, что для голоса лучше будет iLBC.

g.729 - не найду реализацию свободного кодека, есть такой?

Есть в ffmpeg. Но разработчики из Libav постоянно ругают патчи из ffmpeg за несоответствие референс-реализациям и глюки. Не знаю, насколько это так.

plm ★★★★★
()
Ответ на: комментарий от buddhist

Ну, только к ней осталось найти идеальные бесконечные длительности сигналы и все будет норм, а мы живем в реальном мире...

dik
()
Ответ на: комментарий от anonymous

Есть же флак!

FLAC, как и прочие аналогичные форматы, не подходит для RTP, т.к. есть высокие шансы, что пакет по размерам превзойдет MTU и будет неправильно обработан/отброшен каким-либо узлом сети между микрофонами.

plm ★★★★★
()
Ответ на: комментарий от anonymous

Хороший ответ дают умные люди http://floatingpower.narod.ru/izbrannoe_o_zvuke/nsuhov/hi-fi_pravda_i_high-en...

CD - это качество хорошего кассетника. Собственно это было изначально так задуманно. Качество сравнимое с последним винилом, это 96к/24, ну а чтоб лучше было - это уже 192к/24. Правда, к мену нужно еще и усилок качественный :)))

С другой стороны, Opus нужен для интернена (считай бесплатно :), а где крестьянину взять не CD? Не купленные же AAC выкладывать?

fi ★★★
()
Ответ на: комментарий от fi

«CD - это качество хорошего кассетника. »

Бред. И в статье этого нет. Все зависит от аппаратуры воспроизведения (даже если откинуть то, что через несколько раз проигрывания кассета уже звучит как не ТОРТ.

anonymous
()
Ответ на: комментарий от anonymous

Предлагаю забанить пользователя с ником anonymous. Постоянно пишет какую-то хрень.

mmarkk
()
Ответ на: комментарий от mmarkk

«С разморозкой! Давно LZMA задействовали. Памяти требуется побольше, но за счёт меньшего размера образа читается с диска быстрее. »

«Уважаемый» анонин. ЛЗМА жмёт сильнее, но распаковывает дольше. так что фейл и 4.2

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

anonymous
()

Круто, больше стандартов, хороших и открытых!

cetjs2 ★★★★★
()
Ответ на: комментарий от bieming

В блоге skype объявили о грядущем переходе на опус

Даже мелкомягкие приложили руку, с чего бы это?

eugeno ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Чтение на один блок меньше (с HDD) — ничто по сравнению с временем распаковки, так что твой преждевременный выброс комментария - трэш и угар.

mmarkk
()
Ответ на: комментарий от eugeno

с чего бы это?

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

P.S. надеюсь поддержка кодека попадет в какое-нибудь обновление для IE тогда это будет один из шагов в тотальном отказе от флеша для воспроизведения музыки на сайте.

bhfq ★★★★★
()
Ответ на: комментарий от mmarkk

Лол, не унимаешься. Не умеешь читать - не пиши. И «выброс» здесь не причем. Ты, я смотрю, спец по газификации луж. Это тебя надо забанить за кретинизм.

Не говоря о том, что чтение в данном случае может осуществляться с медленного носителя (или маленькая скорость передачи данных), а время распаковки за счет быстрого процессора будет несравнимо меньше, любитель газов.

anonymous
()
Ответ на: комментарий от Pavval

Надо. Причем на доступных примерах, языком как в замечательной ссылке выше по треду, типа «смотреть фильмы в которых частоты света ограничены сверху рентгеном, а то и вовсе нищебродским ультрафиолетом --- полный отстой. Жесткий рентген наше все, без него балеты Чайковского как клипы с MTV!».

t184256 ★★★★★
()
Ответ на: комментарий от fi

Первый раз вижу таких дураков, дают статью на одно, а в посте пишут ахинею, противоречащую фактам, статье и здравому смыслу. ^_^

anonymous
()
Ответ на: комментарий от anonymous

Да ты, я смотрю, риальне неграмотный. Да будет тебе известно, что линейное чтение с диска производится большими блоками, и скорость чтения нескольких последовательных блоков примерно та же что и чтение одного маленького. поэтому чуть меньший размер сжатого ядра или initrd не влияет на скорость его чтения с HDD. А для не умеющих читать я специально написал HDD, потому что на дисководах это не верно.

Теперь насчёт быстрого процессора - ты неуч и неосилятор тестов. Даже самый мощный процессор (АЛУ и кэш) можно засрать слишком тяжёлым алгоритмом. Что и происходит с lzma-сжатием.

А теперь в цифрах:

initrd: raw.img: 41'153'024 байт raw.gz: 14'616'805 байт raw.xz: 10'625'433 байт

Время распаковки: gzip: 0.288s lzma: 0.796s

Время (берём примерно 100 мб/сек для чтения с HDD) gz: 0.288 + 14.616805 / 100 = 0.43416805 xz: 0.796 + 10.625433 / 100 = 0.90225433

SSD: 500 мб/сек gz: 0.288 + 14.616805 / 500 = 0.31723361 xz: 0.796 + 10.625433 / 500 = 0.817250866

ИТОГ: общее время операции минимум в 2 раза больше в случае использования XZ сжатия. В тестах использованы файлы, сжатые с максимальной степенью сжатия.

так что это ты обосрался, ссаный анонин.

mmarkk
()
Ответ на: комментарий от mmarkk

Ну ты и дебилоид. Трудно признать свою тупость? Про HDD НАПИСАЛ ты. В исходном сообщении было про ДИСК, я написал про скорость передачи данных ПО СЕТИ, Так что твои эпичные высеры по initrd совершенно нелепы и не к месту в топике про потоковый звук, не говоря о том. что сравнивать надо не HDD и SSD, а один и тот же объем информации, заархивированный разными способами.

Так что смени подгузники и попробуй еще раз осознать, что твой шизофренический бред никак не относится к теме сообщений, на которые ты пытаешься отвечать.

anonymous
()
Ответ на: комментарий от mmarkk

«ИТОГ: общее время операции минимум в 2 раза больше в случае использования XZ сжатия. В тестах использованы файлы, сжатые с максимальной степенью сжатия.» то есть по твоим выводам потоковый звук при втором способе сжатия будет играться в 2 раза медленнее?

anonymous
()
Ответ на: комментарий от anonymous

ЛОЛШТО?

Твоя тупость просто поражает.

1. Ни в одном из твоих высеров нет ничего про передачу данных по сети.

2. Приведено два расчёта в качестве примера — HDD и SSD чтобы показать что в обоих случаях я прав.

3. Как раз именно твой высер не относится к теме. Ибо ты решил поспорить со мной по поводу применимости LZMA для сжатия вместо ответа на заданный в моём первом посте вопрос.

4. Для особо тупых неосиляторов текста — тест проводился на одном и том же initrd сжатом разными способами.

mmarkk
()
Ответ на: комментарий от anonymous

Нет, тебя можно только изолировать от общества.

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

Алгоритмы сжатия, создающие повышенные задержки (как по причине большой буферизации, так и по причине CPU usage) для передачи звука по сети в реальном времени не годятся.

Теперь. по поводу передачи звука — почитай требования к созданию кодеков звука для реального времени. Ты думаешь, все такие же тупые как ты и просто не могу реализовать алгоритм с более сильным сжатием? Расстрою тебя — кодеки делают умные ребята. Они заботятся о батарейках и их волнуют задержки. Они знают про тайм-слоты и так далее. Впрочем, школоте не понять, хотя кому я объясняю....

mmarkk
()
Ответ на: комментарий от mmarkk

1. Не умеешь читать текст? Аутист?

«Не говоря о том, что чтение в данном случае может осуществляться с медленного носителя (или маленькая скорость передачи данных), а время распаковки за счет быстрого процессора будет несравнимо меньше»

Как ты думаешь. где бывает маленькая скорость передачи данных? Если не по сети?

2. При чем здесь твои бредовые расчеты и HDD/SSD? Ты ведь пытался опровергнуть вышеприведенный текст. Где ты увидел необходимость сравнивать SSD или HDD? Вообще-то топик - про потоковую передачу звука, и про то, что на более мощном процессоре новый формат даст большую стабильность при передаче. Зачем ты замерял загрузку initrd, это вообще может сказать только доктор Хаус (возможно, у тебя некроз тканей мозга).

3. На это я уже ответил выше, повторяться дла даунов не буду

4. То, что ты зачем-то initrd мерял, тебе надо обратиться к психиатру. Не говоря о том, что погрешность измерения милисекунд в ядре слишком велика, чтобы твои замеры долей милисекунды имели бы какой-то смысл.

anonymous
()
Ответ на: комментарий от mmarkk

«Ты думаешь, все такие же тупые как ты и просто не могу реализовать алгоритм с более сильным сжатием? Расстрою тебя — кодеки делают умные ребята. Они заботятся о батарейках и их волнуют задержки. Они знают про тайм-слоты и так далее.»

Напиши об этом создателям кодека Opus, я тут не причем. Они такие глупые, просвети их.

anonymous
()
Ответ на: комментарий от mmarkk

Чтение на один блок меньше (с HDD) — ничто по сравнению с временем распаковки

Вах core i7-3770k на несколько миллисекунд дольше будет распаковывать - как страшно жить (с)

Меня всегда веселили нубы. Они не способны помыслить что время иногда не критично. В свое время у меня в хозяйстве на одном компе ядро пару лет грузилось с флопа - так как материнская плата винт 80гб не видела, а апдейтов биоса не было и не предвиделось. Резать винт джампером до 32гб (или сколько там) мне не хотелось. Так вот пожатое gzip2/bzip ядро не влезало на флоп. lzma решило вопрос. Ядро бутится, далее маунтит / на винте (который биосом не виден вообще) и вуаля.

black7
()
Ответ на: комментарий от fi

CD - это качество хорошего кассетника
narod.ru ... pravda ...

Как всё у вас складывается :3

anonymous
()
Ответ на: комментарий от anonymous

Первый раз вижу таких дураков, дают статью на одно, а в посте пишут ахинею, противоречащую фактам, статье и здравому смыслу. ^_^

Я смотрю у нас на лоре новичок :3

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.