The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Проект FFMpeg представил собственную реализацию декодировщика xHE-AAC"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Проект FFMpeg представил собственную реализацию декодировщика xHE-AAC"  +1 +/
Сообщение от opennews (?), 06-Июн-24, 00:28 
Разработчики мультимедийного пакета FFMpeg объявили о создании  собственной реализации декодировщика для формата кодирования звука xHE-AAC (Extended High-Efficiency AAC), определённого в стандарте ISO/IEC 23003-3. Декодировщик xHE-AAC уже принят в основную кодовую базу FFMpeg и войдёт в состав следующего выпуска. Реализация может использоваться для большинства стерео-потоков xHE-AAC. Потоки SBR, USAC и MPEG-H с объёмным звуком, а также кодировние речи пока не поддерживается. Поддержку USAC и SBR обещают добавить в ближайшее время...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61321

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


4. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (4), 06-Июн-24, 01:18 
HE-AAC всегда был ужасен своими искажениями, только AAC-LC. Сабж видимо больше из оперы HE-AAC всё же? AAC-LC до сих пор нечем заменить.
Ответить | Правка | Наверх | Cообщить модератору

6. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (6), 06-Июн-24, 01:22 
Что Столлман и латиноамериканский фонд СПО удалили flac из твоего дистрибутива?
Ответить | Правка | Наверх | Cообщить модератору

20. "Проект FFMpeg представил собственную реализацию декодировщик..."  –5 +/
Сообщение от Аноним (4), 06-Июн-24, 09:26 
> Что Столлман и латиноамериканский фонд СПО удалили flac из твоего дистрибутива?

Ты ещё mp3 предложи. Существует только aac и truehd. Ну ещё dts-hd и ac-3. И для сжатых файлов подходит только aac из списка. Вообще, зачем тебе flac, когда есть wavpack?

Ответить | Правка | Наверх | Cообщить модератору

21. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (21), 06-Июн-24, 09:47 
Waveform Audio File Format — формат файла-контейнера для хранения записи оцифрованного аудиопотока, подвид RIFF. Этот контейнер, как правило, используется для хранения несжатого звука в импульсно-кодовой модуляции. Однако контейнер не налагает каких-либо ограничений на используемый алгоритм кодирования. Википедия
MIME-тип: audio/vnd.wave
Разработчик: IBM и Майкрософт
Тип формата: аудиоформат
Ответить | Правка | Наверх | Cообщить модератору

23. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 06-Июн-24, 10:40 
Слишком ограниченный, опенсорс плохо поддерживает, файлы бессмысленно раздуты. Например, у меня есть пример "legacy WAVE file has format type 1 but bits-per-sample=24. На самом деле, truehd это индикация, что это современный студийный мастеринг, и такие дорожки не убиты, как у CD.
Ответить | Правка | Наверх | Cообщить модератору

30. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (-), 06-Июн-24, 14:22 
> Слишком ограниченный, опенсорс плохо поддерживает,

Чего в нем ограниченного? Это просто набор чанков. Произвольных. С чем угодно. В этом наборе - может быть аболютно что угодно, в любом кодеке. Как впрочем и в MP4 контейнере, весьма сравнимом по структуре - это тоже такой же набор чанков.

Опеосорсом поддержимается норм - ffmpeg например сжует почти все существующие на этом глобусе кодеки, в винде для чего-то сравнимого даже пары жирных кодекпаков от васяна маловато будет.

> файлы бессмысленно раздуты. Например,

Как может быть "бессмысленно раздут" набор чанков? Это вопрос к содержимому чанков. С тем же успехом все то же самое можно и с MP4 контейнером делать - он такой же абстрактный набор чанков. И кодеки там - произвольные. Можно даже AV1 в него запихать - и это даже будет по стандарту и все такое. Но софтом это поддерживается - сильно хуже чем вон то. Большая часть софта такое суперкомбо не ожидает пока еще. Хотя ffmpeg какой - и это сжует, конечно.

> у меня есть пример "legacy WAVE file has format type 1
> but bits-per-sample=24. На самом деле, truehd это индикация, что это современный
> студийный мастеринг, и такие дорожки не убиты, как у CD.

Это индикация что тут адепт маркетингового булщита, точно уверенный что версия 1 лучше версии 2, независимо от деталей.

Ответить | Правка | Наверх | Cообщить модератору

32. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 06-Июн-24, 17:03 
> Чего в нем ограниченного? Это просто набор чанков. Произвольных. С чем угодно.
> В этом наборе - может быть аболютно что угодно, в любом
> кодеке. Как впрочем и в MP4 контейнере, весьма сравнимом по структуре
> - это тоже такой же набор чанков.

Где мои теги?

> почти все

overestimation

>> файлы бессмысленно раздуты. Например,
> Как может быть "бессмысленно раздут"

Отсутствие сжатия, во многих случаях пустые биты вместо информации.

> Это индикация что тут адепт маркетингового булщита, точно уверенный что версия 1
> лучше версии 2, независимо от деталей.

Это индикация того, что существующие файлы могут не поддерживаться опенсорсом, конкретно мне приходилось переворачивать 2 байта чтобы файл вообще открывался. Про кд-мастеринг ты не ответил, видимо осознаёшь бесперспективность.

Ответить | Правка | Наверх | Cообщить модератору

44. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 06-Июн-24, 22:37 
> Где мои теги?

Для них вроде есть чанки. Насколько это полное хз, но так можно было.

>> почти все
> overestimation

Если что-то не сожрет даже ЭТО - в остальных местах вы и подавно заманаетесь такое открывать.

И вы просто не видели что бывает с например виндой если туда попытаться сравнимое количество кодеков вкатить. Там может наступить апокалипсис при попытке вкатить половину от этого числа форматов. А это хотя-бы на уровне системы конфликтовать не будет ни с чем.

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

Что значит - отсутствие сжатия? В WAV можно прекрасно затолкать допустим MP3 поток. И вот уже вполне себе сжатие. Но есть и дофига иных вариантов разной степени стандартности. Можно и любой иной - вопрос лишь в готовности софта это сжевать.

> Это индикация того, что существующие файлы могут не поддерживаться опенсорсом, конкретно
> мне приходилось переворачивать 2 байта чтобы файл вообще открывался.

Да мало ли кому и что приходилось? Вон под виндой можно bink video закодировать тулсами от radgametools. А теперь попробуйте .bik проиграть вообще как именно видео, произвольным плеером. А, не очень катит? Даже в системе где он сделан?! Ну а вот ffmpeg таки даже и это с неких пор жрет! А, и некий самопальный формат аудио - у них тоже в том чудном формате есть.

И даже под виндой выбор у вас будет - либо купить за дофига денег RadGameTools SDK на конских условиях, либо любить .. тот самый ffmpeg и софт на его основе. А больше вы это ничем и не откроете. Потому что проприетарный формат - и таки не "кодек" в понимании винды.

> Про кд-мастеринг ты не ответил, видимо осознаёшь бесперспективность.

А смысл обсуждать очередной маркетинговый булшит?

Ответить | Правка | Наверх | Cообщить модератору

31. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (31), 06-Июн-24, 16:45 
> опенсорс плохо поддерживает, файлы

