TCP против UDP в потоке видео

Я только что вернулся со своего экзамена по сетевому программированию, и один из вопросов, который они задали нам, был . Если вы собираетесь передавать видео, используете ли вы TCP или UDP? Дайте объяснение как сохраненным видео и живые видеопотоки ". На этот вопрос они просто ожидали короткий ответ TCP для сохраненного видео и UDP для видео в реальном времени, но я думал об этом по дороге домой, и разве обязательно лучше использовать UDP для потокового видео в реальном времени? Я имею в виду, если у вас есть пропускная способность для него, и скажите, что вы потоковываете футбольный матч или концерт в этом отношении, вам действительно нужно использовать UDP?

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

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

Итак, это подводит меня к моему вопросу. Есть ли недостатки, которые я не знаю об использовании TCP для потоковой передачи в реальном времени? Или должно быть, действительно, если у вас есть пропускная способность для него, вы должны пойти на TCP, учитывая, что он "лучше" для сети (управление потоком)?

Ответ 1

Недостатки использования TCP для видео в реальном времени:

Обычно потоковые видеопотоки не разработаны с учетом потока TCP. Если вы используете TCP, ОС должна буферизовать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий; предположительно, ваш список одновременных клиентов длинный из-за особенностей события. Предварительно записанные видео-роли обычно не имеют такой проблемы, потому что зрители размахивают своей деятельностью по воспроизведению; поэтому TCP более подходит для воспроизведения видео по требованию.
Многоадресная передача IP значительно снижает требования к пропускной способности видео для большой аудитории; TCP предотвращает использование многоадресной рассылки IP, но UDP хорошо подходит для многоадресной рассылки IP.
Живое видео, как правило, представляет собой поток с постоянной пропускной способностью, записанный с камеры; предварительно записанные видеопотоки сходят с диска. Динамика потерь в обратном канале TCP затрудняет обслуживание живого видео, когда исходные потоки имеют постоянную полосу пропускания (как это было бы для живого события). Если вы загружаете диск на диск с камеры, убедитесь, что у вас достаточно буфера для непредсказуемых сетевых событий и переменных TCP/Sendoff. Обратите внимание: если TCP теряет слишком много пакетов, соединение умирает; таким образом, UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижении транспортного уровня сети.

FYI, пожалуйста, не используйте слово "пакеты" при описании сетей. Сети отправляют "пакеты".

Ответ 2

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

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

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

Ответ 3

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

Если ваш прямой эфир использует TCP/IP, он будет вынужден ждать тех упавших пакетов до, что он может продолжить обработку более новых данных.

Это вдвойне плохо:

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

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

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

Ответ 4

Есть некоторые варианты использования, подходящие для транспорта UDP, и другие, подходящие для транспорта TCP.

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

При использовании многоадресной рассылки для доставки видео вашим клиентам используется UDP.

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

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

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

Рабочий процесс Unicast (TCP) позволяет серверу проверять учетные данные клиента и разрешать только действительные подписки. Даже разрешите только определенное количество одновременных подключений.

Многоадресная рассылка не включена через Интернет.

Для доставки видео через Интернет необходимо использовать TCP. Когда UDP используется, разработчики заканчивают повторную реализацию повторной передачи пакетов, например. Протокол Bittorrent p2p live.

"Если вы используете TCP, ОС должна буферизовать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий".

Этот буфер должен существовать в некоторой форме. То же самое верно для буфера дрожания на стороне игрока. Он называется "буфером сокетов", и серверное программное обеспечение может знать, когда этот буфер заполнен, и отбросить правильные видеофрагменты для прямых потоков. Лучше использовать метод одноадресной /TCP, потому что серверное программное обеспечение может реализовать правильную логику сброса кадров. Случайные отсутствующие пакеты в случае UDP просто создадут плохой пользовательский интерфейс. как в этом видео: http://tinypic.com/r/2qn89xz/9

"Многоадресная передача IP значительно снижает требования к пропускной способности видео для больших аудиторий"

Это верно для частных сетей, многоадресная рассылка не включена через Интернет.

"Обратите внимание: если TCP теряет слишком много пакетов, соединение умирает, поэтому UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижении уровня сетевого транспорта."

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

"Обычно видеопоток несколько отказоустойчив"

Кодированное видео не является отказоустойчивым. При передаче по ненадежным транспортным средствам в видеоконтейнер добавляется исправление ошибок. Хорошим примером является контейнер MPEG-TS, используемый в спутниковой передаче видео, которые несут несколько потоков аудио, видео, EPG и т.д. Это необходимо, поскольку спутниковая связь не является дуплексной связью, то есть приемник не может запросить повторную передачу потерянных пакетов.

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

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

Результат отсутствия пакетов - это артефакты, подобные этому:

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

Ответ 5

Это зависит. Насколько критичен контент, который вы передаете? Если критическое использование TCP. Это может вызвать проблемы с пропускной способностью, качеством видео (возможно, вам придется использовать более низкое качество для работы с задержкой) и латентностью. Но если вам нужен контент, чтобы его можно было получить, используйте его.

В противном случае UDP должен быть точным, если поток не является критическим и будет предпочтительным, поскольку UDP имеет меньше затрат.

Ответ 6

Я рекомендую вам посмотреть новый протокол p2p Bittorent Live.

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

Ответ 7

Одна из самых больших проблем с доставкой живых событий в Интернете - "масштаб", а TCP не очень хорошо масштабируется. Например, когда вы сидите в прямом футбольном матче, и против воспроизведения фильма по требованию - количество людей, которые смотрят, может быть легко в 1000 раз больше. В таком сценарии использование TCP является смертельным приговором для CDN (сетей доставки контента).

Существует несколько основных причин, по которым TCP плохо масштабируется:

Одним из самых больших компромиссов TCP является изменчивость пропускной способности, достигаемая между отправителем и получателем. При потоковой передаче видео через Интернет видеопакеты должны проходить через несколько маршрутизаторов через Интернет, каждый из этих маршрутизаторов связан с различными скоростными соединениями. Алгоритм TCP начинается с небольшого окна TCP, затем растет до тех пор, пока не будет обнаружена потеря пакетов, потеря пакетов считается признаком перегрузки, и TCP реагирует на него, резко уменьшая размер окна, чтобы избежать перегрузки. Таким образом, в свою очередь, сразу снижается эффективная пропускная способность. Теперь представьте себе сеть с передачей TCP с использованием 6-7 переходов маршрутизатора для клиента (очень обычный сценарий), если какой-либо из промежуточного маршрутизатора теряет любой пакет, TCP для этой ссылки уменьшит скорость передачи. Фактически поток трафика между маршрутизаторами соответствует форме песочных часов; всегда гонг вверх и вниз между одним из промежуточных маршрутизаторов. Предоставление эффективного сквозного перевода намного ниже по сравнению с UDP с максимальным усилием.
Как вы уже знаете, TCP - это протокол, основанный на подтверждении. Например, скажем, отправитель находится на расстоянии 50 мс (т.е. Задержка между двумя точками). Это будет означать время, которое требуется для отправки пакета в приемник и приемник для отправки подтверждения, равным 100 мс; таким образом, максимальная пропускная способность, возможная по сравнению с передачей на основе UDP, уже уменьшена вдвое.
TCP не поддерживает многоадресную рассылку или новый новый стандарт многоадресной передачи AMT. Это означает, что CDN не имеют возможности сократить сетевой трафик путем репликации пакетов - когда многие клиенты просматривают один и тот же контент. Это само по себе является достаточной причиной для CDN (например, Akamai или Level3), чтобы не переходить с TCP для живых потоков.

Ответ 8

Для полосы пропускания видеопотока, вероятно, существует ограничение на систему. Используя многоадресную рассылку, вы можете значительно уменьшить количество используемой полосы пропускания. С UDP вы можете легко переадресовать свои пакеты на все подключенные терминалы. Вы также можете использовать надежный протокол многоадресной рассылки, один называется Pragmatic General Multicast (PGM), я ничего не знаю об этом, и я предполагаю, что он не распространен в его использовании.

Ответ 9

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

TCP может намного легче проходить через брандмауэры и NAT. В зависимости от вашего NAT и оператора вы даже не сможете получать поток UDP из-за проблем с перфорированием отверстий UDP.

Ответ 10

Все ответы "использовать UDP" предполагают открытую сеть и "заставляют ее использовать столько, сколько вы можете". Хорошо подходит для закрытых садов в закрытом саду аудио/видео сетей, которые исчезают.

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

Ответ 11

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

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

UDP испытывает потерю пакетов. В течение секунды во время видеопотока угол экрана становится немного расплывчатым. Никто не замечает, и шоу продолжается, не ища потерянные пакеты.

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

UDP FTW при потоковой передаче.

Ответ 12

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

Случай 1: последовательные пакеты теряются в течение нескольких секунд. = > живое видео остановится на стороне клиента независимо от уровня транспорта (TCP или UDP). Когда сеть восстанавливается: - если используется TCP, клиентский видеоплеер может выбрать перезапуск потока при первом потерянном пакете (временный сдвиг) ИЛИ удалить все поздние пакеты и перезапустить видеопоток без временного сдвига. - если используется UDP, на стороне клиента нет выбора, перезагрузка видео в реальном времени без какого-либо временного сдвига. = > TCP равно или лучше.

Случай 2: некоторые пакеты случайно и часто теряются в сети. - если используется TCP, эти пакеты будут немедленно ретранслироваться и с правильным буфером дрожания не повлияют на качество/латентность видеопотока. - если используется UDP, качество видео будет неудовлетворительным. = > TCP гораздо лучше

Ответ 13

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