> И для аудио книгПро них я знаю только что они существуют. Мне не понятен пойнт этого формата. Это не мой формат.
> Да, хочу проверить на каких битрейтах (для mp3 и opus) определение сжатого трека станет неуверенным.
Хорошая идея. Для себя я сделал прикидки, точность понятно какая.
> У опус вроде упор оптимизации был на низкие битрейты. Нужно сравнивать.
Он по своему уникален - позволяет относительно плавный переход из спич-кодека в обычный. Так вроде никто больше не умеет.
> Нет, у clip zip только ARM926EJS, так что декодирование полностью программное.
Тогда видимо роялит что система менее разлапистая.
> Так он и использует. Просто я не знаю надежной методики, как сравнивать
> качество на движущихся сценах.
Идеальных метрик как я понимаю нет. Вроде пытаются аппроксимировать учитывая temporal masking как эффект. Но есть ли какие-то готовые метрики на основе этого я не знаю.
> При обычном просмотре на моих битрейтах оба кодека ведут себя прилично.
А мне нравится иследовать границы возможностей технологий. Движение вперед - это часть инженерии.
> анимация будет демонстрироваться студентам в качестве примера, да и неподвижных/
> малоподвижных кадров там много.
По моим наблюдениям у vp9 нет особых проблем с такими вещами. Как раз мелкий текст и прочий лайнарт он вроде особо не портит, даже при достаточно агрессивных настройках битрейта. А вот как переубедить x264 не грохать текст в титрах - я так и не придумал особо. Ну то-есть конечно можно битрейт закручивать, но я не понимаю почему это должно требовать столько битов, да и почему я это должен как-то сильно отдельно вручную костылить, даже при 2-pass.
> Неправильно написал - crf 21-24, то есть постоянное качество.
Этот уже поинтереснее, насколько я понимаю - набор настроек которые я предпочитаю - чем-то похож на CRF по смыслу. С той разницей что я обычно считаю более целесообразным предоставить кодеку самому выбирать квантизатор в пределах бюждета и вместо этого оперировать желаемым битрейтом/размером файла.
> Не, для xvid нужен еще в двое больший битрейт.
Говоря за себя - я использую VP9 с достаточно агрессивными настройками битрейта (если я что-то пережимаю - то чтобы убавить размер). Но тут стоит сказать что я обычно упражняюсь на более-менее обычных видео, снятых с камерой или как максимум - у меня есть несколько нежатых мувиков и самым синтетическим из того что у меня есть наверноя является Big Buck Bunny и пара скринкастов.
> Не знаю. Но при crf=21 2d/3d анимация (там часто текст анимируется) стопкадры
> выглядят практически идеально.
А тут вопрос в том какой битрейт получается, насколько сильно меняется контент и проч. Грабля которую я заметил - если x264 указать некий желаемый битрейт (чтобы контролировать итоговый размер файла или требования к серверу) и в целом этот битрейт для этого фильмообразеого мувика ОК, убедить x264 прилично себя вести на титрах почти невозможно. Такое ощущение что он не может адаптироваться к резкой смене типа контента или motion compensation не срабатыает. Я не совсем понимаю почему у него титры и т.п. мелкий текст хреново выглядят даже на довольно большом (по сравнению с VP9) битрейте и даже на самых медленных пресетах. VP9 вроде никакого подъема битрейта не требуется и он сам на автомате с таким справляется. Что в принципе не удивительно - гуглу актуален режим "fire and forget".
> Там задача другая - сохранить максимум деталей. Я бы лично хотел еще
> больший битрейт, так как стоп кадр все равно уступает хорошему jpeg.
Для меня задача на видео с камеры обычно чуть иная - сдуть их в разы и сделать играемыми даже на не очень мощных компьютерах. Добрых 50Мбит H.264 - по зубам далеко не любой машине, а некоторые камеры почему-то норовят снять именно так, видимо компенсируя хреновый motion compensation суровым битрейтом. Что на тяжелом кодеке предъявляет очень высокие требования к CPU и занимает уйму места неизвестно ради чего.
> А далее редактирование и естественно сжатие с качеством зависящим от задачи.
Если редактрование подразумевается - тут да, минимальное сжатие по любому, а в идеале - lossless или прочая нарезка/склейка без рекомпрессии. Иначе будет артефакт на артефакте, жать много раз подряд плохая идея.
> It helps at most ~1% compared to the veryslow preset at the
> cost of a much higher encoding time.
...и в результате - x264 не может взять высоты VP9, хоть там что. Он продувает явно более чем на 1% по битрейт-качество. По крайней мере на низких-средних битрейтах оно так. А сильно высокие меня как-то и не интересуют обычно если я рекомпрессией занялся, 50 мбитов H.264 - и так навалом :)
> 5% compared to the slow preset, and slow helps about 5-10%
> compared to the medium preset.
Ну и вот в результате я вообще не могу из x264 получить битрейт/качество похожие на VP9. Наверное логично что я считаю VP9 более сильным кодеком в итоге.
> На placebo два часа видео (720p) будет жаться примерно двое суток, при
> выигрыше менее 10%. Электричество дороже обойдется, чем место на винте :)
Тут комплексная проблема.
1) Положить видео на сервак - сервировать 50 Мбит H.264 не прикольно.
2) В отличие от электричества, место жрется постоянно и на любом девайсе.
3) Покупки новых винчей подразумевают ощутимые единоразовые затраты.
4) На количество винчей есть технические лимиты, особенно у ноутов.
5) Тяжелое видео грузит проц, а распоследний core i7 для декодирования H.264 @ 50mpbs есть не у всех и не везде.
> Так им все равно, что 44.1, что 48 или 96 - им качество второстепенно.
А это кому как. В любом случае их оборудование оперирует 48 (96, 192,...) и отрасль перестроится под них. Как известно, кто платит - тот и заказывает музыку.
> В лучшем случае они будут слушать через средние затычки,
> а то и вовсе через динамик смарта/ноутбука.
Им ничего не мешает купить ну хотя-бы неплохие наушники. А у современных интеграшек параметры в общем-то достаточно приличные. По поводу чего дискретное аудио и позагибалось основательно.
> Как нет? ИМХО не один SoC без него не обходится (возможно называется иначе).
А это зависит от SoC и периферии. Как-то клоки конечно же формируют, но обычно берут круглый по частоте кварц и из него легко сделать все клоки делением счетчиками и умножением на PLL.
> Сейчас обычно ставят один кварц и от него тактируют все блоки.
Ну да. Благо большинство периферии от грампластинок-2.0 не унаследованы. Еще у UART скорости дурные, потому что унаследовано от релюшек и телетайпов. Но UART без проблем переживают ошибку до 2% и там это не важно.
> Для SoC - норма.
SoC - термин вольный, им называется что угодно. И вы подставляетесь, выдавая столь общие заявления. Если это норма для специализированных SoC плеров - ок, может быть. А для остальных это как повезет.
> Ну STM32 это все же uC и не предназначен для аудио,
Ну как, если DAC есть - подразумевается что им можно пользоваться. Внешний DAC приделать тоже можно, всякие I2S там есть, etc. Но вот формировать именно 44100 (или 22050, или что там у кого) - там все-таки изврат. А 48кГц или деривативы можно идеально точно сделать из многих типовых кварцев. Хоть тех же 12МГц, которые в STM идеально вписываются в работу с usb, и максимальные частоты проца - кратные им зачастую. Некоторые SoC/SBC которые я видел юзали 24МГц клок. Те же яйца, вид в профиль.
> to 1088 (48Mhz / 1088 = 44117)". Точность не ахти, но
> для такого случая более чем достаточно.
Кто понимает зачем ему эти извращения - пусть этим и занимается, имхо.
>> А хомякам все-равно сейчас 24/192/lossless подавай.
> Не забывайте, что есть и второй стандартный ряд - 44.1/88.2/176.4.
Ни разу не видел музыки в 88.2 или 176.4. А с инженерной точки зрения я предпочту развидеть левые битрейты характерные для каких-то цифровых патефонов и оперировать частотами которые легко синтезировать из типовых системных клоков/кварцев.
> Говорить они могут много. А вот реально мало кто использует 96 или 192.
Онлайн продаванам это все расскажете. И сдуваюищимся магазинам сидюков. Скоро они вообще останутся в том же количестве что и продавцы винила, имхо. Спору нет, кто-то и винил слушает.
> Ибо если человеку нужно хорошее аудио - он читает и через 5-10 минут узнает,
> что 96-192 ничего реально не дают. Если ему все равно - то он и не знает,
> что такое 24/192.
С практической точки зрения человек покупает то что есть, хорошо для него работает и удобно в использовании. И треки в 176.2 - я вообще ни разу в жизни не видел. Нет, технически то скроить то можно что угодно. Я даже какие-то 37 с чем-то кГц видал. ЧСХ под внимание попало за кривую редискретизацию.
> HD audio доступно уже лет 15. Пять лет ничего не изменят.
Тут фокус в том что сидюки померли как формат распостранения а продажи ушли в онлайн. Этого 15 лет назад не было, а так все хорошо, прекрасная маркиза.
> Люди не хотят качать альбомы в гигиабайт-два.
Не знаю, мувики с ютуба смотрят миллионами, а там гиг - вообще не траффик. Посмотреть пару мувиков на 720p по часу - больше сожрет.
> MP3/320 и flac/16/44.1 стали фактически стандартами.
Стандартами для кого? Для всяких иррациональных аудиофилов верящих в торсионщину и прочих варезников? Покупатели сидюков - внезапно не приносят основной доход студиям уже, а пираты - в лучшем случае их не замечают.
> Да и то flac качают только меломаны. Уверен, что и
> через 5 лет - MP3/320 существенно не сдаст позиций.
Среди "мыломанов" - возможно. Только они все вместе взятые - ничего не решают. Источниом дохода студий являются не они. И таки глядя на FullHD'ец я думаю что и тут у маркетологов все прокатит.
> Оглянитесь вокруг: все слушают mp3 и даже не знают что такое 24/192.
Оглянулся. Половина онлайн площадок беззазренно барыжит lossless'ом в упомянутом формате. И как угодно но этот эффект серьезно прогнет отрасль в ту сторону.
> Я знаю четырех людей, у которых основной источник - коллекция винила,
> в том числе и современного (у двух из них ламповые усилители).
Им нравится теплое ламповое шипение винила? Ах, ну да, это же милые сердцу некроманта теплые аналоговые искажения. А на предложения померять THD конструкции - некромант оскорбится? Вон кто-то продает "конденсаторы с прослушки". Не подошли, типа.
> Но не знаю никого, кто собирает 24/192.
Зато некоторые собирают вкладыши от жвачек. Наверное они от этого сразу поголовно становятся экспертами в полиграфии и специалистами по технологиям производства жевательной резинки.
> Я могу поверить, что opus приживется в online,
Да он уже прижился - его заимплементили кому не лень и он банально часть спеков webm.
> но не как не 24/192 с их битрейтами.
А упомянутый прижился у онлайн-продаванов выгодно загоняющих треки хомячкам. И вот эти продаваны сейчас как раз студиям и платят в основном, если что. И всем хорошо - хомяки получают кр00той трек парой клацев. Продаваны получают сотни профита. Студиям и артистам тоже что-то перепадает. А те кто барыжил сидюками и их форматы - они на излете жизни технологии.
> Нет это единый блок для всего SoC.
Это на самом деле каждый д... как он хочет. Ну то-есть обычно делают некий мастер-клок и из него так или иначе получают большинство остальных клоков. А как именно это будет сделано - да на это никаких единых типовых подходов нет. И я с наскока привел вполне широко распостраненных STM32 где 44100 - не доставляет. Поэтому пусть там это как-нибудь аудиофилы со своими радиолампами используют, имхо. А где они будут лет через 5 брать контент - уй, не знаю, не мои проблемы.
> Для uC - да. Для SoC PLL и CGU - неотъемлемая часть.
Опять же - термин SoC очень generic и может включать в себя очень разные вещи. И вот так огульно расписываться за всех - дохлый номер.
> Типа моих emu-1212m и emu-0204.
А, понятно. Правда не совсем понимаю при чем они тут, все-таки нишевые железки.
> выгодно. Ставят один кварц и CGU. Он тактирует железо как угодно.
Совершенно не обязательно. Могут ориентироваться на один номинал кварца и под него все подогнать. Большинство скоростных и-фейсов используют круглые частоты, да и i2c/spi всякие обычно тоже. UART - терпит до 2% ошибку и ее там никому не слышно. Никаких стандартов и регламентов как генерить клоки - нет. И как видите я навскидку нашел целый популярный выводок МК где с 44100 - "не очень".
> Да и удобно это - так как можно легко отключать/включать блоки
> и произвольно менять частоты для оптимальной производительности/энергопотребления.
Включение и выключение блоков делается, пардон, силовыми полевиками встроенными в цепь питания блока. Кто и откуда ими командует - совершенно отдельный вопрос. Это делается в меру дурости разработчиков SoC. Гейтование клоков - аналогично. Это может быть и отдельный юнит, и куча регистров в разных местах и что там кому удобнее.
> Если в плеер с конечной ценой 15-30$ ставят SoC с GCU, то в смарте без него никак.
В плеере SoC посвящен своей задаче целиком и полностью. А для смарта проигрывание аудио - это одна из туевой кучи функций. И кстати парочка из allwinner + чип power manager ему внагрузку может стоить менее $5, все остальное там вообще копейки при массовых тиражах. А в смартах - в смартах некоторые компании делают сверхприбыли. Даже в самом крутом ифоне железа реально спасибо если баксов на 150, при том дороже всего IIRC стоит высококачественный LCD. Все что сверх этой цифры - чистейшая маржа той или иной цепочки продаванов.
> Ok, 99.9% пользователей.
Ок, как эти проценты посчитаны? :)
> и можно свободно использовать его с арифметическим кодированием, но все из-за
> совместимости продолжают использовать обычный jpeg.
В конечном итоге с арифметическим кодированием жлобы таки довы...сь до того до чего и должны были. Слыхали что-нибудь про ANS? Ну и далее - сделанный на основе этого FSE (Finite State Entropy). Из интересного - хорошие реализации FSE ухитряются сочетать скорость работы а-ля huffman с точностью (и стало быть степенью сжатия) характерной для арифметического кодирования. Придумал это некий Jarek Duda, опубликовавший весьма нетривиальный в чтении paper. Он же помогал Yann Colett'у запилить это в практическую скоростную реализацию.
И сейчас как минимум:
1) Zstd (и apple FSE, но кому оно надо если Zstd его рвет) - это FSE+HUF+LZ.
2) В VP10 (и AV1) entropy coding - IIRC тоже на чем-то типа FSE основан. Хотя в AV1 все сложнее т.к. там части из Daala включили и в Daala был какой-то свой EC, но как я понял мастер-план подразумевает все-таки кодинг энтропии на основе изобретения Jarek-а. Т.е. в принципе декодирование может оказаться довольно быстрым. Приветы ресурсожоркому CABAC'у.
Поэтому саботаж как ни странно внезапно привел к инженерному прорыву, когда спецы придумали алгоритм который и лучше по сочетанию параметров и патенты не нарушает. И я так считаю что будущее будет вокруг технологий Jarek'а. А арифметики - да кому они теперь нужны? Хоть с патентами, хоть без.
В общем всем этим экспертам из ISO имхо придется учиться заниматься разведением рассады. Наконец то впихивание патентованых технологий оптом в свои стандарты им отольется.
> Бывает и так.
При том довольно часто. Сильно специализированные блоки вообще вещицы на любителей. Компьютеры всем нравятся за то что они generic и перепрограммируемые.
>> уши улетают какие-то доли ватта,
> Очень не много, в первом приближении их можно вообще не учитывать.
Это имхо довольно много по сравнению с тем что светит снять с обычных по восприятию пользователями кнопок мелкого гаджета когда он валяется в кармане.
> Возможно, это будет и лучше. Или комбинация источников. Но в любом случае
> нужно работать над потреблением устройства.
Мне в STM'ках попроще с потреблением, но вот если датчик никто не освещает, не трясет и даже нет источника вибрации или нагрева - сделать его вечным уже заметно сложнее. А хотелось бы :)
> Да. Учитывая сколько может работать обычная звонилка, эффективность смарта и в режиме
> ожидания/разговора также не велика.
Если активна сотовая сеть - смарт периодически должен перерегиваться в сети. В GSM этот период обычно выставляют порядка 2 часов, но вообще это параметр который сеть диктует. А стрелять передатчиком в эфир - это энергоемко (в GSM - до 2W в импульсе, что обеспечивает короткие и злые импульсы токов под пару ампер по всему питанию).
> Ну тогда - да ;) Но даже на нем есть разница в 5-10%.
У меня так вообще почему-то vorbis чуть экономичнее но в целом - что так 50-55 ма, что эдак. Разница в пределах 10%, что с учетом импульсных процессов где-то в пределах погрешностей.
Версия для распечатки