Ну тут без вариантов формат виноват, что опенсорс его плохо поддерживает.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 06-Июн-24, 18:31 
Мне кажется, или тут топит за вавпак один человек?

flac: фактический стандарт lossless-аудио, имеет спецификацию*, всегда асимметричный**.
wavpack: а я кофе варить умею.

В вавпак можно ID3-теги, а можно APE-теги. Можно симметрично жать, а можно асимметрично. Можно PCM, а можно DSD. Можно в один файл, а можно гибридно (дома: lossy-файл + correction-файл = lossless, с собой: lossy-файл).

Идея гибридности была красива, но не взлетела. DSD сжимает, но хуже, чем DST. Кофе варит, но "продуманность наперёд" флака мне ценнее "комбайновости" вавпака. Степень сжатия флака при желании можно немного докрутить за пределы очевидных настроек (-8 ---> -8 -ep).

* хотел написать "отличную спецификацию", но для начала - она _существует_
** то есть всегда быстро декодируется

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

40. "Проект FFMpeg представил собственную реализацию декодировщик..."  –1 +/
Сообщение от Аноним (4), 06-Июн-24, 20:33 
Тебе кажется, я вижу единомышленников. Хороший формат на самом деле, если разберёшься с возможностями. Флак даже необходимые теги не может обеспечить стандартизированные, в итоге в них пихают что придётся и задача плеера в них разобраться. Уж не надо эту помойку хвалить. А wavpack медленно декодируется? Вроде, проблем нет. Это у monkeyaudio сложности с декодированием. То, что поддерживает куда больше чем flac, это же хорошо. Хочешь, пихай 1-битный звук, хочешь, 256 дорог, что угодно. Эффективность зависит от контента, на чём-то флак невозможно отстаёт.
Ответить | Правка | Наверх | Cообщить модератору

47. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 06-Июн-24, 23:26 
Вроде же в APEv2 (вавпак) 30 стандартных тегов, в VorbisComment (флак) - 15 и они оба не способы к ID3-шному принуждению типа "байт 127 - жанр, жанр номер 75 - полька".

Симметричность страшно звучит как раз после Monkey's Audio. Нашёл объяснение, как именно вавпак защищает от простреливания ног[1-3] (настроить до тормозов при перемотке на ПК нельзя, захардкожено разумное ограничение, а -x (extra encode processing) на скорость декодирования не влияет).

> на чём-то флак невозможно отстаёт

В losless-сжатии звука не было никаких невозможных разрывов типа PNG<--->JXL. Ну, последних лет 25. И выжимание байтов непопулярно, ну не жмут хотя бы с -8ep (есть и другие настройки для байтовыжимания-в-пределах-спецификации, но это уже не для меня).

> То, что поддерживает куда больше чем flac, это же хорошо

Ну, поддержка ID3v1 - очевидное легаси. Фича поиска заголовка в первом мегабайте файла родила раржипеги на новый лад - "iso.wv", что тоже скорее плохо, чем хорошо. Поддержка float32 и 9+ch создают нишу вавпаку, но это узкая ниша, а не "зачем тебе flac, когда есть wavpack". Отполированность, стандартизированность, проигрывание кофеварками имеют ценность.

[1] https://hydrogenaud.io/index.php/topic,123655.msg1022223.html#msg1022223
[2] https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/wavp...
[3] https://www.wavpack.com/wavpack_doc.html#:~:text=-x%5Bn...

Ответить | Правка | Наверх | Cообщить модератору

93. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (93), 08-Июн-24, 04:28 
> Вроде же в APEv2 (вавпак) 30 стандартных тегов, в VorbisComment (флак) -
> 15 и они оба не способы к ID3-шному принуждению типа "байт
> 127 - жанр, жанр номер 75 - полька".

Что есть стандартный тег? Особенно для APE какого-то левого? Каким стандартам это все conforms? Какой организации? Номера и референсы этих стандартов в студию?

> Симметричность страшно звучит как раз после Monkey's Audio.

Опять тут какой-то чатгпт от копирасов забрел?

> В losless-сжатии звука не было никаких невозможных разрывов типа PNG<--->JXL.

Сравнение в духе экспертов опеннета - это вот так.

> Ну, поддержка ID3v1 - очевидное легаси. Фича поиска заголовка в первом мегабайте
> файла родила раржипеги на новый лад - "iso.wv"

При том 99% людей за всю жизнь не увидят не только это - но и .wv как таковое.

Ответить | Правка | Наверх | Cообщить модератору

97. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 08-Июн-24, 10:49 
> Что есть стандартный тег? Особенно для APE какого-то левого? Каким стандартам это
> все conforms? Какой организации? Номера и референсы этих стандартов в студию?

Мы мило говорили про сжатие, про FLAC и WavPack. Бесцельно докапываться - это не сюда, а к столбу. И к ГОСТ Р 50.1.041-2002 п. 3.1.13.

>> Симметричность страшно звучит как раз после Monkey's Audio.
> Опять тут какой-то чатгпт от копирасов забрел?

Страшно звучит, страшно выглядит, пугает. Словарь подарить?

>> В losless-сжатии звука не было никаких невозможных разрывов типа PNG<--->JXL.
> Сравнение в духе экспертов опеннета - это вот так.

Люди в теме должны знать, что пережатие из PNG в lossless JXL уменьшит файл в среднем на треть. Если не согласен, то покажи подобную ситуацию в мире lossless-аудио.

"Невозможный разрыв" это обыгрывание "невозможного отставания" у собеседника.

> При том 99% людей за всю жизнь не увидят не только это
> - но и .wv как таковое.

Если ты зашёл в ветку просто чтобы сказать, что WavPack не нужен, то с этого надо было начинать, а не заканчивать.

Ответить | Правка | Наверх | Cообщить модератору

98. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 08-Июн-24, 10:57 
> ГОСТ

Чёрт, это не ГОСТ, это только "рекомендации по стандартизации". Но к ним докопаться тоже можно.

Ответить | Правка | Наверх | Cообщить модератору

102. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 19:26 
> Мы мило говорили про сжатие, про FLAC и WavPack.

Прекрасно. Просто я никогда не встречал понятия "стандартные теги" и уж тем более - описание какое их количество считается "джентльменским минимумом", а что - уже noncompliant. Без этого не понятно о чем мы говорим.

> Бесцельно докапываться - это не сюда, а к столбу.

Если некто говорит про стандарты желательно указать какая стандартизирующая организация под каким идентификатором стандарт выкатила. Иначе с хрена оно стандарт? А стандарт-де-факто это так, типа маркетингового булшита. Там что угодно может быть и не понятно о чем мы говорим и как комплайнс определять. Майкрософт вон попробовал такое, застандартизировал OOXML. Народ мигом накидал тесткейсов когда MSO не открывает файло сделаное по этим спекам. Такой вот стандарт, даже не дефактовый а формально пропиханый, на 6000 страниц.

> И к ГОСТ Р 50.1.041-2002 п. 3.1.13.

К каким-то "рекомендациям"? Про стандарты де-факто? Ну хоть не к забору с надписью, хотя, за столб сойдет наверное.

