что такое медиа поток

Потоковое мультимедиа

Потоковое мультимедиа (от. англ. stream media ) — это мультимедиа, которое непрерывно получается пользователем от провайдера потокового вещания. Это понятие применимо как к информации, распространяемой через телекоммуникации, так и к информации, которая изначально распространялась посредством потокового вещания (например, радио, телевидение) или непотоковой (например, книги, видеокассеты, аудио CD).

Содержание

История

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

С конца 1980-х и до 1990-х компьютеры, доступные потребителям, уже были способны отображать различные виды информации. Основными техническими проблемами потокового вещания были:

Тем не менее, компьютеры сети оставались ограниченными, а потоковое мультимедиа уступало традиционному (CD-ROM).

В период с 1990 до 2000 пользователи интернета получили:

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

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

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

Потоковое вещание и хранение информации

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

размер хранилища (в мегабайтах) = продолжительность (в секундах) * битрейт (в кбит/с) / (8 * 1024)

(если считать, что 1 мегабайт = 8 * 1024 кбитов)

Один час видео, закодированного со скоростью 300 кбит/с (типичное видео по состоянию на 2005 год, имеющее размер 320×240 пикселов), будет занимать:

(3600 с * 300 кбит/с) / (8*1024) = порядка 130 Мб места на диске

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

300 кбит/с * 1000 = 300.000 кбит/с = 300 Мбит/с сетевого интерфейса

Это эквивалент порядка 125 Гб информации в час. Разумеется, при использовании протокола Multicast нагрузка на сервер намного ниже, так как для передачи информации всем клиентам используется единственный поток. Следовательно, такой поток будет занимать всего 300 кбит/с сетевого интерфейса сервера. Более подробная информация об этих протоколах даётся ниже.

Протоколы потокового вещания

Разработка сетевых протоколов потокового вещания вызывает следующие проблемы:

Источник

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

СОДЕРЖАНИЕ

Этимология

Термин «потоковая передача» впервые был использован для ленточных накопителей, производимых Data Electronics Inc., которые должны были медленно наращиваться и работать на протяжении всей дорожки; более медленное время разгона снизило затраты на привод. Термин «потоковая передача» применялся в начале 1990-х годов как лучшее описание видео по запросу, а затем и видео в реальном времени в IP-сетях. Впервые это было сделано Starlight Networks для потокового видео и Real Networks для потокового аудио. Такое видео ранее неправильно называлось «видео для хранения и пересылки».

Прекурсоры

Начиная с 1881 года, Театрофон позволял абонентам слушать оперные и театральные представления по телефонным линиям. Так действовало до 1932 года. В конечном итоге в Америку пришла концепция потокового мультимедиа.

Телефонная музыкальная служба, служба музыкальных автоматов в прямом эфире, началась в 1929 году и продолжалась до 1997 года. В конечном итоге клиентура включала 120 баров и ресторанов в районе Питтсбурга. Посетитель таверны помещал деньги в музыкальный автомат, пользовался телефоном над музыкальным автоматом и просил оператора воспроизвести песню. Оператор находил пластинку в библиотеке студии, насчитывающей более 100 000 пластинок, помещал ее на проигрыватель, и музыка передавалась по телефонной линии для воспроизведения в таверне. Музыкальные медиа начинались как 78, 33 и 45, которые играли на шести проигрывателях, которые они контролировали. Компакт-диски и кассеты были включены в более поздние годы.

У бизнеса была череда владельцев, в частности Билл Пёрс, его дочь Хелен Ройтцель и, наконец, Дотти Уайт. Поток доходов каждого квартала был разделен на 60% на музыкальный сервис и 40% на владельца таверны. Эта бизнес-модель в конечном итоге стала неустойчивой из-за городских разрешений и затрат на установку этих телефонных линий.

История

Ранняя разработка

Попытки отображать мультимедиа на компьютерах восходят к самым ранним дням развития компьютеров в середине 20-го века. Однако в течение нескольких десятилетий был достигнут незначительный прогресс, в первую очередь из-за высокой стоимости и ограниченных возможностей компьютерного оборудования. С конца 1980-х до 1990-х годов персональные компьютеры потребительского уровня стали достаточно мощными, чтобы отображать различные мультимедиа. Основные технические проблемы, связанные с потоковой передачей, заключались в наличии достаточной пропускной способности ЦП и шины для поддержки требуемых скоростей передачи данных, достижения производительности вычислений в реальном времени, необходимой для предотвращения опустошения буфера и обеспечения плавной потоковой передачи контента. Однако в середине 1990-х компьютерные сети все еще были ограничены, и аудио- и видеоматериалы обычно доставлялись по каналам без потоковой передачи, таким как воспроизведение с локального жесткого диска или компакт-дисков на компьютере конечного пользователя.

Развитие бизнеса

В 1995 году Microsoft разработала медиаплеер, известный как ActiveMovie, который позволял потоковую передачу мультимедиа и включал собственный формат потоковой передачи, который был предшественником функции потоковой передачи позже в Windows Media Player 6.4 в 1999 году. В июне 1999 года Apple также представила формат потокового мультимедиа в своем Приложение QuickTime 4. Позже он также был широко распространен на веб-сайтах вместе с форматами потоковой передачи RealPlayer и Windows Media. Конкурирующие форматы на веб-сайтах требовали, чтобы каждый пользователь загружал соответствующие приложения для потоковой передачи, и в результате многим пользователям приходилось иметь все три приложения на своих компьютерах для общей совместимости.

В 2000 году Industryview.com запустил свой «крупнейший в мире архив потокового видео», чтобы помочь компаниям продвигать себя. Интернет-вещание стало новым инструментом бизнес-маркетинга и рекламы, сочетающим иммерсивный характер телевидения с интерактивностью Интернета. Возможность сбора данных и обратной связи от потенциальных клиентов позволила этой технологии быстро набрать обороты.

Потоковые войны

Использование широкой публикой

Переход от DVD к культуре потокового вещания

Истоки потоковой передачи музыки: Napster

Борьба за права интеллектуальной собственности: A&M Records, Inc. против Napster, Inc.

Судебный процесс A&M Records, Inc. против Napster, Inc. коренным образом изменил способ взаимодействия потребителей с потоковой передачей музыки. Он был оспорен 2 октября 2000 г. и вынесен 12 февраля 2001 г. Апелляционный суд девятого округа постановил, что служба обмена файлами P2P может быть привлечена к ответственности за соучастие и косвенное нарушение авторских прав, что стало знаковым решением для интеллектуальной собственности. закон.

Второе требование истцов заключалось в том, что Napster активно способствовал нарушению авторских прав, поскольку знал о широко распространенном обмене файлами на их платформе. Поскольку Napster не предпринял никаких действий для уменьшения количества нарушений и получил финансовую выгоду от многократного использования, суд вынес решение против P2P-сайта. Суд постановил, что «до восьмидесяти семи процентов файлов, доступных на Napster, могут быть защищены авторским правом, и более семидесяти процентов могут принадлежать истцам или управляться ими».

Платформы потоковой передачи музыки

Технологии

Пропускная способность

В 2018 году видео составляет более 60% мирового трафика данных, и на его долю приходится 80% роста использования данных.

Протоколы

Качество взаимодействия серверов и пользователей зависит от загруженности стримингового сервиса; Чем больше пользователей пытается получить доступ к услуге, тем больше ухудшается качество, если не хватает полосы пропускания или хост не использует достаточное количество прокси-сетей. Развертывание кластеров потоковых серверов является одним из таких методов, когда в сети разбросаны региональные серверы, управляемые единым центральным сервером, содержащим копии всех медиафайлов, а также IP-адреса региональных серверов. Затем этот центральный сервер использует алгоритмы балансировки нагрузки и планирования для перенаправления пользователей на близлежащие региональные серверы, способные их принять. Этот подход также позволяет центральному серверу предоставлять потоковые данные как пользователям, так и региональным серверам с использованием библиотек FFMpeg, если это необходимо, что требует от центрального сервера мощной обработки данных и огромных возможностей хранения. В свою очередь, рабочие нагрузки в магистральной сети потоковой передачи сбалансированы и уменьшены, что обеспечивает оптимальное качество потоковой передачи.

Запись

Приложения и маркетинг

Вызовы

Вопросы авторского права

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

Выбросы парниковых газов

Источник

Разработка системы доставки мультимедийных потоков. С чего начать?

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

Система доставки мультимедийных потоков

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

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

Архитектура системы

Архитектура системы состоит из семи основных модулей:

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

Модули системы

1. Модуль хранения файлов пользователей

2. Модуль доставки VOD медиапотоков конечным пользователям

Данный модуль разворачивается на серверах под управлением ОС Linux (Ubuntu). В качестве медисервера, например, можно рассмотреть варианты использования Wowza Streaming Engine, Nimble Streamer, Flussonic.

3. Модуль публикации live медиапотоков

Данный модуль будет развернут на серверах под управлением ОС Linux (Ubuntu). В качестве медисервера, например, можно рассмотреть варианты использования Wowza Streaming Engine, Nimble Streamer, Flussonic.

4. Модуль доставки Live медиа-потоков конечным пользователям

Данный модуль будет развернут на серверах под управлением ОС Linux (Ubuntu). качестве медисервера, например, можно рассмотреть варианты использования Wowza Streaming Engine, Nimble Streamer, Flussonic.

5. Модуль ядра

Данный модуль будет развернут на серверах под управлением ОС Linux (Ubuntu).

6. Модуль баз данных

7. Модуль веб-серверов

Веб-интерфейс и скрипты сервиса

На сегодня все! Эта статья была написана, отредактирована и опубликована совместно c моими коллегами и специалистами Евгением Петровым и Евгением Кузьминым. В будущих статьях мы постараемся более подробно рассмотреть реализацию представленных модулей.

Всего хорошего!

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

Источник

«Передовые» технологии «Медиапотока»

Помню я «Медиапоток», когда он еще пешком под стол ходил! Троллил я их, каюсь, мол не позорились бы, по 3 просмотра на новость – убрали бы статистику)). Сейчас эта контора на неофициальном финансировании от Серого Дома выросла, под стол не ходит. Под себя ходит.

В общем, учитесь, как надо делать, если работать не получается, а показать работу надо.

Давайте-ка оценим статистику посещаемости этого ресурса, открытую явно по глупости, пока не закрыли. Обратите внимание, что можно сделать за один год, если уметь… пользоваться сервисом накрутки трафика. Итак, середина ноября 2018 года, понедельник, 19 ноября. 3 515 посетителей, вполне себе нормальная цифра. Хотя, как оказалось, и она несколько нереальна, но об этом чуть позже.

Но как быть, если денег на сайт выделяется больше, чем на нем букв, а просмотров нет?!

А вот есть вариантец. Берёте сервис накрутки, и…

И за бросовую цену в 500 рублей в день получаете липовые просмотры. Осматриваетесь, мммм, и начинаете ездить по ушам, вот мы какие посещаемые, читаемые да известные. Формируем общественное мнение, и вообще.

Действительно, заходит малоразбирающийся человек и видит – ну ничего себе! 38 000 просмотров за день! 30 000 посетителей! Ай, молодцы! Держите премию.

Но я тип вредный. И въедливый. Зайдя в так неосторожно открытую для постороннего взгляда расширенную панель статистики, я увидел, что за типичный понедельник середины ноября 2019 года на сайте действительно 34 477 посетителей, причем 19 782 НОВЫХ. Вот это размах, представляете? Вот это развитие! Могут, когда захотят, пацаны ваще ребята.

Первый канал, Коммерсант и прочие РБК нервно курят в сторонке и очень хотят такую же ошеломляющую динамику развития, не говоря уже о «Марийской Правде» с её жалкими 7 402 посетителями. Не хухры-мухры, в общем! Зачем «Марийская Правда» менеджера по продажам ищет?! С такой статистикой они «Медиапотоку» не конкуренты, неее…

Но давайте копнем глубже, что же это за 34 000 посетителей, да еще из них 19 000 новых?! Что это за 38 000 просмотров?! Начнем, пожалуй, с последних. Выбираем людей с местоположением «Республика Марий Эл»… И получаем, что пиковое значение не превышает СОТНИ. Ну, например, в 16:00 был 81 просмотр с такими параметрами.

Теперь посетители. Действуем аналогично, и… И узнаем, что одновременно на сайте из Марий Эл больше ста человек не было. А всего за сутки был 1931 посетитель.

С новыми посетителями та же история – 548 человек из Марий Эл, нормальная, реальная цифра.

А откуда остальные? Да много откуда. Москва, например:

Санкт-Петербург, и Ленинградская область очень живо интересуются делами в Марий Эл:

А вот, собственно, по роботам:

А новость от Виталия Малясева в 14:02 того же дня «зашла» намного успешнее, 11 777 просмотров. Так-то да, «нидерланский язык» это вам не Параньгинский район.

Мне вот интересно, вы хоть никого там не обманываете? Надеюсь, что если да, то только рекламодателей, а не Главу Республики. Хотя, в РМЭ и не такое с рук сходит.

Источник

Что такое медиа поток

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

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

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

Из уровня техники известно также решение, представленное в заявке на изобретение US 2009216758 «Method and apparatus for an application crawler», в котором представлены способ и устройство для поиска видеофайлов и извлечения подробной информации из веб-страниц и веб-приложений. С помощью данного изобретения осуществляют проверку функционирующего приложения. Поисковый робот, может загрузить и инсталлировать компоненты так, что веб-приложение будет представлено тем же самым способом, что было бы создано в браузере. Метод может включать инсталлирование видеофайлов, видеопотоков. Поисковый робот приложения может индексировать контент, используя многочисленные поля метаданных. В одном из вариантов исполнения изобретения поисковый робот приложения может достигнуть видео потока или видеоплеера и «вытащить» соответствующие данные.

Изобретение позволяет находить на веб-страницах аудио или видео файл и определять их описание и технические характеристики.

Наиболее близким к заявляемому решению является способ определения медиа потоков, вещание которых осуществляется в масштабе реального времени, н система для реализации способа, представленные в контексте описания технологии Интернет-поиска мультимедийного контента реального времени (RU 2399090 (С2); МПК: G06F 17/30). Способ содержит этапы, на которых: А) заранее задают в поисковой системе расширяемый и модифицируемый набор признаков наличия на Web-страницах вещания AV контента реального времени; В) осуществляют анализ загруженной Web-страницы на предмет присутствия в ней признаков, свидетельствующих о наличии на данной Web-странице вещания AV контента реального времени, из упомянутого их набора; С) если такие признаки выявлены в Web-странице при анализе, сохраняют адрес данной Web-страницы в базе данных из состава поисковой системы. Если же на этапе С) такие признаки не выявлены, то переходят на этап D), на котором загружают новую Web-страницу и повторяют в отношении нее этапы В) и С). При этом этап В) осуществляют посредством разбора текстового содержимого файлов Web-страницы сначала на предмет обнаружения в нем по меньшей мере одного признака, указывающего на средство или технологию воспроизведения AV контента, и затем, при успешном обнаружении, на предмет присутствия в нем по меньшей мере одного признака, указывающего на то, что воспроизводимый AV контент является именно AV контентом реального времени. Признак может представлять собой некоторой символ или набор символов. В частности, признак может представлять собой элемент разметки Web-страницы, такой как тег, параметр или атрибут.

В материалах описания данного изобретения (RU 2399090) также предоставлена компьютерно-реализуемая поисковая система, включающая модуль поиска признаков, выполненный с возможностью анализа загруженной Web-страницы на предмет присутствия в ней признаков, свидетельствующих о наличии на данной Web-странице вещания AV контента реального времени, из упомянутого их набора; базу данных, приспособленную для сохранения адресов Web-страниц, в которых модулем поиска признаков по результатам анализа установлено наличие вещания AV контента реального времени.

В техническом решении по патенту RU 2399090 в процессе поиска ссылок на мультимедийные потоки предусмотрена возможность проверки данных ссылок на предмет их соответствия критерию «живой» поток. При этом в качестве объекта обработки выступают Web-страницы Интернета. В данном техническом решении не предусмотрена возможность подключения непосредственно к серверу по ссылке для получения результирующего списка ссылок с высоким процентом релевантности на соответствие критерию «живой поток». Таким образом, набор ссылок, предоставляемый конечному пользователю, в большинстве своем, включает ссылки, находящиеся в «выключенном» состоянии или представляющие собой статические файлы фиксированной продолжительности, т.е. не удовлетворяющие критерию «живого» потока.

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

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

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

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

— подключение к медиа серверу по сетевой ссылке,

— получение (загрузку) от медиа сервера информации о медиа потоке, включающей характеристики потока в заданном формате и/или часть потока, предназначенную для воспроизведения на клиентской стороне,

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

при этом в качестве признаков используют любую последовательность символов и/или байт в медиа потоке, на основе которых делают вывод о том, что медиа поток соответствует критерию «живой» поток.

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

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

В качестве признаков могут быть использованы:

— параметр, характеризующий продолжительность потока (Duration), и/или

— параметр, характеризующий позицию, с которой начинается воспроизведение в потоке (Start Time) и/или

— параметр возможности перемотки в рамках передаваемого потока (Seekable). В случае, если значение параметра, характеризующего продолжительность потока (Duration), является отрицательным или нулевым, или больше заданного предела, осуществляют анализ значения параметра возможности перемотки в рамках передаваемого потока (Seekable), в случае, если он указывает на запрет перемотки в потоке, делают вывод о том, что анализируемый поток является источником мультимедиа, вещание которого осуществляется в масштабе реального времени.

В случае, если значение параметра, характеризующего продолжительность потока (Duration), находится в интервале от нуля до заданного предела, осуществляют повторное подключение к медиа серверу и определение значений данного параметра и параметра, характеризующего позицию, с которой начинается воспроизведение (Start Time), которые сравнивают со значениями аналогичных параметров, полученных при первоначальном подключении, и в случае не совпадения хотя бы одного из значений параметров делают вывод о том, что анализируемый поток является источником мультимедиа, вещание которого осуществляется в масштабе реального времени; в случае если значения параметров совпадают, осуществляют поиск признаков мультимедийного потока в заголовках ответа сервера, при обнаружении которых делают вывод о том, что проверяемый поток является источником мультимедиа, вещание которого осуществляется в масштабе реального времени.

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

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

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

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

— блок анализа информации о медиа потоке,

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

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

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

Характерной чертой «живого» потока (контента) является невозможность выполнения в отношении него «перемотки вперед» с помощью средств клиентского воспроизводящего приложения. Типичными примерами «живого» AV контента в Интернете являются телевизионное (ТВ) и радиовещание эфирных студий, специальное Интернет-вещание профессиональных и любительских студий, изображение с Веб-камеры потокового вещания.

Изобретение поясняется чертежами.

На фиг.1 представлена схематическая иллюстрация структуры и работы поисковой системы со встроенным блоком 5 определения типа потока, включающим модуль определения медиа потоков, вещание которых осуществляется в масштабе реального времени (модуль определения «живых потоков» 14), реализованный согласно настоящему изобретению. На фиг.1 представлена высокоуровневая архитектура поисковой системы. Позициями на фиг.1 обозначены:

На фиг 2. представлена схематическая структура работы блока 5 определения типа потока со встроенным модулем 14 согласно настоящему изобретению, где

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

Подробное описание изобретения.

Ниже представлено подробное описание заявляемого изобретения, реализованного в модуле 14 фиг.2, в контексте работы поисковой системы фиг.1. При этом наилучший вариант реализации алгоритма работы заявляемого модуля подробно представлен на фиг.3.

Поисковая система 1 (см. фиг.1) предоставляет пользователю инструмент поиска ссылок на потоки, вещание которых осуществляется в масштабе реального времени, посредством Веб-сервера 8. Перед тем как предоставить конечному пользователю ссылку на мультимедийный поток, осуществляют проверку типа потока через блок 5 определения типа потока. Поток, на который указывает ссылка, должен находиться в вещающем (включенном) состоянии и соответствовать критерию «живого» потока, то есть, вещание которого должно осуществляться в режиме реального времени. Проверка осуществляется с помощью заявляемой системы (модуля 14), которую содержит блок 5. При этом в блок определения типа потока 5 попадают ссылки из БД не проверенных потоков 4, сформированной по итогам поиска поисковыми роботами посредством модуля поисковой системы ссылок на потоки 2, в которую поступают данные из БД поисковой системы 3. Функции модуля 2 аналогичны функциям поисковых роботов вертикальных поисковых машин. Переданная блоку 5 ссылка подвергается анализу. Если проанализированная ссылка указывает на источник мультимедиа, вещание которого осуществляется в режиме реального времени, тогда она сохраняется в БД потоков реального времени 6. Модуль 2 и модуль 5 подключены к сети Интернет 9 для осуществления коммуникаций. Веб-сервер 8 также выполнен с возможностью подключения к сети Интернет 9 с целью предоставления пользователю интерфейса для осуществления поисковых запросов.

Далее представлено подробное описание принципа работы блока определения типа потока 5 (см. фиг.2) со встроенным модулем 14, в котором реализовано заявляемое изобретение.

При реализации изобретения на вход блока 5 поступает ссылка, указывающая на поток воспроизведения любого из существующих форматов аудио, видео из базы данных 4 не проверенных потоков, при этом передача мультимедийных данных по ссылке может осуществляться по любому из известных открытых, а также закрытых протоколов. Модуль 10 определения типа медиа данных по ссылке определяет схему протокола и расширение контента, на который указывает ссылка. Примером таких ссылок могут служить ссылки на потоковое воспроизведение данных по протоколу (схеме) RTSP, HTTP, MMS, RTMP и другим общеизвестным или закрытым протоколам передачи мультимедийных данных по сети. Проанализировав ссылку в модуле 10, данные передаются модулю определения мультимедийных контейнеров 11, целью которого является определения данных, возвращаемых по ссылке при первичном запросе. Мультимедийная ссылка может указывать на поток воспроизведения, или же на мультимедийный контейнер, или плейлист. Если возвращаемыми данными является контейнер или плейлист, в таком случае модуль 11 определит тип контейнера и передаст его содержимое модулю анализа и извлечения данных из контейнера 12. Любой из загруженных мультимедийных контейнеров подвергается анализу. В зависимости от типа контейнера из него может быть извлечена следующая информация:

— Описание потока, которое может включать в себя:

— Информацию об авторе,

— Ссылку на сайт правообладателя,

