Как записать поток ethernet

Обновлено: 05.07.2024

Видео по сети используют не только интернациональные компании. С появлением новых продуктов и программного обеспечения полноценное видео может получать и ваша настольная система. БАЗОВОЕ ВИДЕО: КАДРЫ И ПИКСЕЛЫ НА МАЗИ ПЕРЕДОВОЕ ВИДЕО: ДА ЗДРАВСТВУЕТ КОДЕК! ATM ИЛИ IP?

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

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

БАЗОВОЕ ВИДЕО: КАДРЫ И ПИКСЕЛЫ

Мир видео может быть разделен на две части. Во-первых, это видео реального времени, когда запись осуществляется одновременно с ее просмотром. Видеоконференции классический тому пример. Типичным источником видео реального времени являются небольшие камеры с зарядовой связью (Charged Coupled Device, CCD), например QuickCam производства Connectix. В зависимости от мощности настольного ПК эти небольшие камеры (обычно размещаемые над монитором) осуществляют съемку с частотой от 5 до 30 кадров в секунду, причем последняя величина соответствует нормальному качеству вещания. Разрешение видео реального времени может меняться в значительных пределах от крупных изображений, требующих большей пропускной способности, но более подходящих для нормального общения, до небольших "почтовых марок", вмещающих только говорящую голову.

Во-вторых, это потоковое видео, известное так же, как видео по запросу, когда предварительно записанные "фильмы" или другие источники видео хранятся на сервере и запрашиваются приложением конечного пользователя, например модулем расширения браузера Web или выделенным видеоклиентом. Потоковое видео воспроизводится при получении.

Ориентированное на массового потребителя программное обеспечение видеоконференций, такое как CU-SeeMe от White Pine Software, заполняет изображением лишь часть экрана с разрешением 640*480 пикселов, как правило, одну четвертую (320*240 пикселов) или одну шестнадцатую (160*120 пикселов). Другое программное обеспечение, например системы видеоконференций NetMeeting компании Microsoft или LiveLAN компании PictureTel, использует общий промежуточный формат (Common Intermediate Format); CIF, иногда называемый Full CIF (FCIF), определяет окно размером 352*288 пикселов.

Стандартными производными этого формата являются Quarter CIF (QCIF, 176*144 пикселов) и Subquarter CIF (SQCIF, 128*96 пикселов), т. е. реально экран в одну девятую экрана CIF. Стандарты видеоконференций, такие как H.261 для сжатия видео, разрабатывались с учетом форматов CIF, QCIF, SQCIF, 4-CIF (704*576 пикселов) и 16-CIF (1408*1152 пикселов).

Используемая глубина цвета имеет зачастую более важное значение, чем размер изображения. Глубина цвета колеблется в диапазоне от 256 (8 бит на пиксел) до миллиардов цветов (32 бит на пиксел). В Таблице 1 приводятся наиболее распространенные размеры изображений с указанием глубины цвета, а также минимально необходимой пропускной способности при передаче несжатых данных. Пропускная способность варьируется в широких пределах - от 768 Кбит/с для небольших дергающихся картинок до свыше 221 Мбит/с для полноэкранных изображений с хорошим разрешением.

ТАБЛИЦА 1. НЕОБХОДИМАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ ДЛЯ НЕСЖАТОГО ВИДЕО

НА МАЗИ

Стоящая перед видеосервером задача далеко не проста. В отличие от простого файлового сервера, он должен поставлять непрерывный поток информации, причем этот поток должен быть по своим характеристикам достаточно равномерным. В отличие от сервера транзакций, такого как сервер Web, видеосервер предоставляет файлы размером в мегабайты. Кроме того, ему приходится обслуживать множество видеопотоков одновременно, в некоторых случаях это одни и те же файлы (но на разных стадиях передачи). Как таковому, видеосерверу необходим мощный ЦПУ и высокоскоростная шина.

Всего несколько производителей предлагают сетевое программное обеспечение видеосервера. Starlight Net-works продает семейство программных видеосерверов для Windows NT Server, Solaris, HP-UX и AIX в сетях IP. Продукт Starlight под названием StarWorks 3.2 для потокового видео способен предоставлять 150 Мбит/с с Windows NT

и поддерживать до 100 видеосеансов. Для доступа к системе клиенты используют браузеры Web с модулем расширения StarWorks. Сопутствующий продукт StarCast обеспечивает многоадресную передачу мультимедиа по IP от аналоговых и цифровых источников. Оба продукта понимают форматы MPEG-1 и Indeo.

Web Theater Server компании VXtreme, оптимизированный для работы в сети, но могущий работать и через модем со скоростью 28,8 Кбит/с, также использует модули расширения браузера на стороне клиента. Последняя версия, 2.2, может передавать видео в формате CIF по соединению на 56 Кбит/с. По утверждению VXtreme версия Windows NT 4.0, установленная на сервере с одним процессором Pentium 90 МГц с оперативной памятью емкостью 64 Мбайт, способна поддерживать до 25 видеопотоков; сервер с четырьмя процессорами Pentium Pro на 200 МГц может обслуживать до 500 видеопотоков. Web Theater Server работает также и под управлением UNIX (на Solaris и IRIX).

Другое решение для видеосерверов, CU@Work компании White Pine, предназначено главным образом для проведения настольных видеоконференций, - это сетевая версия популярного программного обеспечения CU-SeeMe для видеообщения по Internet. Базовый вариант CU@Work - сервер на 50 пользователей с 25 клиентами на основе IP Multicast. Последнее предложение компании, Meeting Point, - более надежный сервер, опирающийся на стандарты H.323 и T.120. Выполняется он на серверах Windows NT, Solaris, IRIX и HP-UX. Meeting Point взаимодействует с клиентами на базе H.323 (о них мы поговорим позднее), а не только с клиентами CU-SeeMe. (Дополнительную информацию о T.120 смотри во врезке "T.120: суперстандарт" .)

Если Windows NT ваша основная платформа, то NetShow 2.0 компании Microsoft устанавливается в качестве сервиса (он включается также в состав комплекта SiteServer) и предоставляет потоковое видео по коммутируемым или сетевым соединениям. Дополнительная функция, NetShow FSV (Full Screen Video), позволяет передавать видео MPEG-1 или MPEG-2 по коммутируемому Ethernet и ATM; в настоящее время клиент поддерживает только MPEG-1. По утверждению Microsoft максимальная скорость, с которой NetShow FSV может подавать потоковое видео через сетевую плату Ethernet на 100 Мбит/с, составляет 80 Мбит/с, а всего он может обслуживать около 40 потоков. В случае сетевой платы ATM на 155 Мбит/с скорость потокового видео достигает 100 Мбит/с, а число одновременно обслуживаемых потоков - 50.

Один из наиболее интересных вопросов - дисковая подсистема. Многие производители видеосерверов настоятельно рекомендуют, главным образом для улучшения скорости передачи, использовать дисковую подсистему RAID-5. Крупные системы RAID обеспечивают лучшие характеристики, чем типичные для чередования RAID; они, например, имеют большой аппаратный кэш. Небольшие же серверы могут опираться на обычные адаптеры SCSI для выполнения функций RAID, а функции чередования и избыточности осуществляться серверной ОС.

Жесткий диск типичного сервера с кэшем 512 Кбайт способен обслуживать до 5 Мбайт/с - эта величина намного меньше скоростей передачи данных, приводимых производителями накопителей, но они обычно указывают максимальную скорость пакетной передачи, достигаемую на внешних дорожках накопителя.

Новое поколение так называемых "аудио/видеодисков" намного превосходит скорости прежних, например Tomahawk AV на 9,1 Гбайт компании Mic-

ropolis вращается со скоростью 7200 оборотов в минуту. По словам Сэма Сойера, менеджера линии продуктов в Micropolis, средняя скорость передачи данного продукта 6,5 Мбайт/с, а максимальная - около 10,5 Мбайт/с. Диски, подобные Tomahawk со встроенным кэшем на 2 Мбайт, намного превосходят производительность систем RAID-5 младшего класса. Однако Сойер считает, что системы RAID-5 с большим аппаратным кэшем (скажем, от 20 до 30 Мбайт) не в силах извлечь аналогичные преимущества из данных накопителей. Если у вас есть такой контроллер, то он рекомендует установить менее дорогие накопители с меньшим встроенным кэшем.

ПЕРЕДОВОЕ ВИДЕО: ДА ЗДРАВСТВУЕТ КОДЕК!

Наихудшая ситуация в случае цифрового видео - когда видео передается в несжатом виде, например 30-кадровое изображение в формате QCIF требует пропускной способности 12 Мбит/с. Но это довольно редкая ситуация, поскольку цифровое видео упаковывается (сжимается) кодеками (сокращение от английского compressor/decompressor). С помощью разнообразных схем кодирования, применение которых зависит от вычислительной мощности, доступной пропускной способности и требуемого качества видеоизображения, необходимая пропускная способность может быть уменьшена до приемлемого уровня. Однако помните: любая схема сжатия не лишена недостатков. Например, накладные расходы на сжатие могут оказаться непомерными для снабженных видеокамерой старых ПК с 486-м процессором. Видеоприложения поддерживают, как правило, несколько кодеков - в основном, посредством подключаемых модулей. Некоторые кодеки, такие как MPEG-2, предназначены для обработки потокового видео; они относительно легко поддаются распаковке, но сжатие способен осуществить только достаточно мощный ЦПУ.

Одним из последних кодеков для видео в реальном времени является RealVideo. Он встроен в видеосистему RealPlayer компании Progressive Net-work. CU-SeeMe компании White Pine Software использует Motion JPEG, или M-JPEG, для соединений по локальной сети либо ISDN.

Кодеки также бывают стандартными, например видеокодек H.263 поддерживается несколькими системами для проведения конференций от PictureTel и Intel. Имеются и отдельные аудиокодеки, наиболее распространенными среди которых являются MPEG уровня 3 группы MPEG и G.723 от ITU-T.

Выбор кодека зависит от того, какая пропускная способность необходима и какое будет видео - по запросу или в реальном времени. Многие видеосерверы и клиенты работают с различными кодеками. По этому поводу Гайлз говорит следующее: "Утверждения типа MPEG-2 лучше, чем H.263, абсолютно беспочвенны в отрыве от контекста. В определенных условиях каждая технология способна проявить себя наилучшим образом".

Например, MPEG-1 предназначался для работы со скоростью 150 Кбайт/с, с разрешением 320*240 пикселов при частоте 30 кадров/с; MPEG-2 - со скоростью от 400 до 800 Кбайт/с с видео телевизионного качества. H-263 разрабатывался под медленные модемы со скоростью порядка 10 Кбайт/с и разрешением 160*120 пикселов (частота кадров зависит от требуемого качества воспроизведения).

Потоковое видео от видеосерверов налагает специальное требование: видеофайл должен быть записан в формате, который не только сжат при записи, но и оптимизирован для просмотра на клиенте в процессе его передачи. Прежние форматы цифрового видео, такие как MPEG-1 и Quick-Time, разрабатывались с учетом вышесказанного. Microsoft продвигает новый формат - Action Streaming Format, благодаря которому потоковое видео передается более равномерно. Дополнительную информацию об ASF смотри во врезке "Активный потоковый формат" .

ATM ИЛИ IP?

Один из наиболее актуальных вопросов относительно видео по сети состоит в следующем: достаточно ли Ethernet с IP или лучше сразу переходить к ATM? Во многих ситуациях это вопрос столь же вкуса, сколь и техники, поскольку потоковые мультимедиа и видео в реальном времени совместимы и с IP, и с ATM. Ввиду значимости этого вопроса и последствий его решения не только для мультимедиа, мы рассмотрим те особенности ATM и IP, которые имеют непосредственное отношение к передаче высококачественного видео.

архитектура ATM подходит естественным образом для сетевого мультимедиа в силу своих трех основных и одной побочной особенностей. Во-первых, коммутируемые виртуальные соединения (Switched Virtual Circuit, SVC) позволяют создавать высокоскоростные соединения между узлами по необходимости, например между двумя участниками видеоконференции или между видеосервером и клиентом.

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

В-третьих, это стандарт Multiprotocol over ATM (MPOA). Активно продвигаемый Cisco, Fore Systems и Newbridge Network, MPOA является в настоящее время первым стандартом для коммутации третьего уровня в сети. MPOA расширяет эмуляцию ЛС на втором уровне за счет создания виртуальных соединений практически со скоростью линии через несколько подсетей. По сути MPOA решает ту же самую проблему, что и так называемая IP-коммутация (которую мы тоже обсудим), с тем только отличием, что производители пришли к согласию относительно MPOA - стандарт был одобрен ATM Forum в июле прошлого года.

В-четвертых, многие операторы свя-зи имеют магистрали ATM; AT&T, MCI и Sprint предлагают сервисы на 155 Мбит/с, а некоторые другие собираются модернизировать свою магистраль до ATM на 622 Мбит/с. В корпоративной среде ATM находит основное применение на магистрали; лишь немногие компании прокладывают ATM до настольных систем или даже до коммутатора рабочей группы/отдела. Ethernet и IP доступны на несравнимо большем числе настольных систем, и, таким образом, они охватывают все предприятие. IP - это стандартный протокол Internet, и, как таковой, он естественным образом используется для транспортировки видео по Internet и виртуальным частным сетям на базе IP. Но, в отличие от ATM, Ethernet не имеет стандартных средств для обеспечения качества услуг из конца в конец. По сути коммутация со скоростью линии между подсетями - иными словами, коммутация третьего уровня - застряла в трясине несовместимых разработок.

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

Протокол передачи в реальном времени (Real-time Transport Protocol, RTP) призван заменить TCP и UDP. В отличие от TCP, RTP поддерживает многоадресное распространение информации, а в отличие от UDP он предоставляет информацию о времени, необходимую для передачи в реальном времени.

Протокол управления передачей в реальном времени (Realtime Transport Control Protocol, RTCP) обеспечивает обратную связь для RTP-совместимых приложений о сети и качестве доставки, благодаря которой эти приложения могут вносить необходимые коррективы на лету.

Третьим членом этой троицы стал протокол резервирования ресурсов (Resource Reservation Protocol, RSVP), с помощью которого конечные системы (клиенты и серверы) могут резервировать сетевые ресурсы, необходимые для обеспечения качества услуг при трафике RTP. Вместе RTP и RSVP обладают многими достоинствами качества услуг ATM - по крайней мере, когда они поддерживаются из конца в конец во всей сети. (Подробное обсуждение этих протоколов смотри в статье "RTP и RSVP: доставка в срок" в сентябрьском номере журнала за прошлый год.)

Короче говоря, когда дело касается передачи видео по сети, преимущества АТМ очевидны. Качество услуг встроено в этот протокол, и, таким образом, все устройства ATM, а также накопленный опыт в обеспечении качества услуг и жесткая конкуренция между производителями привели к оптимизации его характеристик. Щднако, многие из функций АТМ появляются одна за другой и у Ethernet/IP. Если вы готовы подождать, то переходить от Ethernet к ATM - как в случае решения от одного поставщика, так и собранного по частям - не имеет смысла, во всяком случае, ради поддержки видео в сети. Если вам этот вариант не подходит, ну что ж, тогда ATM - лучшее, что есть.

КАК ПОЛУЧИТЬ КАРТИНКУ?

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

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

СТАНДАРТ КАК ОН ЕСТЬ

T.120: суперстандарт

Стандарт разбит на несколько уровней. Верхний уровень составляют два протокола для приложений по проведению конференций: Т.126 для обмена и редактирования неподвижных изображений идельно подходит для электронных досок, а T.127 - для передачи любых типов двоичных файлов во время конференции.

Нижние уровни стандарта обеспечивают непосредственное проведение конференции. T.123 включает специфические сетевые транспортные протоколы для телефонной связи, ISDN и цифровых сетей с коммутацией каналов и пакетов. Вместе T.122 и T.125 определяют базовые программные сервисы и сам протокол передачи данных. T.125 описывает способ взаимодействия между приложениями, использующими протоколы T.126 и T.127. Стандарт управления конференцией T.126 позволяет организовать и проводить конференцию, вести учет приложений и узлов, обеспечивать защиту, а также он описывает "дирижера", или менеджера конференции.