>>> Симметричность страшно звучит как раз после Monkey's Audio.
>> Опять тут какой-то чатгпт от копирасов забрел?
> Страшно звучит, страшно выглядит, пугает. Словарь подарить?

Я не догоняю - про какую симметричность, чего именно, идет речь. Так просто и банально.

>>> В losless-сжатии звука не было никаких невозможных разрывов типа PNG<--->JXL.
>> Сравнение в духе экспертов опеннета - это вот так.
> Люди в теме должны знать, что пережатие из PNG в lossless JXL
> уменьшит файл в среднем на треть.

О, еще и температура в среднем по больнице? Нормуль! А то что png довольно специализированый формат под всякий пикселарт, лайнарт и прочие скриншоты, с практически 100% гарантией что скачка PNG это точно лосслесс, видимо местных экспертов не парит? :)

Грубо говоря, скачать png примерно как скачать .bmp.zip (ppm.gz, etc). В то время как в jxl попробуй угадать что втулят. Может и пережатое мутное месиво быть, без гарантий. Не эквивалетно для этого кейса, мягко говоря.

> Если не согласен, то покажи подобную ситуацию в мире lossless-аудио.

??? Мой пойнт был что JXL и PNG довольно разные на уровне технологий штуки, под несколько разные сценарии.

> Если ты зашёл в ветку просто чтобы сказать, что WavPack не нужен,
> то с этого надо было начинать, а не заканчивать.

В принципе можно и так сказать. Во всяком случае FLAC в диком виде мне попадался - а расширение wv я впервые в жизни вижу. Видимо настолько всем нужно. Ну да, теоретически он есть. Практически FLAC раньше подсуетился, нишу занял, улучшения относительно маргинальные, ну оно и...

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

106. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 08-Июн-24, 20:59 
> не встречал понятия "стандартные теги"

хз, на wiki hydrogenaudio встречается.

> желательно указать какая стандартизирующая организация

Ну, всё равно в гостах (теперь уже настоящих) можно нагуглить фразы "фактический стандарт", "стандарт де-факто", "официальный стандарт". Так что лучше сначала пойти докапываться к ним.

> Я не догоняю - про какую симметричность, чего именно, идет речь. Так просто и банально.

Плохо быть тобой. Другие бы пересилили себя и спросили.

> *о том, что JXL может быть lossy*

Ясен пень, он может быть lossy.
Ясен пень, он НЕ может быть lossy в контексте разговора и я во второй раз на всякий случай это прямо написал.
Опять можно было спросить, неужели в JXL есть lossless-режим, а не продолжать делать вид, что я умудрился перепутать lossy и lossless-кодеки.

Да, теперь у lossy и lossless одинаковое расширение, а разное расширение было полезным побочным эффектом. Но это не новая проблема (она есть у видео, у JPEG 2000, у WebP) и о ней не интересно тут говорить.

Ответить | Правка | Наверх | Cообщить модератору

33. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 06-Июн-24, 17:37 
> Сабж видимо больше из оперы HE-AAC всё же?

А кодеки H.26* (и VP*) вообще одной цифрой отличаются, и так лет 40.

Что слышно сразу: xHE-AAC однозначно лучше Opus'а на битрейтах, где до прозрачности далеко (<< 100 kbps).

О чём ещё говорят: xHE-AAC не хуже AAC-LC. Но на битрейтах около ~100 kbps значимого улучшения не даёт. Говорят, что xHE-AAC@96kbps не дотягивает до Opus/AAC-LC@128kbps. А была бы этакая психологически важная ступенька.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

52. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 06:46 
Вот что пишут: "HE-AAC (англ. High-Efficiency Advanced Audio Coding — высокоэффективное усовершенствованное аудиокодирование) — формат сжатия звука с потерями, определен как профиль MPEG-4 Audio (Part 3) в стандарте ISO/IEC 14496-3. Формат является расширением профиля Low Complexity AAC (AAC LC), оптимизированным для приложений с низким потоком передачи данных цифрового потока. В профиле HE-AAC версия 1 (HE-AAC v1) используется технология восстановления высоких частот SBR (англ. Spectral band replication — копирование спектральной полосы) для повышения эффективности кодирования в частотной области. В профиле HE-AAC версия 2 (HE-AAC v2) технология SBR объединена с технологией Параметрического кодирования стереопанорамы (англ. Parametric Stereo) для повышения эффективности кодирования стереосигналов. Это стандартизованная и улучшенная версия аудиокодека AACplus"
Ответить | Правка | Наверх | Cообщить модератору

54. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (-), 07-Июн-24, 06:50 
Вот что пишут AAC:

Подразделяется на профили

    Main Profile — «основной профиль»;
    Low Complexity (LC-AAC) — «низкая сложность»;
    High-Efficiency Advanced Audio Coding (HE-AAC) — «высокая эффективность»;
    Extended High Efficiency Advanced Audio Coding (xHE-AAC) — «расширенная высокая эффективность»;
    Scalable Sample Rate (SSR) — «масштабируемая частота дискретизации»;
    Long Term Prediction (LTP) — «долгосрочное предсказание». Более сложный и ресурсоёмкий (но и более качественный), чем все остальные.

High Efficiency Advanced Audio Coding (ААС+)
ААС+ — профиль, ориентированный на низкий битрейт. Представляет собой комбинацию AAC LC, но с частотой дискретизации вдвое меньшей, чем у оригинала, что существенно уменьшает накладные расходы на битрейт, затем используется технология восстановления спектра (англ. Spectral Band Replication) путём его предсказания и использования некоторой дополнительной информации для восстановления. Естественно, такой подход не обладает большой точностью и пригоден только в случаях, когда очень необходимо уменьшить битрейт"

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

76. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 07-Июн-24, 13:45 
Если упростить, то:
- под AAC по дефолту подразумевают AAC-LC
- потом появился другой формат HE-AAC
- потом HE-AAC v2
- потом xHE-AAC
- остальные форматы - дремучие, в широкие массы не пошли

- другие современники AAC-LC - AAC Main и AAC-SSR умерли в младенчестве, нет их
- виды AAC называют не только отдельными форматами/стандартами/кодеками, но ещё и "профилями"
--- это нормальная странность, вон MPEG-4 - это гора стандартов обо всём. H.264 - это MPEG-4, "DivX/Xvid" - это MPEG-4, AAC-LC - это MPEG-4, ISOBMFF - это MPEG-4, .mp4 - это MPEG-4...
--- и намёк на поддержку декодерами предыдущих форматов. Это как если бы декодер H.265 проигрывал H.264, H.263 и так далее. В цепочке из первого абзаца AAC-LC->...->xHE-AAC так оно и есть

Ответить | Правка | Наверх | Cообщить модератору

49. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 06:23 
Так вроде профиль LC-AAC ограничен не ниже 80 килобит/c, вроде некоторые кодеки ААС имеют реализацию только профиля LC-AAC и ограничены не ниже 80 килобит/c. И если LC-AAC не ограничены битрейтом 80 килобит/c то звук портится очень сильно если битрейт для профиля LC-AAC использовать ниже 80 килобит/c - чем ниже 80 килобит/c тем хуже, проверял. Профиль HE-AAC 24 килобит/c два канала: плохо или не плохо это на любителя - точно нормально, проверял. Не все разновидности кодеков AAC кодируют с профилем HE-AAC нет такого в них, не реализовано. Вроде так, перепроверят надо.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

53. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 06:50 
В 80 килобитах 10 килобайт. Битрейт измеряется в килобайтах. Дело не в битрейте, качество AAC сильно зависит от того, чем он закодирован. Из доступного есть проприетарный fdk_aac, он интегрируется в тот же ffmpeg. Но он достаточно средний, если сравнивать с эпловским кодером.
Ответить | Правка | Наверх | Cообщить модератору

55. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (-), 07-Июн-24, 07:01 
Перепроверпл. Нет я не перепутал. Битрейт звука измеряется в "килобит в секунду"

Килобит в секунду (условное обозначение кбит/с или кб/с, часто сокращенно «кбит/с») — единица измерения скорости передачи данных, равная:

1 000 бит в секунду
125 байт в секунду

Ответить | Правка | Наверх | Cообщить модератору

56. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 07:03 
Английский вариант:

Kilobit per second

Kilobit per second (symbol kbit/s or kb/s, often abbreviated "kbps") is a unit of data transfer rate equal to:

1,000 bits per second
125 bytes per second

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

57. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 07:14 
Да есть реализация AAC кодека разная, но сравнивать разность реализаций кодеков AAC надо только между одинаковыми профилями. Если закодировать звук с профилем High Efficiency Advanced Audio Coding (ААС+) и битрейтом 24 килобит/c и попробовать закодировать звук LC-AAC и битрейтом 24 килобит/c разница будет большая. AAC c профилем High Efficiency Advanced Audio Coding (ААС+) 24 килобит/c это нормальное качество звука. AAC c профилем LC-AAC битрейтом 24 килобит/c это явно заметное плохое качество звука.
Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

60. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 07:40 
Да есть реализация AAC кодека разная, но сравнивать разность реализаций кодеков AAC надо только между одинаковыми профилями. Если закодировать звук с профилем High Efficiency Advanced Audio Coding (ААС+) и битрейтом 24 килобит/c и попробовать закодировать звук с профилем LC-AAC и битрейтом 24 килобит/c разница будет большая. AAC c профилем High Efficiency Advanced Audio Coding (ААС+) 24 килобит/c это нормальное качество звука. AAC c профилем LC-AAC битрейтом 24 килобит/c это явно заметное плохое качество звука.
Ответить | Правка | Наверх | Cообщить модератору

61. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 07:41 
Физически больно слушать файлы меньше чем с ~70кбпс на канал, например, звуковую дорожку видеофайлов часто кодируют в 96кбпс aac или 64кбпс aac (2 канала) и это довольно ужасно. И да, aac+/aac++ вносят просто нереальные искажения, поэтому смысла рассматривать даже нет. Без использования silk и прочего подобного кодировать 1 секунду в 3 килобайта? Ха. Да и у того это будет квакание.

В общем, я посмотрел, что такое этот сабж, это he-aac v2 (aac++) и есть, в него добавили только эвристику. Не сравнивал, но эвристика того же опуса абсолютно ужасна и искажения совершенно непредсказуемые.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

62. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 09:33 
Сильно раздражает звук в youtube? А там используется Opus и AAC вроде Opus с битрейтом 250 килобит/c это не точно предположение. Как посмотреть ААС или Opus ипользуется - правой кнопкой на видео, выбрать статистика. Что мы сравниваем файлы c битрейтом 24,64,96,128,160,192,256,320,384 килобит/c и т.д. 16 бит, 32 бит переменный, 441000, 48000 МГц? 24 килобит/c Opus c качеством сжатия максимальное 10 и AAC+ 24 килобит/c это нормально. mpeg2 аудио вроде минимум 32 килобит/c можно выбрать для mpeg2 точно не помню, mpeg3, ogg, AAC LC-AAC c 24 килобит/c 441000, 48000 МГц не справляются это явно плохо.
Ответить | Правка | Наверх | Cообщить модератору

63. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 09:37 
441000 ноль лишний. 44100
Ответить | Правка | Наверх | Cообщить модератору

64. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 09:38 
По этой причине я переключил на aac и он там совсем порезанный. Opus на утубе около 100kbps и при этом имеет сильные искажения, будь он 250 претензий никаких бы не было. Сравнить можно скачав дорожки в yt-dlp.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

66. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 09:56 
Попробую узнать какой битрейт у opus в youtube. Я к чему упоминаю 24 клбит к тому, что если для меня opus и AAC+ c 24 клбит/c это не ужас то opus и AAC c 100 клбит/c для музыки будет нормально,  но это для меня. Я музыку не сжимаю. Я сжимаю голос - разговоры. Для этого использую Opus c 12 клбит/c моно один канал и этого достаточно чтобы голос был понятен и не искажался явно, только если придираться и то скорее всего претензия будет по тому что это моно, а не стерео. Сам предпочитаю музыку слушать если есть возможность в формате сжатия не меньше того, что записывают и продают в СD дисках.
Ответить | Правка | Наверх | Cообщить модератору

70. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 10:08 
Голос и музыка в опусе это 2 разных кодека. Большая проблема опуса это эвристики. Ну и сам принцип кодирования, при котором кодируется сразу несколько вариантов и выбирается случайный подходящий это не то что хочется слышать. Конкретно, меня нервируют искажения голоса с музыкой на фоне (по идее, это "хорошая" часть опуса), aac более естественно и единообразно звучит. Голос предпочтительнее кодировать в wavpack с небольшими потерями.
Ответить | Правка | Наверх | Cообщить модератору

72. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 10:23 
Для меня сильно плохо это если сжимать ниже 64 клбит/c. Я не против битрейт выше. Я о том какой битрейт для меня уже не удобен для прослушивания. Я не о opuы я любом кодеке примерно ниже 64 и я о музыке.
Ответить | Правка | Наверх | Cообщить модератору

81. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 19:00 
Всё таки я подумал, повспоминал. Нет к AAC+ и Opus скорее всего это не относится. Я когда-то лет 7-10 назад проверял AAC кодек от NERO там скорее всего для битрейта 24 килобит в секунду используется какая-то разновидность профиля "High Efficiency Advanced Audio Coding" сравнивал с кодеком AAC из Ffmpeg, AAC из Ffmpeg намного хуже было качество сжатия, явно с таким битрейтом AAC из FFnpeg не годится. Nero AAC сжимал с битрейтом 24 килобит в секунду и это было не плохо. Предполагаю что и с Opus с битрейтом 24 килобит в секунду примерно также. Используя Opus сжать музыкальный файл с 24 килобитами для меня работа на минуты ленюсь снова проверять мне это не очень надо. Я и Opus когда-то проверял сжимал музыку c 24 килобит в секунду. Подзабыл как звучит точно. Но, точно помню что с этими кодеками Nero AAC, OPUS  с битрейтом 24 килобит в секунду музыка это приемлемо не ужас ужас. Тогда я кодеки использовал консольные для Windows. Сейчас по разному когда из Linux, а когда из Windows. AAC кодека от NERO вроде для Linux нет.
Ответить | Правка | Наверх | Cообщить модератору

83. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 19:36 
Есть предположение что в FFmpeg используется разновидность AAC кодека с профилем LC-AAC.
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

99. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 08-Июн-24, 11:45 
Даже не надо предполагать.

"FFmpeg supports three AAC-LC encoders (aac, libfdk_aac, aac_at) and two HE-AAC (v1/2) encoder (libfdk_aac, aac_at)" - https://trac.ffmpeg.org/wiki/Encode/AAC

С ютубом тоже проще.


yt-dlp -F <url> >1.txt
139     m4a  audio only ...  49k[bit/s] ... mp4a.40.5 ... low, m4a_dash
249     webm audio only ...  49k[bit/s] ... opus      ... low, webm_dash
250     webm audio only ...  55k[bit/s] ... opus      ... low, webm_dash
140-drc m4a  audio only ... 129k[bit/s] ... mp4a.40.2 ... medium, DRC, m4a_dash

Плюс объяснение из [1]:
"mp4a.40.2" — MPEG-4 AAC LC
"mp4a.40.5" — MPEG-4 HE-AAC v1 (AAC LC + SBR)

[1] https://www.w3.org/TR/webcodecs-aac-codec-registration/#full...

Ответить | Правка | Наверх | Cообщить модератору

107. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 23:08 
А как правильно? В одном месте я вижу профили называются LC-AAC, а не AAC-LC. Логично выглядит LC-AAC, HE-AAC  там так и написано. Может я чего-то не знаю и что-то уже поменялось или профиль HE-AAC в FFMpeg для ААС кодеке надо включать указывая прописыванием для кодирования настройкой? Давно сжимал через FFMpeg кодеком ААС в 24 килобит лет 7-10 назад , сжимал по простому без указывания для кодека AAC дополнительных настроек. Тогда когда сжимал разница между Nero AAC 24 килобит и FFMpeg AAC 24 килобит была значительная на слух. Nero AAC 24 килобит на слух было не плохо, FFMpeg AAC 24 килобит на слух было хуже и явно плохо. Ссылку помотрел поверхностно вникать пока не хочу.
Ответить | Правка | Наверх | Cообщить модератору

111. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (35), 09-Июн-24, 01:37 
> А как правильно?

AAC LC, HE-AAC. Всё-таки это самые точные[1] их названия.

> или профиль HE-AAC в FFMpeg для ААС кодеке надо включать

Да, он по дефолту AAC LC выберет.

> FFMpeg AAC 24 килобит на слух было хуже и явно плохо

И это не единственный его подвох. На больших битрейтах тоже стоит поколдовать - отказаться от штатного энкодера (-codec:a aac) и выбрать реализацию получше (-codec:a libfdk_aac или ещё лучше эпловский aac_at), которых нет в обычных сборках ffmpeg из-за лицензий (по крайней мере, aac_at не видел). Вместо собирания ffmpeg с aac_at проще запустить этот эпловский энкодер отдельным приложением (qaac).

[1] https://www.iso.org/obp/ui#iso:std:iso-iec:14496:-3:ed-4:v1:en

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

108. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 23:57 
И без -. А как правильно? В одном месте я вижу профили называются LC-AAC, а не AAC LC. Или это может что-то разное, вроде об одном и томже.
Ответить | Правка | Наверх | Cообщить модератору

109. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 09-Июн-24, 00:13 
Я уже плохо помню, а может это был для сравнения Nero AAC и VLC AAC (FFMpeg). AAC+ я использовал через программу где можно сжимать в разные форматы разных кодеков: AAC, AAC+ и другие кодеки. Берём кодеки под свои нужды, сравниваем кодеки, пользуемся что устраивает и что для нас лучше.
Ответить | Правка | Наверх | Cообщить модератору

110. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 09-Июн-24, 00:36 
Вспоминаю скорее всего я сравнивал не с FFMpеg используя консоль, а с сжатием используя VLC.
Ответить | Правка | Наверх | Cообщить модератору

114. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 11-Июн-24, 05:17 
И если нет проблем с использованием Windows Nero AAC доступен если запустится в Win. 10,11 и кому нужен AAC с низким битрейтом. www.videohelp.com/software/Nero-AAC-Codec

Nero AAC: "The encoder and decoder support MPEG-4 AAC LC, HE-AAC (AAC LC + SBR), and HE-AACv2 (LC + SBR + PS) Audio Object Types. Sample rates up to 96 kHz, and multichannel audio up to six channels (5.1 surround) are supported".

Ответить | Правка | Наверх | Cообщить модератору

74. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 10:27 
Я не о opus, я о любом кодеке примерно ниже 64 клбит/c и я о музыке.
Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

85. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 21:25 
Посмотрел на одном файле с yoyutube с разрешением 360p. Может битрейт у звука и 100 килобит/c, а может и 128 килобит/c. Битрейт звука в файле переменный от 98 килобит/c было одну секунду 98 килобит/c, остальное время в диапазоне 115-140 битрейт. Больше похоже звук закодирован с битрейтом 128 килобит/c переменный. А как на самом деле я не знаю это только предположение из того что я увидел
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

68. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 10:05 
как правило mpeg3 16бит 44100
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

71. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 10:17 
Если слушать через компьютер там уже ресемплирование у меня участвует в плеерах, в 32 бит 48000 Гц для сжатых файлов. В основном это интернет радио, а там как правило 16бит 44100. А если я буду СD слушать или с качеством как у CD я буду скорее всего ресемплировать в 384000Гц 32бит. Для звука это не МГц, а Гц. Не то чтобы я не знал, с обозначением частоты процессора перепутал.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

65. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 09:41 
ogg это контейнер. Я имел ввиду vorbis.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

86. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 23:28 
> В 80 килобитах 10 килобайт. Битрейт измеряется в килобайтах.

Странно, говорим про биты а меряем - байты? Хотя эксперты опеннета еще и не такое надо.

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

87. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 23:44 
Ничего странного. Если бы диски были в битах, другое дело.
Ответить | Правка | Наверх | Cообщить модератору

92. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 04:19 
> Ничего странного. Если бы диски были в битах, другое дело.

Понятие битрейт - означает скорость битового потока. И меряется таки - в битах в секунду.

Но для опеннетовских экспертов не умеющих в поискарь, так и быть:
https://en.wikipedia.org/wiki/Bitrate
https://ru.wikipedia.org/wiki/%D0%91%D0%...

"Битрейт выражается битами в секунду (бит/c, bps)". The bit rate is expressed in the unit bit per second (symbol: bit/s). Но, конечно, можно заспорить что васян с опеннета - авторитетнее энциклопедий.

Ответить | Правка | Наверх | Cообщить модератору

94. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 08-Июн-24, 08:19 
Это называется "абстрактное мышление", ты палишься, когда демонстрируешь его отсутствие.

Ответить | Правка | Наверх | Cообщить модератору

58. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 07:18 
Я перепутал, 24 килобит/c не с профилем HE-AAC, а с профилем High Efficiency Advanced Audio Coding (ААС+).
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

88. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (88), 08-Июн-24, 00:01 
В новости же написано
> Потоки SBR... пока не поддерживается.

Так что можешь спать спокойно, файлы в плохом качестве он воспроизведёт в ещё худшем качестве. ;) В таком же плохом, как должно быть в LC-AAC.

А то что вышло - скорее убийца AC3! High Dynamic Range (float) теперь поддерживается. AC3 больше ненужен, или может быть сконвертирован без потерь этого самого HDR-звука (который был в 90% всех DVD и который лучше НЕ конвертить в wav/mp3/aac, а оставить в AC3).

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

89. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (88), 08-Июн-24, 01:07 
> HE-AAC всегда был ужасен своими искажениями

Для музыки - да. Для речи получается наоборот. При низких битрейтах HE и HEv2 однозначно лучше. На речи (диктор читает новости) очень даже хороший результат и всегда лучше LC-AAC.

Претензию нужно просто переформулировать в виде: "Зачем нужен HE-AAC при битрейтах 96kbit/s и выше?" Многие кодеки такой режим умеют, а зачем - совершенно непонятно... лучше не станет никак.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

96. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 08-Июн-24, 08:54 
Мне не нравится, когда голоса не естественные. А уж если там фоновый шум есть, то всё. Иногда может и музыка попасться. Я пытался использовать aac++ для мувиков, перегоняемых в низкое разрешение, но это невозможно.
Ответить | Правка | Наверх | Cообщить модератору

112. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (112), 10-Июн-24, 00:12 
Для фильмов - может быть и хуже, особенно, если есть запас по битрейту до 128кбит/с на аудиодорожку.
Для internet radio broadcast в 32-48-64кбит/с HE-AAC рвёт почти всех (ну уж точно лучше vorbis, mp3 и LC-AAC, они тупо свалятся в 22050Hz). Даже небольшую фоновую музыку не так уж и искажает. Конечно любимую музыку в таком ужасном качестве никто слушать не будет ;) Да и для фильмов можно лучше, если догнать до ~128кбит/с на дорожку.

Но тут надо смотреть именно область применения и бюджет по битрейту. Интернет-трансляции какого-нибудь радио Маньяк только выиграют от внедрения HE-AAC, т.к. LC-AAC на 32кбит/с тоже даёт огромные искажения, не говоря уже об mp3.

Ответить | Правка | Наверх | Cообщить модератору

5. "Проект FFMpeg представил собственную реализацию декодировщик..."  –2 +/
Сообщение от Аноним (6), 06-Июн-24, 01:21 
Как же у нас все любят проприетарный треш. Сколько сотен миллионов долларов Netflix платит патентодержателям Via Licensing история умалчивает. Чем быстрее h266 пойдет в массы стриминговых платформ тем скорее все начнут забывать про AV1. Лол.
Ответить | Правка | Наверх | Cообщить модератору

8. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Bob (??), 06-Июн-24, 01:36 
1) слушай - а за софт и кодеки платить не надо, если результат реально хороший?
2) av1 он где есть? а вот h265 почти везде. Так же и с h266 будет.

Если бизнесу проще и дешевле проприетарщина - ок.
Параллельно есть опен сурс и он в относительном паритетете? - гуд.
Баланс соблюли.

Тому же нетфликсу проще 1 перекодировать и стримить Эгзаба́йтами меньше, при том же качестве. Как резеовная копия и на девайс офлайн кинуть послушать - тоже ок.

Лично я предпочитаю "свободу" vorbis, vp9 и webp. Но вполне и других понимаю. xHH-AAC, h265 и HEIC давно хардварно в ходу на многих девайсах (те же самсунг и яблоко, более 10 лет) и тут банально батаоейка и траффик порешали.

Ответить | Правка | Наверх | Cообщить модератору

9. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от cheburnator9000 (ok), 06-Июн-24, 01:41 
AV1 в ютубе есть. Можешь проверить через yt-dlg. Для этого браузер должен поддерживать декодирование. Под вендой нужно установить либо сторонние кодеки, либо https://www.microsoft.com/store/productId/9MVZQVXJBQ9V?ocid=... AV1 в 1080p вытянет даже процессоры времен Haswell, загрузка будет в районе 10-30% в зависимости от сцены. 4K нужно аппаратное ускорение от новых видеокарт, процессором декодировать уже не так клево, нагрузка будет серьезная хоть на восмиядернике под 5ггц.
Ответить | Правка | Наверх | Cообщить модератору

10. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (10), 06-Июн-24, 02:57 
А четырехядерники по 3ггц так вообще будут пропускать почти все кадры, со 100% загрузкой CPU. Хороший тест между прочим, Линукс зависает.
Ответить | Правка | Наверх | Cообщить модератору

11. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от нитгитлистер (?), 06-Июн-24, 05:30 
если он так хорош, почему у него рейтинг 3,6?
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

12. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (12), 06-Июн-24, 06:04 
Вот примеры отзывов с единицей:

> 1.0 Another stupid thing
> That should be included with the operating system. At least they didn't charge for it this time.
> 1.0 Should be installed by default
> Stupid to make this 1.55MB an optional install

Ответить | Правка | Наверх | Cообщить модератору

13. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Xo (?), 06-Июн-24, 07:36 
Потому что на селеронах запускают.
Ответить | Правка | Наверх | Cообщить модератору

34. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (34), 06-Июн-24, 17:56 
Тут стоит указывать fps. Хотя даже 6-и ядерника 3-х летней давности хватит, чтобы без особых проблем вывезти 4К@60, с загрузкой в районе 30%. Серьезная нагрузка - это 8К.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

37. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от cheburnator9000 (ok), 06-Июн-24, 19:39 
> Тут стоит указывать fps. Хотя даже 6-и ядерника 3-х летней давности хватит,
> чтобы без особых проблем вывезти 4К@60, с загрузкой в районе 30%.
> Серьезная нагрузка - это 8К.

30%?? Ты проверял? Проверь. У тебя процессор сожрет электричества на весь свой термопакет. В то время как хардварные декодеры в видеочипах в тысячу раз эффективнее. Вон даже у MediaTek есть декодер ARM чипах. Жалко что история с mini pcie хардварными декодерами для ПК заглохла в 2014 году.

Ответить | Правка | Наверх | Cообщить модератору

41. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (34), 06-Июн-24, 20:45 
> 30%?? Ты проверял?

Разумеется. В догонку 4K@30 ~ 15%, 8K@24 ~ 40%. Это в ютубе на Хромом под оффтопиком. На mpv загрузка существенно ниже. Ryzen 5600, если что.

> В то время как хардварные декодеры в видеочипах в тысячу раз эффективнее.

А вот с этим никто не спорит


Ответить | Правка | Наверх | Cообщить модератору

42. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от cheburnator9000 (ok), 06-Июн-24, 20:58 
>> 30%?? Ты проверял?
> Разумеется. В догонку 4K@30 ~ 15%, 8K@24 ~ 40%. Это в ютубе
> на Хромом под оффтопиком. На mpv загрузка существенно ниже. Ryzen 5600,
> если что.
>> В то время как хардварные декодеры в видеочипах в тысячу раз эффективнее.
> А вот с этим никто не спорит

я лично вообще не уверен, что это данные CPU декодинга.

Ответить | Правка | Наверх | Cообщить модератору

75. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (75), 07-Июн-24, 11:04 
> я лично вообще не уверен, что это данные CPU декодинга.

А больше некому. GPU - Pascal, и он не умеет в AV1


Ответить | Правка | Наверх | Cообщить модератору

14. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 06-Июн-24, 07:59 
> 2) av1 он где есть? а вот h265 почти везде.

А ничего что ютуб кажет в AV1 - а 265 в вебе - по нулям практически?

> Так же и с h266 будет.

Т.е. - по нулям в вебе то? Кто бы сомневался.

> Параллельно есть опен сурс и он в относительном паритетете? - гуд. Баланс соблюли.

А чего вы тогда так нервничаете?

> Тому же нетфликсу проще 1 перекодировать и стримить Эгзаба́йтами меньше,

Нетфликс тоже с неких пор AV1 использует, внезапно.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

46. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 06-Июн-24, 23:16 
>а 265 в вебе - по нулям практически

У меня для тебя есть новости, большинство людей использует именно его в вебе. И специальный пропатченный браузер, ага.

Ответить | Правка | Наверх | Cообщить модератору

48. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 04:19 
> У меня для тебя есть новости, большинство людей использует именно его в вебе.

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

> И специальный пропатченный браузер, ага.

Сразу с троянцами от васяна, внагрузку к варезку, чтобы все по уму? Вас обманули, это не большинство в общепланетарном масштабе. Мягко говоря.

Большинство - это пара миллиардов юзерей какого-нибудь ведроида. VP9 из них сожрет буквально 99.9% а процентов 90 и AV1 уже таки. А васяны с самопальными патчеными браузерами таки жесточайшая маргинальщина.

Ответить | Правка | Наверх | Cообщить модератору

50. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 06:23 
Я имел в виду именно в планетарном масштабе. Гугл не большинство.
Ответить | Правка | Наверх | Cообщить модератору

90. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 04:03 
> Я имел в виду именно в планетарном масштабе. Гугл не большинство.

Ну конечно, большинство - васяны с патченым браузером. А не пара миллиардов гуглофонов - с ютубом и всем этим великолепием. Черт, даже эпл прожался - а куда он денется с подводной лодки? Своего популярного видеосервиса у них же нет, и когда гугл стал в 264 только fallback с мутным качеством и низким битрейтом грузить (и даже так все равно битрейт ломовой) - пользователи привыкшие к премиум экспериенсу не поняли и таки задолбали эпл.

Ответить | Правка | Наверх | Cообщить модератору

95. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 08-Июн-24, 08:29 
Почему, васяны? Самые обычные пользователи. Ютуб и его пользователи далеко не большинство, так что ты просто очевидно не в теме. И даже эпол (который очень любит H265, сервисы эпл долгое время оставались самыми качественными стриминговыми сервисами) не особо влияет. Между прочим, такая политика применения куда более качественного и эффективного кодека вместо древнего avc, без оглядки на гуглы, заслуживает уважения. Яндексу и прочим стоило бы поучиться.
Ответить | Правка | Наверх | Cообщить модератору

103. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 19:41 
> Почему, васяны? Самые обычные пользователи.

Обычные пользователи зырят ютубы и нетфликсы и точно никакие плагины никуда не ставят. Как максимум на смарте ютуб в проге гугли открыться может. Если им что-то не кажется - свалят с сайта в 95% случаев. Сюрприз!

> Ютуб и его пользователи далеко не большинство,
> так что ты просто очевидно не в теме.

Я в теме, что около 80% трафика в интернете генерят эти двое. А ваши васяны все, вместе взятые, с всем остальным вообще, вплоть до скачки исошек и зипарей - остальные 20%.

> И даже эпол (который очень любит H265, сервисы эпл долгое время оставались
> самыми качественными стриминговыми сервисами) не особо влияет.

У эпла нет своего популярного видеосервиса. Поэтому он будет изволить уметь то что дают жрать вон те. Так и прожались под AV1, куда они с подводной лодки денутся? Будут смотреть fallback шевелящиеся квадратики в 264? Тогда половина в следующий раз купит флагман от самсуня и проч с неоспоримым аргументом "там ютуб сильно лучше играется".

> Между прочим, такая политика применения куда более качественного и эффективного
> кодека вместо древнего avc, без оглядки на гуглы, заслуживает уважения. Яндексу
> и прочим стоило бы поучиться.

Я не знаю у кого такая политика стрельбы себе в пятки - но это хороший способ остаться без пользователей.

Ответить | Правка | Наверх | Cообщить модератору

104. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 08-Июн-24, 20:04 
В стране нет ютуба и нетфликса. И гугла. О чём ты вообще? Кто куда свалит?
Ответить | Правка | Наверх | Cообщить модератору

101. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 18:34 
> Я имел в виду именно в планетарном масштабе. Гугл не большинство.

Именно в планетарном масштабе гугол и нетфликс держат львиную долю аудитории и трафика в интернете. Оба юзают AV1. А если кто предпочитает бакланить и тормозить - ну вот поэтому есть гугл и нетфликс. А есть - все остальные, по сути безымянные треш-сервисы. Потому что технологиями не вышли.

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

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

105. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 08-Июн-24, 20:07 
Всё хорошо, но ты забыл парочку-другую стран с половиной населения планеты, в планетарном масштабе.


Ответить | Правка | Наверх | Cообщить модератору

51. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (4), 07-Июн-24, 06:26 
Про av1 хорошая шутка, кстати. Его пытаются пропихивать (в основном в гугле), но какой же он дефективный, больно видеть.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

78. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 17:29 
> Про av1 хорошая шутка, кстати. Его пытаются пропихивать (в основном в гугле),
> но какой же он дефективный, больно видеть.

Походу с нами чатгпт болтает - взаимоисключающие параграфы в одном посте это так мило :)

Ответить | Правка | Наверх | Cообщить модератору

80. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (4), 07-Июн-24, 18:43 
А в чём взаимоисключение? Попроси чатгпт разжевать, если тяжело.
Ответить | Правка | Наверх | Cообщить модератору

15. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 06-Июн-24, 08:06 
> Как же у нас все любят проприетарный треш. Сколько сотен миллионов долларов
> Netflix платит патентодержателям Via Licensing история умалчивает. Чем быстрее h266 пойдет
> в массы стриминговых платформ тем скорее все начнут забывать про AV1. Лол.

А пока-что Netflix начал кодировать в этом самом AV1 почему-то :). При том не понятно кто и поему будет для 266 на тех условиях эффективные кодеки корябать. С этим и для 265 то не задалось.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

18. "Проект FFMpeg представил собственную реализацию декодировщик..."  +4 +/
Сообщение от Вова (?), 06-Июн-24, 08:41 
Когда одна компания платит другой "патентные отчисления" (при наличии "бесплатных аналогов"), это кажется глупостью. Но...

1. Возможно, платный кодек на порядок круче FOSS. Тем более, что над такими вещами работают специалисты, а не энтузазисты.
2. Не удивлюсь, если патентодержатель - это "сын директора" :) Денюшки легально уплывают в лоно семьи, а родные работники остаются с носом.
3. Какие-нть внутренние игры по отмыванию денег.

Короче, если что-то связано с деньгами и вам кажется "ну это же глупо!", то вот там не всё так просто. :) Надо расследовать, вникать в детали... С дивана, понятно, никакой правды не найти.

Ответить | Правка | Наверх | Cообщить модератору

19. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от кент кента (?), 06-Июн-24, 09:15 
>если что-то связано с деньгами и вам кажется "ну это же глупо!", то вот там не всё так просто.

Много лет работаю в системообразующем предприятии РФ. инфа 100500, что куча сервисов покупается без веской причины, либо из соображений "ну дали же бюджет", либо минимальный тариф такой, что выбирается 10% у одного управления и 15% у другого. А замутить общий доступ для всей группы компаний (часто размазанной на 100+ отдельных ЮЛ) лениво. итд итп а откатывают и пилят совсем на другом.

Ответить | Правка | Наверх | Cообщить модератору

26. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от Аноним (26), 06-Июн-24, 12:21 
Теории заговора и не всё так однозначно.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

38. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от cheburnator9000 (ok), 06-Июн-24, 19:52 
Бесплатные аналоги плохо интегрируются в профессиональный видеоредакторы. Потому что там все завязано на профессиональные камеры, а те в свою очередь сохраняют видеопоток в Apple ProRes формат.

Не нужно смотреть на iPhone ProRes видео, оно там по сути от HEVC отличается лишь более яркими цветами и HDR информацией. Видеокамеры за 2+ килобаксов показывают куда качественную картинку. И конечно данные весят десятки гигабайт и больше.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

24. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (24), 06-Июн-24, 11:12 
А для декодирования/воспроизведения низкобитрейтных AAC ELD всё ещё нужно пользоваться сторонней библиотекой AAC FDK, что печально... Всё, что ниже 64 kbps, воспроизводится только так:
$ ffplay -codec:a libfdk_aac audio-aac-eld.m4a
Ответить | Правка | Наверх | Cообщить модератору

25. "Проект FFMpeg представил собственную реализацию декодировщик..."  +2 +/
Сообщение от нах. (?), 06-Июн-24, 11:39 
чего печального в том что тебе на халяву дана профессионалами сделанная библиотека, делающая то что положено (а не то что кое-как получилось)?

Ответить | Правка | Наверх | Cообщить модератору

27. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (26), 06-Июн-24, 12:23 
Печально что из-за этого она не нужна.
Ответить | Правка | Наверх | Cообщить модератору

28. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (24), 06-Июн-24, 13:04 
Печально то, что она не входит в состав FFMpeg из-за несовместимости лицензий. Ей нужно скачивать отдельно и собираться сам FFMpeg с её поддержкой.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

29. "Проект FFMpeg представил собственную реализацию декодировщик..."  +1 +/
Сообщение от нах. (?), 06-Июн-24, 13:50 
расскажите им уже кто-нибудь что там патент протух - год уже по-моему, если не два.

А лицензия изначально была "free without patent license"

(т.е. если ты не имеешь проблем с патентом - неважно, купил или не действует, то код можешь использовать как хочешь, правда, кроме перепродажи, но это белок-истеричек наоборот же должно возбуждать)

Ответить | Правка | Наверх | Cообщить модератору

77. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 07-Июн-24, 17:28 
> не действует, то код можешь использовать как хочешь, правда, кроме перепродажи,
> но это белок-истеричек наоборот же должно возбуждать)

Это еще с хрена ли? GPLщики совершенно не прочь подзаработать на своем коде не хуже всех остальных. А какой-нибудь CC-BY-NC-ND внезапно за это считается несвободной лицензией.

Прикинь, даже AGPL какой ничего про деньги не говорит. Только о том что сорцом надо делиться. Поэтому на том же линухе толпа народа делает деньги. Прикинь, так можно было!

Ответить | Правка | Наверх | Cообщить модератору

79. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от нах. (?), 07-Июн-24, 18:21 
> Это еще с хрена ли? GPLщики совершенно не прочь подзаработать на своем коде не хуже всех
> остальных

а заодно и чужой перепродать, раз уж пошла такая карта.

Но тут не подкопаешься - даже осф признала эту лицензию вполне шва6одной, хотя в скобочках очень, очень негодовала - как так, патенты ей не отдали нахаляву.

Ответить | Правка | Наверх | Cообщить модератору

91. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (-), 08-Июн-24, 04:11 
> а заодно и чужой перепродать, раз уж пошла такая карта.

Ну если клиент совсем тупой и сам скачать не может - окей, не вижу криминала в налоге на тупость. По моему вполне честно оплачивать скачку сорца другими, если сам это не могешь, не? :)

> Но тут не подкопаешься - даже осф признала эту лицензию вполне шва6одной,
> хотя в скобочках очень, очень негодовала - как так, патенты ей
> не отдали нахаляву.

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

Если всякие вымогатели начинают вымогать бабки за факт использования формата на сервере или роялти за чипы - это почему-то много кому не нравится. Стандарты делают не для того чтобы ублажать наиболее охамевших из патентных троллей, а для interop вообще-то. При том если посмотреть кто в AOM вписался, ЭТИ могут всеьма популярно объяснить. В именно понятных капиталистам форматах. Как видишь в практически все новые железки AV1 напихали оптом, тогда как 265 есть - местами, скажем для веба он нафиг не. А что 266 светит - вообще большой вопрос. Тут вон какие-то чатгопты пытаются из кожи вон лезть доказывая что это круто. Пруфскринов запостить ессно стесняются. Видимо не умеет чатгпта такое пока.

Ответить | Правка | Наверх | Cообщить модератору

39. "Проект FFMpeg представил собственную реализацию декодировщик..."  –1 +/
Сообщение от cheburnator9000 (ok), 06-Июн-24, 19:53 
> А для декодирования/воспроизведения низкобитрейтных AAC ELD всё ещё нужно пользоваться
> сторонней библиотекой AAC FDK, что печально... Всё, что ниже 64 kbps,
> воспроизводится только так:
> $ ffplay -codec:a libfdk_aac audio-aac-eld.m4a

Открой для себя уже Opus.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

43. "Проект FFMpeg представил собственную реализацию декодировщик..."  +2 +/
Сообщение от Аноним (43), 06-Июн-24, 21:49 
А откуда эти ELD файлы берутся? В смысле какой софт создает?

AAC такой уж формат, что туда в свое время пропихнули практически все существующие на тот момент технологии, реально же даже проприетарные утилиты от создателей стандарта поддерживают только часть из этого, к примеру вы не найдете софта создающего AAC SSR или MPEG-4 TwinVQ.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

82. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (82), 07-Июн-24, 19:33 
Да по сути дела, любое Android приложение, если укажет такой профиль при записи аудио. Причём, аж с версии Android 4.1: https://developer.android.com/media/platform/supported-forma...

[сообщение отредактировано модератором]

Ответить | Правка | Наверх | Cообщить модератору

115. "Проект FFMpeg представил собственную реализацию декодировщик..."  +/
Сообщение от Аноним (115), 11-Июн-24, 09:10 
Это тот AAC который в андроиде при записи видео используется и у которого при тихом звуке одно бульканье? Нет уж такого не нужно...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру