Обзор передачи и оценок качества восприятия видеоданных при использовании технологии адаптивной передачи видео по протоколу http

Ч КОДИРОВАНИЕ И ПЕРЕДАЧА ИНФОРМАЦИИ

УДК 621.391.1

doi:10.15217/issnl684-8853.2017.3.75

ОБЗОР ПЕРЕДАЧИ И ОЦЕНОК КАЧЕСТВА ВОСПРИЯТИЯ ВИДЕОДАННЫХ ПРИ ИСПОЛЬЗОВАНИИ ТЕХНОЛОГИИ АДАПТИВНОЙ ПЕРЕДАЧИ ВИДЕО ПО ПРОТОКОЛУ HTTP

И. А. Пастушок1, ассистент

аСанкт-Петербургский государственный университет аэрокосмического приборостроения

Введение: рост числа обслуживаемых устройств и объемов видеотрафика в современных телекоммуникационных системах приводит к необходимости адаптации существующих сетей для передачи видеоданных. Наибольший объем видеоданных передается с использованием технологии Dynamic Adaptive Streaming over HTTP (DASH) по протоколу прикладного уровня HTTP. Цель: обзор технологий передачи видеоданных по протоколу HTTP и оценок качества восприятия видеоданных в целях подбора методики оценки качества восприятия видео в зависимости от объема доступных объективных показателей обслуживания. Результаты: проведен обзор технологии передачи видео по протоколу HTTP и на его основе описана трехкомпонентная модель передачи видеоданных при использовании DASH, включающая в себя модели видеоконтент-сервера, сети передачи информации и пользовательского устройства. Обзор показал, что технология DASH приводит к незначительному увеличению нагрузки на сеть по сравнению с другими технологиями. Однако данная технология инвариантна к сети передачи информации. Инвариантность обеспечивается использованием протокола HTTP в сочетании с протоколом транспортного уровня TCP. Технология DASH передачи видео уменьшает нагрузку на сеть за счет хранения видео в различных наборах качества на видеоконтент-сервере, позволяющая пользовательскому устройству выбрать характеристики видео для конкретных условий в сети передачи информации. Практическая значимость: полученные результаты позволяют разработчику приложений для передачи видеоданных принимать решение о целесообразности использования технологии DASH по конкретным требованиям к системе передачи видео, разработчику телекоммуникационных систем — проводить оценки качества восприятия видеопотока на различных узлах сети, на основе которых возможно сформировать управление для увеличения производительности сети при передаче видеоданных.

Ключевые слова — передача видео по HTTP-протоколу, DASH, HPD, HAS, оценка качества обслуживания.

Введение

В настоящий момент происходит бурное развитие систем сотовой мобильной связи. Данное явление вызвано как увеличением числа абонентов в сети, так и ростом популярности мобильных сервисов, в особенности доставки видео по запросу, занимающего более 55 % объема всего мобильного трафика, большая часть которого передается с использованием протокола HyperText Transfer Protocol (HTTP) [1]. Подобное распределение трафика между мобильными сервисами и его постоянный рост приводят к необходимости оптимизации существующих систем передачи информации для передачи именно видеоконтента.

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

1 Научный руководитель — доктор технических наук, заведующий кафедрой инфокоммуникаци-онных систем Санкт-Петербургского государственного университета аэрокосмического приборостроения А. М. Тюрликов.

дения загруженного видео. Однако оценка качества восприятия видео является нетривиальной задачей ввиду субъективного восприятия проигрывания пользователем. Отличительной особенностью видео от других видов контента в сети Интернет является зависимость оценки качества передачи от характеристик воспроизводящего устройства. Общепринятым критерием качества восприятия является Mean Opinion Score (MOS), который может быть получен на основе опроса группы пользователей [2], что критично замедляет получение результата.

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

Структура систем передачи видеоданных по технологии DASH

В настоящее время существует множество технологий передачи видеоданных через телекоммуникационные сети. Наибольшее распространение получили технологии на основе протокола прикладного уровня HTTP: Dynamic Adaptive Streaming over HTTP (DASH), включающую в себя технологии Progressive Download (HPD) и HTTP Adaptive Streaming (HAS) [1]. Изначально технология передачи видеоданных через протокол HTTP была стандартизирована Международной электротехнической комиссией (ISO/IEC) в 2012 г. [3], в настоящее время представлена в спецификации консорциума, разрабатывающего решения для беспроводной связи, 3GPP (3rd Generation Partnership Project) [4].

Система передачи видеоданных при использовании технологии DASH состоит из трех основных компонентов (рис. 1): системы видеоконтент-серверов (ВКС), пользовательских устройств и сети передачи информации. Рассмотрим особенности данных компонентов. Программный модуль ВКС обеспечивает хранение, представление и доставку видеоданных с использованием протоколов HyperText Transfer Protocol, HyperText Transfer Protocol Secure или Transport Layer Security. На пользовательском устройстве установлен программный комплекс — видеоплеер, который организует управление загрузкой видеоданных с ВКС путем формирования последовательности запросов на видеоданные. Видеоплеер устанавливает соединение c ВКС и отправляет на него запросы по протоколу HTTP. Важно отметить, что передача информации в технологии DASH происходит с использованием протокола гарантированной доставки данных Transmission Control Protocol (TCP), что приводит к невозможности потери данных при их прохождении через сеть передачи информации.