Ссылка, извлеченная из контейнера или плейлиста, передается модулем 12 в модуль определения типа медиа данных 10. Подобная итеративная процедура повторяется до тех пор, пока модуль определения мультимедийных контейнеров 11 не получит прямую ссылку на мультимедийный поток, после чего данная ссылка будет передана мультимедийному клиенту 13. Модуль 13 подключается к серверу по указанному адресу с целью получения метаинформации о потоке, а также самого мультимедийного потока(ов). Передаваемый от сервера поток «разбирается» в модуле 13 в соответствии с правилами, установленными для проверяемого формата потока. Примерами таких форматов могут служить такие форматы потоковой передачи данных как asf, ogg, mpeg-ts и другие известные, а также закрытые форматы передачи мультимедийных данных. Далее модуль 13 определяет характеристики потока из передаваемых данных, такими характеристиками, например, могут являться продолжительность потока, позиция в потоке с которой следует начать воспроизведение, формат аудио и (или) видео потока, битрейт аудио и (или) видео потока, количество сменяемых кадров за единицу времени в видео потоке (FPS), кодеки, необходимые для воспроизведения аудио и (или) видео данных и другие передаваемые характеристики потока. Собранная информация мультимедийным клиентом 13 передается в модуль определения «живых» потоков 14 для анализа. Передаваемые данные включают в себя все заголовки протокола, полученные от сервера, полученную метаинформацию о характеристиках потока(ов) и буферы, предназначенные непосредственно для воспроизведения. Целью анализа является поиск признаков, явно или не явно указывающих на тип потока. В качестве признака может выступать любая последовательность символов или байт в медиа потоке, на основе которых может быть сделано заключение о том, что медиа поток является источником мультимедиа, вещание которого осуществляется в реальном времени. Характерными признаками, как в отдельности, так и в совокупности могу быть такие характеристики, как продолжительность потока, начало воспроизведения потока, отдельные значения в заголовках протокола, или же отдельные байты, передаваемые в виде информационных флагов в момент установки медиа сессии с сервером, а также байты, или их последовательность, передаваемые в самом медиа потоке. Схематическая последовательность реализуемых действий определена в блок-схеме фиг.3. Описание действий в соответствии с данной блок-схемой отображено в примерах конкретного выполнения. После анализа данных модуль определения «живых» потоков 14 определяет тип потока:

— Мультимедийный поток, вещание которого осуществляется в режиме реального времени;

— Статический файл конечной продолжительности;

— Ссылка не является мультимедийным источником аудио или видео.

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

Таким образом, заявляемая в качестве изобретения система, содержит мультимедийный клиент 13, выполненный с возможностью подключения к медиа серверу по ссылке и загрузки информации о медиа потоке, включающей характеристики потока в заданном формате и/или определенной части потока, предназначенной для воспроизведения на клиентской стороне и/или заголовках протоколов, полученных от медиа сервера, и блок анализа информации о медиа потоке, реализованный в примерах на фиг.1-3 в виде модуля определения «живых» потоков 14. При этом блок анализа информации о медиа потоке выполнен с возможностью реализации заявляемого способа.

Ниже представлено описание наилучшего варианта реализации изобретения по алгоритму фиг.3.

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

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

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

При проверке параметра Duration, его значение могло быть больше нуля, но меньше установленного предела, в таком случае система делает вывод о том, что проверяемая медиа ссылка воспроизводит файл фиксированной длины. Для подтверждения этой установки, системой будет сделано повторное подключение к медиа серверу с целью определения характеристик и сравнения их с характеристиками первого запроса. На этом этапе проверяется изменение параметров Duration и Start Time, полученных после первого и второго подключения к медиа серверу. Если изменился параметр Start Time, это означает, что после повторного запроса сервер сдвинул позицию воспроизведения. Такие изменения указывают на то, что медиа сервер изменил воспроизводимые данные не зависимо от того просматривался поток или нет. При этом так же отслеживаются изменения параметра Duration, так как может измениться сам буфер воспроизведения и, как следствие, его продолжительность. Подобные изменения говорят о том, что воспроизводимый поток является источником мультимедиа реального времени. Если же при повторном запросе значения параметров Duration и Start Time остаются без изменений, начинают анализировать заголовки ответа сервера. Целью анализа заголовков является поиск косвенных признаков. Примером косвенного признака может служить значение заголовка Pragma=features=»broadcast», а так же другие косвенные признаки. Если косвенные признаки найдены, считают ссылку на поток источником мультимедиа реального времени. В противном случае, считают воспроизводимый поток ссылкой на файл фиксированной длины.

Второй аналитический подход включает анализ битовых сообщений сервера. Система подключается к серверу в соответствии с установленными правилами и запрашивает необходимый поток на воспроизведение. Сервер начинает отдачу потока, сообщая его характеристики (пример характеристик приведен выше). Попутно с характеристиками от сервера идут, так называемые, информационные сообщения, представленные определенной последовательностью байт. Каждое из передаваемых сообщений имеет свое значение. Модуль 13 принимает все сообщения до тех пор, пока от сервера не начинают приходить буферы потока(ов), предназначенные непосредственно для воспроизведения. Из всех передаваемых данных от сервера мультимедийный клиент ожидает сообщение с информацией о том, что поток является записанным «Stream Is Recorded». Если данное сообщение получено, делают вывод о том, что данный поток является файлом фиксированной длины, если же данного сообщения не было получено, данный поток считают источником мультимедиа реального времени.

Ниже представлены конкретные примеры анализа и определения типа потока.

На вход блока определения типа потока была получена медиа ссылка следующего формата http://Reference_l?MSWMExt=.asf (URL). После подключения к серверу, загрузки передаваемой от сервера информации и определения характеристик, на выходе была получена структура с переменным набором характеристик (см. таблицу №1)

Данная структура была передана модулю определения «живых» потоков. Совместно с характеристиками из таблицы №1, данному модулю также были переданы заголовки протокола, по которому осуществлялась коммуникация с медиа сервером (см. таблицу №2).

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

Start Time=4041177.35 (4041177.35/86400=46.8 дней, где 86400 количество секунд в сутках)

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

В рамках настоящего примера представлено три варианта реализации изобретения с измененными значениями параметра Duration при сохранении всех остальных значений параметров Примера 1. Для всех вариантов также можно сделать вывод о том, что поток является источником мультимедиа реального времени, если продолжительность потока задана достаточно большим интервалом или отрицательной величиной, что явно указывает в рамках одного признака на то, что данный поток является потоком реального времени. В таблице №3, приведены варианты значений продолжительности потока, которые явно указывают на его принадлежность к потокам реального времени.

Этап получения и обработки данных в данном случае полностью аналогичен примеру №1. Так же загружаются данные, формируется структура с характеристиками потока и данные передаются модулю определения «живых» потоков для анализа. Модуль анализирует продолжительность потока и позицию воспроизведения (см. таблицу №4). В момент анализа модуль посчитал, что продолжительность является достаточно маленькой величиной, что явно указывает на то, что данный поток является файлом с фиксированной продолжительностью.

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

При этом обнаружено что, при повторном соединении изменилась позиция воспроизведения в потоке. Для модуля это означает, что сервер передает трафик небольшими буферами переменной длины, при этом, указывая с какой позиции в буфере следует начать воспроизведение. В некоторых случаях при повторном обращении может быть получен новый размер продолжительности (Duration), подобная ситуация возникает в том случае, если при первичном обращении позиция воспроизведения находилась в конце буфера (см., например, таблицу №6).

Основной сутью повторного запроса является определение изменений в характеристиках потока. Если при втором запросе изменяется продолжительность и (или) позиция, с которой надо начинать воспроизведение, модуль считает данный поток источником мультимедиа реального времени.

Для различных видов протоколов используется разный подход с целью определения типа потока, например в случае подключения к потоку по протоколу RTMP в момент так называемого «рукопожатия», клиент отправляет запрос на воспроизведение конкретного потока, после чего сервер отправляет клиенту определенный набор метаинформации с характеристиками потока и сообщений о статусе обработки запроса. В случае с протоколом RTMP для файлов конечной длины сервер передает сообщение «Stream Is Recorded». Если такое сообщение получено, тогда поток считается файлом, если такое сообщение не получено, поток считает источником мультимедиа реального времени.

В некоторых случаях, проанализировав полученные характеристики потока, а так же сам буфер для воспроизведения, не получается определить тип потока. В таких случаях анализируют различные косвенные признаки, полученные от медиа сервера. Модулем просматриваются заголовки протокола, переделанные серверам (заголовки ответа см. Таблицу №7).

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

Источник