Размер буфера: 100000.

Расчетно-пояснительная записка к
курсовому проекту по теме:
Надежная передача потокового видео: исследование поведения
видео трафика реального времени в различных условиях загрузки
сети.
Студент: Плахин И.А.
Группа: ИУ3-91
Преподаватель: Федоров С.В.
Москва, 2010г
1
Введение
Все большая часть информации, предоставляемой конечному пользователю,
передается через компьютерные сети: интернет, локальные сети и т.д. Сухие новостные
порталы понемногу уходят в прошлое, и наступает время онлайнового вещания
телевидения. Это стало возможным, поскольку появились производительные алгоритмы
для сжатия видео с минимальными потерями. Однако, передача видео реального
времени по сети неизбежно осложняется следующими факторами: ширина канала, ее
изменение от времени, задержки, потери и другие. Так же нерешенными остаются
проблема, как эффективно передавать видео контент по схеме один ко многим.
Цель
1. Исследовать существующие технологии по передачи потокового видео, понять их
преимущества и недостатки (в частности: RTP). Исследовать возможности IPv6 по
передаче потоковых данных.
2. Исследовать инструменты и библиотеки, которые можно использовать для
организации передачи видео в режиме реального времени.
3. Сконструировать систему с помощью, которой можно проводить анализ
математической модели потерь в интернете и локальных сетях. Проанализировать
результаты.
4. Продумать модель сети из ВМ для дальнейших экспериментов и разработок.
Описание стенда для построения
модели ошибок передачи пакетов в
компьютерных сетях
Задачи
1. Протестировать передачу UDP пакетов через компьютерную сеть на различных
режимах передачи и условиях в сети.
2. Собрать данные в удобном для анализа виде, построить графики, зависимости и
посчитать показатели процессов.
3. Сделать выводы исходя из полученных данных, о том какие параметры и факты
нужно учитывать при проектировании системы передачи потоковой
видеоинформации в режиме реального времени.
2
Теоретическое обоснование
Для тестирования был выбран транспортный протокол UDP, поскольку вся
ответственность за доставку пакетов лежит на уровне приложения, а не на уровне стека
системы, как в случае с протоколом TCP. Если пакет или группа пакетов повреждаются или
вовсе не приходят получателю, то стек протокола TCP вызывает повторную передачу
столько раз сколько необходимо для успешного завершения передачи. В случае с
видеоинформацией реального времени такой подход не слишком хорош, поскольку это
вносит существенные задержки в процесс воспроизведения видео в программе
конечного пользователя.
Природа видеоинформации, описанная выше, позволяет «потерять» пакеты из
видео потока без сильного влияния на информацию, которую видит пользователь. То есть
если мы обеспечиваем надежную передачу базовых кадров, то для других кадров
допустимо иметь ошибки или вообще не быть принятыми, поскольку конечной целью
является идея о безостановочном воспроизведении пусть даже с некоторой потерей
качества.
Структура стенда
Стенд состоит из клиентской и серверной части, программные реализации которых были
написаны под ОС Linux и базы данных MySQL, используемой для хранения логов передачи
и приема.
Для проведения испытаний требуются два ПК с ОС Linux, и установленным сервером базы
данных MySQL, причем на ПК с серверной частью программы доступ к базе данных
должен быть открыт извне.
В каждый UDP пакет закладывается полезная нагрузка – идентификатор пакета, затем
идут байты заполненные случайными данными. Перед отправкой или после получения
соответственно отправитель и получатель вычисляют текущее системное время и
сохраняют её вместе с идентификатором пакета в базу данных.
Дальнейшие вычисления основываются на данных которые содержатся в каждой
из этих таблиц после того как модули передачи и приема закончат свою работу.
3
Результаты экспериментов
Было проведено несколько экспериментов по передаче UDP-пакетов по кафедральной сети.
Целью эксперимента было выяснить влияние параметров отправки (размер пакета, задержка
между отправками пакетов) и размера буфера приемника на качество приема пакетов (процент
потерь, групповые ошибки и т.д.). Результаты занесены в таблицу. Составлены графики изменения
времени пакета в пути от кол-ва отправленных/принятых пакетов по каждому эксперименту.
Базовый опыт №1.
Передано пакетов: 7152.
Размер буфера: 8000.
Размер пакета: 128.
Задержка при отправке: 1мкс.
Задержка, мс
1000
800
600
400
200
1
10
19
28
37
46
55
64
73
82
91
100
109
118
127
136
145
154
163
172
181
190
199
208
217
226
235
244
253
262
271
280
289
298
0
Номер принятого пакета
Рис.1.
Наблюдаем резкий скачок времени задержки (рис.1), начиная с 388-го принятого (1554-го
отправленного) пакета. Объясняется малым размером буфера принимающей части. До первого
переполнения буфера время между отправкой пакета и регистрацией его приемной частью
минимально (порядка 1мс), далее – резкий рост времени доставки. Последующий ровный
характер графика объясняется быстрым опустошением буфера (до определенного уровня) и его
последующим заполнением. При увеличении отдельного участка наблюдается пилообразный
профиль (скачок – переполнение буфера, плавный спад – чтение пакетов из буфера) на рис.2:
Рис.2.
4
Базовый опыт №2.
Передано пакетов: 5736.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 1мкс.
При большом размере буфера передача идет нелинейно-постоянно, то есть ровно, без
серьезных провалов. Пиковые значения могут относиться к периодически возрастающей
нагрузке на сеть/маршрутизатор от других пользователей.
1
0.9
0.8
0.6
0.5
0.4
0.3
0.2
0.1
0
1
88
175
262
349
436
523
610
697
784
871
958
1045
1132
1219
1306
1393
1480
1567
1654
1741
1828
1915
2002
2089
2176
2263
2350
2437
2524
2611
2698
2785
2872
2959
Задержка, с
0.7
Номер принятого пакета
Рис.3.
5
Увеличим размер буфера (относительно базового опыта №1).
Уменьшим размер пакета (относительно базового опыта №2).
Передано пакетов: 4957.
Размер буфера: 100000.
Размер пакета: 128.
Задержка при отправке: 1мкс.
Предположительно, во время проведения опыта была серьезная нагрузка на сетевое
оборудование, в связи с чем величина задержки возрастает почти монотонно и достигает
~30мс к моменту прихода последних пакетов. По сравнению с базовым опытом №2,
условия улучшились, а показатели ухудшились.
35
30
25
15
10
5
0
1
87
173
259
345
431
517
603
689
775
861
947
1033
1119
1205
1291
1377
1463
1549
1635
1721
1807
1893
1979
2065
2151
2237
2323
2409
2495
2581
2667
2753
2839
2925
Задержка, с
20
-5
Номер принятого пакета
Рис.4.
6
Увеличим размер пакета и задержку при отправке пакетов.
Передано пакетов: 5681.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 25мкс.
Характер передачи остался тем же, т.е. увеличение размера пакета и увеличение
задержки нивелировали влияние друг друга. Отметим, что вследствие уменьшения
скорости отправки данных, максимальная задержка к концу передачи составляет ~20с.
Показатели групповых потерь пакетов практически совпадают.
25
15
10
5
0
1
100
199
298
397
496
595
694
793
892
991
1090
1189
1288
1387
1486
1585
1684
1783
1882
1981
2080
2179
2278
2377
2476
2575
2674
2773
2872
2971
3070
3169
3268
3367
3466
Задержка, с
20
Номер принятого пакета
Рис.5.
7
Повторим предыдущий опыт, увеличив число отправленных
пакетов до ~10000.
Передано пакетов: 9871.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 25мкс.
Как видим, сеть снова разгрузилась, и максимальная задержка к концу передачи
составила ~6мс. Но монотонно возрастающий характер изменения задержки сохраняется
(рис.6). Наблюдается незначительное увеличение средней длины групповой потери
пакетов.
7
6
5
3
2
1
0
1
116
231
346
461
576
691
806
921
1036
1151
1266
1381
1496
1611
1726
1841
1956
2071
2186
2301
2416
2531
2646
2761
2876
2991
3106
3221
3336
3451
3566
3681
3796
3911
4026
Задержка, с
4
-1
Номер принятого пакета
Рис.6.
8
Повторим предыдущий опыт, увеличив число отправленных
пакетов до ~15000.
Передано пакетов: 15641.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 25мкс.
Теория монотонного роста задержки (а не вида арктангенса) при заданных параметрах
подтверждена. Необходимо уменьшать размер пакета или же уменьшить частоту
отправки пакетов.
Снова наблюдается незначительное увеличение средней длины групповой потери
пакетов.
14
12
8
6
4
2
0
1
193
385
577
769
961
1153
1345
1537
1729
1921
2113
2305
2497
2689
2881
3073
3265
3457
3649
3841
4033
4225
4417
4609
4801
4993
5185
5377
5569
5761
5953
6145
6337
6529
Задержка, с
10
Номер принятого пакета
Рис.7.
9
Увеличим задержку при отправке пакетов.
Передано пакетов: 10240.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 700мкс.
Характер изменения задержки снова становится нелинейно-постоянным, т.е.
маршрутизатор справляется с нагрузкой.
1.2
1
0.6
0.4
0.2
0
1
173
345
517
689
861
1033
1205
1377
1549
1721
1893
2065
2237
2409
2581
2753
2925
3097
3269
3441
3613
3785
3957
4129
4301
4473
4645
4817
4989
5161
5333
5505
5677
5849
Задержка, с
0.8
-0.2
Номер принятого пакета
Рис.8.
10
Увеличим задержку при отправке пакетов.
Передано пакетов: 10088.
Размер буфера: 100000.
Размер пакета: 1000.
Задержка при отправке: 2000мкс.
Картина аналогичная предыдущей, то есть дальнейшее уменьшение частоты посыла
пакетов не приведет к уменьшению задержек. Но при увеличении периода отправки
примерно в 3 раза процент потерь упал в 2.5 раза, в основном за счет уменьшения кол-ва
групповых потерь пакетов.
1.4
1.2
1
0.6
0.4
0.2
0
1
242
483
724
965
1206
1447
1688
1929
2170
2411
2652
2893
3134
3375
3616
3857
4098
4339
4580
4821
5062
5303
5544
5785
6026
6267
6508
6749
6990
7231
7472
7713
7954
8195
Задержка, с
0.8
-0.2
Номер принятого пакета
Рис.9.
11
Установим задержку при отправке 1мкс и увеличим размер пакета
до 1200.
Передано пакетов: 10557.
Размер буфера: 100000.
Размер пакета: 1200.
Задержка при отправке: 1мкс.
По сравнению с передачей пакетов размером 1000байт, увеличился наклон кривой, т.е.
увеличился рост задержки со временем. Сильно уменьшилась средняя длина групповых
потерь.
45
40
35
30
20
15
10
5
0
1
179
357
535
713
891
1069
1247
1425
1603
1781
1959
2137
2315
2493
2671
2849
3027
3205
3383
3561
3739
3917
4095
4273
4451
4629
4807
4985
5163
5341
5519
5697
5875
6053
Задержка, с
25
-5
Номер принятого пакета
Рис.10.
12
Сводная таблица результатов
экспериментов
Exp.
4
Exp.
5
Exp.
6
Exp.
7
Exp.
8
Exp.
9
Exp.
10
Exp.
11
Exp.
12
Exp.
13
Exp.
14
PackSize,
byte
RcvBuffer Send
Delay
Packets
send
Packets
received
Lost,
%
Burst
Errors
Length
27
1 2 3
88.31
Burst
Errors,
num
739
128
8000
1
7152
2640
1000
100000
1
5736
2921
49.08
81
35
0 0 0
128
100000
1
4957
2991
39
92
21
0 0 0
128
100000
0
5719
2207
61
75
46
0 0 0
1000
100000
25
5681
3549
37.54
91
23
0 0 0
1000
100000
25
9871
4119
58.28
225
25
0 0 0
1000
100000
25
15641
6718
57
287
31
0 0 0
1000
100000
700
10240
6005
41.36
303
13
1 0 0
1000
100000
2000
10088
8426
16.48
74
22
1 0 0
1200
100000
1
10557
6209
41
183
24
0 1 0
1200
100000
2000
9993
8722
12.75
79
16
1 0 0
13
0 0 0
Выводы по экспериментам
Мы можем варьировать следующими параметрами – скоростью передачи (в виде
задержки при отправке и размера пакета) и размером буфера принимающей стороны.
Скорость передачи