Родственный стандарт, T.121, не являющийся частью базового стандарта T.120, определяет типичный шаблон приложения. Шаблон приложения предназначен для улучшения согласованности и взаимодействия T.120-совместимых приложений.

Семейство стандартов T.120 далеко от завершения. Так, ITU-T собирается стандартизовать поддержку ATM, frame relay и других технологий глобальных сетей. Другая группа ITU-T работает над T.130 - в настоящее время представляющий собой ряд рекомендаций, касающихся аудио/визуального управления мультимедийными конференциями. T.130 может использовать различные механизмы конференций, в том числе T.120 для поддержки конференций с обменом данными между несколькими участниками и H.320 для аудио/видеоконференций на базе ISDN.

АУДИО/ВИДЕО ФОРМАТ БЕЗ ПЕРЕРЫВОВ

Активный потоковый формат

Active Streaming Format (ASF) - это новый формат файлов, предложенный Microsoft. Он призван обеспечить потоковую доставку и синхронизированное воспроизведение различных типов мультимедийных файлов, в том числе видео, анимации, графики, аудио, MIDI-музыки и текста.

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

Другая функция ASF - масштабируемость воспроизведения. Файл ASF может иметь базовый поток, обеспечивающий минимальное качество, и дополнительные потоки с лучшим качеством - на случай, если клиент способен обрабатывать дополнительные данные, а сеть обладает достаточной пропускной способностью. Взаимоотношения между различными воспроизводимыми потоками могут быть гораздо более сложными; например, если клиент выбрал определенный язык, текст, звук или даже графику, то этот поток будет посылаться, а все потоки с другими языками нет.

Собственно захват сетевого трафика – это первый шаг при любом анализе трафика на предмет как производительности, так и безопасности. Не так много специалистов полностью осознают, насколько критичен этот шаг и на какие неожиданные грабли (вплоть до безнадежно испорченного дампа) можно наступить, если не подойти к данному процессу с полным осознанием. На SharkFest 2016 я говорил о том, насколько важен сам процесс захвата и подготовки к нему, и теперь я решил создать серию статей, описывающих оптимальный подход к захвату. Итак, начнем с начала – с самых основ по захвату трафика в проводной (wired) инфраструктуре.

Обо всем по порядку

Захват сетевого трафика может быть полезен для:

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

Насколько достоверным должен быть дамп?

Если вам все равно – захватывайте прямо на клиенте, сервере или любом другом устройстве на пути. Этот метод называется «локальным захватом», потому что пакеты захватываются на самом устройстве, когда они создаются или просто проходят сквозь него.

Для такого способа захвата характерны 2 важных момента:

  1. Его очень легко осуществить (нужен всего лишь софт захвата).
  2. Этот способ искажает реальную картину больше, чем какой-либо другой.

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

Помните те дни, когда Ethernet был всего лишь одним из многих L2-протоколов, используемых для соединения устройств? Возможно, некоторые из вас до сих пор помнят Толстый Желтый Кабель (Thick Yellow Cable), в который для подключения новых устройств нужно было (буквально) врезаться с помощью трансивера-вампира:

Но – захват трафика в то время был реально прост. Почему? Всё из-за алгоритма CSMA-CD (странно ли, что я до сих пор могу расшифровать эту аббревиатуру по памяти?) Что всё это значит? Вот что: каждый в сети видит все пакеты, которые там есть. Это общая среда передачи – и если кто-то отправляет пакет, все его могут считать, пока он путешествует по кабелю:

Как видите, «Устройство захвата» видит всё, что происходит в сети, впрочем, и все остальные устройства.

Концентратор (он же хаб)

Присоединение всех к одному длинному кабелю при помощи Т-коннекторов доставляло много неудобств. Ведь добавить новое устройство к кабелю не так и легко. Поэтому на замену способу «вскрой кабель, вставь Т-коннектор, соедини кабель снова» пришли хабы. К ним можно было уже быстро присоединять / отсоединять обратно любое устройство. Но суть не менялась – хаб просто отправлял полученный пакет во все остальные порты. Просто рай для захвата. Кстати, даже сейчас, годы спустя, иногда хаб можно встретить в действующей сети, хотя давно пора было бы его заменить на коммутатор:

Общая среда Ethernet начинала испытывать проблемы с увеличением числа узлов сети, когда пакетов становилось больше и больше. Коллизии случались так часто, что заметно портили производительность – есть мнение, что из общей среды можно было «выдавить» 30-40% максимально возможной загрузки. Кстати, у Token Ring производительность была гораздо выше, но это не был открытый и дешевый стандарт как Ethernet, поэтому догадайтесь, кто из них выжил?

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

Видите МАС-адрес назначения, который начинается с «ca:5e:00:50», и за которым следует много одинаковых 0x55? Последовательность шестнадцатеричных 55 выглядит в двоичном виде так:

Двоичный паттерн 010101010101… это преамбула Ethernet. Она используется для того, чтобы сказать «эй, я хочу передать пакет» и она может столкнуться с пакетом, который уже передается. Эту коллизию можно увидеть при захвате.

Больше скорости! С коммутаторами

