Как узнать, когда увеличить битрейт? (Потоковое решение TCP)

Question

У нас есть приложение, которое генерирует данные. Например, захватывать живое видео с камеры и кодировать его. Нам нужно знать, какого размера может быть один кодированный кадр, чтобы он мог быть отправлен по сети и получен без задержки. Так сказать, «прямой поток видео через TCP». Каковы его основные проблемы - личная нагрузка на пользователя и общая нагрузка на сервер. Наши кадры должны иметь такой размер (размер здесь == битрейт), чтобы быть принятым сервером с минимальной задержкой. В моем случае должен использоваться TCP (мы должны отправить все захваченные кадры, даже если их качество упадет)

У нас есть поток с "кадрами". Каждый «кадр» имеет «метку времени». Кадры имеют свойство битрейта, которое фактически является их размером. Мы генерируем фреймы с нашим приложением и направляем их один за другим на наш сокет TCP-сервера. В то же время сервер отправляет ответы, поэтому, когда после каждого отправленного кадра мы пытаемся прочитать из сокета, мы получаем, какая временная метка в настоящий момент находится на сервере. Если временная метка меньше, чем в предыдущем кадре, мы снижаем скорость передачи битов на 20%. Такая схема, кажется, работает, давая мне один способ vbr (понижение), но мне интересно, как реализовать увеличение? Я имею в виду, что мы всегда можем попытаться увеличить 5% каждого кадра до некоторого ограниченного желаемого значения, но каждый раз, когда у нас есть задержка, мы теряем функцию нашего потока в реальном времени ... Обычно такая схема предназначена для определения того, какая часть сетевого потока в настоящее время используются другими пользовательскими приложениями и дают представление о том, сколько серверов загружено в одно и то же время, поэтому мы можем передавать только необходимое количество данных для всех, чтобы получать их в режиме реального времени. Так что я должен сделать, чтобы добавить увеличение к моей схеме? Таким образом, имея текущий битрейт A, я думал, что мы могли бы добавить + 7% для 3 кадров, а затем один -20%, а затем, если все эти 3 кадра с + 7% пришли вовремя, мы могли бы добавить 14% к A и повторить круг и надеюсь, будет не очень заметно, если 2-й кадр придет к нам с опозданием ...

Answer 1

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

Answer 2

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

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

Answer 3

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