Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 22196 сообщений
Cообщения с меткой

flash - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Восстановление 1С базы после форматирования

Среда, 26 Апреля 2017 г. 13:04 (ссылка)

Люди в погоне за комфортными для них условиями работы зачастую не задумываются о безопасности и сохранности своих данных и рано или поздно сталкиваются с вопросами их утраты. Рассмотрим обращение клиента с USB Flash 2Gb Transcend. Со слов клиента, в один из дней при установке накопителя в USB порт компьютера было предложено ее отформатировать. Как утверждает клиент, он отказался от этого и обратился за помощью к системному администратору. Системный администратор, обнаружив, что при подключении USB накопителя «подвешивается» компьютер, не придумал ничего лучшего, чем согласиться с предложением операционной системы отформатировать его (никогда этого не делайте!). Далее системный администратор использовал популярную программу автоматического восстановления R-Studio. Результат ее работы в виде безымянных папок был скопирован клиенту на другой накопитель. При просмотре результата клиент обнаружил, что около четверти файлов не могут быть открыты и, что хуже всего, 1С Бухгалтерия 7.7 отказывалась запускаться с восстановленной базой, ссылаясь на отсутствие файлов.





рис. 1



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





Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.



Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.

Открываем LBA 0 (0x0 в файле образе) и проверяем там наличие таблицы разделов, либо наличие Boot сектора файловой системы.





рис. 2



В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)





рис. 3



Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.

Для этого нам нужны следующие параметры, описанные в boot секторе (будут указаны в виде смещения от начала сектора): размер сектора по смещению 0x0B — 0x200 (512 байт), количество секторов в кластере по смещению 0x0D — 0x08, размер кластера получается посредством перемножения размера сектора на количество секторов в кластере 0x08*0x0200=0x1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц FAT — по смещению 0x0E=0x01FE (510 секторов), количество копий FAT — по смещению 0x10=0x02, размер одной копии FAT — по смещению 0x24=00000F01 (3841 секторов). Используя полученные параметры, произведем расчет положения начала области данных: 0x10000+0x01FE*200+0x00000F01*2*200=0x410000 (8320 сектор). Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы рассчитали начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в FAT таблице зарезервированы и не используются по прямому назначению, в связи с чем нулевой точкой принимается начало области данных за минусом 2 кластеров. В данном случае это будет 0x410000-0x1000*2=0x40E000 (8318 сектор)

Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.





Рис. 4



Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.

Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.





рис. 5



По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.



Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).





рис. 6



При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.



Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.





рис. 7



Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.



Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 32-байтных блоков с нулевым смещением.





Рис. 8



Таким образом, находим все директории, содержащие в себе указатель на файл 1CV7.MD. В нашем случае обнаружилась только одна такая директория, что позволяет предполагать, что мы нашли первый кластер необходимой директории. Далее следует анализ положения родительских директорий, вплоть до корневой директории. Каждая найденная директория прописывается в таблицу FAT (сначала как директория из одного кластера, посредством записи FF FF FF 0F для соответствующего элемента таблицы). Также в корневой директории прописывается ссылка на дочерний объект.



На текущем этапе мы выполним копирование найденных файлов с предположением об их непрерывности, так как обе копии FAT не содержат информации о фрагментации (напомним, что они были безвозвратно уничтожены системным администратором в результате необдуманного форматирования USB flash). После копирования директории 1С базы анализируем количество файлов. Учитывая, что фрагмент директории был размером в один кластер, то извлекли мы не более 126 файлов, что явно намного меньше, чем должно быть в директории с DBF и CDX файлами, относящимися к 1С базе. Примерно такой же результат выдадут программы автоматического восстановления, о чем свидетельствует результат, полученный системным администратором посредством использования R-Studio.



Среди извлеченных файлов есть 1CV7.MD (файл конфигурации) и 1СV7.DD (файл словаря данных). После выполнения проверки целостности создадим у себя на диске временную папку, куда поместим 1CV7.MD. Укажем данный путь при добавлении новой базы и откроем конфигуратор, посредством которого создадим чистую базу на основании этой конфигурации. Сравним сформированный DD файл с восстановленным, если описания и количество справочников идентичны, то никаких дополнительных действий не требуется, и, имея полный список файлов, можно приступать к поиску остальных фрагментов директории 1С базы. Для этого необходимо осуществить поиск последовательностей из ASCII кодов символов, используемых в именах недостающих DBF файлов. По мере обнаружения фрагментов директории дописывать в таблицу размещения файлов продолжение цепочки. После каждой операции дополнения цепочки директории выполнять копирование файлов и анализировать, насколько сократилась количество недостающих DBF файлов, и вновь формировать последовательность ASCII кодов символов для поиска следующего фрагмента.





рис. 9



Также необходимо помнить, что при записи цепочки фрагментов директории в таблицу размещения файлов, необходимо анализировать фрагменты, чтобы стыковались LFN записи. В случае только коротких записей цепочку можно писать с любым порядком фрагментов.

В данном случае выполнив поиск 5 последовательностей удалось найти все остальные фрагменты директории с базой 1С.



После того, как построена полная цепочка фрагментов директории, выполняем повторное копирование уже всех файлов 1С базы с предположением об их непрерывности. Пользовательская информация содержится в DBF файлах, поэтому необходимо проверить их целостность.



Основной метод контроля целостности DBF файла – это проверка информации, содержащейся в служебном заголовке и соответствует ли содержимое файла описанию в заголовке.





рис. 10



Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A. Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08. 0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.

Для контроля целостности содержимого полей можно использовать визуальный метод.





рис. 11



В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.



При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.





Рис. 12



Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).



Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.





рис. 13



В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327414/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Трансляция RTMP видеопотока из Live Encoder на WebRTC

Понедельник, 24 Апреля 2017 г. 11:02 (ссылка)



HTTP протоколы доставки видеоконтента, такие как HLS и DASH давно потеснили Flash в нише воспроизведения онлайн-видео контента в браузерах.



Тем не менее, изначально флэшовый протокол RTMP, остается одним из самых популярных способов доставки Live видео от источника видео до сервера ретранслятора. RTMP продолжают использовать такие сервисы, как Facebook Live, Youtube Live, и другие, где требуется вещать живое видео и проводить трансляции. Таким образом, несмотря на предсказания и констатации скорой кончины Flash, протокол RTMP все еще на коне и не уступает своих позиций в нише видеотрансляций.



Для захвата видео с камер, с последующей кодировкой в RTMP создано много хардварных и софтверных решений — коробок, которые подключаются к одной или нескольким камерам, обрабатывают полученные видеосигналы и отправляют полученную картинку по RTMP на удаленный сервер или сервис для дальнейшей ретрансляции. Классическая схема трансляции выглядит так:





Недостатком такой схемы можно назвать только задержку в видеотрансляции, которая может быть около 30 секунд. Если же вместо HLS и DASH использовать Adobe Flash Player и RTMP, то снова возвращаемся к Flash плагину, который находится, мягко говоря, не в авангарде современных средств отображения онлайн видео.



WebRTC



Решение, позволяющее отыграть поток без плагинов и с минимальной задержкой — это WebRTC и конвертация RTMP в WebRTC на стороне сервера решает задачу воспроизведения потока на большом числе устройств и браузеров.



Однако здесь следует понимать, что WebRTC — это технология, заточенная под реалтайм. В отличие, например от того же HTTP (HLS), где просто отдаются сегменты по протоколу HTTP, WebRTC работает гораздо сложнее и использует плотный обмен данными между отправителем и получателем трафика, с использованием RTCP-фидбеков, контролем полосы пропускания и таргетированием задержки.



Поэтому прежде чем включать WebRTC для простого воспроизведения потока, нужно ответить на один простой вопрос: требуется ли в проекте доставки видео низкая задержка. И если низкая задержка не требуется, то есть смысл рассмотреть другие технологии доставки, такие HLS и DASH чтобы избежать оверхеда с WebRTC.





Для максимальной совместимости с другими устройствами и сохранения возможности раздачи на HLS, необходимо выбрать правильные кодеки. Как правило, RTMP кодеры поддерживают H.264 видео кодек и AAC аудио кодек. Эта комбинация достаточно стандартная и встречается очень часто.



WebRTC в браузерах не поддерживает кодек AAC, поэтому придется транскодировать AAC в Opus или AAC в G.711. Транскодинг в Opus дает лучшее качество и позволяет, при желании, выкрутить его еще выше с помощью настроек. Поэтому если и транскодить, то предпочтительно делать это в Opus.



Так как мы используем H.264 при получении видеопотока сервером и при его воспроизведении с WebRTC-устройств, то транскодинга здесь не требуется, а требуется депакетизация полученного по RTMP видео с последующей пакетизацией в SRTP (WebRTC). Процесс ре-пакетизации, очевидно отнимает меньше процессорного времени чем транскодинг, что позволяет обслужить больше входящих потоков.



Однако, не все устройства поддерживают H.264. Например браузер Chrome под Android не везде дает использовать этот кодек. В этом случае включится полноценный транскодинг в WebRTC кодек VP8 и схема будет выглядеть так:





Транскодинг на стороне сервера предъявляет серьезные требования к CPU, поэтому нужно быть готовым заложить около 1 ядра сервера, при необходимости транскодинга потока высокого разрешения, например 720p



Кодеры



Профессиональные коробочки вроде такой стоят хороших денег и требуются для профессионального вещания 24x7 и серьезных бизнес-задач:





Для вещания более простых мероприятий подойдут софтверные решения, одним из которых является бесплатный Live Media Encoder от Adobe.





Версия кодера для Mac OS имеет поддержку кодеков H.264 и AAC. Поэтому если использовать Live Media Encoder на Mac, он может в каком-то смысле стать заменой хардварного кодера или платного софта, позволяющего вещать RTMP в сеть с теми же кодеками.



Тестирование



Для начала убедимся, что поток доступен и играет по RTMP. Если с воспроизведением по RTMP все в порядке и поток на месте, подключаемся к нему по WebRTC.



Процесс стриминга видеопотока на сервер называется публикация (publishing) и требует как минимум:




  1. Выбрать используемую камеру.

  2. Указать RTMP-адрес публикации потока

    Пример:

    rtmp://192.168.88.59/live

  3. Указать имя потока

    Пример:

    stream2229





Если адрес сервера правильный, есть доступ к камере, то при нажатии кнопки Start, кодер должен получить соединение с сервером по протоколу RTMP и начать публикацию видеопотока по указанному адресу и с указанным именем stream2229.





Теперь нужно забрать видеопоток с сервера по RTMP. Для этого будем использовать простое Flash-приложение Flash Streaming, которое также доступно по этой ссылке. Это обычная флэшка (swf-файл), которая располагается на web-странице и выполняется в Adobe Flash Player. Поэтому убедитесь, что Flash Player установлен и доступен в вашей системе для этого теста.



Здесь требуется ввести те же данные: адрес RTMP потока и его имя. В результате получаем видео на веб-странице. Его играет Flash Player.





Далее, вспоминаем, что нашей целью было протестировать воспроизведение с помощью WebRTC, и воспроизведение во Flash было лишь промежуточным тестом, подтверждающим работу RTMP кодера и сервера трансляции.



Для теста просто заберем видеопоток WebRTC плеером. Этот плеер не требует указания RTMP-адреса, так как для подключения к серверу используется протокол Websockets и адрес будет таким: wss://192.168.88.59:8443



Здесь:



wss — это вебсокеты через SSL

192.168.88.59 — адрес WebRTC сервера

8443 — порт сервера для протокола Websockets SSL





После того, как в качестве имени потока указали stream2229, нажимаем Play и получаем картинку уже по WebRTC.



Здесь нужно отметить, что несмотря на то, что подключение к серверу произошло по Websockets и порт указан 8443, видеотрафик пойдет не через это соединение. Для видео будут открыты специальные UDP порты на стороне браузера и на стороне сервера и именно через эти открытые UDP порты будет осуществляться передача видео. Через Websockets же будут переданы простые команды воспроизведения, статусы, а также конфигурация кодеков и другой важной для WebRTC информации.



Чтобы посмотреть как заходит WebRTC видеотрафик, используем браузер Google Chrome и во время воспроизведения открываем chrome://webrtc-internals





Графики показывают, что битрейт принимаемого видеопотока составляет около 600 kbps, фрейм рейт 28-30 FPS.





Следующие графики дают информацию о количестве потерянных UDP пакетов (50), о скорости приема пакетов в секунду, о разрешении видеопотока 640x480, о джиттере и времени декодирования.



Таким образом, мы протестировали воспроизведение RTMP видеопотока, отправленного с Adobe Live Media Encoder на HTML5 — странице в браузере с поддержкой WebRTC и не использовали дополнительных браузерных плагинов. Тестирование проходило с сервером Web Call Server 5, который поддерживает входящие RTMP потоки с последующей раздачей по RTMP, WebRTC и другим протоколам.



Код страницы — WebRTC плеера



Минимальный код плеера для встраивания в веб-страницу выглядит так









The player








Этот код опирается на файл API flashphoner.js, который доступен в сборке Web SDK.

Сам плеер будет встроен в div-элемент remoteVideo.



Скрипт player.js использует три функции: инициализацию с помощью Flashphoner.init(), создание подключения к серверу с помощью Flashphoner.createSession() и воспроизведение WebRTC видеопотока session.createStream(...).play().



Статусы соединения с сервером отслеживаются с помощью событий: ESTABLISHED, DISCONNECTED, FAILED.



Статусы видеопотока отслеживаются с помощью событий PLAYING, STOPPED, FAILED.



Таким образом получаем полный контроль над соединением с сервером и статусами видеопотока.



var remoteVideo;

function init(){
Flashphoner.init();
remoteVideo = document.getElementById("remoteVideo");
}

function start() {
Flashphoner.createSession({urlServer: "wss://wcs5-eu.flashphoner.com:8443"}).on(Flashphoner.constants.SESSION_STATUS.ESTABLISHED, function (session) {
//session connected, start streaming
startPlayback(session);
}).on(Flashphoner.constants.SESSION_STATUS.DISCONNECTED, function () {
setStatus("DISCONNECTED");
}).on(Flashphoner.constants.SESSION_STATUS.FAILED, function () {
setStatus("FAILED");
});
}

function startPlayback(session) {
session.createStream({
name: "stream2229",
display: remoteVideo,
cacheLocalResources: true,
receiveVideo: true,
receiveAudio: true
}).on(Flashphoner.constants.STREAM_STATUS.PLAYING, function (playStream) {
setStatus(Flashphoner.constants.STREAM_STATUS.PLAYING);
}).on(Flashphoner.constants.STREAM_STATUS.STOPPED, function () {
setStatus(Flashphoner.constants.STREAM_STATUS.STOPPED);
}).on(Flashphoner.constants.STREAM_STATUS.FAILED, function () {
setStatus(Flashphoner.constants.STREAM_STATUS.FAILED);
}).play();
}

function setStatus(status) {
document.getElementById("status").innerHTML = status;
}


Минимальный код WebRTC плеера доступен для скачивания по этой ссылке и для работы требует установленного WebRTC-сервера Web Call Server 5. Сервер может быть скачан и установлен на Linux-хост https://flashphoner.com/download или же запущен в виде образа на Amazon EC2.



Минимальный код WebRTC плеера в работе



Пример плеера и скриншоты представленные выше, имели некоторые дополнительные стили и скрипты для позиционирования картинки.



В минимальном коде мы ограничились простейшим HTML и урезанным скриптом для максимально быстрого внедрения в страницу сайта. Результат выглядит так:





Этот плеер можно интегрировать в любую веб-страницу сайта или проекта, т.к. он требует лишь включения скрипта API flashphoner.js и одного div-блока под видео на веб-странице.



Сервер, который работает с WebRTC может физически находиться на другой независимой машине, никак не связанной с хостингом веб-проекта.





В итоге, мы описали код WebRTC-плеера и показали как встроить плеер в веб-страницу сайта и развернуть на собственном веб-сервере. Плеер играет WebRTC H.264 видеопоток. Источником потока RTMP является Adobe Live Media Encoder.



Ссылки



Adobe Flash Media Encoder — кодер от Adobe, позволяющий стримить RTMP.

Flash Streaming Demo — воспроизведение RTMP потока в Flash Player.

Player — стандартный пример плеера WebRTC с исходным кодом.

Player Minimal — скачать скрипты минимального плеера WebRTC player.html и player.js

WebRTC Server — сервер Web Call Server 5 для ретрансляции RTMP потока по WebRTC.

Web SDK — сборка содержит flashphoner.js — файл API для плеера.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327214/

Комментарии (0)КомментироватьВ цитатник или сообщество
НАТАЛИЯ11

Не верю, мама, что ты ушла!

Среда, 12 Апреля 2017 г. 18:57 (ссылка)


Не верю, мама, что ты ушла!




Метки:   Комментарии (5)КомментироватьВ цитатник или сообщество
Элми09

FLASH-АНИМАЦИИ РОЗЫ + КОД.

Воскресенье, 09 Апреля 2017 г. 22:57 (ссылка)

Это цитата сообщения be-ll Оригинальное сообщение

Flash-анимации розы + код.




Смотрим далее + 20 >>>

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

WebRTC, Safari

Суббота, 08 Апреля 2017 г. 18:49 (ссылка)



В апреле прошлого года по сети прокатился пресс-релиз о том, что Apple выкатывает поддержку WebRTC в браузерах Safari для Mac OS и iOS. С момента выхода пресс-релиза скоро пройдет ровно 1 год как Apple продолжает выкатывать WebRTC для Safari. Ждем.





Однако ждут не все. Кому-то требуется реал-тайм видео в Safari прямо сейчас и в этой статье мы расскажем как обходиться без WebRTC в браузере iOS Safari и Mac OS Safari и чем можно его заменить.



На сегодняшний день нам известны следующие варианты:




  • HLS

  • Flash

  • Websockets

  • WebRTC Plugin

  • iOS native app



Так как мы ищем альтернативу RTC (Real Time Communication), то сравним эти варианты не только по платформам iOS / Mac OS, но и по средней задержке (Latency) в секундах.








































iOS Mac OS Latency
HLS, DASH Да Да 15
Flash RTMP Нет Да 3
Flash RTMFP Нет Да 1
Websockets Да Да 3
WebRTC Plugin Нет Да 0.5


HLS



Как видно из этой таблицы, HLS совсем выпадает из реалтайма со своими 15 и более секундами задержки, хотя и прекрасно работает на обоих платформах.



Flash RTMP



Несмотря на то, что «Flash умер», он продолжает работать на Mac OS и даёт годную для реалтайма задержку. Но дела у флэша на Safari действительно обстоят не очень. Бывает так, что Flash оказывается попросту отключен.



Flash RTMFP



Тоже самое что и Flash RTMP, с той лишь разницей, что работает по UDP и умеет сбрасывать пакеты, что несомненно лучше для реалтайма. Хорошая задержка. Не работает на iOS.



Websockets



Некоторая альтернатива для HLS, если нужна сравнительно низкая задержка. Работает в iOS и Mac OS.



В этом случае видеопоток приходит через Websockets (RFC6455), декодируется на уровне JavaScript и отрисовывается на HTML5 canvas с помощью WebGL. Этот способ работает гораздо быстрее HLS, но имеет свои недостатки:




  1. Односторонняя доставка.Поток можно только проиграть в реалтайме, но нельзя захватить с камеры устройства и отправить на сервер.

  2. Ограничения по разрешению. При разрешении 800x400 и выше, нужен уже мощный CPU на последних iPhone или iPad для ровного декодирования такого потока на JavaScript. С iPhone5 и iPhone6 разрешение скорее всего не удастся поднять выше 640x480 и оставить плавным.



WebRTC Plugin



В Mac OS можно установить WebRTC плагин, который реализует WebRTC. Это несомненно дает самую лучшую задержку, но требует скачивания и установки пользователем стороннего программного обеспечения. Можно справедливо заметить, что Adobe Flash Player тоже плагин и тоже может требовать ручной установки, но «мертвый флэш» плагин от Adobe, очевидно, обгоняет Noname WebRTC плагины по распространенности. Кроме этого, WebRTC плагины не работают в iOS Safari.



Другие альтернативы WebRTC для iOS



Если не ограничиваться браузером Safari, можно рассмотреть следующие варианты:



iOS native app



Имплементим iOS приложение с поддержкой WebRTC и получаем низкую задержку и всю мощь WebRTC-технологии. Не браузер. Требует установки из App Store.



Browser



Браузер с поддержкой WebRTC под iOS. Говорят, что поддерживает WebRTC, но мы не тестировали. Не очень популярный браузер. Но если есть возможность заставить пользователей им пользоваться, можно попробовать это сделать.