Позже для того, чтобы увеличить производительность Ethernet, были созданы коммутаторы. И если хаб это как Уоки-токи, то коммутатор – это уже как полноценный телефон: вы можете и говорить, и слушать одновременно (ну.. теоретически. Обычно мужчины не могут. Женщины обычно могут. Я подозреваю, у них лучше реализована мультизадачность). Возможность говорить и слушать одновременно называется «полный дуплекс».

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

Сетевое устройство захвата не получит пакетов (сейчас мы говорим про юникаст), которые принадлежат потоку между другими узлами. А всё это просто потому, что устройство захвата – это не тот узел, которому пакеты были адресованы. А настоящий «получатель» определяется по его MAC-адресу. Но не по IP-адресу или ещё чему-то – коммутаторы это layer 2 устройства, что подразумевает работу с именно с MAC-адресами.

Использование коммутаторов вместо хабов означает, что аналитики потеряли возможность легкого доступа ко всем пакетам в сети, и никогда уже это не вернется назад. Поэтому, всем, кто спрашивает «а как захватить все пакеты в сети?» можно смело ответить: никак! (Строго говоря, можно попытаться приблизиться к чему-то подобному, но велика вероятность, что производительность сети будет при этом убита почти полностью).

Время развлечься: вопросы на засыпку

Вопрос 1. Сколько юникаст-пакетов захватит устройство захвата на коммутаторе как на рисунке 5, если оставить его включенный на какое-то время?

Неправда. Оно будет захватывать юникаст-пакеты время от времени, но только один пакет за соединение (на самом деле, по моему (переводчика) мнению, все может быть несколько сложнее, о чем я написал в своем комментарии к оригиналу статьи – прим. перев.). Причина этого в том, что коммутатор стирает записи в своем списке МАС-адресов по прошествии некоторого времени и потом изучает узлы заново. Эта функция полезна для обнаружения узлов, которые были физически переключены в другой порт. Иначе юникаст-пакеты продолжали бы попадать в старый, ранее известный порт и не попали бы к узлу в его новый порт.

Для того, чтобы изучить, в какой порт подключен узел, коммутатор отправит юникаст-пакет с неизвестным ему MAC-адресом назначения во все порты. Этот процесс называется «port flooding» или «MAC flooding». Коммутатор надеется, что узел подключен к одному из его портов, и когда ответный пакет придет назад, коммутатор изучит его source MAC-адрес и добавит себе в таблицу. А вот все последующие пакеты этого соединения уже пойдут прямо по адресу и благополучно обойдут сбоку устройство захвата, и вы ничего не увидите до следующего «port flooding».

Вопрос 2. А что произойдет, если пакеты будут продолжать отправляться для узла, которого нет, или который просто не отвечает?

Коммутатор не сможет изучить порт этого узла и продолжит рассылать юникаст-пакеты во все порты.

Вопрос 3. А если пакет проходит через другой коммутатор, в который я (устройство захвата) даже не подключен? Я смогу вообще хоть как-то захватывать трафик?

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

Понял. Давайте дальше!

Итак, что же делать, когда нам очень надо захватить трафик, а у нас коммутатор? Мы должны попросить коммутатор прислать нам копии всех нужных нам пакетов на наш порт:

На своем коммутаторе Cisco я предпочитаю использовать командную строку для той же задачи:

Коммутаторы и SPAN-порты

Когда речь идет о SPAN/port mirroring, коммутаторы бывают четырех типов:

  1. «Тупые» вообще такой функции не имеют. Они как правило очень дешевые и продаются в обычных компьютерных магазинах. Когда речь заходит о захвате трафика, в такой коммутатор все и упрется: ничего полезного из него выдавить не получится.
  2. «Устаревшие управляемые» коммутаторы. Обычно конфигурируются (при помощи Telnet), но не имеют функции SPAN – я иногда встречал подобные в больницах (3Com), и да, это был 2009 год. Мой совет: меняйте как можно быстрее.
  3. «Управляемые» коммутаторы, которые могут настраиваться через SSH или по другому протоколу. Стоят дороже, чем «тупые», в зависимости от их возможностей и функций. Я рекомендую всегда покупать только управляемые коммутаторы.
  4. Коммутаторы со вшитым SPAN-портом («hard wired monitor port»). Это коммутаторы, которые зачастую не конфигурируются, НО изначально уже имеют один из портов, настроенный как SPAN. Например, коммутатор по умолчанию зеркалирует трафик из порта 1 в порт 5.

Если вы хотите просто позахватывать трафик в домашней обстановке, я обычно рекомендую купить один из следующих управляемых портативных коммутаторов, их можно установить в разрыв линка, который вы хотите захватить (ну, или, конечно, можно такой коммутатор использовать на постоянной основе, если на нем хватает портов):

Или, если ищете что-то дешевое со вшитым зеркальным портом для захвата время от времени и даже вообще без необходимости что-то настраивать (но, конечно, все же нужно где-то взять питание по USB):

Ещё один способ захвата трафика – использовать TAP (в дальнейшем будет использоваться именно этот термин как наиболее краткий и устоявшийся – прим. перев.) ТАР – это профессиональные устройства, которые физически устанавливаются в разрыв соединения, предоставляя дополнительный выход, к которому можно подключить устройство захвата и видеть всё, что протекает через этот линк. Большое преимущество ТАР в том, что они более точны, чем обычный SPAN-порт коммутатора. Но есть у них и недостатки:

  1. Они стоят денег, в то же время, когда SPAN обходится бесплатно как встроенная функция коммутатора (ну, не совсем бесплатно, ведь это часть цены коммутатора).
  2. Для установки ТАР будет необходимо разорвать линк на время установки. Позже для снятия ТАР нужно разорвать линк ещё раз. Для обычного пользовательского ПК ничего страшного тут нет, а вот на backbone-линке, который должен работать в режиме 24/7, не всегда возможно это сделать.

Я опишу ТАР, их возможности и преимущества в одной из следующих статей, поэтому пока что оставим эту тему (последняя фраза была необходима, чтобы производители устройств ТАР и Тим О’нил не выразили мне свое недоверие 🙂 )

«Hub-out»: табу!

Когда-то был третий способ захвата трафика в коммутируемых сетях, который называется «hubbing out». Идея его заключалась в том, чтобы установить хаб в разрыв линка (по примеру ТАР) и присоединить к нему устройство захвата. Если мы внедряем хаб в сеть, наш линк вынужден перейти в режим общей среды, и тогда мы увидим все, что там происходит. Я, бывало, и сам так делал, у меня всегда был с собой 5-портовый хаб с USB-питанием. В то время (10-15 лет назад) коммутаторы со SPAN-портом были ещё не очень распространены. Сегодня я настойчиво не рекомендую пользоваться таким способом, потому что:

Заключительные слова

Начать захват трафика несложно. Хотя раньше, во времена хабов, это было вообще элементарно – каждый из узлов видел всё. Теперь, когда мы везде используем коммутаторы, нам нужны функции SPAN коммутаторов или отдельные устройства ТАР. Если ваши коммутаторы не могут зеркалировать трафик, ничего не получится без использования ТАР. В следующих статьях мы увидим, что в некоторых случаях правильная система захвата может быть достаточно сложной, со многими моментами, которые нужно иметь в виду (особенно в виртуальном окружении), но на сегодня достаточно.

В определенной степени, захват WiFi-трафика подобен захвату в общей среде, где каждый видит всё (естественно, в пределах зоны приема). Но у WiFi есть свои особенности – придется иметь дело с радиоволнами, разными каналами, мощностью сигнала, шифрованием трафика.

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

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

Чтобы подключиться к IP камере и записать видео RTSP поток нужно знать маршрут (route), то есть URL адрес, который начинается с «rtsp://».

  • rtsp://85.105.131.242:554/stream1
  • rtsp://192.168.0.167:554/user=admin_password=JUkhMFgP_channel=1_stream=0.sdp/
  • rtsp://:@79.127.101.32:554/user=admin&password=&channel=1&stream=0.sdp?

Как открыть RTSP в VLC и MPlayer

Оба этих проигрывателя поддерживают работу с потоковым видео.

В меню VLC перейдите в Медиа → Открыть URL, либо откройте окно ввода адреса с помощью сочетания клавиш Ctrl+n. Перейдите на вкладку «Сеть» и введите адрес вместе с указанием протокола.


Когда всё будет готово, нажмите кнопку «Воспроизвести».


openRTSP — клиент RTSP

IP-камеры разного качества, некоторые из них, по моему опыту, ведут себя нестабильно. Работа с их потоками RTSP требует определённого терпения.

Проект Live555 предоставляет относительно отказоустойчивую реализацию клиента RTSP, openRTSP, для получения аудио/видеопотоков RTSP через интерфейс командной строки.

Например, чтобы сохранять аудио/видео RTSP камеры в файлы в формате MP4 (также доступны AVI и QuickTime), один файл каждые 15 минут:

Эти опции означают:

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

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

Запись RTSP потока в ffmpeg

Следующий пример должен сохранить видео фрагментами по 300 секунд. (Обратите внимание, что длина клипа будет зависеть от частоты кадров на входе и выходе):

VLC с интерфейсом командной строки

У VLC есть ещё и консольный интерфейс.

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

Для непрерывной записи с разбивкой на файлы можно запустить скрипт, который завершает этот процесс vlc и запускает новый экземпляр каждые 30 минут.

Вместо того, чтобы запускать задание cron для периодического уничтожения процесса VLC, можно было бы указать VLC, чтобы он работал в течение определённого времени и затем закрылся.


Большинство стримеров начинают с камеры смартфона или веб-камеры. Но со временем всем хочется перейти на более профессиональный уровень. Но не имея базового понимания того, как работает потоковая трансляция – страшно даже пытаться. Постараемся максимально простыми словами объяснить, как это всё работает. Вплоть до пошаговой инструкции.

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

Что вам нужно для прямой трансляции:

  • Видео и аудио источник(и)
  • Энкодер видео
  • Пункт назначения
  • Стабильное интернет-соединение

1. Источники видео и аудио

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

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

  • Зеркальная камера
  • Видеокамера
  • Экран компьютера
  • Веб-камера
  • Камера PTZ
  • Камера телефона или планшета
При прямой трансляции вам необязательно иметь в вашей камере карту памяти – разве что вы хотите сделать локальную запись.

Источники звука могут поступать из микрофона-«петлички», портативного или USB-микрофона, а также из аудиофайла. Если вы пропустите сигнал микрофона через камеру, звук будет встроен в ваш источник видео, что означает, что они будут передаваться вместе по одному кабелю. Это очень распространённый и удобный способ захвата аудио.

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

Как захватить аудио и видео источники

Для того, чтобы начать потоковую передачу в Интернете, вам нужно «захватить» сигнал с ваших аудио и видео источников. Большинство видеоисточников сегодня используют выходы HDMI или SDI для внешнего подключения. Оба этих стандарта способны передавать встроенное аудио вместе с видео.

Если для трансляции вы используете компьютер с программным энкодером, то вы не можете подключить качественные камеры к компьютеру напрямую с помощью кабеля HDMI или SDI. Вам понадобится промежуточное устройство, называемое картой захвата или фрейм-грабером. Карта захвата (например, AV.io HD) подключается к камере с одной стороны и к компьютеру по USB с другой, на лету оцифровывая то, что «видит» камера. Можно сказать, она преобразует видео в понятный компьютеру формат.

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

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

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

2. Энкодеры видео

Что такое энкодер и зачем он мне нужен?

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


Типы энкодеров

По сути, сегодня у вас есть выбор – использовать три типа устройств кодирования:

  • мобильный телефон / планшет
  • компьютер с установленным потоковым программным обеспечением
  • специальный аппаратный энкодер

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

Программные энкодеры

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

Доступно большое количество бесплатных и платных потоковых программ, включая Wirecast, vMix, Streamlabs OBS, популярную OBS Studio и многие другие. Вы можете узнать все о различиях между ними в нашей статье о программном обеспечении для трансляций. OBS Studio – это хорошее решение для начинающих. Программа бесплатная, все настройки достаточно просты, плюс имеется множество интерактивных руководств.

Аппаратные энкодеры

Аппаратный энкодер – это отдельное устройство, которое выполняет всё кодирование. Аудио и видео источники подключаются напрямую к аппаратному энкодеру, карты захвата не требуются. Современные энкодеры способны принимать несколько входных форматов видео, включая HDMI, SDI, VGA и DVI, а также XLR и 3,5 мм аналоговый звук. Естественно, для трансляции аппаратные энкодеры должны быть подключены к сети (через Ethernet, Wi-Fi или сотовую связь).

Аппаратные энкодеры могут быть разных форм и размеров, отличаться по функционалу и цене. Некоторые из них портативные, с возможностью подключения только одного или двух видеоисточников – например, Pearl Nano. Другие предназначены для путешествий: в них используется сотовое подключение к Интернету – например, Teradek VidiU и LiveU.

А есть гораздо более сложные и мощные, способные захватывать множество видео и аудио источников, записывать, микшировать, масштабировать и переключаться между ними – всё это в реальном времени. Например, Pearl-2 и Pearl Mini, которые является фактически профессиональными студиями «все в одном» с обширными возможностями.


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

Самые важные характеристики кодирования

И программные, и аппаратные энкодеры имеют одинаковые настройки, от которых напрямую зависит качество вашего стрим. Вот самые важные из них:

Частота кадров: сколько кадров транслируется за одну секунду (кадр/с или fps). Основные варианты:
10 fps – невероятно низкая, приводящая в ярость частота с «дёрганными» кадрами
24 fps – стандарт для кино
25 fps и 30 fps – стандарты для цифрового видео
60 fps – особенно подходит для динамичного видео, например, для трансляции спорта и компьютерных игр

Выходное разрешение: размер видеокадра, ширина и высота в пикселях. Ниже приведены самые распространённые разрешения, их характеристики и названия:

Название стандарта Размеры в писелях Сокращённое название
480p 858×480 SD или Standard Definition
720p 1280×720 HD или HD Ready
1080p 1920×1080 FHD или Full HD
1440p 2560×1440 QHD или Quad HD resolution
4K или 2160p 3840×2160 UHD или Ultra HD resolution

Сейчас в стримах чаще всего используются разрешения 720p и 1080p. Эти цифры обозначают высоту кадра в пикселях. Но «p» здесь означает «прогрессивное сканирование», а не «пиксель».

Битрейт – сколько видео данных вы загружаете в секунду. Обычно выражается в килобитах в секунду (Кбит/с), хотя используются и мегабиты в секунду (Мбит/с). Это Кбит/с, делённые примерно на 1000.

Общий диапазон значений: от 1000 до 8000 Кбит/с. Наиболее распространённые: 1000 Кбит/с (абсолютный минимум для прямой трансляции) 2500 Кбит/с, 3000 Кбит/с, 5000 Кбит/с. Это число зависит от частоты кадров и разрешения: чем выше частота кадров и разрешение, тем выше должна быть скорость передачи для плавного и качественного стрима.

Кодек: относится к способу сжатия (кодирования) аудио- и видеоданных для более быстрой передачи. Наиболее распространённым сейчас является кодек H.264.

Для качественного стрима необходим хороший баланс между битрейтом, частотой кадров и разрешением на выходе. Это во многом зависит от типа используемого энкодера и пропускной способности вашего интернета. Например, при достаточной пропускной способности интернет-канала аппаратный энкодер уровня Pearl Mini может выдавать стрим с разрешением 1080p и частотой 60 fps без пропуска кадров. В то время как старый компьютер с потоковым программным обеспечением может подвисать, отбрасывая кадры и вызывая буферизацию даже при достаточной пропускной способности.

3. Пункт назначения

Пункт назначения – это онлайн-сайт, платформа или приложение, где ваш стрим становится доступным для других. Эти пункты назначения чаще называют сетями доставки контента или CDN. Популярные бесплатные сети доставки контента (CDN) включают такие платформы, как Youtube, Facebook Live, Twitch, Periscope и многие другие.

Также есть платные потоковые платформы. Они предлагают гораздо больший контроль над тем, где и как представлен ваш стрим, кто его видит, и как он монетизируется. CDN, такие как Livestream Vimeo, DaCast, StreamShark и другие, предлагают разные ежемесячные планы. Стоимость зависит от объёма загружаемых вами данных в гигабайтах.

Бесплатно или за плату, вам нужно будет зарегистрироваться и войти в выбранную вами CDN. Некоторые платформы (YouTube) требуют от вас выполнить несколько дополнительных шагов и подождать 24 часа, прежде чем вы сможете начать прямую трансляцию.

Выбор CDN (пункта назначения)

Естественно, каждая CDN обслуживает определённую аудиторию. Определитесь, кто является вашей основной аудиторией, и выбирите подходящий CDN. Вот некоторые примеры:

  • Twitch предназначен в основном для игр.
  • Youtube (бесплатно) для многих вещей: личного, образа жизни, шоу
  • Facebook (бесплатно) предназначен для общения с вашим сообществом, а также для развития вашего бренда.
  • Более специализированные платные CDN, такие как DaCast, StreamShark и Vimeo Livestream, хороши для крупных мероприятий, таких как концерты.

Наш совет – начать с бесплатной CDN, разобраться с тем, как оно, а затем перейти к платному, если вам понадобятся дополнительные возможности и сервисы. Так что можете начать трансляцию бесплатно прямо сейчас! И обязательно ознакомьтесь с нашей статьей о том, как выбрать наиболее подходящую под ваши задачи CDN.

4. Стабильное интернет-соединение

Стабильный интернет-канал достаточной пропускной способности часто является самой сложной частью организации качественного стрима. Наиболее надёжным соединением является выделенная линия Ethernet. Конечно, вы можете использовать Wi-Fi или сотовый (4G / LTE) Интернет, но эти типы соединений имеют тенденцию к колебаниям.

Очень важно заранее выполнить тест скорости. Мы рекомендуем всегда иметь приблизительно полуторакратный запас по битрейту для компенсации этих возможных колебаний пропускной способности. Например, если вы стримите с битрейтом 5 Мбит/с, то для обеспечения надёжного стрима убедитесь, что ваш канал тянет как минимум 7,5 Мбит/с исходящего сигнала.

Да будет стрим: 5 основных шагов

По сути, рабочий процесс настройки потоковой передачи сводится к следующему:

  • подключение источников к энкодеру
  • настройка сцен (макетов) для переключения между ними в реальном времени
  • настройка параметров энкодера и пункта назначения стрима
  • установление соединения между энкодером и пунктом назначения

Естественно, пользовательские интерфейсы пункта назначения и энкодера будут отличаться, в зависимости от того, какие устройства и сервисы вы выберите. Но основной рабочий процесс останется тем же. В приведённом ниже примере мы выбрали отображение интерфейса Pearl Mini для энкодера и интерфейса Youtube для пункта назначения стрима.

Шаг 1: Подключите ваши источники аудио и видео к энкодеру

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


Шаг 2: Настройте энкодер

Если вы планируете переключаться между несколькими источниками – заранее подготовьте макеты (сцены). Затем настройте наиболее важные параметры стрима: разрешение, частоту кадров, битрейт. Если вы не уверены, начните с разрешения 1280×720, частоты кадров 30 fps и автоматической или скорости передачи данных 3000 Кбит/с. Все остальное в значительной степени можно оставить по умолчанию. В случае программного энкодера, такого как OBS, вы сможете настраивать эти параметры в приложении на своём компьютере. В случае аппаратного энкодера вам нужно будет получить доступ к настройкам устройства через веб-интерфейс или приложение. Создайте новый RTMP Push поток.


Шаг 3: Настройте параметры CDN

Войдите на платформу прямой трансляции (CDN) и настройте новое событие прямой трансляции. Заполните описание потока, настройки конфиденциальности и т. д.


Шаг 4: Найдите и скопируйте URL и имя потока / ключ из CDN и вставьте в энкодер

Это то, что на самом деле связывает ваш кодер и потоковую платформу. Чтобы узнать, где можно получить видеоданные, CDN необходимо проверить и подключиться к энкодеру, в то время как энкодер должен знать, куда отправлять данные. Это делается с помощью специального пароля, совместно используемого обеими сторонами, называемого именем стрима (или иногда ключом стрима). Имя / ключ стрима предоставляется потоковой платформой (CDN). Храните этот ключ в безопасности, так как те, кто его знает, могут вести трансляцию на ваш аккаунт.

URL и ключ стрима обычно находятся в разделах с расширенными настройками CDN или настройками энкодера. Скопируйте URL-адрес стрима (выглядит как веб-адрес) и ключ стрима из CDN в соответствующие поля в пользовательском интерфейсе энкодера. Вы можете оставить поля имени пользователя / пароля пустыми. Нажмите «Сохранить» или «Применить»


Шаг 5: Нажмите «Start Streaming» на энкодере, и вы в прямом эфире!

Как только вы нажмёте «Start streaming» где-нибудь в пользовательском интерфейсе энкодера, ваше окно предварительного просмотра CDN должно сообщить вам, что оно получает сигнал от энкодера. Как правило, между энкодером и стримом в CDN существует задержка в 10-30 секунд.


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

Заключение

Естественно, прямые трансляции в Интернет – очень широкая тема. Эта статья была задумана как очень общее начальное руководство. Тем не менее, мы надеемся, что смогли дать некоторую ясность об основах живого вещания и о том, как начать стримить на более серьёзном уровне. Понимание этих основ наряду с некоторой практикой поможет поднять ваши стримы на действительно профессиональный уровень.

Читайте также: