Comments 14
Честно говоря, я поражен возможностями seriously.js. Мало того, что он работает в realtime, так в нем еще и куча фильтров уже реализована.
Но вообще, как только появились те же Broadway (h264 decoder) и route9.js (vp8 decoder), стало понятно, что на js можно реализовывать очень сложные вещи. Только, с такой эффективностью, это скорее не нужно, чем нужно.
Давайте подумаем, какие фильтры реально бы пригодились для сферического видеосервиса в вакууме (того же youtube). Мне на ум приходит только deblocking, debanding и, возможно, deblurring. И если на десктопе можно смириться со значительно возрастающей загрузкой процессора, то на мобильных устройствах (а эти фильтры было бы эффективнее всего применять именно на мобильных устройствах из-за низкого битрейта мобильного видео) это непозволительно.
Хотя я ничего не имею против тех же Audiocogs (jsmad, flac.js, aac.js, alac.js).
Но вообще, как только появились те же Broadway (h264 decoder) и route9.js (vp8 decoder), стало понятно, что на js можно реализовывать очень сложные вещи. Только, с такой эффективностью, это скорее не нужно, чем нужно.
Давайте подумаем, какие фильтры реально бы пригодились для сферического видеосервиса в вакууме (того же youtube). Мне на ум приходит только deblocking, debanding и, возможно, deblurring. И если на десктопе можно смириться со значительно возрастающей загрузкой процессора, то на мобильных устройствах (а эти фильтры было бы эффективнее всего применять именно на мобильных устройствах из-за низкого битрейта мобильного видео) это непозволительно.
Хотя я ничего не имею против тех же Audiocogs (jsmad, flac.js, aac.js, alac.js).
Из очевидных: деблок, дебанд, повышение резкости, блюр, добавление шума, качественный ресайз. Из редко, но иногда полезных: деинтерлейс, корректировка уровня (TV->PC и наборот), шумодав (опционально — временнОй) и сглаживание движения (madVR-овский smooth motion).
Скорее всего, для реализации потребуется еще RGB<->YUV конвертирование, ибо писать подобные фильтры прямо в RGB может быть неприятно.
Большинство из этих фильтров по сложности в разы превосходит всё то, что сейчас предоставляет seriously.js.
Скорее всего, для реализации потребуется еще RGB<->YUV конвертирование, ибо писать подобные фильтры прямо в RGB может быть неприятно.
Большинство из этих фильтров по сложности в разы превосходит всё то, что сейчас предоставляет seriously.js.
Если в реализации на чистом JS основная проблема — это количество итераций цикла при большом разрешении, то попробуйте использовать алгоритм под названием «Метод Даффа».
А вообще стоит ли оно того? Я бы не хотел чтобы у меня при просмотре видео, процессор сильно грузился, пытаясь эффекты применять в realtime. Возможно для простенького веб-редактора видео, это выглядит интересно, а иначе не вижу смысла.
Это противоречит идеи ухода в облако и неоправдано нагружает клиент, не говоря уже о мобильных устройствах.
Или я неправильно понимаю области применения?
Это противоречит идеи ухода в облако и неоправдано нагружает клиент, не говоря уже о мобильных устройствах.
Или я неправильно понимаю области применения?
Основная идея подобной постобработки — устранение дефектов видео, которые мешают просмотру. Если асбтрактному пользователю ничего не мешает — он может ничего не включать. Главная ЦА — большие десктопные мониторы, на мелких экранах мобильных устройств качество стрима такой большой роли не играет.
В любом случае, при адекватной реализации (не в JS), нагрузка на процессор минимальна и сравнима с декодированием.
В любом случае, при адекватной реализации (не в JS), нагрузка на процессор минимальна и сравнима с декодированием.
Внезапная идея: то же самое, но в отношении обычных картинок. То есть ходит человек во всяким контактикам/фейсбукам, а там адские фоточки с красными глазами, заваленым горизонтом и синюшно-красными мордами.
А вслед за ними плагинчик бегает и исправляет — человек ходит, а там всюду ББ хороший, горизонт ровный, красных глаз не видно.
А вслед за ними плагинчик бегает и исправляет — человек ходит, а там всюду ББ хороший, горизонт ровный, красных глаз не видно.
А что на счёт оптимизации с помощью WebWorkers? Создали N потоков и обрабатываете только чётные номеру воркера куски в каждом потоке.
Хотя, конечно, JS не на столько быстр, что бы обрабатывать сложными фильтрами видео в риал-тайм.
В теории так же можно сделать буфер на определённое количество (мили?)секунд и потом уже погнать видео как-будто-бы в реалтайме.
PS ну и сравнивать работу кодеков с трансформацией сырого массива пикселей — странно, не находите? Сырой массив пикселей(когда видео размером в 20 гиг сжимается до 2) даже на десктопных программах вроде VirtualDub кодируется далеко не в риал-тайме.
PSS ну и некоторые «фильтры» можно делать тупо с помощью изображения/цвета альфо-каналом поверх.
Хотя, конечно, JS не на столько быстр, что бы обрабатывать сложными фильтрами видео в риал-тайм.
В теории так же можно сделать буфер на определённое количество (мили?)секунд и потом уже погнать видео как-будто-бы в реалтайме.
PS ну и сравнивать работу кодеков с трансформацией сырого массива пикселей — странно, не находите? Сырой массив пикселей(когда видео размером в 20 гиг сжимается до 2) даже на десктопных программах вроде VirtualDub кодируется далеко не в риал-тайме.
PSS ну и некоторые «фильтры» можно делать тупо с помощью изображения/цвета альфо-каналом поверх.
Многопоточность может помочь когда будет какой-нибудь asm.js. Пока даже в условиях идеальной параллельности, 8 потоков фактически сократят время блюра в 8 раз, или 400/8 — 50мс в хроме, что всё равно слишком медленно.
Буфер тоже не поможет. Он подразумевает, что вы потом сможете заполнять этот буфер достаточно быстро уже во время воспроизведения, либо буфер будет достаточно большим, чтобы компенсировать лаг. В случае с JS, придется загрузить большую часть видео, что может не очень понавится пользователю.
Ну и я не понял, при чем тут работа кодеков. В десктопных программах типа VirtualDub фильтр blur, приведенный в статье, легко может выполняться на ~800фпс на 1080p (чуть больше 1мс на кадр), что более чем достаточно для работы в реальном времене. Собственно, наличие фильтров в ffdshow подтверждает работоспособность идеи, при этом ffdshow уже много много лет.
Буфер тоже не поможет. Он подразумевает, что вы потом сможете заполнять этот буфер достаточно быстро уже во время воспроизведения, либо буфер будет достаточно большим, чтобы компенсировать лаг. В случае с JS, придется загрузить большую часть видео, что может не очень понавится пользователю.
Ну и я не понял, при чем тут работа кодеков. В десктопных программах типа VirtualDub фильтр blur, приведенный в статье, легко может выполняться на ~800фпс на 1080p (чуть больше 1мс на кадр), что более чем достаточно для работы в реальном времене. Собственно, наличие фильтров в ffdshow подтверждает работоспособность идеи, при этом ffdshow уже много много лет.
Sign up to leave a comment.
Оценка возможности постобработки видео в браузере