Бренден Айк (Brendan Eich), создатель языка JavaScript, занимающий пост технического директора Mozilla Corporation, представил (https://brendaneich.com/2013/05/today-i-saw-the-future/) проект ORBX.js, в рамках которого совместно с компанией OTOY подготовлена высокопроизводительная реализация видеокодека, реализованного целиком на JavaScript и WebGL. По мнению Брендена новый проект подчёркивает возведение JavaScript на новый уровень развития и знаменует стирание границ между Web и нативными приложениями. ORBX.js может работать в любых современных браузерах, в том числе для мобильных платформ, не требуя никаких дополнительных компонентов, кроме поддержки существующих web-стандартов.
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/eOY2U_i2fuc?rel=0" frameborder="0" allowfullscreen></iframe></center>Среди основных областей применения ORBX.js, кроме отображения потокового видео, называется создание работающих в окне браузера средств удалённого доступа к рабочему столу, играм и виртуальным окружениям. В частности, продемонстрированы средства для запуска в облачных окружениях ресурсоёмких 3D-пакетов и игр с трансляцией вывода в окно браузера, запущенного на маломощном нетбуке или планшете.
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/YUsCnWBK8gc?rel=0" frameborder="0" allowfullscreen></iframe></center>
Кроме того, так как ORBX.js не требует наличия отдельных браузерных плагинов и не зависит от наличия кодеков в браузере, он может использоваться в качестве альтернативного пути предоставления средств защиты контента, не требующих продвижения DRM-механизмов в web-стандарты. Вместо DRM предлагается добавлять в кадры уникальные для каждого сеанса водяные знаки. Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.С позиции эффективности, активное использование GPU в процессе работы, позволяет ORBX.js на обычной системе декодировать видеопотоки c разрешением 1080x600 и 60 кадров в секунду. Используемые в ORBX.js методы кодирования позволяют достигнуть на 25% более высокого уровня сжатия, по сравнению с H.264, при близком уровне качества. Среди достоинств нового кодека отмечается поддержка адаптивного изменения битрейта в зависимости от параметров полосы пропускания, более эффективные методы кодирвоания промежуточных кадров, изначальная ориентация на параллельную обработку данных, лучшая глубина цвета.
Для браузеров без поддержки WebGL, таких как Internet Explorer и Safari для iOS, предусмотрен режим упрощённого кодирования, при котором в потоке передаются только ключевые кадры, которые могут быть достаточно быстро и эффективно декодированы без привлечения GPU. Для браузеров с поддержкой WebGL, таких как Firefox, Opera и Chrome, герерируется более изощрённый поток, в котором присутствуют P-кадры, содержащие только информацию об изменениях, что позволяет сократить размер потока в два раза без изменения качества картинки. Декодирование подобных кадров выполняется с привлечением выполняемых на стороне GPU шейдеров.URL: https://brendaneich.com/2013/05/today-i-saw-the-future/
Новость: http://www.opennet.me/opennews/art.shtml?num=36879
Просто оставлю здесь ссылкуPeerCDN is a peer-to-peer distributed CDN
- https://peercdn.com/
- http://www.youtube.com/watch?v=PnBIIdmKO9o&hd=1
А где демо?
Очевидно еще не стабильный, закрытая бета (защита от повседневного использования хрупкого кода в продакшене)
http://www.unrealengine.com/html5/
Подвешивает окно браузера как в старые добрые времена Windows XP
на 23 фоксе пускал? если нет, то тебя предупредили.
осталось допилить в браузерах поддержку реалтаймового захвата видео и аудио.
Уже есть. WebRTC
> Уже есть. WebRTCстандарты - да, есть (но многие еще допиливаются), в браузерах еще не везде есть (в FF наверно допилят к 22..23 версии)
>> Уже есть. WebRTC
> стандарты - да, есть (но многие еще допиливаются), в браузерах еще не
> везде есть (в FF наверно допилят к 22..23 версии)в фф 20 уже есть в статусе релиза. ну и сегодня они дополнительно предложили код для встраивания на любой сайт...
>>> Уже есть. WebRTC
>> стандарты - да, есть (но многие еще допиливаются), в браузерах еще не
>> везде есть (в FF наверно допилят к 22..23 версии)
> в фф 20 уже есть в статусе релиза. ну и сегодня они
> дополнительно предложили код для встраивания на любой сайт...В 20-м как раз очень глючно работает с видеопотоком - для полноценной работы желательна 21-я бета
«Допилить» - это значит допилить ;-)
Крэщащиеся браузеры, внезапное отваливаение функции до перезагрузки браузера, игнорирование некоторых типов камер - пока скорее правило, чем исключение.
>>Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.Как дети, чес-слово. Что мне помешает скачать видео 2-3-42 раза под разными пользователями и выбросить водяные знаки на основе стат. анализа?
>>>Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.
> Как дети, чес-слово. Что мне помешает скачать видео 2-3-42 раза под разными
> пользователями и выбросить водяные знаки на основе стат. анализа?Это усложняет задачу и для большинства пользователей теряется смысл шарить этот контент.
Автоматизировать этот процесс, первое что приходит в голову.
придётся покупать его 2-3-42 раза, не?
Социальные сети на что? :)
> Социальные сети на что? :)Чуть выше тут как раз за краудфандинг ратовали ))
Заголовок статьи прикольный: Сегодня я увидел будущее.Я его ещё позавчера увидел, FF сожрал два гига и встал колом -))
JavaScript и производительность — два понятия которые у меня не стыкуются в голове…
Не повезло тебе с головой)
Заблуждение. Asm.js позволяет писать код близкий по скорости выполнения к "pure C". Плюс неблокирующий I/O и асинхронность. JS очень интересный и гибкий язык, если на нем не быдлокодить, а писать хороший код.
Не совсем так. Ты пишешь код на каком-либо языке программирования (лучше всего Си или плюсы) и потом этот код компилируется в asm.js-«байткод», который уже и выполняется в браузере. Писать такой «байткод» вручную практически равносильно написанию вручную программы на ассемблере, а это просто гигантский простор для быдлокода. Писать хороший код под asm.js сложнее, чем писать хороший код на Си и лучше этого не делать — для этого есть emscripten.
Если Asm.js жесток в синтаксисе, то LLJS выглядит как современный С-подобный язык, на которым можно сразу писать ручками быстрый код.
Не писать, а генерировать из исходников на приличных языках. И, если повезет, его оптимизируют. В этом случае его можно рассматривать не как JS, а как транспортный слой для байткода, полученного компиляцией сей или плюсов. И остаётся под большим вопросом, что и как будет эффективно работать в такой форме. А то подобрать отдельный примеры, хорошо подающиеся заданному набору оптимизаций - дело нехитрое.Ну и остаётся сакраментальный вопрос - зачем оно надо? В чём проблема скормить поток системному видеоплееру, который хоть на линуксах, хоть на винде умеет встраиваться в другие приложения, и заведомо более прилично отработает?
> А то подобрать отдельные примерыUnreal Engine и ORBX это подобранные отдельные примеры хорошей скорости работы asm.js-байткода или таки просто примеры его хорошей работы? Мне почему-то кажется, что второе. По крайней мере ни чего общего с затачиванием под конкретный код не наблюдается.
> В чём проблема скормить поток системному видеоплееру,
1. Это мене безопасно.
2. К нативному плееру не прикрутишь своей «клёвой» морды + неприятные проблемы фокуса и горячих клавиш при управлении табами в браузере.
3. Не у всех h264 в системе есть (да, в винде он уже несколько лет как «из коробки», но в линукс-дистрибутивах его обычно нет).
4. Не у всех установлен/активен плагин видео-плеера и далеко не все его хотят устанавливать/активировать.
5. Можно реализовать DRM не трогая сам браузер и систему (даже нам это может помочь избежать принятия в стандарты куда большей дряни — пусть лучше уже на JS свой DRM делают).И наверняка есть и другие причины.
Разумеется это специально подбранные примеры. ORBX - так вообще целенаправленно под Asm.js написан, насколько я понимаю. Вот когда оно хотя бы с 40-роцентной производительностью будет произвольный код преобразовывать или когда будут четкие правила, проверяемые хотя бы человеком как надо писать код, чтобы asm.js это жрал - тогда другой будет вопрос. Хот как по мне - лучше бы они сделали несколько более полноценный байткод, который, в частности, умел бы предсказуемо работать с памятью.Теперь по видеоплееру:
1) это не более и не менее безопасно, чем браузер. Точно так же есть баги, их фиксят, и так далее. На винде проблем чуть больше, на линуксе - чуть меньше, но в общем ничего особо ужасного нет. даже для флеша, который дыряв по самое не могу, проблем именно с видеопотоком я не припомню.
2) клёвая морда, разумеется, прикручивается. В винде управление будет идти через COM, в линуксе - через D-Bus. Всё, что надо - чтобы плагин предоставлял стандартизированное JS-API.
3) наличие h.264 в браузере менее вероятно, чем наличие h.264 в системе - тот же файрфокс его тащить, например, не может. Хотя при чем здесь h.264?
4) А что мешает тащить этот плагин вместе с браузером? Роль у него-то маленькая, определить,что установлено да команды проксировать.
5) А так можно оставить DRM на откуп собственно плееру и вообще его не реализовывать - сказать "не наше дело".А причина одна - браузероделы - не важно, хром они делают или мозиллу - очень стараются перетащить весь софт под себя, сделать вещь в себе, не взаимодействующую с остальным десктопом. Фактически - отобрать пользователя контроль над его системой.
> Разумеется это специально подбранные примеры. 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 на откуп собственно плееру и вообще
> его не реализовывать - сказать "не наше дело".Хочешь ставить себе в систему неведомый бинарный код, чтоб видео работало? А если его под твою систему ещё и не делали?
У asm.js, насколько я понимаю, большие проблемы с управлением памятью. При этом во всех "больших" играх далеко не зря оно по сей день ручное. А статичекая компиляция никак не мешает программе нагенерировать миллион объектов, а рантайму - вовремя их не собрать.А что до "ронять" - с подходом asm.js, думаю, будет куда больше риска, чем, скажем, с дубовым NaCl. Ну и да, песочницы нынче вполне хороши - и в отличие от всего браузера видеоплеер в песочницу засунуть вполне реально, к примеру, доступ к FS на запись ему, в общем-то, не нужен.
Что до стандарта сжатия - меня вообще срайне смущает идея, что поток будет идти невесть в чем. С плеером есть понятная распространенная реализация декодера, заведомо есть всякие фильтры, возможности отдать на аппаратное декодирование и тому подобное. А когда каждый сайт может безнаказанно гнать ни с чем не совместимый поток - как-то это дурно пахнет.
Насчет изменения плагина под свои нужды - не понял. Там, по идее, должен определяться простейший API, в котором указывается, куда плеер должен встроиться и в каких размерах, откуда брать источник ну и управление, сколько там его есть. Плагин это транислирует в команды того плеера, который найден в системе. На винде это вообще один вариант (WMP есть всегда и встраиваться умеет отлично), на линуксе будет пара вариантов, идущих из коробки. Плюс любители экзотики смогут сравнительно легко добавить поддержку своего любимого плеера - это да, ставить отдельно надо будет - как и сам плеер, впрочем.
А вот ставить себе в систему неведомый код как раз и не хочу - хоть бинарный,хоть нет. Поэтому, в частности, у меня поддержки DRM просто не будет (или будет "поддержка", позволяющая рипать контент). На винде DRM в систему встроен - но там пользователь ССЗБ. Кому на линуксе сильно нужен DRM-контент - пусть ставит что хочет, в любом случае если есть DRM то система уже недоверенная. Но это ж точка зрения защиты пользователя, а мозилловцы давным-давно защищают кого угодно только не его.
На счёт памяти таки ничего не могу сказать, может и так.На счёт того, что проще уронить — я не эксперт, но мне кажется уронить жестко ограниченный JS значительно сложнее, чем защиту в браузере родным системе кодом (а NaCl это и есть родной код, взаимодействующий с системой через интерфейсы, предоставляемые браузером, на сколько я понял). Пусть этот код и тоже ограничен в наборе допустимых команд.
На счёт песочниц — так в одном только Хроме постоянно дырки в них латают. Держится только за счёт того, что у него многослойная защита и пробить все слои сразу очень тяжело.
> Что до стандарта сжатия - меня вообще крайне смущает идея, что поток будет идти невесть в чем.
Меня тоже. Собственно ORBX это уже очередное невесть что.
> Насчет изменения плагина под свои нужды - не понял.
Так ORBX это не плагин, это js-библиотека, на сколько я понял, которую каждый сможет допилить под свои нужды и вкособочить свой метод шифрации потока, например. С системным плагином такое не провернёшь.
Ну а на счёт DRM тут и говорится, что лучше пусть извращенцы с ним колупаются чисто в вебе, а не загаживают им систему. А то вон SONY даже вирус как-то на своих музыкальных дисках распространяла, реализующий их защиту.
>А то подобрать отдельный примеры, хорошо подающиеся заданному набору оптимизаций - дело нехитрое.Да, вы правы.
Но заглянем чуть-чуть дальше в будущее и увидим открытые программы, которые даже можно эксплуатировать у себя дома, без нагрузки, и которые глючат и вываливаются под нагрузкой потому что их не обработали фирменным оптимизатором. Само-собой что код оптимизатора - тайна за семью печатями. При таких раскладах, навыки написания программ особого значения уже не имеют - в счет идет только владение оптимизатором, который стоит бешеных денег... если вообще будет продаваться.
Вас устраивает такое будущее? Меня вот что-то не очень....(((
Ну, это какая-то фантастика. А вот то, что софт уползает в веб и, соответственно, пользователь лишается контроля над ним - это уже грустно. Грубо говоря, проблема не в том, что этот ORBX на какой-то дряни писан, а то, что эта дрянь грузится с сервера и без специальных усилий пользователя только сервер решает, что и как эта штука будет делать.
То, что софт уползает в веб - только свидетельство того, как много появилось в наше время низкокачественных программистов, занимающихся повторением в вебе уже существующих программ.И сервер не решает, "что и как эта штука будет делать". Если Вы захотите выдрать видео с сайта - вы это сделаете. Музыку - пожалуйста, тот же трюк. Книги - фигня вопрос.
А вот что действительно удивляет, так это Ваше отношение к "фантастике". Вы думаете, что если что-то описано в книге под заголовком "фантастике", то этого никогда не будет? Зря Вы так. Вот парень выше всего лишь развивал тему засилья DRM, которую Столлман описал еще 15 лет назад в рассказе "The Right to Read".
И если бы люди несколько десятилетий назад не спохватились бы, и не организовали оборонительный фронт в виде FSF, то так бы сейчас все и было, как Столлман описал. В этом у меня сомнений нет.
Они этот бред просто ведрами откуда-то черпают
> JavaScript и производительность — два понятия которые у меня не стыкуются в
> голове…вылезай из пещеры, сейчас уже JIT во всех движках. Производительность на уровне Java, и всего в 2..3 раза ниже С...
>Производительность на уровне JavaА, ну тогда всё ок )))))))))
> JavaScript и производительность — два понятия которые у меня не стыкуются в
> голове…добро пожаловать в 21,2 век
папку мозиллы indexedDB забил sqlite файлом 103MB O_o
> Новый проект подчёркивает возведение JavaScript на новый уровень развития и знаменует стирание границ между Web и нативными приложениями.У меня разрыв шаблона. Как код, который требует какой-то другой код для своей трактовки может работать также, как нативный код, который имеет возможность быть оптимизирован в местах требующих максимальной производительности путём вставок хоть до уровня ассемблера (машинного кода)?
У них свои понятия о производительности. То, что там у них 30% проца отъело, нативно будет есть 1-5%.
Рекомендую изучить, что такое "адаптивная JIT-компилиция". Для интерпретируемых языков ассемблер конечно не достигаем по производительности, но к скомпилированному из высокоуровневых языков обычному коду приближается очень близко (см. тесты с LLJS и Asm.js).p.s. адаптивный JIT-компилятор умеет находить проблемные участки кода при выполнении байткода и перекомпилировать этот участок с учетом получаемых результатов. А вот "нативный" код так не умеет.
Угу. А ещё он умеет сожрать кучу памяти на вспомогательные данные, статистику выполнения и т.д., а ресурсы процессора - на сбор этой статистики и многократные перекомпиляции. Знаем, проходили. Крутящийся много часов, а то и дней на сервере в одиночку Java-процесс может себе такое позволить, а штуковина, которая грузится на минуту - как-то не очень. Особенно с нынешней модой на планшеты, смартфоны и ноутбуки.
> Рекомендую изучить, что такое "адаптивная JIT-компилиция". Для интерпретируемых языков
> ассемблер конечно не достигаем по производительности, но к скомпилированному из высокоуровневых
> языков обычному коду приближается очень близко (см. тесты с LLJS и
> Asm.js).даже обходит в некоторых местах
Помнится, одна конторка уже хотела запихать весь-весь юзерский софт в вордовский документ.... оле, дде, дна... и где оно всё?
Кстати, идея-то хороша была, а вот реализация... как обычно у MS. Но те не схоиди с ума и просто оставляли указание на формат, который обрабатывался кем угодно, кто это умеет. А у производителей браузеров какая-то навязчивость на тему "всё своё ношу с собой". При том, что это "своё" по понятным причинам убого.
Пришла смерть адоб флэшу!
Адоб сворачивает поддержку настольных продуктов и уходит в облака с HTML5 браузером :)
Два раза смерть!
Я же говорю - эти уроды, скоро, сделают поганый JS основным языком написания прикладных приложений, а потом, ещё, всё это дело в браузеры попытаются запихнуть.
Вот только asm.js этому никак не способствует. Скорее, даже, наоборот — сводит его до уровня вспомогательной прокладки.
Самое удивительное во всем этом почему за столько лет в браузеры не запихали стандартные скриптовые яп (питон, пхп, перл, руби ...) хотя бы в виде плагинов, предлагаемых для скачки при нахождении <script language="phyton">...И у нормальных языков и так производительность хуже нативной в 2-3 раза, так же как и у этого проекта. ТОлько танцы с бубном не нужны, и каждый программирует на любимом языке.
Вообще-то в прошлом в браузерах уже были VBScript и PerlScript, но особой популярности у разработчиков не сыскали и остался только JavaScript.
пыхпых в браузере ? омг... js в 100500 раз лучше...
`
Во всём виноват Брендан Айх(Mozilla CTO), ссудя по его твиттеру неимоверно горд созданием JS, и тем что он один из главных персонажей в вёб, хотя и с интересом почитывает о разработках конкурентов в Google.Тем не менее в мозиле работает значительное количество видных Python-разработчиков, и их ряды пополняются, а так же выпускаются в опенсорс утилиты на отличных от JS языках, "Go" и т.п
> Я же говорю - эти уроды, скоро, сделают поганый JS основным языком
> написания прикладных приложений, а потом, ещё, всё это дело в браузеры
> попытаются запихнуть.с наступающим вас 2012, друг мой живущий в обратном порядке
Вот скоро-скоро и WebGL со всёми дровами будет работать, и о да!
> Вот скоро-скоро и WebGL со всёми дровами будет работать, и о да!Ну когда уже, блин!
>В частности, продемонстрированы средства для запуска в облачных окружениях ресурсоёмких 3D-пакетов и игр с трансляцией вывода в окно браузера, запущенного на маломощном нетбуке или планшете.... alienware :D
На alienware крутили нативное приложение, а ORBX.js работал на нетбуке с облаком. Не нужно передергивать.
Minecraft если тормозит у меня, значит мой друг может на своём новом компе запустить два минекрафта, первым будет сам управлять, а второй расшарит для меня.
А кукую программу нужно использовать для Windows?
Заинтересовало имя компании. Если включить в самую середину маленькую букву s, то не получится ли то, о чем мы все вместе думаем?
Хотел посмотреть на ORBX.js но не нашел где его качнуть. Или я чего не так понял. Пинайте меня пока я не начну кашлять темными сгустками крови.