Ericsson



Тоже что и Bowser. Непонятно, насколько хорошо работает с WebRTC. Не популярен на iOS.



Ждун



Можно подождать внедрение WebRTC от Apple. Прошел уже год. Возможно осталось ждать не так уж и долго. Может у кого-то есть инсайд?



Websockets как замена WebRTC на iOS



Из таблицы выше видно, что на iOS Safari остается только два варианта: HLS и Websockets. Первый имеет задержку более 15 секунд. Второй имеет свои ограничения и задержку около 3 секунд. Есть еще MPEG DASH, но это тот же HLS / HTTP в плане реалтайма.



В силу перечисленных выше ограничений:




  • Декодинг на JavaScript и поддержка низких разрешений

  • Односторонний стриминг (только воспроизведение)



Вебсокеты, конечно же, не могут претендовать на полноценную замену WebRTC в браузере iOS Safari, но позволяют играть реалтайм-потоки прямо сейчас.



В этом случае, схема реалтаймовой трансляции выглядит так:




  1. Отправляем WebRTC видеопоток, например с Mac OS или Win, браузера Chrome на WebRTC-сервер с поддержкой конвертации в вебсокеты.

  2. WebRTC-сервер конвертирует поток в MPEG + G.711 и заворачивает в транспортный протокол Websockets.

  3. 3iOS Safari устанавливает соединение с сервером по протоколу Websockets и забирает видеопоток. Далее распаковывает видеопоток и декодирует аудио и видео. Аудио проигрывает через Web Audio API, а видео рендерит в Canvas с использованием WebGL.







Тестирование воспроизведения по Websockets в iOS Safari



В качестве сервера используется Web Call Server 5, который поддерживает такую конвертацию и отдает поток на iOS Safari по Websockets. Источником реалтаймового видеопотока может быть вебкамера, которая отправляет видео на сервер или же IP камера, работающая по RTSP.



Так выглядит отправка реалтаймового WebRTC видеопотока на сервер в браузере Google Chrome с десктопа:





А так выглядит воспроизведение этого же видеопотока в реалтайме, в браузере iOS Safari:





Здесь мы в качестве имени видеопотока указали d3c6, т.е. Тот видеопоток, который был отправлен с браузера Chrome по WebRTC.



В случае, если видеопоток забирается с IP-камеры, в iOS Safari это будет выглядеть так:





Как видно из скриншота, в качестве имени видеопотока мы использовали RTSP адрес. Сервер забрал RTSP поток и сконвертировал его в Websockets для iOS Safari.



Интеграция плеера для iOS Safari в веб страницу



Исходный код плеера доступен здесь. Однако плеер по ссылке работает не только для iOS Safari. Он может переключаться между тремя технологиями: WebRTC, Flash, Websockets в порядке приоритета и содержит немного больше кода, чем требуется для воспроизведения в iOS Safari.



Попробуем минимизировать код плеера чтобы продемонстрировать минимальную конфигурацию, которая будет играть в iOS Safari



Минимальный код HTML-страницы будет выглядеть так: player-ios-safari.html









The player








Из этого кода видно, что главный элемент на странице — это div-блок





Именно этот блок будет отвечать за воспроизведении видео, после того как скрипты API вставят туда HTML5 Canvas.



Далее идет скрипт плеера. Объем скрипта: 80 строк: player-ios-safari.js



var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS;
var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS;
var remoteVideo;
var stream;

function init_page() {

//init api
try {
Flashphoner.init({
receiverLocation: '../../dependencies/websocket-player/WSReceiver2.js',
decoderLocation: '../../dependencies/websocket-player/video-worker2.js'
});
} catch(e) {
return;
}

//video display
remoteVideo = document.getElementById("remoteVideo");
onStopped();
}

function onStarted(stream) {
//on playback start
}


function onStopped() {
//on playback stop
}

function start() {

Flashphoner.playFirstSound();

var url = "wss://wcs5-eu.flashphoner.com:8443";

//create session
console.log("Create new session with url " + url);
Flashphoner.createSession({urlServer: url}).on(SESSION_STATUS.ESTABLISHED, function(session){
setStatus(session.status());
//session connected, start playback
playStream(session);
}).on(SESSION_STATUS.DISCONNECTED, function(){
setStatus(SESSION_STATUS.DISCONNECTED);
onStopped();
}).on(SESSION_STATUS.FAILED, function(){
setStatus(SESSION_STATUS.FAILED);
onStopped();
});

}

function playStream(session) {
var streamName = "12345";
var options = {
name: streamName,
display: remoteVideo
};

options.playWidth = 640;
options.playHeight = 480;

stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {
setStatus(stream.status());
onStarted(stream);
}).on(STREAM_STATUS.STOPPED, function() {
setStatus(STREAM_STATUS.STOPPED);
onStopped();
}).on(STREAM_STATUS.FAILED, function() {
setStatus(STREAM_STATUS.FAILED);
onStopped();
});
stream.play();
}

//show connection or remote stream status
function setStatus(status) {
//display stream status
}


К наиболее важным частям этого скрипта можно отнести инициализацию API




Flashphoner.init({
receiverLocation: '../../dependencies/websocket-player/WSReceiver2.js',
decoderLocation: '../../dependencies/websocket-player/video-worker2.js'
});




При инициализации подгружается еще два скрипта:




  • WSReceiver2.js

  • video-worker2.js



Эти скрипты являются ядром вебсокет плеера. Первый отвечает за доставку видеопотока, а второй за его обработку. Скрипты flashphoner.js, WSReceiver2.js и video-worker2.js доступны для скачивания в сборке Web SDK для Web Call Server и обязательно должны быть подключены для воспроизведения потока в iOS Safari.



Таким образом имеем следующие обязательные скрипты:




  • flashphoner.js

  • WSReceiver2.js

  • video-worker2.js

  • player-ios-safari.js



Установка соединения с сервером происходит с помощью следующего кода:



Flashphoner.createSession({urlServer: url}).on(SESSION_STATUS.ESTABLISHED, function(session){
setStatus(session.status());
//session connected, start playback
playStream(session);
}).on(SESSION_STATUS.DISCONNECTED, function(){
setStatus(SESSION_STATUS.DISCONNECTED);
onStopped();
}).on(SESSION_STATUS.FAILED, function(){
setStatus(SESSION_STATUS.FAILED);
onStopped();
});

}


Непосредственно воспроизведение видеопотока осуществляется с помощью метода API createStream().play(). При воспроизведении видеопотока в div-элемент remoteVideo будет встроен HTML-элемент Canvas, в котором будет происходить рендеринг видеопотока.



function playStream(session) {
var streamName = "12345";
var options = {
name: streamName,
display: remoteVideo
};

options.playWidth = 640;
options.playHeight = 480;

stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {
setStatus(stream.status());
onStarted(stream);
}).on(STREAM_STATUS.STOPPED, function() {
setStatus(STREAM_STATUS.STOPPED);
onStopped();
}).on(STREAM_STATUS.FAILED, function() {
setStatus(STREAM_STATUS.FAILED);
onStopped();
});
stream.play();
}


Мы захардкодили в коде две вещи:

1) Урл сервера



var url = "wss://wcs5-eu.flashphoner.com:8443";


Это публичный демо-сервер Web Call Server 5. Если с ним что-то не так, вам нужно установить свой для тестирования.



2) Название потока для воспроизведения



 var streamName = "12345";


Это название видеопотока, который мы воспроизводим.

В случае, если это поток с RTSP IP-камеры, его можно прописать так



var streamName = "rtsp://host:554/stream.sdp";


Самая неприметная, но очень важная функция



Flashphoner.playFirstSound();




На мобильных платформах, в частности на iOS Safari есть ограничение Web Audio API, которое не дает проигрывать звук из динамиков до тех пор, пока пользователь не щелкнет пальцем по какому-либо элементу web-страницы. Поэтому при нажатии кнопки Start мы вызываем метод playFirstSound(), который играет короткий кусок сгенерированного аудио, чтобы видео в итоге могло играть с аудио.



В конечном итоге наш кастомный минимальный плеер, состоящий из четырех скриптов и одного HTML файла player-ios-safari.html выглядит так:




  • flashphoner.js

  • WSReceiver2.js

  • video-worker2.js

  • player-ios-safari.js

  • player-ios-safari.html





Скачать исходный код плеера можно здесь.



Таким образом, мы рассказали о текущих альтернативах WebRTC для iOS Safari и разобрали пример с реалтайм-плеером с передачей видео по технологии Websockets. Возможно он поможет кому-то дождаться прихода WebRTC на Safari.



Ссылки



Пресс-релиз — Apple выкатывает WebRTC для Safari

Websockets — RFC6455

WebGL — спецификация

Web Call Server — WebRTC-сервер, который может конвертировать поток в Websockets для воспроизведения на iOS Safari

Установка WCS — скачать и установить

Запуск на Amazon EC2 — запуск готового образа сервера на Amazon AWS

Исходный код — пример плеера: player-ios-safari.js и player-ios-safari.html

Web SDK — web API для сервера WCS, содержащее скрипты flashphoner.js, WSReceiver2.js, video-worker2.js
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325978/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Фото-реалистичная графика в мобильной игре или первая в мире «видео»-игра

Суббота, 08 Апреля 2017 г. 15:27 (ссылка)

Видеоигра, согласно википедии — игра с использованием изображений, сгенерированных электронной аппаратурой.



image



В нашем же случае, "видео"-игра — это видеоигра, основанная на реальном видео.





Если же вы посчитаете этот заголовок слишком жёлтым и существует "видео"-игра в нашем понимании, сделанная раньше — напишите об этом в комментариях и я поправлю заголовок. На тот момент мы не нашли и не вспомнили аналогичных игр.



Статью нельзя уже посчитать и рекламой, т.к. с момента разработки и публикации игры прошло уже столько времени, что мой аккаунт разработчика истёк и игра не доступна больше в Apple AppStore.



В статье я расскажу о процессе подготовки игры и об особенностях работы с видео в IOS и Android на Adobe AIR.



Всё началось светлым солнечным майским питерским утром. Хотя нет, такого не бывает. Всё началось сильно во второй половине обычного майского дня, когда небо было закрыто облаками и мы выехали снимать видео.



image



Представлюсь, мы — это два разработчика: Андрей — серверный программист, далёкий от разработки игр, который, собственно, и задумал сделать игру и Фёдор — профессиональный гейм-программист, который помогал в съёмке видео и советами по разработке.



Хотя, нет, всё началось раньше. Как-то в голову пришла идея сделать игру, основанную на реальных видео-съёмках. При этом, видео должно было быть интерактивно привязано к игре. Видео должно было быть красивым. Игра — одновременно интересной, развлекательной и простой. Так родилась идея PiterJump и дальше всё завертелось.







Подготовка к съёмке



Был написан скрипт, который по полному списку улиц Санкт-Петербурга (названия улиц нормализовались: пр. — проспект, ул. — улица и т.д.) делал запросы (вида Санкт-Петербург "Невский проспект") в Google, получал количество результатов и таким образом был составлен рейтинг известности улиц.



Планировалось для игры использовать съёмку именно этих улиц, предполагая, что раз улица более известная, то она и более интересная. Идея оказалась несостоятельной. Список сохранился для истории, привожу его начало (сортировка по убыванию "известности").




































Количество результатов Название
313000000 Российская ул.
244000000 18-я линия ВО
170000000 Санкт-Петербургский пр.
139000000 19-й проезд
59400000 Ленинградская ул.
56000000 Культуры ул.


Как видно, особенно жителям города, улицы не самые значимые. Например, Невский проспект, пожалуй, самый известный центральный проспект Санкт-Петербурга — находится на 273м месте рейтинга с 3,8 млн. результатов.



Пришлось идти по простейшему пути — использовать съёмку центра города.



Составили маршрут (карта центальной части Санкт-Петербурга на 8 листах А4)



image



Проехали по нему один раз с записью трекинга в навигатор



image



Длина полученного маршрута — 30 километров.



Подготовка видео



Итак, мы выбрали светлый день, но и так, чтобы не было яркого солнца, для равномерного освещения.



Зарядили аккумуляторы, запаслись кассетами.



Взяли камеру (Canon XH A1), штатив, установили, зафиксировали.



image



Спецзнак



image



Во время съёмок



image



В планах было снять около 30 минут красивого видео, легко нарезать его на куски и сделать уровни для игры. Реальность оказалась жестокой.



Видео получилось так много, что пришлось по пути покупать дополнительную кассету. Суммарно мы получили 1 час 40 минут видео.



Красивые виды из окна оказались не такими красивыми на видео, как их видел глаз.



На видео получилось просто невероятно много неинтересных моментов, которые нужно было вырезать и получить в итоге около 40 минут геймплея.



Ошибки начинающих операторов



Слишком быстрая скорость поездки при съёмке. Я старался ехать со скоростью около 30-40 км./ч. Оказалось, что это слишком быстро и дало несколько недостатков видео.



Во-первых, когда тротуар находится близко к проезжей части — относительная скорость пешеходов получается слишком быстрой, что приводит к тому, что не хватает скорости реакции, чтобы их перепрыгнуть. В процессе игры пришлось учитывать этот момент и делать авто-прыжок.



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



Неправильный выбор точки для съёмки. Центр Санкт-Петербурга состоит из машин.



image



Точнее из машин-машин-машин. Все улицы, улочки, переулки заставлены машинами. С недавнего времени город немного цивилизуется в этом направлении, вводятся платные парковки. Но на тот момент, что было, то было. Да, камера была установлена довольно высоко, но недостаточно. В итоге на видео местами получилось почти непрерывная череда машин, вместо красот Санкт-Петербурга, домов и людей. В идеале, снимать нужно было на той же высоте, что и машины, которые снимают панорамы Яндекса/Гугла.



Написание игры



Сначала, по совету, я думал написать игру на Unity (тогда ещё Unity3D). Но у Unity нашёлся фатальный недостаток. После многочисленных экспериментов, оказалось, что на мобильных устройствах не поддерживается наложение на объект видео как текстуры. Нашлись плагины, которые это поддерживали. Но один был платный, второй — воспроизводил разбитое на картинки видео и при большой длительности "видео" давал непригодную для игры частоту кадров.



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



Как пришло в голову использовать Adobe AIR — уже не помню. Я неплохо знал флэш (ни до, ни после не видел такого удобного графического/анимационного редактора), ActionScript 2.0/3.0, но про AIR слышал только слухи — есть де такая технология под мобильные.



А вы знали, что Adobe, несмотря на закат flash, до сих пор регулярно выпускает новые версии AIR, существует коммьюнити (и далеко не 1.5 человека), которое пишет различные плагины для AIR, существуют интеграции под основные мобильные технологии типа встроенных покупок под Apple/Google, все необходимые интеграции под игровые платформы Google/Apple?



Вооружившись Flash Develop + FLEX + AIR SDK мы начали новые тесты. Видео завелось на удивление легко — достаточно было установить настройку ренедеринга с помощью GPU. Позднее рендеринг пришлось поменять на "Direct", т.к. GPU не поддерживал наложение на видео изображений с альфа-каналом.



Для отображения видео в AS 3.0 используется техника загрузки видео в Stage. Документация и примеры не всегда очевидны и заработали не сразу, но в целом, всё довольно просто.



Устанавливается обработчик события, что StageVideo доступен



main.main_stage.addEventListener(StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY, init_video);


Ппосле проверки доступности StageVideo вызывается коллбэк init_video



public function init_video(e:StageVideoAvailabilityEvent):void


В котором создаётся объект стриминга видео из сети/файла



var nc:NetConnection = new NetConnection();
nc.connect(null);

ns = new NetStream(nc);
ns.client = this;


При доступности StageVideo (на IOS, части Android) создаём объект, привязываем объект стриминга



stageVideoAvail = (e.availability == StageVideoAvailability.AVAILABLE);

if (stageVideoAvail)
{
sv = main.main_stage.stageVideos[0];
sv.addEventListener(StageVideoEvent.RENDER_STATE, onRender);
sv.attachNetStream(ns);
}


При недоступности (на части Android, на эмуляторе на PC) создаём обычный объект видео



video = new Video(Data.video_width, Data.video_height);
video.y = int(Data.height / 2 - Data.video_height / 2);
addChildAt(video, 0);
video.attachNetStream(ns);


Далее запускается поток на воспроизведение



var fl:File = File.applicationStorageDirectory.resolvePath(quality + "/level_" + level + ".mp4");
ns.play(fl.url);


При этом, нужно задать ViewPort, без которого видео не отображается в режиме StageVideo



public function onRender(e:StageVideoEvent):void
{
sv.viewPort = new Rectangle(0, Data.height / 2 - Data.video_height / 2, Data.video_width, Data.video_height);


При работе с видео в AIR нужно учитывать, что компилировать флэшку нужно или в режиме "Software rendering" — для тестирования на PC в режиме эмулятора. Или в режиме "GPU rendering" — работает на IOS, но не поддерживает наложение изображений с альфа-каналом (видео просто пропадает), и, кажется, нормально работает на Android. Или в режиме "Direct rendering" — работает на IOS, но, вероятно, даёт большее энергопотребление.



Во время разработки прототипа геймплея, рефакторинга, альфа-версии — на хабре тогда очень удачно появилась статья, в которой было упоминание некоего Adobe Gaming SDK.



Это пакет предоставляет разработчику множество полезных наработок для мобильных игр. Интерфейс, доступ к нативному IOS/Android API, свой 2D и 3D движки.



На то время уже была готова альфа-версия игры и снова рефакторить игру под использование готовых компонентов 2D движка уже не было смысла, поэтому я взял только плагины нативных функций IOS доступа к game center и product store. Плагины в AIR реализованы в виде неких готовых упакованных модулей ANE (AIR Native Extensions) — которые представляют собой обычные zip архивы, содержащие xml файлы (описывающие пространство имён и интерфейсы доступа) и упакованные откомпилированные swf-файлы.



После реализации основного функционала отображения видео, без которого нельзя было делать игру — всё остальное не представляло особой сложности: нарисовать простую графику, расставить во флэше, сделать анимацию встроенными средствами, написать различных классов "бизнес-логики" игры и отправить на утверждение в Apple AppStore.



Итоги



На момент написания игры я думал, что вот уже скоро пойдёт поток скачиваний, придётся добавлять сервера (видео подгружалось в игру на лету, т.к. занимало порядка 3 ГБ суммарно в различном качестве), пойдут деньги (в игру были встроены покупки: первые 4 уровня — бесплатные, чтобы перейти к остальным — 1 доллар), начнутся разработки дальнейших MoscowJump, ParisJump, New-YorkJump, будет возможность людям самим снимать на телефон и добавлять новые уровни, другие будут в них играть, ставить оценки, обмениваться комментариями и игра превратится в некий социальный аналог недавней игры про покемонов.



На самом деле, я так, конечно, не думал. Я видел все недостатки игры. Для запуска игры сейчас (пусть даже с неким новым игровым подходом) — требуются деньги, продвижение. Сама игра должна быть лучшего качества, в игру должны быть встроены интересные фишечки, графика немного получше, видео покачественнее.



А пока, как итог, скажу, что Adobe AIR + Flash — хоть и забытая сейчас, но неплохая технология, с помощью которой можно легко делать мобильные игры даже непрофессионалам.



Для истории я опубликовал полный геймплей, полное видео всех уровней игры на youtube, может, кто себя узнает на видео :) и перенёс исходный код из приватного репозитория на github.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325982/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
SoftLabirint

Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC » SoftLabirint.Ru: Скачать бесплатно и без регистрации - Самые Популярные Новости Интернета

Вторник, 29 Марта 2017 г. 01:20 (ссылка)
softlabirint.ru/games/eroig...engpc.html


Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC

Посетители сайта SoftLabirint.Ru – Представляем вам полные версии эксклюзивной коллекции игр от студии christiesroom. Вас ожидает большое разнообразие игр симуляторов и море удовольствия...

 



Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC



Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC



Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC






Системные требования:

- Операционная система: Windows XP / Vista / 7 / 8 / 10

- Процессор: Pentium 2 GHz

- Оперативная память: 1 GB

- Видео-карта: 512 MB

- Свободное место на диске: 2 GB



Год выхода: 2012-2017

Жанр: Sex games, Erotic quest

Цензура: Отсутствует

Разработчик: christiesroom

Издательство: christiesroom

Платформа: PC

Тип издания: Пиратка

Язык игры: Английский

Язык интерфейса: Английский

Таблэтка: не требуется

Размер: 1.49 GB



Скачать: Christie’s Room - Коллекция флеш-игр / Christie’s Room - Flash Games Collection (2017) ENG/PC >>>



 





Не пропустите








 

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<flash - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda