GIF-сокеты. Коммуникации в реальном времени через анимированный GIF

[@Yan_Alex]

*Wide open eyes*, не он не курил ..., он что то другое…

[@Dmitry_f]

Здорово. Можно, вероятно, устраивать онлайн-трансляции, или сделать видеоплеер на GIF.

[@briskly]

ну это совсем не оправданно, слишком много трафика, или вы предлагаете, кодировать видео, передавать в гиф, а на стороне клиента преобразовать во что то типа flv, ну это совсем извращение ))

[@Dmitry_f]

Траффик, да, но с другой стороны, можно устраивать потоковое вещание совершенно на любом сайте, где можно ставить гифку. Типа тут, в комментах хабра =)

[@DizzWebS]

То есть сама статья — это нормально?:)

[@Prototik]

А по gif сокету можно передавать другой gif socket?

[@drakmail]

Тут скорее подойдет:

[@davaeron]

need_to_go_deeper.jpg.to

[@dax]

need_to_go_GIFer.gif

[@Prototik]

Некрофил :D

[@MonkAlbino]

Почему House M.D., а не inception?

[@Anton_from_Amber]

Вероятно потому, что в этой серии (2-17) он рассказывает Вилсону про то, что самый большой член в животном мире принадлежит морскому жолудю. Инстересный и бесполезный факт. Типа как данный прикол с GIF. Ящитаю

[@Alukardd]

А по gif сокету можно передавать другой gif socket?

Этот вопрос напомнил мне пост о minecraft.

[@Xazzzi]

Рискуете отправиться в рекурсию.

[@L3n1n]

Cложно найти этой технологии полезное применение

Этим все сказано.

В начале видео идей для применения появилось сразу несколько. Но то что страница все время грузиться убило все…

[@azproduction]

Можно покадрово транслировать состояние терминала. 8 цветов хватит на всех.

[@equand]

Iframe :D

[@TheShock]

Этим все сказано

Я не знаю как на счёт сабжевой технологии, но что у ВебСокетов, что у Стриминга через readyStateChange=3 есть огромная проблема с файрволами и антивирусами. Вполне возможно, что сабжевая технология их не имеет.

[@ryo_oh_ki]

Например хитрую капчу можно сделать.

[@brainworm]

Как именно?

[@VolCh]

А по-моему достаточно интересный вариант для эмуляции веб-сокетов в браузерах их не поддерживающих. При условии, что клиентский JS сможет получить доступ к данным, полученным от сервера. Как-то интереснее, чем, например, flash.

[@kafeman]

Бесконечный iframe лучше, ИМХО.

[@Slonoed]

Чем лучше-то?

[@Shedal]

По-моему, это эмуляция не веб-сокетов, а long polling.

[@VolCh]

Скажем так: и то, и другое, и третье с четвёртым реализация полнодуплексного обмена между браузером и сервером. Но веб-сокеты нативны в современных браузерах, а всё остальное костыли. Потму как-то сейчас чаще встречается эмуляция костылями именно интерфейса веб-сокетов (или приведение всего к абстрактному интерфейсу, но ближе к сокетам).

[@VolCh]

Почему только one-way?

[@TheShock]

Отличие сокетов в том, что соединение не закрывается после получение данных, так что в long-polling надо все таки терять время на установление нового коннекта

Есть технологии, как бесконечный ифрейм и ajax-readyStateChange=3, в которых новый коннект устанавливается только для отправления данных.

[@truezemez]

Дайте, пожалуйста, пару ссылок, где можно почитать, упоминаемые Вами подходы.

[@TheShock]

Во, еле нашёл эту статью meteorserver.org/interaction-modes/:

Streaming делается одним из двух способов — бесконечный iframe (старый проверенный способ) или открытое XHR соединение, в которое постоянно дописываются данные, и срабатывает событие onreadystatechnage.

Второе работает только в Хроме и Фоксе, так как onreadystatechange в Опере вызывается только раз, а в IE нельзя получить responseText до readystatechange=4.

Если надо послать данные, то паралельно просто отправляется ajax-запрос, а от сервера данные сваливаются всё-равно в исходный канал.

Ну а polling и long-polling — известные способы, их даже объяснять не буду.

[@truezemez]

Спасибо. Я не знал про бесконечный ифрейм.

[@iFrolov]

это обычный progressive stream

[@trijin]

любопытно. а получится обрабатывать поток JS без полной загрузки? а то там сокет вполне как сокет заработать может.

[@k0ldbl00d]

Потоковое видео в gif? Это что-то… старенькое!

[@AFoST]

Даёшь видеоконференции через почтовые клиенты! ))

[@ComputerPers]

После просмотра видео осталось впечатление, что автор (видео) не то хотел написать для демонстрации: «The Matrix has you...»

[@Athari]

Подозреваю, что при достаточно долгой загрузке память будет нехило отжираться: браузер будет держать в памяти все загруженные кадры. То есть как прогресс-бар — ну, можно при большом желании (кстати, надо не забывать отправлять пустые кадры через небольшие отрезки времени, иначе скачивание прервётся). А для долгого чата и подобных задач методика слишком непрактична (даже если забыть, что она создана ради прикола).

[@JustLuckyGuy]

Это прям как браузер кеширует весь ролик на ютюбе?

[@Athari]

Хуже. В браузере видео остаётся упакованным набором байтов, а GIF-ка с большой вероятностью распаковывется в грубо говоря 32-битный BMP.

[@equand]

Где? Зачем?

[@Athari]

Ну а как вы думаете хранится графика в памяти? Распаковывается из ГИФа ради каждой перерисовки, ради каждого кадра?

[@zim32]

Непонятно почему видео браузер может каждый раз раскодировать, а вот GIF нет. В чем разница то принципиальная?

[@Athari]

Браузер может каждый раз декодировать ГИФки, но я сильно сомневаюсь, что современные браузеры так делают. Скажем, если я смотрю видео, то я не удивляюсь, что мой CPU нагружается (при условии отсутствия аппаратного декодирования или настолько большого числа ядер, что нагрузка совсем незаметна). Это нормально: вот оно, одно такое видео, я его смотрю, другими задачами не занимаюсь, по 10 видео одновременно не воспроизвожу. Если же я просто читаю сайт, а автор разместил на сайте десяток гифок, то за нагрузку CPU я на браузер обижусь. У меня 50 вкладок открыто, на каждой по паре гифок, всё висит.

Также см. комментарий ниже.

[@badchemist]

Я так понимаю, Athari о том, что браузер хранит в памяти скачанное flv, а флеш-плеер выводит 24-битные кадры 848x480, читая нужную часть этой памяти, и их нигде не складирует. А тут придется хранить в памяти весь ресурс (bitmap, много кадров).

[@equand]

Зачем 8битному гифу распаковываться в 32битный бмп?

[@Athari]

Современные графические карты не поддерживают палитровую графику, каким бы парадоксальным это ни казалось. :) Текстурные палитры с имитацией на шейдерах и прочие извраты — наше всё. То есть для быстрой работы будет 32 бита. Если насиловать железо, то можно хранить в 8 битах, но рисоваться будет на порядок медленнее, потому что каждый раз будут копироваться данные.

Хотя как на самом деле браузеры поступают — без понятия. Разные могут по-разному. Учитывая, что сейчас стало модным аппаратное ускорение, думаю, графика из любого формата будет перегоняться в полноцветную текстуру. И если сейчас так не у всех, до завтра будет у всех.

[@equand]

Можно рефрешем ифрейма сбрасывать память и открывать новый гиф-коннект, эдак каждые 50 мегабайт.
Сессию сохранить не проблема.

[@iFrolov]

можно, но тем самым можно пропустить небольшой фрагмент данных. Это как вещание видео с разрывами. Да и кеше будет помойка.

[@equand]

Зачем терять данные? Все равно пользуем яваскрипт, новые данные не приходят по сокету, делаем локейшн на iframe, ничего сверъестественного даже для ie6

[@iFrolov]

потеря будет при реконнекте. Когда происходит лаг, ты отстаешь от реального времени, образуется буфер. Когда происходит реконнект, буфер теряешь.

[@skabbit]

Кстати, для камер наблюдения вполне подходит. (и разве там так не делали?)

[@Lsh]

Там обновляется jpg в iframe через n секунд. Не?

[@ertaquo]

Отправлять один-два раза в секунду черно-белые кадры, как вариант.

[@Roxis]

Для php есть что-то готовое? Или возможно ли реализовать такое с imagick не вникая в gif формат?

[@Veterinar]

Пацаны ваще ребята, смотрим порно фильмы с субтитрами на древних телефонах без поддержки видео онлайн!

[@L3n1n]

Не хочу вас огорчать, но у вас не получиться.
Древние телефоны как раз работают по схеме «сначала загрузил и обработал — потом показал». Это очень частая ошибка при разработке сайтов… Даже повисший счетчик или баннер не даст открыть страницу сайта.

[@Crazybot]

Ну простыми гифками на Nook Simple Touch киношки крутил кто-то. Извращение, конечно, но забавно выглядело.

[@iFrolov]

К сожалению, далеко не все браузеры показывают GIF сразу и без задержек, не все умеют корректно обрабатывать FPS внутри потока и синхронизируют время «рывками». Пример тому Opera, в том числе последних версий. Если по пути будет прокся, то мелкие фреймы могут запаздывать, ожидая остаток файла. Браузер может дропнуть соединение по таймауту. Да и когда будет начата анимация? Некоторые браузеры начинают проигрывание только при появлении анимации в видимой области. Вообще, много чего может произойти. Именно поэтому я когда-то написал свою либу для работы и гифами и забросил ее.

Ради шутки могу добавить поддержку трансляции GIF в Icecast, если кому-то интересно (и у меня дойдут руки).

[@bolk]

Это настолько очевидно, что непонятно что тут изобретать: bolknote.ru/2011/10/08/~3431/ mJPEG существует, почему бы и не быть mGIF?

[@Alexei03a]

А что будет, если объединить GIF со звуком, которая обсуждалась ранее?

[@2king2]

Скоро на всех сайтах запестрит реклама основанная на GIF-сокетах (дешево и сердито). Так укроп я курил, знаю что получается. Может амброзия попробовать!?

[@ktotamcamoetakoe]

Круто!

Было уже, правда не так круто =) Один парень сделал в году 2003 что-то вроде архиватора в GIF-файл. Получалось так, что гифка была размером 1 пиксел но весила 100 мегабайт =)

А если шагнуть ещё дальше, то можно прокинуть VPN через GIF или tor

[@Alexei03a]

Хорошо бы еще HTML5 Canvas Sockets т.е. транслировать по Canvas элементу. ВОТ ЭТО БУДЕТ КРУТО!

[@Demir0]

Блин, это очень интересно. Я вот подумал, что этим методом можно воспользоваться для постинга таких гифок на сайтах типа Лепрозория. Попытался вчитаться, но либо терпения либо знаний мне не хватило… Может кто нибудь подсказать, как подобное реализовать? Есть сервер, нужно чтоб работало из ссылки на этот «гиф».