H.264 декодер на JavaScript

[@vanxant]

Я так понимаю, разработка оплачена производителями процессоров? Надо же куда-то девать мощь новых чипов:)

[@googol]

Точь-в-точь такая же мысль возникла и у меня. Наверное Intel спонсирует подобные проекты.

[@Ocelot]

А напомните-ка, уважаемые мсье, операционку на JavaScript уже написали? :)

[@Zelgadis]

Да.

[@Voenniy]

Там эмулятор компьютера на js. Про операционку на js там речи нету.

[@ZimM]

Linux, который крутится под этим компьютером, уже не ОС?

[@WGH]

Ну Linux-то никто не переписывал на JavaScript.

[@Voenniy]

Я надеюсь, вы не считаете, что linux написан на js?

[@ZimM]

Нет. Но тем не менее, в итоге получается ОС, работающая на js. А работает она под эмулятором или написана на js — это уже детали реализации

[@bolk]

Ну, я когда-то писал операционку на JS :) Давно это было. Называлась JUnix :)

[@leviaxma]

Ну уж эмуляторы старых компов (в данном случае ZX Spectrum) вовсю пишут: ispeccy.com

[@vitkarpov]

В тему к операционкам на джаваскрипте — runtimejs.org. Любопытно. Проект новый.

[@bad_guy]

смеха ради

Вот это чувство юмора, мне бы так шутить…

[@Finom]

Пожалуйста, выложите куда-то рабочую демку.

[@dax]

Линк на гитхаб в статье. Если не пользуетесь git, можете просто скачать snapshot проекта. Для тестов авторы рекоммендуют Firefox Nightly Build.

[@dax]

Добавлю, что демка лежит в каталоге Broadway/Demo/broadway.html

[@Eddy_Em]

Это будет называться «слайдшоу 1 кадр в час»?

[@general]

Ну написано же «ходе демонстрации скрипт генерирует 30 фреймов в секунду». Почему бы не почитать статью прежде чем комментировать?

[@erlyvideo]

Для H.264 «30 кадров в секунду» — это как сказать: «этот декодер распакует zip файл за 20 секунд», при этом опустив: какого он размера, какая степень сжатия.

[@nickpetrovsky]

Некоторые параметры демо последовательности admiral.264 (480x272, 9 378 028 байта):
profile: Baseline(idc:66)
энтропийный кодер CAVLC (сравнительно простой, лучшие результаты даёт CABAC)
только inter предсказание
остальное приводить не буду, но уже ясно что касается сжатия, то оно очень средненькое.

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

[@nickpetrovsky]

Мой тест:
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ебе слишком лёгкие последовательности :>

Позже попробую что-нибудь действительно сложное ему подсунуть. :)

[@Eddy_Em]

Где параметры? Или вы хотите сказать, что этот декодер сможет отображать 1020p с шестиканальным звуком?

[@homm]

Разговор только что шел о кадре в час. И покажите мне H.264 декодер, который звук отображает, чисто поржать.

[@ArtemSmirnov]

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

[@bootch]

JS просто считают очень медленным. Если вы помните, то тут кто-то сделал видеопроигрыватель из кассового аппарата. По сути ведь, ну подумаешь, что там: просто ассемблер. Но ведь всем очевидно, что сделать это могут лишь еденицы.
P.S. И на крайний случай: я не наезжаю на JS.

[@Eddy_Em]

Каждый инструмент должен знать свое место. JS был разработан для client-side в веб-технологиях. Не надо пытаться распространять его на то, что он делать не может (хотя, конечно, уже есть WebGL и WebCL — на JS можно и отличную 3D-графику безо всякого торможения выводить, и даже элементарные расчеты на GPU делать).

[@Grundiss]

Дело все в том, что JS «стал» серьезным языком совсем недавно. В кавычках, потом что сам JS никак особенно не изменился, поменялись представления разработчиков о скриптовых языках. За что, кстати, спасибо в первую очередь Питону и Руби.

[@entze]

Поменялось отношение со стороны разработчиков браузеров. Такие эксперименты вынуждают к пискомерству и оптимизации JS-движков. Как следствие — меньше потребление ресурсов и более высокая скорость работы и возможность еще больше творить на клиенте.

[@Gorthauer87]

Памяти современные движки больше кушают. А в конечном итоге JS же стал фактически компилируемым языком программирования.

[@olololog]

В смысле?

[@googol]

> JS «стал» серьезным языком совсем недавно

Да просто количество памяти на машинах увеличилось. Сейчас 4Гб это как бы почти стандарт. И у тех кто пишет на JS и других скриптовых языках кажется что памяти бесконечное количество, ну по крайней мере пока не запускается несколько виртуальных машин.

[@Grundiss]

Если у чела не идет игрушка, мы без зазрения совести ему говорим: «Проапгрейдь тачку». Почему же мы должны стесняться такого ответа, если у кого-то «не идет интернет»?

[@mdk]

Потому что в отличие от игрушки, я не вижу ради чего я должен апгрейдить комп. Плюсы-то какие? Ради моды? Или поддержки компании Intel, которой надо сбывать все более мощные чипы?

[@Grundiss]

Очень большой процент своего времени пользователи находятся в браузере. В веб клиенты переползла почта, в облака ушли файлы, видео и аудио больше нет нужды хомячить на винте. Даже офис медленно, но верно утекает в сеть. Скоро, уверен, и ИМ-клиенты обзаведутся веб-мордой. Вот они и плюсы.

[@mdk]

И как из этого следует необходимость использования декодеров на js? Чем это лучше использования браузером декодера из системы?

[@dax]

в системе может элементарно не оказаться нужного декодера

[@mdk]

И поэтому вместо предложения скачать — запускаем нечто тормозное на js?

[@GreatWizard]

Kill it with fire!

[@Vovanys]

На видео показывают российский фильм Адмирал с Хабенским…
Копирастеры вы где? )
А по сабжу круто сделали, скоро походу много чего будет еще написано

[@jakobz]

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

[@googol]

Именно это я считаю лучшим решением, компиляция и оптимизация кода (js/c/...) происходит в платформо-независимый ассемблер (байт-код). А у клиента *во время инсталляции* он перегоняется в платформо-зависисмый код+оптимизация+проверка безопастности…

[@daken]

Это называется .NET и уже давно используется в Silverlight.

[@googol]

У .NET/Silverligh есть одна критическая проблема…

[@Moonrise]

<trollmode>Заключающая в его существовании?</trollmode>

[@dikarik]

Например, заключающаяся в том, что иметь дело с Майкрософт может быть чревато в плане патентной чистоты, и выясниться это может отнюдь не сразу (как в случае FAT с длинными именами).
Вторая — что сишный/плюсовый код (вроде того самого декодера) мы тогда использовать не сможем — очевидно, что платформа будет поддерживать только managed код. Что, к тому же, отсекает ещё кучу языков. Ну и как ложатся всякие скриптовые языки на .NET я тоже не уверен. На JVM, к примеру — с трудом, насколько я знаю.

В этом слысле NaCl для десктопа (не учитывая мобильные платформы) смотрится куда лучше — одна сборка под x86 будет работать везде, если надо — можно еще 64-битный вариант сделать. Что на мобильных я не в курсе — там, конечно, ARM везде, но очень уж разный он бывает…

[@Cryptochild]

Даже так:
У .NET/Silverligh есть одна критическая проблема.

[@ArtRoman]

Точнее, «фатальный недостаток».

[@DjOnline]

Хорошая замена для APNG/AJPG

[@unxed]

Мозиллушка! WebM, пожалуйста! А лучше сразу ffmpeg!

[@dikarik]

А лучше — нативный ffmpeg (можно в комплекте с мозиллушкой, но лучше — системный, где возможно)…