> Разумеется это специально подбранные примеры. ORBX - так вообще целенаправленно под Asm.js
> написан, насколько я понимаю.

С ASM.js несколько мутно, согласен. По крайней мере я пока не нашёл на чём именно оно в оригинале написано. Ну не писали же они на этом ассемблере вручную?

> Вот когда оно хотя бы с 40-роцентной
> производительностью будет произвольный код преобразовывать или когда будут четкие правила,
> проверяемые хотя бы человеком как надо писать код, чтобы asm.js это
> жрал - тогда другой будет вопрос.

Уже обсуждалось. Пишешь на C/C++, компилируешь через clang+emscripten в байткод и оно работает с ~50% производительности от clang. Причём это лишь первая реализация и у них намечена пачка доработок к нему. Подробности тут: http://asmjs.org/faq.html

>  Хот как по мне -
> лучше бы они сделали несколько более полноценный байткод, который, в частности,
> умел бы предсказуемо работать с памятью.

Разве он не предсказуем? Он ведь компилируется ahead-of-time и работает со статическими типами переменных.

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

Ну вот, например, из стана яблочников нарыл первое попавшееся: http://support.apple.com/kb/ht3937
Так что специально подготовленным видео-файлом вполне можно уронить декодер и заставить систему выполнить произвольный код. Вообще было бы странно, если б этого было нельзя сделать. Вот только когда ты роняешь JS-декодер, то остаёшься ограничен возможностями JS (и я вообще не уверен, что даже к ним ты доступ получишь). Собственно тут сам смысл ронять декодер теряется так-как предполагается, что видео будет идти в комплекте с JS-библиотекой его декодирования и если можешь подсунуть JS-код, то лучше уже пробовать уронить сам JS-компилятор в браузере.
Тогда как если ты роняешь системный декодер, то в лучшем случае оказываешься в песочнице, а то и вовсе прямой доступ к системе получаешь (смотря как будет устроен плагин видео-плеера).

> 3) наличие h.264  в браузере менее вероятно, чем наличие h.264 в
> системе - тот же файрфокс его тащить, например, не может. Хотя
> при чем здесь h.264?

Вероятно меня запутало то, что его сравнили с h.264. Но если это не реализация h.264, а что-то иное, то в системе его точно не будет. Причём желающие поизвращаться с DRM могут взять ORBX и изменить под себя так, что их видео не будут вообще ни с чем совместимо, кроме как с их собственной версией.

> 4) А что мешает тащить этот плагин вместе с браузером? Роль у
> него-то маленькая, определить,что установлено да команды проксировать.

То, что каждый может видоизменять его под свои нужды?

> 5) А так можно оставить DRM на откуп собственно плееру и вообще
> его не реализовывать - сказать "не наше дело".

Хочешь ставить себе в систему неведомый бинарный код, чтоб видео работало? А если его под твою систему ещё и не делали?