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

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

Я так понимаю, разработка оплачена производителями процессоров? Надо же куда-то девать мощь новых чипов:)
Точь-в-точь такая же мысль возникла и у меня. Наверное Intel спонсирует подобные проекты.
А напомните-ка, уважаемые мсье, операционку на JavaScript уже написали? :)
Да.
НЛО прилетело и опубликовало эту надпись здесь
Там эмулятор компьютера на js. Про операционку на js там речи нету.
Linux, который крутится под этим компьютером, уже не ОС?
Ну Linux-то никто не переписывал на JavaScript.
Я надеюсь, вы не считаете, что linux написан на js?
Нет. Но тем не менее, в итоге получается ОС, работающая на js. А работает она под эмулятором или написана на js — это уже детали реализации
Ну, я когда-то писал операционку на JS :) Давно это было. Называлась JUnix :)
Ну уж эмуляторы старых компов (в данном случае ZX Spectrum) вовсю пишут: ispeccy.com
В тему к операционкам на джаваскрипте — runtimejs.org. Любопытно. Проект новый.
смеха ради

Вот это чувство юмора, мне бы так шутить…
Пожалуйста, выложите куда-то рабочую демку.
Линк на гитхаб в статье. Если не пользуетесь git, можете просто скачать snapshot проекта. Для тестов авторы рекоммендуют Firefox Nightly Build.
Добавлю, что демка лежит в каталоге Broadway/Demo/broadway.html
Это будет называться «слайдшоу 1 кадр в час»?
Ну написано же «ходе демонстрации скрипт генерирует 30 фреймов в секунду». Почему бы не почитать статью прежде чем комментировать?
Для H.264 «30 кадров в секунду» — это как сказать: «этот декодер распакует zip файл за 20 секунд», при этом опустив: какого он размера, какая степень сжатия.
Некоторые параметры демо последовательности admiral.264 (480x272, 9 378 028 байта):
profile: Baseline(idc:66)
энтропийный кодер CAVLC (сравнительно простой, лучшие результаты даёт CABAC)
только inter предсказание
остальное приводить не буду, но уже ясно что касается сжатия, то оно очень средненькое.

Ещё не хватает данных о стендовой конфигурации (я не смог найти). Считаю демо незаконченным без грязных технических подробностей :).

Мой тест:
win32 (3 Gb RAM, CPU: Intel Core 2 Duo E8400)
admiral.264:
Average FPS (All / Steady) 49.54 49.11
Elapsed 56.63
mozilla.264:
Average FPS (All / Steady) 47.48 47.99
Elapsed 111.90

При динамичной смене кадров fps падал до 25. Результаты в целом неплохие.
Основой JS декодера является PacketVideo(C++). Беглый обзор исходников показывает что декодер должен поддерживать FMO(это восстановление повреждённых макроблоков вроде) и intra предсказание.

Считаю что разработчики подкладывали cебе слишком лёгкие последовательности :>

Позже попробую что-нибудь действительно сложное ему подсунуть. :)
Где параметры? Или вы хотите сказать, что этот декодер сможет отображать 1020p с шестиканальным звуком?
Разговор только что шел о кадре в час. И покажите мне H.264 декодер, который звук отображает, чисто поржать.
Когда вижу такие посты мне кажется что люди все еще не поняли что js полноценный язык, если бы декодер написали на C то врятле бы об этом написали на хабр, а про js пишут как если бы декодер был написан на брейнфаке, обидно за js.
JS просто считают очень медленным. Если вы помните, то тут кто-то сделал видеопроигрыватель из кассового аппарата. По сути ведь, ну подумаешь, что там: просто ассемблер. Но ведь всем очевидно, что сделать это могут лишь еденицы.
P.S. И на крайний случай: я не наезжаю на JS.
Каждый инструмент должен знать свое место. JS был разработан для client-side в веб-технологиях. Не надо пытаться распространять его на то, что он делать не может (хотя, конечно, уже есть WebGL и WebCL — на JS можно и отличную 3D-графику безо всякого торможения выводить, и даже элементарные расчеты на GPU делать).
Дело все в том, что JS «стал» серьезным языком совсем недавно. В кавычках, потом что сам JS никак особенно не изменился, поменялись представления разработчиков о скриптовых языках. За что, кстати, спасибо в первую очередь Питону и Руби.
Поменялось отношение со стороны разработчиков браузеров. Такие эксперименты вынуждают к пискомерству и оптимизации JS-движков. Как следствие — меньше потребление ресурсов и более высокая скорость работы и возможность еще больше творить на клиенте.
Памяти современные движки больше кушают. А в конечном итоге JS же стал фактически компилируемым языком программирования.
В смысле?
> JS «стал» серьезным языком совсем недавно

Да просто количество памяти на машинах увеличилось. Сейчас 4Гб это как бы почти стандарт. И у тех кто пишет на JS и других скриптовых языках кажется что памяти бесконечное количество, ну по крайней мере пока не запускается несколько виртуальных машин.
Если у чела не идет игрушка, мы без зазрения совести ему говорим: «Проапгрейдь тачку». Почему же мы должны стесняться такого ответа, если у кого-то «не идет интернет»?
Потому что в отличие от игрушки, я не вижу ради чего я должен апгрейдить комп. Плюсы-то какие? Ради моды? Или поддержки компании Intel, которой надо сбывать все более мощные чипы?
Очень большой процент своего времени пользователи находятся в браузере. В веб клиенты переползла почта, в облака ушли файлы, видео и аудио больше нет нужды хомячить на винте. Даже офис медленно, но верно утекает в сеть. Скоро, уверен, и ИМ-клиенты обзаведутся веб-мордой. Вот они и плюсы.
И как из этого следует необходимость использования декодеров на js? Чем это лучше использования браузером декодера из системы?
в системе может элементарно не оказаться нужного декодера
И поэтому вместо предложения скачать — запускаем нечто тормозное на js?
На видео показывают российский фильм Адмирал с Хабенским…
Копирастеры вы где? )
А по сабжу круто сделали, скоро походу много чего будет еще написано
Неплохо. Но лучше, конечно, LLVM запускать прямо в браузере, без промежуточного JS. Google что-то на эту тему придумывает, может и другие подтянутся.
Именно это я считаю лучшим решением, компиляция и оптимизация кода (js/c/...) происходит в платформо-независимый ассемблер (байт-код). А у клиента *во время инсталляции* он перегоняется в платформо-зависисмый код+оптимизация+проверка безопастности…
Это называется .NET и уже давно используется в Silverlight.
У .NET/Silverligh есть одна критическая проблема…
<trollmode>Заключающая в его существовании?</trollmode>
Например, заключающаяся в том, что иметь дело с Майкрософт может быть чревато в плане патентной чистоты, и выясниться это может отнюдь не сразу (как в случае FAT с длинными именами).
Вторая — что сишный/плюсовый код (вроде того самого декодера) мы тогда использовать не сможем — очевидно, что платформа будет поддерживать только managed код. Что, к тому же, отсекает ещё кучу языков. Ну и как ложатся всякие скриптовые языки на .NET я тоже не уверен. На JVM, к примеру — с трудом, насколько я знаю.

В этом слысле NaCl для десктопа (не учитывая мобильные платформы) смотрится куда лучше — одна сборка под x86 будет работать везде, если надо — можно еще 64-битный вариант сделать. Что на мобильных я не в курсе — там, конечно, ARM везде, но очень уж разный он бывает…
Точнее, «фатальный недостаток».
Хорошая замена для APNG/AJPG
Мозиллушка! WebM, пожалуйста! А лучше сразу ffmpeg!
А лучше — нативный ffmpeg (можно в комплекте с мозиллушкой, но лучше — системный, где возможно)…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.