В технологии DASH к сети передачи информации предъявляется только требование обеспечения корректной работы протокола HTTP и всех нижележащих уровней модели OSI. Таким образом, в соответствии со стандартом DASH [4] в настоящей работе сеть передачи информации представляется в виде «черного ящика» с некоторыми характеристиками, обладающего произвольной структурой, построенного на любом физическом принципе и обеспечивающего корректную работу протокола HTTP.

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

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

Организация передачи видео посредством технологии DASH

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

Видеоконтент-сервер

Сеть передачи информации

Пользовательские устройства

Рис. 1. Структура системы передачи видеоданных на основе стандарта DASH: MPD — формат Media Presentation Description

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

Репрезентация является общепринятой характеристикой видеоданных в технологии DASH, описывающая взаимосвязь между битовой скоростью, рекомендованным разрешением и частотой кадров. Под битовой скоростью понимается количество бит, затрачиваемое на хранение контента в одну единицу времени (Bitrate). Рекомендованное разрешение — размер экрана, заполняемый при воспроизведении потока. Единицей измерения разрешения потока является прогрессивная развертка (p), например, экран высокого разрешения (High Definition) обозначается 720p, что соответствует 720 точкам (пикселям) по вертикали. Такая нотация основана на стандартном соотношении сторон экрана 16:9, следовательно, значение по вертикали задает и значение по горизонтали, для примера, представленного выше, разрешение составляет 1280x720 пикселей. Сервисом YouTube, основанным на стандарте DASH, представлены рекомендации по взаимосвязи параметров репрезентации для стационарных и мобильных устройств (табл. 1) [5, 6].

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

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

Формат MPD, описывающий каждый сегмент последовательности: идентификатор, длительность и репрезентацию, — был разработан для описания всей имеющейся информации о последовательности [4]. Файл данного формата загружается на видеоплеер перед началом загрузки видео, и на основе информации, записанной в нем, видеоплеер будет осуществлять загрузку видеопоследовательности.

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

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

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

В состоянии Воспроизведение и загрузка происходит одновременная демонстрация видео (опустошение буфера) и загрузка данных (наполнение буфера). Если ввиду состояния сети пере-

Таблица 1. Рекомендуемые сервисом YouTube характеристики битовой репрезентации

Прогрессивная развертка Битовая скорость видео, Мбит/c

Стандартная частота кадров (24, 25, 30) Высокая частота кадров (48, 50, 60) Видео для мобильных устройств

2160p (4K) 35-45 53-68 13,5

1440p (2K) 16 24 6

1080p 8 12 3

720p 5 7,5 1,5

480p 2,5 4 0,7

360p 1 1,5 0,45

240p - - 0,25

Буфер

Рис. 2. Конечный автомат видеоплеера

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

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

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

Всевозможные плееры, использующие технологию DASH, разделены на два множества — HPD и HAS. Основным отличием является проведение адаптации репрезентации видеоряда под условия канала передачи информации: плееры группы HPD не осуществляют адаптацию, поэтому далее в работе они будут называться неадаптивными, плееры группы HAS, осуществляющие адаптацию, будут называться адаптивными.

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

Следующим шагом в развитии видеоплееров стали адаптивные плееры [4]. Часто для обозна-

чения адаптивного плеера используется название стандарта DASH. Отдельной веткой развития технологии DASH стала HTTP Live Streaming (HLS). Плееры, построенные на основе этих технологий, отличаются рекомендованной длительностью сегментов видео: в DASH длительность сегмента 2-4 с, а в HLS — около 10 с [6].

В 2012 г. был опубликован стандарт для передачи видеоконтента MPEG-DASH, на данный момент актуальна версия 2014 г. [3]. Как было сказано ранее, стандарт DASH описывает формат хранения видеоконтента и видеоплеер, поддерживающий этот формат.

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

В настоящее время наиболее популярным сервисом хранения и доступа к видеоданным является YouTube. Сервис YouTube построен на основе технологии DASH, что позволяет ему быть запущенным в любом современном браузере; это обеспечило данному сервису такую колоссальную популярность. Однако его исходный код является закрытым, что затрудняет его анализ. Существует ряд исследований, анализирующих его работу на основе захвата трафика в канале [7, 8]. Их авторы проводили анализ работы сервиса YouTube в различные временные периоды, из его результатов следует, что изначально сервис поддерживал неадаптивный плеер, а актуальная версия основывается на стандарте DASH. Обобщенная логика адаптивных плееров представлена на рис. 3, б. Из ее анализа следует, что в период высокой активности плеер делает паузы между заказами сегментов, обусловленными скоростью просмотра контента, что приводит к уменьшению загрузки сети.

а)

М

ы т й а

М

я и т ы б о С

Восходящий канал

Время

Нисходящий канал

1111

Время

Начало работы

о О О О О О

Начало проигрывания

Время

Просмотр сегмента

б)

ы т й а

и

ы т й а

и

я

иа £ а те ые бел

оп

О п

Восходящий канал

Нисходящий канал

Начало работы

2

Время

и

Время

о

Начало проигрывания

Заполнение буфера

I

О

Время

Адаптация репрезентации

Просмотр сегмента

Рис. 3. Логика работы неадаптивного (а) и адаптивного (б) видеоплеера

предоставляет открытую реализацию видеоплеера и серверных приложений.

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

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

Любой адаптивный плеер имеет возможность работать в неадаптивном режиме путем отключения функционала адаптации репрезентаций. Если отключена адаптация, то плеер может поддерживать одновременную загрузку нескольких сегментов, однако по умолчанию такой функционал не используется для экономии трафика в сотовых сетях. Основные параметры адаптации видеопотока представлены в табл. 2 [6, 9].

Проигрывание

Загрузка

Рис. 4. Логика адаптивного выбора репрезентации опорного плеера БавИов

Мониторинг

XI

0

го

>

1 т

т XI

т

>

I

е

о

XI >

с

Таблица 2. Сводная таблица параметров адаптации видеопотока

Параметр Описание Значение

Общие параметры

Длительность сегмента видеоданных Длительность сегментов, на которые разделена видеопоследовательность От 2 до 10 с

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

Максимальный размер буфера Максимальная длительность видеопоследовательности, которая может быть помещена в буфер на плеере > 60 с

Параметры адаптации репрезентации видеопотока

Начальная оценка канала Оценка канала передачи данных, на основе которой будет выбран первый сегмент 1 Мбит/с

«Память» при оценке скорости канала Число сегментов, на основе которых будет производиться оценка скорости канала передачи информации 3 сегмента

Понижающий коэффициент оценки скорости Коэффициент для понижения оценки скорости передачи информации при оценке скорости загрузки 0,9

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

Коэффициент порогового ожидания загрузки сегмента Длительность числа сегментов, которую будет ожидать плеер перед удалением текущего сегмента (см. рис. 4, «Мониторинг») 1,5

Методики оценки качества передачи видеоконтента по технологии DASH

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

Для неадаптивных видеопотоков длительности от 30 до 60 с существует разработанный ITU-T

стандарт P.1201 оценки качества просмотренной последовательности на основе информации, доступной на клиентском устройстве [10] (далее в работе для обозначения данного стандарта будет использоваться сокращение ITU MOS). То есть существует способ на основе большого массива объективных характеристик воспроизведения видео оценить удовлетворенность пользователя от просмотра, причем полученное значение не отличается от результата, полученного в ходе демонстрации данной последовательности группе экспертов.

На основе характеристик входного видеопотока и его воспроизведения рассчитываются два показателя качества: воспроизведение, аудио и видео. Каждый из них представляет из себя число от 1 до 5, чем выше данное значение, тем более удовлетворенным считается пользователь по данным показателям. Далее полученные значения агрегируются в результирующее значение MOS. Пользователь считается удовлетворенным, если данное значение выше трех. Рассмотрим более подробно каждый показатель качества:

1) аудио и видео — данный показатель учитывает такие параметры видеопотока, как битовая скорость, частота кадров, аудио- и видеокодеки,

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

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

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

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

Компанией Huawei было представлено свое решение для оценки удовлетворенности пользователя при просмотре видео — U-vMOS [11]. Данный способ так же, как и стандарт ITU и MOS, производит вычисление факторов качества по нескольким показателям: длительности начальной буферизации (sInteraction), разрешению репрезентации (sQuality) и замиранию воспроизведения видео (sView). Каждый фактор определен в интервале от 1 до 5.

Последовательно рассмотрим факторы по отдельности. Фактор качества разрешения битовой репрезентации определяется в зависимости от устройства, на котором происходит воспроизведение видеопотока. Компанией Huawei были рассмотрены два основных размера экрана: 100" телевизионного (ТВ) и 9,7" смартфона — и предложена таблично заданная функция для оценки удовлетворенности пользователя от просмотра

Таблица 3. Оценка качества репрезентации U-vMOS

Разрешение битовой репрезентации Оценка sQuality

для ТВ для смартфона

8K 5 5

5K 4,72 5

4K 4,65 4,78

2K 4,2 4,58

1080p 4 4,45

720p 3,15 4

480p 2,44 3,64

360p 1,66 3

Таблица 4. Оценка длительности ожидания начала воспроизведения И-уМОБ

Оценка sInteraction Ожидание начала воспроизведения

для ТВ для смартфона

