И нет смысла загонять в васм такой поток.

Я делал как то банальный таймер, который отсылал картинку в васм с канвы не как это делает по дефолту requestanimationframe , зависящий от fps экрана, а только с частотой примерно   10fps. Когда не нужно отрисовывать поверх канвы в реалтайме что, мне кажется так меньше какие нибудь буфера забиваются. Но на компе не особо заметил разницу.

Нет, как это?
Это если ты на GPU решил посчитать

Нет, там не делают чаще чем доступен кадр.
Нету смысла, так как будет дублирование.

это я понимаю, но доступен он 60 раз в секунду где-то, я снижал эту частоту.

фрейм камеры через превью не доступен обычно 60 кадров, 30, 25
Но все это тюнится на уровне MediaStream

верно, но ведь канва все равно отрисовывается 60 кадров? Все равно множит кадры cо стрима и если повесить обработчик на requestAnimationFrame()  то его вызов будет происходить с частотой вызова requestAnimationFrame() а не фрейма камеры

нет, не верно

она рисуется ток если рисовать

да, но она рисуется же через requestAnimationFrame() 60fps, это я имею ввиду, когда мы вебкамеру отображаемна сайте через канвас, не важно что источник выдает 15 fps

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

а как узнать факт получения кадра?

Есть какое то событие у стрима? Я вижу что просто цепляют стрим и  через requestAnimationFrame()  фигачать отрисовывать в канву

Ну это просто сильно браузерозависимо

обычно смотрят что время обновилось

Даже если так, рисовать != читать

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

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

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

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

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

есть линки на такое браузерное API? По нативному распознаванию куркодов?