Малая задержка при отправке приводит к частым переполнениям буфера и как
следствие – большому количеству групповых потерь. Большая задержка ведет к
повышению процента принятых пакетов, но снижает скорость передачи (при
одинаковых размерах пакета). Частота отправки может использоваться как
механизм управления передачей при изменении состояния канала (пропускной
способности).
При большой задержке падает средняя длина групповых потерь.
Размер пакета влияет на частоту групповых потерь. Передача больших пакетов
приводит к частым провалам в приеме из-за недостаточного размера буфера
принимающей стороны.
Дополнительные эксперименты покажут, какой вариант предпочтительнее –
частая отправка маленьких пакетов или редкий посыл больших.
Буфер приемника

Размер буфера должен рассчитываться исходя из скорости передачи данных.
Изменять его объем динамически нежелательно, потому необходимо выбрать
объем, ориентируясь на максимально возможную скорость передачи
(минимизируя потери от переполнения буфера).
Эксперименты по отправке одновременно пакетов разной длины с большой задержкой,
в т.ч. в течение большого периода времени (до суток), покажут процент потерь
пакетов в зависимости от размера.
Также планируется проверить влияние проверки целостности пакета UDP на качество
приема и конечные цифры.
14
IPv6
Ниже рассмотрим вкратце формат пакета IPv6 и какие его особенности можно использовать для
передачи потоковых данных и управления потоками.
Структура пакета








Версия 4-битный код номера версии Интернет протокола (версия Интернет протокола для
IPv6= 6).
Приор. 4-битный код приоритета.
Метка потока 24-битный код метки потока (для мультимедиа).
Размер поля данных 16-битовое число без знака. Несет в себе код длины поля данных в
октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина
поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне
опций.
Следующий заголовок 8-битовый разделитель. Идентифицирует тип заголовка, который
следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол
IPv4.
Предельное число шагов 8-битовое целое число без знака. Уменьшается на 1 в каждом
узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет
удаляется.
Адрес отправителя 128-битовый адрес отправителя пакета.
Адрес получателя 128-битовый адрес получателя пакета (возможно не конечный
получатель, если присутствует маршрутный заголовок).
15
Управление потоком (некоторые моменты)

Традиционно поток определялся как совокупность таких полей как адреса
отправителя/получателя, порты и тип протокола. В IPv6 поток идентифицировать
поток как последовательность пакетов от одного отправителя и с одинаковым
полем Метка потока.

Метка потока представляет собой число, однозначно идентифицирующее поток.
Выбирается произвольным образом.

IPv6 также позволяет управлять потоком путем задания приоритета всего потока
или отдельных пакетов в нем. Поле Приоритет содержит 4битное число (от 0 до
15), которое указывает на тип передачи (с управлением перегрузками или без
таковой и т.д.). Предположительно при передаче возможно повышение
приоритета пакетов, содержащих базовые кадры, для более надежной и быстрой
передачи этих самых базовых кадров.

Маршрутизатор (поддерживающий работу с IPv6) сможет распознать в сетевом
трафике поток и будет обрабатывать его универсально, одинаково для всех
пакетов. При этом информация о том, как именно обрабатывать пакеты, может как
находиться в одном из заголовков пакета, так и быть получена через управляющий
протокол.
16
Модель IPv6-сети
В рамках изучения IPv6 была создана виртуальная сеть – 2 виртуальные машины на MS
WinXP SP2, связанные напрямую виртуальным же кабелем.

Поддержка IPv6 в WinXP – экспериментальная. По умолчанию отключена,
включается командой ipv6 install или netsh interface ipv6 install (установка через
netsh – Network Shell – более предпочтительна).
Первым делом хотелось проверить работоспособность команды ping для 6-х адресов.


Для первой виртуальной машины (winXP, winxp3sp3.vdi) для IPv4 был установлен
адрес 194.168.1.2, после установки IPv6 командой netsh > interface ipv6 > add
address “4” 2000::1234 был добавлен IPv6-адрес 2000::1234 (выбран произвольно;
«::» означает нулевые поля в адресе).
Аналогично для второй машины (winXP2, winxp3sp3_1.vdi) был добавлен адрес
2000::4321.
С обеих машин команда ping <ipv6-адрес назначения> показывает те же результаты
работы, что и ping <ipv4-адрес назначения>. При этом машины принимают пакеты по
обоим адресам, и IPv4, и IPv6. В программе Wireshark убедились, что приходят пакеты по
протоколу ICMPv6.Задержек не замечено, времена приема-передачи во всех случаях
порядка 1мс (собственно, локальная сеть). При перезагрузке добавленные адреса не
обнуляются.
Позднее появились трудности с IPv6, а именно – появилась необходимость
периодически (но не каждый запуск системы) обновлять службу, регулирующую работу
IPv6, командой renew. В противном случае компьютер не может быть обнаружен в
сети по IPv6-адресу. Проблема, скорее всего, в устаревшей WinXP (возможно, помогла
бы установка SP3).
Следующие опыты
Дальнейшие опыты целесообразно проводить на ВМ с системами Linux или Windows 7,
в полной мере поддерживающими работу с протоколом IPv6. Однако, остается
открытым вопрос, какой процент сетевых устройств поддерживает работу с этим
протоколом и будет корректно и главное эффективно обрабатывать поток. В
противном случае выгоды не будет никакой, неизвестные опции/заголовки
маршрутизатор будет игнорировать и работать с пакетами в порядке «общей
очереди».
17
RTP/ RTCP
Следует сказать, что характерные для IP-сетей временные задержки и вариация задержки
пакетов (джиттер) могут серьезно исказить информацию, чувствительную к задержке, в
нашем случае видео и речь, сделав ее абсолютно непригодной для восприятия. Отметим,
что вариация задержки пакетов гораздо сильнее влияет на субъективную оценку качества
передачи, чем абсолютное значение задержки.
Для уменьшения джиттера и задержек могут применяться механизмы, обеспечивающие
пользователю заданный уровень качества обслуживания. Они, конечно, улучшают качество
услуг, предоставляемых сетью, но не могут совсем устранить образование очередей в
сетевых устройствах и совсем убрать джиттер.
Протокол RTP позволяет компенсировать негативное влияние джиттера на качество
речевой и видеоинформации. В то же время, он не имеет собственных механизмов,
гарантирующих своевременную доставку пакетов или другие параметры качества услуг, это осуществляют нижележащие протоколы. Он даже не обеспечивает все те функции,
которые обычно предоставляют транспортные протоколы, в частности функции
исправления ошибок и управления потоком. Обычно протокол RTP базируется на
протоколе UDP и использует его функции, но может работать и поверх других
транспортных протоколов.

Существует несколько серьезных причин, по которым TCP плохо подходит для передачи
чувствительной к задержкам информации. Во-первых, это алгоритм надежной
доставки пакетов. Пока отправитель повторно передаст пропавший пакет,
получатель будет ждать, результатом чего может быть недопустимое увеличение
задержки. Во-вторых, алгоритм управления при перегрузке в протоколе TCP не
оптимален для передачи речи и видеоинформации. При обнаружении потерь пакетов
протокол TCP уменьшает размер окна, а затем будет его медленно увеличивать.
Однако передача речевой и видеоинформации осуществляется на вполне определенных,
фиксированных скоростях, которые нельзя мгновенно уменьшить, не ухудшив качество
предоставляемых услуг. Правильной реакцией на перегрузку для информационных
потоков этих типов было бы изменение метода кодирования, частоты видеокадров
или размера видеоизображения.
18
Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового
номера пакета в потоке, а также применение временных меток. Отправитель помечает
каждый RTP-пакет временной меткой, получатель извлекает ее и вычисляет суммарную
задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить
его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.
Итак, главная особенность RTP - это вычисление средней задержки некоторого набора
принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой,
равной этому среднему значению. Однако следует иметь в виду, что временная метка RTP
соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если
RTP-пакет разбивается на блоки данных нижележащего уровня, то временная метка уже
не будет соответствовать истинному времени их передачи, поскольку они перед
передачей могут быть установлены в очередь.
Для работы с протоколом и эффективного управления передачей потоковых данных по
RTP для нас представляют интерес следующие поля пакета:


РТ (7 бит) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и
формат данных, включая сжатие и шифрование. В стационарном состоянии
отправитель использует только один тип полезной нагрузки в течение сеанса, но
он может его изменить в ответ на изменение условий, если об этом сигнализирует
протокол управления транспортировкой информации в реальном времени (RealTime Transport Control Protocol).
Порядковый номер пакета (Sequence Number, 16 бит). Каждый источник начинает
нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с
каждым переданным пакетом RTP. Это позволяет обнаруживать потери пакетов и
определять порядок пакетов с одинаковым временным штампом. Несколько
последовательных пакетов могут иметь один и тот же штамп, если логически они
19


порождены в один и тот же момент, как, например, пакеты, принадлежащие
одному и тому же видеокадру.
Временной штамп (Timestamp, 32 бита). Момент времени, в который был создан
первый октет данных полезной нагрузки. Единицы, в которых время указывается в
этом поле, зависят от типа полезной нагрузки. Значение определяется по
локальным часам отправителя.
Идентификатор SSRC (Synchronization Source Identifier, 32 бита) - поле
идентификатора источника синхронизации. Псевдослучайное число, которое
уникальным образом идентифицирует источник в течение сеанса и не зависит от
сетевого адреса. Это число играет важную роль при обработке порции данных,
поступившей от одного источника.
Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control
Protocol). Основной функцией протокола RTCP является организация обратной связи
приемника с отправителем информации для отчета о качестве получаемых данных.
Протокол RTCP передает сведения (как от приемника, так и от отправителя) о числе
переданных и потерянных пакетов, значении джиттера, задержке и т.д. Эта информация
может быть использована отправителем для изменения параметров передачи, например
для уменьшения коэффициента сжатия информации с целью улучшения качества ее
передачи.
RTP не имеет стандартного зарезервированного номера порта. Единственное
ограничение состоит в том, что соединение проходит с использованием чётного
номера, а следующий нечётный номер используется для связи по протоколу RTCP.
20
Стенд на основе оборудования CISCO
для малого бизнеса
Среди решений для малого бизнеса интерес представляют 3 модели - Cisco RVS4000, Cisco
RV 120W и Cisco WRVS4400N. Функциональность трех моделей одинакова (что касается
интересующего нас IPv6). С учетом роста популярности и даже востребованности
беспроводных сетей WiFi, вторая и третья модели более предпочтительны, т.к.
поддерживают WiFi стандарта 802.11n.

Cisco RV 120W – аппаратный firewall и VPN маршрутизатор. Четыре проводных
подключения Ethernet 10/100Мбит. Поддержка беспроводных сетей. Есть возможность
работы в режиме точки доступа.
http://www.cisco.com/en/US/prod/collateral/routers/ps9923/ps10852/DS_C78-59016100.html

Cisco WRVS4400N – VPN маршрутизатор. Четыре проводных подключения Ethernet
10/100/1000Мбит.
http://www.cisco.com/en/US/prod/collateral/routers/ps9923/ps9931/data_sheet_c78496737.html

Cisco RVS4000 – VPN маршрутизатор. Четыре проводных подключения Ethernet
10/100/1000Мбит. Поддержка беспроводных сетей.
http://www.cisco.com/en/US/prod/collateral/routers/ps9923/ps9928/data_sheet_c78496735.html
21
Что касается структуры стенда – предлагается использовать две пары машин с Win7/Linux
(или другие, полноценно поддерживающие работу с IPv6), одна из которых будет
имитировать нагрузку сети, другая же будет будет передавать потоковые данные,
используя IPv6. Также предполагается использовать написанную ранее программу
сниффера для имитации задержек в сети Интернет на основе полученных статистических
данных.
Схема стенда приведена ниже.
22
Выводы
Мы провели работу по подбору материала для изучения методов организации
систем потоковой передачи видео в режиме реального времени. Ознакомились с
основами кодирования видео, и привели информацию о существующих системах, работу
которых можно ощутить, пройдя по ссылкам, указанным в последнем разделе. Был
спроектирован и запущен стенд для экспериментов по передаче видео и выявления
проблем, которые могут возникнуть в таких системах.
Судя по результатам экспериментов на стенде и данным из освященных выше
статей основная сложность состоит в динамическом изменения всех параметров, которые
влияют на процесс передачи видео. Может оказаться выгодным применение каких-либо
оптимизирующих алгоритмов, которые будут сами решать задачу о подборе параметров,
руководствуюсь определенными соотношениями. Очевидно, то при проектировании
протокола нужно исходить из наличия обратной связи между приемником и
передатчиком для адаптации передачи под текущие условия.
23
Использованные источники
информации
1.
2.
3.
4.
5.
IPv6 - http://ipv6.com/articles/general/IPv6-Header.htm
RTP/RTCP - http://www.ietf.org/rfc/rfc1889.txt
Cisco – www.cisco.com
UDP - http://www.29west.com/docs/THPM/udp-buffer-sizing.html
VLC (video streaming) - http://www.videolan.org/vlc/streaming.html
24