Pull to refresh
Comments 30
Спасибо! Очень интересная статья.
В следующей серии хотелось бы услышать о NetGroup и о методе post(), а конкретно — почему при соединении NetGroup не сразу возможно вызывать метод post()
недавнее обновление продуктов Adobe Flash Player до 10.1 и Adobe AIR до 1.5

С недавним вы загнули) Этому обновлению уже третий год) Ныне актуальны версии 11 и 3 соответственно)
Тем не менее статья у вас отличная, ждем продолжения. Я вот недавно убил не мало времени на поднятие сервера для подобных целей…
Вот это как раз самое и интересное как поднять соединения на собственном сервере, а в статье пусто.
Если локально, можно попробовать скачать исходник из статьи (ссылка в посте), установить Денвер или УСБВебсервер, залить это всё в РООТ, создать БД, настроить reg.cgi и дело в шляпе.
Нее, мой интерес глубже — расшифровка того, что возвращает в XML скрипт флешке.
| — протокол не управляется по Transmission Control Protocol (TCP) из-за его привычки повторно досылать потерянные пакеты данных, а базируется на User Datagram Protocol (UDP)

Что то не ладно в этом мире… tcp в противовес udp содержит механизмы предотвращения потери данных из-за потери пакетов и отсутствия необходимости контролировать это на верхних уровнях… а udp — нет
Для медиапотоков часто более приемлемо потерять пакеты, чем тратить время на ретрансмит.
Порадовало использование домена macromedia. Прям аж в груди защемило.
Для RTMP не обязателен Adobe Flash Media Server, есть альтернативы в виде Red5, rtmpd, Wowza и другие…

В качестве RTMFP совместимого сервиса, точнее регистратора потоков, может выступать не только FMS4 или Cirrus, мы используем простой сервис Cumulus. В нем есть ряд проблем, но для передачи видео потоков между пользователями напряму более чем подходит.

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

Из (печального) опыта использования: примерно в 10% случаев соединения не устанавливается — не может пробиться через NAT. В этом случае FP начиная с 10.2 и Adobe Flash Media Server позволяют прозрачно откатиться на обмен через сервер. В этом плане вариант с Cumulus подходит для корпоративных видеоконференций, а для широкой публики — не слишком.
Это помогает не всегда, к сожалению. Сами столкнулись с довольно распространённой траблок у клиентов — тупо подключиться к игрушкам не могли ибо в офисах злые админы всё режут :-)
Если я не ошибаюсь, то протокол закрытый и его эмулируют по reversengineering`у, так что адоб всеравно не прав.
Попробуйте erlyvideo.org — как любят говорить, отечественная разработка.
Ерли требует сервера. Не всегда это оправдано, очень часто для минимизации задержки намного удобнее быстрее и проще юзать именно RTMFP, проверено на собссной шкуре.
Так, я предлагал erlyvideo для замены Red5, rtmpd, Wowza, а не для замены протокола.
Ааа, по сравнению с ними конеш эрли рулит. Я вот после проверки всяких разных серверов в итоге к rtmpd и к ерли и пришёл, ими двумя и пользуюсь.
Вообще-то уже более года этому «новшеству», его уже даже вконтакт и прочие используют.
При этом почему-то статей о нём крайне мало. Хотя фича очень интересная. Вот любопытно, хоть когда-нибудь в HTML5 что-то подобное будет? Кстати, краем уха слышал (сейчас искать не с руки), что с 10.2 Flash Player умеет и файлы через P2P слать…
Слать впринципе через p2p можно что угодно.
Насчет HTML5 — спецификация уже довольно давно разрабатывается, но когда это появится в html5 — совершенно неизвестно. Вот, кстати, ссылка: developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication
Слать впринципе через p2p можно что угодно.
Насчет HTML5 — спецификация уже довольно давно разрабатывается, но когда это появится в html5 — совершенно неизвестно. Вот, кстати, ссылка: developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication
Как-то не освещен вопрос о досутпе к потоку посторонних лиц. Если узнать ид потока, то, как я понял, поднимая однажды свою пиринговую раздачу видео, к потоку сможет подключиться любой клиент.

В статье есть o.onPeerConnect = function(subscriberStream:NetStream):Boolean, но не сказано, откуда берется объект accept и с чего вдруг он будет знать, что кому-то можно, а кому-то нет.
На серверной стороне достаточно сделать ограничение по домену и практически ноу проблем.
accept — параметр который, я палагаю, можно взять другим методом, может отдельной проверкой по базе MySQL или как-то иначе.
Вопрос о доступе к потоку посторонних лиц будет освещён во 2-ой части про Группы пиринговых сетей и безопасность.
«недавнее обновление продуктов Adobe Flash Player до 10.1 и Adobe AIR до 1.5 версий осуществило целый фурор, презентовав новый протокол связи Real-Time Media Flow Protocol (RTMFP)»

Ээээ, собссно RTMFP аж с начала весны доступен. Мы его с конца марта юзаем как основной протокол для наших машинок, так что насчёт недавнего обновления вы немного погорячились :-)
эх, сорри, верхние комменты не прочёл, там уже аналогично высказывались
К огромному сожалению, флэш не позволяет никаким макаром с ip-камерами общаться. Так что и рад бы в текущем проекте RTMFP использовать, а не могу ибо ip-камеры. Вот и приходится с ерливидео мудрить :-(
апдейт: MJPG можно но коряво и только в AIR, а вот RTSP хрен там :-( Когда ж Адоб это наконец-то реализует
Only those users with full accounts are able to leave comments. Log in, please.