Comments 51
Я так понимаю, разработка оплачена производителями процессоров? Надо же куда-то девать мощь новых чипов:)
А напомните-ка, уважаемые мсье, операционку на JavaScript уже написали? :)
Да.
UFO just landed and posted this here
Ну уж эмуляторы старых компов (в данном случае 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 предсказание
остальное приводить не буду, но уже ясно что касается сжатия, то оно очень средненькое.
Ещё не хватает данных о стендовой конфигурации (я не смог найти). Считаю демо незаконченным без грязных технических подробностей :).
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ебе слишком лёгкие последовательности :>
Позже попробую что-нибудь действительно сложное ему подсунуть. :)
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 с шестиканальным звуком?
Когда вижу такие посты мне кажется что люди все еще не поняли что js полноценный язык, если бы декодер написали на C то врятле бы об этом написали на хабр, а про js пишут как если бы декодер был написан на брейнфаке, обидно за js.
JS просто считают очень медленным. Если вы помните, то тут кто-то сделал видеопроигрыватель из кассового аппарата. По сути ведь, ну подумаешь, что там: просто ассемблер. Но ведь всем очевидно, что сделать это могут лишь еденицы.
P.S. И на крайний случай: я не наезжаю на JS.
P.S. И на крайний случай: я не наезжаю на JS.
Каждый инструмент должен знать свое место. JS был разработан для client-side в веб-технологиях. Не надо пытаться распространять его на то, что он делать не может (хотя, конечно, уже есть WebGL и WebCL — на JS можно и отличную 3D-графику безо всякого торможения выводить, и даже элементарные расчеты на GPU делать).
Дело все в том, что JS «стал» серьезным языком совсем недавно. В кавычках, потом что сам JS никак особенно не изменился, поменялись представления разработчиков о скриптовых языках. За что, кстати, спасибо в первую очередь Питону и Руби.
Поменялось отношение со стороны разработчиков браузеров. Такие эксперименты вынуждают к пискомерству и оптимизации JS-движков. Как следствие — меньше потребление ресурсов и более высокая скорость работы и возможность еще больше творить на клиенте.
> JS «стал» серьезным языком совсем недавно
Да просто количество памяти на машинах увеличилось. Сейчас 4Гб это как бы почти стандарт. И у тех кто пишет на JS и других скриптовых языках кажется что памяти бесконечное количество, ну по крайней мере пока не запускается несколько виртуальных машин.
Да просто количество памяти на машинах увеличилось. Сейчас 4Гб это как бы почти стандарт. И у тех кто пишет на JS и других скриптовых языках кажется что памяти бесконечное количество, ну по крайней мере пока не запускается несколько виртуальных машин.
Если у чела не идет игрушка, мы без зазрения совести ему говорим: «Проапгрейдь тачку». Почему же мы должны стесняться такого ответа, если у кого-то «не идет интернет»?
Потому что в отличие от игрушки, я не вижу ради чего я должен апгрейдить комп. Плюсы-то какие? Ради моды? Или поддержки компании Intel, которой надо сбывать все более мощные чипы?
Kill it with fire!
На видео показывают российский фильм Адмирал с Хабенским…
Копирастеры вы где? )
А по сабжу круто сделали, скоро походу много чего будет еще написано
Копирастеры вы где? )
А по сабжу круто сделали, скоро походу много чего будет еще написано
Неплохо. Но лучше, конечно, LLVM запускать прямо в браузере, без промежуточного JS. Google что-то на эту тему придумывает, может и другие подтянутся.
Именно это я считаю лучшим решением, компиляция и оптимизация кода (js/c/...) происходит в платформо-независимый ассемблер (байт-код). А у клиента *во время инсталляции* он перегоняется в платформо-зависисмый код+оптимизация+проверка безопастности…
Это называется .NET и уже давно используется в Silverlight.
У .NET/Silverligh есть одна критическая проблема…
<trollmode>Заключающая в его существовании?</trollmode>
Например, заключающаяся в том, что иметь дело с Майкрософт может быть чревато в плане патентной чистоты, и выясниться это может отнюдь не сразу (как в случае FAT с длинными именами).
Вторая — что сишный/плюсовый код (вроде того самого декодера) мы тогда использовать не сможем — очевидно, что платформа будет поддерживать только managed код. Что, к тому же, отсекает ещё кучу языков. Ну и как ложатся всякие скриптовые языки на .NET я тоже не уверен. На JVM, к примеру — с трудом, насколько я знаю.
В этом слысле NaCl для десктопа (не учитывая мобильные платформы) смотрится куда лучше — одна сборка под x86 будет работать везде, если надо — можно еще 64-битный вариант сделать. Что на мобильных я не в курсе — там, конечно, ARM везде, но очень уж разный он бывает…
Вторая — что сишный/плюсовый код (вроде того самого декодера) мы тогда использовать не сможем — очевидно, что платформа будет поддерживать только managed код. Что, к тому же, отсекает ещё кучу языков. Ну и как ложатся всякие скриптовые языки на .NET я тоже не уверен. На JVM, к примеру — с трудом, насколько я знаю.
В этом слысле NaCl для десктопа (не учитывая мобильные платформы) смотрится куда лучше — одна сборка под x86 будет работать везде, если надо — можно еще 64-битный вариант сделать. Что на мобильных я не в курсе — там, конечно, ARM везде, но очень уж разный он бывает…
Точнее, «фатальный недостаток».
Хорошая замена для APNG/AJPG
Мозиллушка! WebM, пожалуйста! А лучше сразу ffmpeg!
Only those users with full accounts are able to leave comments. Log in, please.
H.264 декодер на JavaScript