5 <100 мс < 100 мс

4 1 с 1 с

3 2 с 3 с

2 5 с 5 с

1 8 с 10 с

битовых репрезентаций различного разрешения (табл. 3).

Показатель качества в^егас^ои основан на длительности ожидания начала воспроизведения, заданной табл. 4. Она характеризуется длительностью нахождения видеоплеера в состоянии Буферизация до начала показа видео.

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

После того как рассчитаны все вышеперечисленные показатели качества, результирующее

Реализованный программный комплекс представлен в виде библиотеки на языке С++. Он позволяет оценить качество для адаптивного видеопотока неограниченной длительности на основе методики U-vMOS. На вход поступают «сырые» данные для каждого просмотренного сегмента: разрешение, битовая скорость, замирание воспроизведения и длительность ожидания начала воспроизведения. На выходе представлены оценки воспроизведения потока (sQuality, sInteraction, sView) и результирующее значение оценки удовлетворенности пользователя от просмотра.

Таким образом, метод оценки U-vMOS применим для адаптивного и неадаптивного видеопотока. Данное свойство позволяет использовать его для большего множества видеоконтента по сравнению со стандартом ITU MOS. Из описания методик оценок качества воспроизведения видео ITU MOS и Huawei U-vMOS следует, что для их использования необходимо иметь доступ к информации на видеоплеере. Данное ограничение значительным образом сужает возможную сферу их применения.

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

Возможно табл. 7 использовать следующим образом: зафиксировать некоторый объем данных, доступный разработчику сети, и выбрать те критерии качества обслуживания, которые могут оценить удовлетворенность пользователя. Например, при знании битовой скорости просматриваемого потока можно использовать метод, описанный в работе [16], однако если добавить информацию о длительности опустошения буфера и просмотра, возможна более точная оценка на основе критерия [17].

Таблица 5. Оценка качества воспроизведения U-vMOS

Оценка sView Длительность замираний воспроизведения, %

для ТВ для смартфона

5 0 0

4 0,1 5

3 1 10

2 5 15

1 10 30

Таблица 6. Коэффициенты для расчета значения MOS в методологии U-vMOS

Коэффициент Для ТВ Для смартфона

а 0,66 0,71

ß 0,77 0,77

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

и^МОЭ = ^иаШу -1) х а

4

+1,

где коэффициенты а и ß заданы табл. 6 в зависимости от вида вещания.

Из вида функции U-vMOS следует, что если зафиксировать некоторое значение показателя sQuality, то результирующее значение не может превышать значение данного показателя. Таким образом, чтобы получить значение MOS, превышающее 3, необходимо демонстрировать пользователю видеопоток с разрешением не менее 720p и 360p для телеэкранов и смартфонов соответственно. Показатели качества sInteraction и sView, отличные от пяти, только понижают результирующее значение MOS. Как следствие, для обеспечения значения U-vMOS больше трех следует обеспечивать более высокие репрезентации.

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

Таблица 7. Аппроксимации функции MOS для интерактивного видео

Формула Описание Источник

Процент замирания воспроизведения потока

rbt (t) gl = lim v ' ; rbt (t j + dt yt) minimize: "^gj i gi — процент времени, когда пользователь наблюдал замирание воспроизведения потока; гЬ1(€) — длительность замираний воспроизведения потока за время Р; di(t) — длительность просмотренной последовательности за время t [13, 14]

Отношение длительности ожидания и просмотра видеоряда

г wi (i) =lim , / л; i -> di ytJ minimize: ^(fr i wi(t) — длительность ожидания в течение времени t, учитывающая начальные буферизации и замирания воспроизведения потока [15]

Взвешенные суммы характеристик воспроизведения

MOSi = fRATE {Rt); maximize: ^ MOSi l Ri — битовая скорость просматриваемого потока [16]

rbj (t) fi =k1 in Ri - h—^r; 1 1 1 2 <k (t) maximize: ^fj l k1, k2 — весовые коэффициенты приоритета функции от битовой скорости и замираний воспроизведения соответственно, ^ ^ [17]

minimize: WX - 6 X — средний процент времени замирания воспроизведения по всем пользователям; 0 — среднее значение скорости битовой репрезентации по всем пользователям; W — весовой коэффициент приоритета замирания воспроизведения, сравним со значением 0 [18]

M W! {Ri ^ ^ M" BUfthr )2 "] QoEt [t\= Wi log 9 ' I- w3 iRi[t]-Ri[t-!]) ) maximize: ^QoEi [i] i Wi — весовые коэффициенты; Ri[t] — битовая скорость в момент времени Р; Bufi[t]- уровень буфера в момент времени Р; Bufthr — пороговое значение уровня буфера [19]

O! + a2FrRi + a3 log (JRlTCP) MOSi =-, \2 '; 1 + a4PLi + Og (PLi) maximize: ^ MOSi l ai — коэффициенты, зависящие от характеристик просматриваемого контента; FrRi — частота кадров потока; ТСР Ri — скорость получения информации; PLi — вероятность потери пакета [20]

b - a MOSi =-+ a; 1 + c0 j (c2) 1 maximize: ^MOSj l a, Ь — нормирующие константы; ci — константы, подобранные в ходе эксперимента; SUDi — длительность ожидания начала воспроизведения [21, 22]

MOSRes (Resli) = 1,475 log (Resli) - 6,15 MOSReb (RebRatei) = 0,738 e-RebRate' MOSSUD (SUDi) = -0,02SUDi +2,53 MOSi = 0,174МО5де8 (Resli)MOSReb (RebRate). x <MOSSUD (SUDi); -naximize: ^ MOSi i Resli — разрешение репрезентации; RebRatei — отношение времени просмотра к длительности опустошения буфера [23]

О взаимосвязи характеристик сети передачи информации и качества восприятия видеоданных

После определения методов оценки качества восприятия видеопотока необходимо продемонстрировать, каким образом характеристики сети передачи информации влияют на восприятие видеопоследовательности. Важно отметить, что все объективные характеристики сети передачи информации (задержка, джиттер и т. д.) агрегируются в полезной скорости получения информации на уровне приложения — скорость получения информации, не учитывающая накладные расходы при доставке информации. За основу рассмотрения в данной части работы был взят критерий качества восприятия И-уМОЯ.

Зафиксируем длительность начальной буферизации для видео равной 2 с ^1^егае^оп) и построим плоскость всевозможных значений критерия И-уМОЯ. Исходя из описания методологии, для получения оценки требуется информация о разрешении видеопотока и процента времени прерывания воспроизведения. Для получения оценки sQuality используем значения из табл. 1 о взаимосвязи между битовой скоростью потока и его разрешением для мобильных устройств, а в качестве оценочного значения выберем среднее значение. Для получения промежуточных значений для битовой скорости и всех таблично задан-

ных функций показателей качества И-уМОЯ был использован метод бета-сплайна с кубической степенью полинома. Полученный результат представлен на рис. 5.

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

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

Граничная область (заштрихованная область) соответствует значениям в отрезке от 2,5 до 3. Граничная область характеризует пограничное состояние удовлетворенности пользователя.

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

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

Рис. 5. Зависимость качества восприятия от объективных характеристик сети

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

Заключение

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

В статье продемонстрировано, каким образом особенности работы видеоплеера влияют на

1. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update 2016-2021 White Paper. 2017. http://www.cisco.com/c/en/us/solutions/collat-eral/service-provider/visual-networking-index-vni/ mobile-white-paper-c11-520862.html (дата обращения: 01.04.2017).

2. Маколкина М. А. Оценка качества восприятия видео на основе распознавания эмоций // Электросвязь. 2015. № 9. С. 24-28. issn0013-577

3. ISO/IEC 23009-1:2014. Information Technology, Dynamic Adaptive Streaming over HTTP (DASH); Progressive Download and Dynamic Adaptive. — ISO/ IEC, 2014. — 144 p.

4. 3GPP TS 26.247 v14.0.0. Transparent End-to-End Packet Switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming Over HTTP (3GP-DASH). — 3GPP, 2016. — 104 p.

5. Рекомендуемые настройки кодирования. https:// support.google.com/youtube/answer/1722171?hl=ru (дата обращения: 01.04.2017).

6. Video as a Basic Service of LTE Networks: Mobile vMOS Defining Network Requirements. http://www. huawei.com/minisite/4-5g/en/ industryjsdc-j.html (дата обращения: 01.04.2017).

7. Oyman O., Singh S. Quality of Experience for HTTP Adaptive Streaming Services // IEEE Communication Magazine. 2012. N 4. P. 20-27. doi:10.1109/ issn0163-6804

8. Ameigeiras P., Ramos-Munoz J., Navarro-Ortiz J., Lopez-Soler J. M. Analysis and Modelling of You-Tube Traffic // Transactions on Emerging Telecommunications Technologies. 2012. N 23. P. 360-377. doi:10.1002

9. Dash Industry Forum. https://github.com/Dash-In-dustry-Forum/ dash.js/ wiki (дата обращения: 01.04.2017).

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

Работа выполнена в рамках инициативного научного проекта № 8.8540.2017/БЧ «Разработка алгоритмов передачи данных в системах 1оТ с учетом ограничений на сложность устройств».

10. P.1201. Amendment 2, Parametric Non-intrusive Assessment of Audiovisual Media Streaming Quality Amendment 2: New Appendix III Use of ITU-T P.1201 for Non-adaptive, Progressive Download Type Media Streaming. — ITU-T, 2013. — 23 p.

11. U-vMOS, Benchmarking Video Experience. http:// www.huawei.com/minisite/ubbf2015/ppt/PPT-111-vMOS-Video%20Experience% 20Standard%20-%20 Ken%20Wang% 20-% 2020150908% 20V1.pdf (дата обращения: 01.04.2017).

12. U-vMOS SDK. http://developer.huawei.com/ru/ict/ Products/TelecoSoftware/ VideoExperienceCapbili-ty/U-vMOS/SDK (дата обращения: 01.04.2017).

13. Ramamurthi V., Oyman O. Video-QoE Aware Radio Resource Allocation for HTTP Adaptive Streaming// IEEE ICC 2014 — Communication QoS, Reliability and Modeling Symposium, Sydney, June 10-14, 2014. P. 1076-1081.

14. Pastushok I., Turlikov A. Lower Bound and Optimal Scheduling for Mean user Rebuffering Percentage of HTTP Progressive Download Traffic in Cellular Net-works// 2016 XV Intern. Symp. "Problems of Redundancy in Information and Control Systems" (REDUNDANCY), Saint-Petersburg, September 26-29, 2016. P. 105-111.

15. Bakin E., Evseev G., Turlikov A. Lower Bound of Mean user Waiting/Watching Time Ratio in Wireless Video Streaming Network// 2014 IEEE Global Communications Conf., Austin TX, December 7-12, 2014. P. 1170-1175.

16. Essaili A. E., Schroeder D., Staehle D., Shehada M., Kellerer W., Steinbach E. Quality-of-Experience Driven Adaptive HTTP Media Delivery// IEEE ICC 2013 — Communication QoS, Reliability and Modeling Symp., Budapest, June 9-13, 2013. P. 24802485.

17. Борисовская А. В., Пастушок И. А. Эвристический алгоритм выбора подоптимальных значений ха-

рактеристик видеопотока и параметров алгоритма распределения ресурсов радиоканала// Научная сессия ГУАП: сб. докл., Санкт-Петербург, 1016 апреля 2015 г. СПб., 2015. С. 209-219.

18. Bui N., Valentin S., Widmer J. Anticipatory Quality-Resource Allocation for Multi-user Mobile Video Streaming// 2015 IEEE Conf. on Computer Communications Workshops (INFOCOM WKSHPS), Hong Kong, April 26 - May 1, 2015. P. 245-250.

19. Pu W., Zou Z., Chen C. W. Video Adaptation Proxy for Wireless Dynamic Adaptive Streaming over HTTP// Proc. of 19th Intern. Packet Video Workshop, Munich, May 10-11, 2012. P. 65-70.

20. Khan A., Sun L., Jammeh E., Ifeachor E. Quality of Experience-Driven Adaptation Scheme for Video Applications over Wireless Networks. 2010. N 11. P. 1337-1347. doi:10.1049

21. Hosek J., Ries M., Vajsar P., Nagy L., Sulc Z., Hais P., Penizek R. Mobile web QoE Study for Smartphones// 2013 IEEE Globecom Workshops (GC Wkshps), Atlanta, December 9-13, 2013. P. 1157-1161.

22. Hosek J., Vajsar P., Nagy L., Ries M., Galinina O., Andreev S., Koucheryavy Y., Sulc Z., Hais P., Penizek R. Predicting user QoE Satisfaction in Current Mobile Networks// 2014 IEEE Intern. Conf. on Communications (ICC), Sydney, June 10-14, 2014. P. 10881093.

23. Chen Y. C., Chang J. W., Wei H. Y. A Multi-level QoE Framework for Smartphone Video Streaming Applications// 2014 Globecom Workshops (GC Wkshps), Austin, December 8-12, 2014. Moscow, 2014. P. 225230.

UDC 621.391.1

doi:10.15217/issn1684-8853.2017.3.75

Transmission and Quality-of-Experience Estimation for HTTP-based Video. A Survey

Pastushok I. A.a, Assistant Professor, i.pastushok@vu.spb.ru

aSaint-Petersburg State University of Aerospace Instrumentation, 67, B. Morskaia St., Saint-Petersburg, 190000, Russian Federation

Introduction: The rise in the number of users and video traffic amount in modern telecommunication networks leads to the idea that the networks already available should be adapted to video transmission. The greatest amount of video traffic is transmitted using «Dynamic Adaptive Streaming over HTTP (DASH)» technology which is based on HTTP protocol. Purpose: Our goal is a survey of HTTP video transmission technologies and Quality-of-Experience estimations in order to choose a methodology of estimating Quality of Experience depending on the limited amount of the available objective characteristics. Results: On the base of a survey of HTTP-based video transmission technologies, we have proposed a three-component model which includes the models of a video content server, a network, and the user equipment. The survey has shown that DASH technology leads to a slight increase in the load on the network as compared to other video streaming technologies. However, the technology is invariant to the network structure due to the usage of HTTP and TCP protocols. DASH technology provides less severe network congestions because the video content is stored on the server in several sets of quality. This approach allows the user equipment to select a certain video quality for particular network conditions. Practical relevance: The obtained results provide a way for a software engineer to make decisions about the appropriateness of using DASH for specific network requirements, and for a network-engineer to estimate video user experience at intermediate network nodes. On the base of this estimation, you can organize control in order to improve the network performance. Keywords — HTTP-based Video Transmission, DASH, HPD, HAS, Quality of Experience.

References

1. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update 2016-2021 White Paper 2017. Available at: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/mobile-white-paper-c11-520862.html (accessed 1 April 2017).

2. Makolkina M. A. Video Quality of Experience Evaluation Based on Emotions. Elektrosviaz', 2015, no. 9, pp. 24-28 (In Russian). issn0013-577

3. ISO/IEC 23009-1:2014. Information Technology, Dynamic Adaptive Streaming over HTTP (DASH); Progressive Download and Dynamic Adaptive. ISO/IEC, 2014. 144 p.

4. 3GPP TS 26.247 v14.0.0. Transparent End-to-End Packet Switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming Over HTTP (3GP-DASH). 3GPP, 2016. 104 p.

5. Rekomenduemye nastroiki kodirovaniia [Live Encoder Settings, Bitrates, and Resolutions]. Available at: https://sup-port.google.com/youtube/answer/1722171?hl=ru (accessed 1 April 2017).

6. Video as a Basic Service of LTE Networks: Mobile vMOS Defining Network Requirements. Available at: http://www.hua-wei.com/minisite/4-5g/en/industryjsdc-j.html (accessed 1 April 2017).

7. Oyman O., Singh S. Quality of Experience for HTTP Adaptive Streaming Services. IEEE Communication Magazine, 2012, no. 4, pp. 20-27. doi:10.1109/issn0163-6804

8. Ameigeiras P., Ramos-Munoz J., Navarro-Ortiz J., Lopez-Soler J. M. Analysis and Modelling of YouTube Traffic. Transactions on Emerging Telecommunications Technologies, 2012, no. 23, pp. 360-377. doi:10.1002

9. Dash Industry Forum. Available at: https://github.com/ Dash-Industry-Forum/dash.js/wiki. (accessed 1 April 2017).

10. P.1201. Amendment 2, Parametric Non-intrusive Assessment of Audiovisual Media Streaming Quality Amendment 2: New Appendix III Use of ITU-T P.1201 for Non-adaptive, Progressive Download Type Media Streaming. ITU-T, 2013. 23 p.

11. U-vMOS, Benchmarking Video Experience. Available at: http://www.huawei.com/minisite/ubbf2015/ppt/PPT-111-vM0S-Video%2 0Experience%2 0Standard%2 0-% 20Ken%20Wang% 20-% 2020150908% 20V1.pdf (accessed 1 April 2017).

12. U-vMOS SDK. Available at: http://developer.huawei.com/ ru/ict/Products/TelecoSoftware/VideoExperienceCapbili-ty/U-vMOS/SDK (accessed 1 April 2017).

13. Ramamurthi V., Oyman O. Video-QoE Aware Radio Resource Allocation for HTTP Adaptive Streaming. IEEE ICC 2014 — Communication QoS, Reliability and Modeling Symp., Sydney, 2014, pp. 1076-1081.

14. Pastushok I., Turlikov A. Lower Bound and Optimal Scheduling for Mean user Rebuffering Percentage of HTTP Progressive Download Traffic in Cellular Networks. 2016 XV

Intern. Symp. Problems of Redundancy in Information and Control Systems (REDUNDANCY). Saint-Petersburg, 2016, pp. 105-111.

15. Bakin E., Evseev G., Turlikov A. Lower Bound of Mean user Waiting/Watching Time Ratio in Wireless Video Streaming Network. 2014 IEEE Global Communications Conf., Austin TX, 2014, pp. 1170-1175.

16. Essaili A. E., Schroeder D., Staehle D., Shehada M., Kellerer W., Steinbach E. Quality-of-Experience Driven Adaptive HTTP Media Delivery. IEEE ICC 2013 — Communication QoS, Reliability and Modeling Symp., Budapest, 2013, pp. 2480-2485.

17. Borisovskaya A. V., Pastushok I. A. Overview of Heuristic Algorithm for Selecting Suboptimal Values of Characteristics of Video Steream and Parameters of MAC Scheduling Algorithm. Sbornik dokladov nauchnoi sessii GUAP [Collection of Reports of the Scientific Session of SUAP]. Saint-Petersburg, 2015, pp. 209-219 (In Russian).

18. Bui N., Valentin S., Widmer J. Anticipatory Quality-Resource Allocation for Multi-user Mobile Video Streaming. 2015 IEEE Conference on Computer Communications Work-

shops (INFOCOM WKSHPS). Hong Kong, 2015, pp. 245250.

19. Pu W., Zou Z., Chen C. W. Video Adaptation Proxy for Wireless Dynamic Adaptive Streaming over HTTP. Proc. of 19th Intern. Packet Video Workshop, Munich, 2012, pp. 65-70.

20. Khan A., Sun L., Jammeh E., Ifeachor E. Quality of Experience-Driven Adaptation Scheme for Video Applications over Wireless Networks. IET Communications, 2010, no. 11, pp. 1337-1347. doi:10.1049

21. Hosek J., Ries M., Vajsar P., Nagy L., Sulc Z., Hais P., Penizek R. Mobile web QoE Study for Smartphones. 2013 IEEE Globe-com Workshops (GC Wkshps), Atlanta, 2013, pp. 1157-1161.

22. Hosek J., Vajsar P., Nagy L., Ries M., Galinina O., Andreev S., Koucheryavy Y., Sulc Z., Hais P., Penizek R. Predicting user QoE Satisfaction in Current Mobile Networks. 2014 IEEE Intern. Conf. on Communications (ICC), Sydney, 2014, pp. 1088-1093.

23. Chen Y. C., Chang J. W., Wei H. Y. A Multi-level QoE Framework for Smartphone Video Streaming Applications. 2014 Globecom Workshops (GC Wkshps), Austin TX, 2014, pp. 225-230.

Уважаемые авторы!

При подготовке рукописей статей необходимо руководствоваться следующими рекомендациями.

Статьи должны содержать изложение новых научных результатов. Название статьи должно быть кратким, но информативным. В названии недопустимо использование сокращений, кроме самых общепринятых (РАН, РФ, САПР и т. п.).

Объем статьи (текст, таблицы, иллюстрации и библиография) не должен превышать эквивалента в 20 страниц, напечатанных на бумаге формата A4 на одной стороне через 1,5 интервала Word шрифтом Times New Roman размером 13, поля не менее двух сантиметров.

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

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

Формулы набирайте в Word, не используя формульный редактор (Mathtype или Equation), при необходимости можно использовать формульный редактор; для набора одной формулы не используйте два редактора; при наборе формул в формульном редакторе знаки препинания, ограничивающие формулу, набирайте вместе с формулой; для установки размера шрифта никогда не пользуйтесь вкладкой Other... , используйте заводские установки редактора, не подгоняйте размер символов в формулах под размер шрифта в тексте статьи, не растягивайте и не сжимайте мышью формулы, вставленные в текст; в формулах не отделяйте пробелами знаки: + = -.

Для набора формул в Word никогда не используйте Конструктор (на верхней панели: «Работа с формулами» — «Конструктор»), так как этот ресурс предназначен только для внутреннего использования в Word и не поддерживается программами, предназначенными для изготовления оригинал-макета журнала.

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

Иллюстрации предоставляются отдельными исходными файлами, поддающимися редактированию:

— рисунки, графики, диаграммы, блок-схемы предоставляйте в виде отдельных исходных файлов, поддающихся редактированию, используя векторные программы: Visio 4, 5, 2002-2003 (*.vsd); Coreldraw (*.cdr); Excel (*.xls); Word (*.doc); AdobeIllustrator (*.ai); AutoCad (*.dxf); Matlab (*.ps, *.pdf или экспорт в формат *.ai);

— если редактор, в котором Вы изготавливаете рисунок, не позволяет сохранить в векторном формате, используйте функцию экспорта (только по отношению к исходному рисунку), например, в формат *.ai, *.esp, *.wmf, *.emf, *.svg;

— фото и растровые — в формате *.tif, *.png с максимальным разрешением (не менее 300 pixels/inch).

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

В редакцию предоставляются:

— сведения об авторе (фамилия, имя, отчество, место работы, должность, ученое звание, учебное заведение и год его окончания, ученая степень и год защиты диссертации, область научных интересов, количество научных публикаций, домашний и служебный адреса и телефоны, e-mail), фото авторов: анфас, в темной одежде на белом фоне, должны быть видны плечи и грудь, высокая степень четкости изображения без теней и отблесков на лице, фото можно представить в электронном виде в формате *.tif, *.png с максимальным разрешением — не менее 300 pixels/inch при минимальном размере фото 40x55 мм;

— экспертное заключение.

Список литературы составляется по порядку ссылок в тексте и оформляется следующим образом:

— для книг и сборников — фамилия и инициалы авторов, полное название книги (сборника), город, издательство, год, общее количество страниц;

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

— ссылки на иностранную литературу следует давать на языке оригинала без сокращений;

— при использовании web-материалов указывайте адрес сайта и дату обращения.

Список литературы оформляйте двумя отдельными блоками по образцам lit.dot на сайте журнала (http://i-us.ru/paperrules) по разным стандартам: Литература — СИБИД РФ, References — один из мировых стандартов.

Более подробно правила подготовки текста с образцами изложены на нашем сайте в разделе «Оформление статей».

Контакты Куда: 190000, Санкт-Петербург, Б. Морская ул., д. 67, ГУАП, РИЦ Кому: Редакция журнала «Информационно-управляющие системы» Тел.: (812) 494-70-02 Эл. почта: ius.spb@gmail.com Сайт: www.i-us.ru