Как стать автором
Обновить

Комментарии 19

Проще всё же стирать весь холст, а потом рисовать все цветные столбики, чем бегать и отдельно рисовать разделители и закрашивать старые столбики.


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


Ну а ещё проще было бы не заморачиваться с холстом. Достаточно нарисовать свг в духе: <svg><path class="past" v="..."/> <path class="future" v="..."/></svg> и просто обновлять координаты линий. Стилизацией же можно весьма гибко управлять через CSS. По скорости работы это ничуть не хуже: http://mol.js.org/app/bench/#bench=geometry/sample=canvas-lines~canvas-path~svg-lines~svg-path/sort=render

Хм… так как размер полотна меняется в зависимости от ширины экрана, то его и нет смысла стирать, просто отрисовать по размеру заново по новым данным. Одноразовая операция, кроме момента, когда смартфону меняешь ориентацию.

При старте страницы рисуется две PNG. Это два дива друг над другом, верхний всего лишь в процентах меняет свою ширину и тем самым создает анимацию прогресса.

toDataURL я больше люблю т.к DOM и разметка не модифицируется и не нужно держать в памяти при просмотре html что тут js кое куда что-то подкладывает при старте.

с SVG не хотел связываться, потому что большое количество мелких деталей всегда было задачей для растра. А вот с обновлением координат не выйдет, в зависимости от ширины экрана массив меняется полностью как по количеству данных так и по их значениям — этож тогда нужно в сущносности выделять каждый столбик, что совершенно не оправдано.
Если он неразывен да. Но по вашему бенчу если на 2000 точек потыкать раз 10 в режиме отдельных линий все равно быстрее рисуются на полотне. Плюс там еще градиентик нужно наносить, не знаю как с этим у путей у SVG. Потесировать будет интересно. Спасибо.
Перевод waveform в вектор

Очень странно генерировать сначала картинку, потом конвертировать ее в данные, когда существует масса библиотек которые вам отдадут массив данных по отданому им mp3 файлу. Как на стороне клиента, так и не стороне сервера.
В той же нативной либе GD, которую мы использовали для генерации JSON

Вы можете попасть в неприятную ситуацию, когда GD откажется обрабатывать ваш файл. А если быть точнее, то просто процесс будет убит с out of memory в силу того, что GD для обработки изображения в обязательном порядке загружает все изображение в память, а это изображение, совсем не обязательно у вас всегда будет полтора килобайта. Потому что тот же ffmpeg так же пишут люди которые допускают ошибки(не говоря уже об авторах графических библиотек), и результирующая картинка даже на микрофайле может оказаться в пару гигабайт.
Очень странно генерировать сначала картинку, потом конвертировать ее в данные, когда существует масса библиотек которые


Все очень логично. Я конвертирую в два формата аудио файлы для веба — mp3 128 и opus, а оригинал — в архив. Библиотеки, которые умеют читать АЧХ без распаковки mp3? Мне такие почти не попадались. На сколько они точны, а главное, быстрее ffmpeg? А где гарантии, что завтра на вход FLAC не кинут? У меня нет никаких гарантий на входной аудиопоток. На стороне клиента, вариант не рассматривался вообще. Это не рабочий варинат.

Вы можете попасть в неприятную ситуацию, когда GD откажется обрабатывать ваш файл. А если быть точнее, то просто процесс будет убит с out of memory

Ну это же совсем несерьезно. Если вы говорите о high-load, конечно же, результат расчета на лету можно кешировать. И пусть загружает в память, она для этого и нужна. Но это общая ситуация с out of memory для любого узла в системе.

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

Конечно же обязательно. Выходной формат на диск это png c палитрой в 8 бит. Там ничего не предсказуемого особо быть то и не может. Даже если учесть,1000x60px 2.5кб в распаковке это 60 кб (ого, что действительно не мало!) то при сервере с 128бм свободной оперативки это 2000 человек в секунду. О такой посещаемости мечты не стояли. А из-за ошибок может полететь все что угодно. Добавить механизм кеширования совсем не сложно. Но я выбрал более универсальное решение.
Ну это же совсем несерьезно. Если вы говорите о high-load, конечно же, результат расчета на лету можно кешировать. И пусть загружает в память, она для этого и нужна. Но это общая ситуация с out of memory для любого узла в системе.

Я говорю о том, что использовать библиотеку GD можно только в небольших подделках, из за особенностей его архитектуры. А именно обязательной загрузки всего изображения в память. Более серезные инструменты обрабатывают изображения иначе.

Конечно же обязательно.

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

Разве это не тот самый случай для GD работать на мелочевке? По хорошему, конечно, надо просто хранить json а не картинку. Но в моём случае мне нужны были бОльшие гарантии, который я получаю с картинки.


Что касается ffmpeg, расчёт идёт на сервере с админкой. Поэтому теоретическое падение не страшно.

Для генерации пиков (сразу в JSON) есть отличное решение, впрочем как и для отрисовки waveform.prototyping.bbc.co.uk Генерация пиков там в несколько десятков раз будет быстрее, чем ffmpeg + php + gd2
Вы не очень глубоко, видимо, варились в этой теме. По вашей ссылке диаграмма, где вместо ffmpeg и php, некий код на c++ и руби. Вы никуда от распаковки mp3 в wave для построения ачх от С или С++ не убежите.
Во-первых
C++ program that generates waveform data files from MP3, WAV, or FLAC format audio.

Так что она отлично распаковывает самые популярные форматы, в том числе mp3.

В-вторых, ffmpeg и php — это разве надежнее чем c++? На практике эта программа генерит из mp3 готовый json быстрее, чем запускается ffmpeg на чтение файла.

Чтение из файла в спектрограмму сейчас можно даже средствами браузера Web Audio Api), а вы предлагаете через GD2 картинку парсить, что супер неэффективно для такой задачи.

Вообще есть еще пару решений готовых (например, wavesurfer-js.org), перед изобретением велосипеда вам стоило повариться больше в гугле с этой темой.
Так что она отлично распаковывает самые популярные форматы, в том числе mp3

Почему бы и нет? Как и ffmpeg использует библиотеки. Но не кодирует т.к у неё более узкая задача. А кодировать мне нужно. Поэтому взял более общее решение.
ffmpeg и php — это разве надежнее чем c++?

Вы наверное про мою связку ffmpeg PNG php json? И их waveform png ruby gem json? Что надежнее не знаю. Но логика совершенно такая же. Мне это даже льстит. Ffmpeg как и gd очень обточенные вещи с сотнями тысяч пользователей. Сомневаюсь что их решение шустрее ffmpeg т.к они брали все из исходников audacity. А как он работает на построение waveform я знаю т.к работал с этим софтом

Web audio api это совсем не то. Работает только при проигрывании и все что там на клиенте считается это фигня. Каталог аудио не вывести.

Wavesurfer сильно избыточен. Не подходит по дизайну. Как и peak.js от BBC он про другое. Мой велосипед отличный.
Вы наверное про мою связку ffmpeg PNG php json? И их waveform png ruby gem json?

Вы ffmpeg-ом делаете картинку, потом парсите ее через PHP+GD и на входе получаете json. Конечно это крайне неэффективно!

В audiowaveform вы запускаете команду
audiowaveform -i test.mp3 -o test.dat -z 256 -b 8

и на выходе получаете готовый json без лишних движений

Работает она быстрее даже, чем ffmpeg делает картинку, потому что по сути там тот же алгоритм, но ffmpeg еще тратит время на создание картинки. Я уже не говорю о том, что потом эту картинку надо парсить сомнительными инструментами вроде PHP+GD.

У нас на боевом сервере waveform генерируются налету (необходимость) на большом проекте. Несколько вещей пробовали, остановились на этой. Просто рекомендую ее.

Уверен, если бы вначале вы внимательнее погуглили на эту тему, вам бы не пришлось изобретать велосипед.
Я видел эту утилиту несколько лет назад, но если мне не изменяет память, json туда добавили не сразу. Статья на самом деле не новая. Сейчас я бы конечно взял бы эту утилиту. Я согласен, что решение не самое эффективное. Но совсем не согласен, что крайне. Отрабатывает оно так же, как если бы сервер просто отдавал файл. Какой бы там не был говнокод в libgd, на 60кб (распакованный 2кб png) данных все отрабатывается в считанные микросекунды. К тому же, нет никакой разницы, если кешировать Json. Я бы ещё подумал, нужен ли мне такой камтомный формат от BBC. Нафига там числа отрицательные...? Мне не нужно рисовать ниже оси, а если надо — я сам минус поставлю. Хотя можно же пересобрать самому, чего это я.
Да, мы тоже отрицательные убирали, нам это не нужно было ;) Кажется просто верх и низ не симметричны, на стерео файлах.
Они слишком много стащили из Audacity походу, а в редакторе волна должна показывать ассиметричность сигнала. А в любых других местах оно вообще не нужно. Большинству и в редакторе не нужно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории