Адаптация скорости видео к состояниям обратной линии связи

Адаптация скорости видео к состояниям обратной линии связи

Иллюстрации

Показать все

Реферат

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

Раскрытие относится к кодированию видео и, более конкретно, к способам, предназначенным для адаптации скорости кодирования видео к состояниям обратной линии связи.

Уровень техники

Сотовый телефон может включать в себя устройство захвата аудио, такое как микрофон или синтезатор речи, и аудиокодер, чтобы генерировать аудиопакеты (или кадры). Телефон может использовать уровни протоколов связи, такие как уровень протокола радиоканала (RLP), уровень управления доступом к среде (МАС) и физический (PHY) уровень. Телефон может помещать аудиопакеты в очередь RLP. Модуль уровня МАС может генерировать пакеты уровня МАС из содержимого очереди RLP. Пакеты уровня МАС могут быть преобразованы в пакеты PHY уровня для передачи через канал связи в другое устройство связи.

Сущность изобретения

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

Другой аспект относится к способу, содержащему этапы, на которых определяют размер Vn очереди видео на уровне протокола радиоканала (RLP) в первый момент времени tn на основании скорости видеокадра, определяют второй размер Vm очереди видео во второй момент времени tm на основании скорости аудиокадра, если первый размер Vn или второй размер Vm больше нуля, тогда используют первый размер Vn, предыдущий размер Vn-1 очереди видео, связанной с предыдущим видеокадром, размер Bn-1 предыдущего видеокадра, первый момент времени tn и момент времени tn-1, связанный с предыдущим размером очереди видео, чтобы определить пропускную способность VTP видео, если первый размер Vn и второй размер Vm равны нулю, тогда ищут более ранний момент времени, когда размер очереди видео был больше нуля, на основании скорости аудиокадра, после нахождения более раннего момента времени на основании скорости аудиокадра, когда размер очереди видео был больше нуля, используют более ранний размер очереди Vm-i на основании скорости аудиокадра, предыдущий размер Vn-1 очереди видео, связанной с предыдущим видеокадром, размер Bn-1 предыдущего видеокадра, более ранний момент времени tm-1 и момент времени tn-1, связанный с предыдущим размером очереди видео, чтобы определить пропускную способность VTP видео, используют определенную пропускную способность VTP видео, чтобы определить размер видеокадра, ограниченный каналом, и используют размер видеокадра, ограниченный каналом, чтобы управлять скоростью кодирования видео.

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

Другой аспект относится к устройству, содержащему машиночитаемую память, которая хранит множество инструкций. Инструкции сконфигурированы с возможностью определения первого размера Vn очереди видео на уровне протокола радиоканала (RLP) в первый момент времени tn на основании скорости видеокадра, определения второго размера Vm очереди видео во второй момент времени tm на основании скорости аудиокадра, если первый размер Vn или второй размер Vm больше нуля, тогда использования первого размера Vn, предыдущего размера Vn-1 очереди видео, связанной с предыдущим видеокадром, размера Bn-1 предыдущего видеокадра, первого момента времени tn и момента времени tn-1, связанного с предыдущим размером очереди видео, чтобы определить пропускную способность VTP видео, если первый размер Vn и второй размер Vm равны нулю, тогда поиска более раннего момента времени на основании скорости аудиокадра, когда размер очереди видео был больше нуля, после нахождения более раннего момента времени на основании скорости аудиокадра, когда размер очереди видео был больше нуля, использования более раннего размера очереди Vm-i на основании скорости аудиокадра, предыдущего размера Vn-1 очереди видео, связанной с предыдущим видеокадром, размера Bn-1 предыдущего видеокадра, более раннего момента времени tm-1 и момента времени tn-1, связанного с предыдущим размером очереди видео, чтобы определить пропускную способность VTP видео, использования определенной пропускной способности VTP видео, чтобы определить размер видеокадра, ограниченного каналом, и использования размера видеокадра, ограниченного каналом, чтобы управлять скоростью кодирования видео.

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

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

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

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

Краткое описание чертежей

Фиг.1 иллюстрирует систему кодирования и декодирования видео.

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

Фиг.3 иллюстрирует корреляцию между (а) задержкой видео каждого кадра и (b) информацией нижнего уровня.

Фиг.4 иллюстрирует первую методику адаптации скорости с примерами структур и потоков данных.

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

Фиг.5В-5Е иллюстрируют примеры определения размера очереди RLP.

Фиг.6 иллюстрирует вторую методику адаптации скорости с примерами структур и потоков данных.

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

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

Фиг.1 иллюстрирует систему 10 кодирования и декодирования видео. Система 10 включает в себя систему 12 кодера, посылающую данные через канал 16 передачи в систему 14 декодера. Система 12 кодера может быть в первом устройстве видеосвязи и может включать в себя источник 17 аудио, источник 18 видео, видеокодер 20, аудиокодер 22, модуль 26 преобразования транспортного протокола реального времени (RTP)/протокола пользовательских датаграмм/протокола Internet (IP)/двухточечного протокола (РРР), очередь 28 протокола радиоканала (RLP), модуль 30 уровня МАС и модуль 32 физического (PHY) уровня. Другие варианты осуществления системы 12 кодера могут включать в себя другие элементы вместо элементов или дополнительно к элементам, изображенным на фиг.1. Другие варианты осуществления системы 12 кодера могут включать в себя меньше элементов, чем изображено на фиг.1.

Система 14 декодера может быть в другом устройстве видеосвязи и может включать в себя модуль 34 PHY уровня, модуль 36 уровня МАС, очередь 38 RLP, модуль 40 преобразования RTP/UDP/IP/PPP, видеокодер 42, аудиокодер 44, блок 46 вывода аудио и блок 48 вывода видео. Другие варианты осуществления системы 14 декодера могут включать в себя другие элементы вместо элементов или дополнительно к элементам, изображенным на фиг.1. Другие варианты осуществления системы 14 декодера могут включать в себя меньше элементов, чем изображено на фиг.1.

Система 10 может обеспечивать двунаправленную передачу видео и аудио, например, для видеотелефонии (VT) через канал 16 передачи. Взаимосоответствующие модули кодирования, декодирования и преобразования могут быть обеспечены на противоположных концах канала 16. В некоторых вариантах осуществления система 12 кодера и система 14 декодера могут быть осуществлены в устройствах видеосвязи, таких как беспроводные мобильные терминалы, оснащенных для потоковой передачи видео, VT или и того и другого. Мобильные терминалы могут поддерживать VT в соответствии со стандартами с коммутацией пакетов, такими как RTP, UDP, IP или PPP.

Модуль 26 преобразования RTP/UDP/IP/PPP добавляет соответствующие данные заголовка RTP/UDP/IP/PPP к аудио- и видеоданным, принятым из аудиокодера 22 и видеокодера 24, и помещает данные в очередь 28 RLP. RTP выполняется поверх UDP, в то время как UDP выполняется поверх IP, а IP выполняется поверх PPP. Модуль 30 уровня МАС генерирует пакеты МАС RLP из содержимого очереди 28 RLP. Модуль 32 PHY уровня преобразует пакеты МАС RLP в пакеты PHY уровня для передачи через канал 16.

Модуль 34 PHY уровня и модуль 36 уровня МАС системы 14 декодирования работают обратным способом. Модуль 34 PHY уровня преобразует пакеты PHY уровня, принятые из канала 16, в пакеты МАС RLP. Модуль 36 уровня МАС помещает пакеты МАС RLP в очередь 38 RLP. Модуль 40 преобразования RTP/UDP/IP/PPP вырезает информацию заголовка из данных в очереди 38 RLP и выполняет повторную сборку видео- и аудиоданных для доставки в видеодекодер 42 и аудиодекодер 44 соответственно.

Система 10 может быть разработана с возможностью поддержки одной или более технологий беспроводной связи, таких как множественный доступ с кодовым разделением (CDMA), множественный доступ с частотным разделением (FDMA), множественный доступ с временным разделением (TDMA) или ортогональное частотное разделяющее мультиплексирование (OFDM), или другого подходящего беспроводного способа. Вышеупомянутые технологии беспроводной связи могут быть реализованы в соответствии с любой из множества технологий радиодоступа. Например, CDMA может быть реализован в соответствии со стандартами cdma2000 или широкополосным CDMA (WCDMA). TDMA может быть реализован в соответствии со стандартом глобальной системы мобильной связи (GSM). Стандарт универсальной мобильной телекоммуникационной системы (UMTS) допускает работу GSM или WCDMA. Для приложений VT система 10 может быть разработана с возможностью поддержки технологий высокоскоростных данных (HDR), таких как cdma2000 1х EV-DO версия 0, версия А или последующие версии EV-DO.

Источник 18 видео может быть устройством захвата видео, таким как одна или более видеокамер, один или более видеоархивов, или комбинацией видеокамер и видеоархивов. Видеокодер 20 генерирует закодированные видеоданные в соответствии со способом сжатия видео, таким как MPEG-4. Могут быть использованы другие способы сжатия видео, такие как способы H.263 международного союза телекоммуникаций (ITU), H.264 ITU или MPEG-2. Видеокодер 20 может обеспечивать схему управления скоростью источника видео, которая обычно является зависимой от кодека. Например, видеокодер 20 может быть адаптирован для кодирования видео в соответствии с MPEG4, H.263 ITU или H.264 ITU. Видеокодер 20 может быть осуществлен с помощью DSP или встроенного логического ядра.

Источник 17 аудио может быть устройством захвата аудио, таким как микрофон или устройство синтезатора речи. Аудиокодер 22 может кодировать аудиоданные таким образом, чтобы сопровождать видеоданные. Аудиоданные могут быть закодированы в соответствии со способом сжатия аудио, таким как адаптивная многоскоростная узкая полоса частот (AMR-NB), или другими способами. Для приложений VT видео будет разрешать просмотр участников конференции VT, а аудио будет разрешать слышать голос говорящего участника.

Во время работы модуль 26 преобразования RTP/UDP/IP/PPP получает пакеты видео- и аудиоданных из видеокодера 20 и аудиокодера 22. Модуль 26 преобразования RTP/UDP/IP/PPP добавляет соответствующую информацию заголовка к аудиопакетам и вставляет результирующие данные в очередь 28 RLP. Подобным образом модуль 26 преобразования RTP/UDP/IP/PPP добавляет соответствующую информацию заголовка к видеопакетам и вставляет результирующие данные в очередь 28 RLP. Модуль 30 уровня МАС выбирает данные из очереди 28 RLP и формирует пакеты уровня МАС. Каждый пакет уровня МАС несет информацию заголовка RTP/UDP/IP/PPP и данные аудио- или видеопакета, который содержится в очереди 28 RLP.

Аудиопакеты могут быть вставлены в очередь 28 RLP независимо от видеопакетов. В некоторых случаях пакет уровня МАС, сгенерированный из содержимого очереди 28 RLP, будет нести только информацию заголовка и данные видеопакета. В других случаях пакет уровня МА будет нести только информацию заголовка и данные аудиопакета.

В некоторых случаях пакет уровня МАС будет нести информацию заголовка, данные аудиопакета и данные видеопакета в зависимости от содержимого очереди 28 RLP. Пакеты уровня МАС могут быть сконфигурированы в соответствии с протоколом радиоканала (RLP) и могут быть упомянуты как пакеты МАС RLP. Модуль 32 PHY уровня преобразует аудиовидеопакеты МАС RLP в пакеты PHY уровня для передачи через канал 16.

Канал 16 несет пакеты PHY уровня в систему 14 декодера. Например, канал 16 может быть проводным соединением, таким как локальная или глобальная проводная сеть. В качестве альтернативы, как описано в настоящей заявке, канал 16 может быть беспроводным каналом, таким как сотовый, спутниковый или оптический канал.

Состояния канала могут иметь значение для проводных и беспроводных каналов, но являются особенно проблематичными для приложений мобильной VT, выполняемых через беспроводные каналы, в которых состояния канала могут страдать вследствие замирания или перегрузки. Например, канал 16 может отличаться обратной линией связи (RL), имеющей пропускную способность, которая изменяется в соответствии с состояниями канала. Пропускная способность может быть оценена на основании состояний канала как представленных с помощью одного или более из следующего: текущей скорости передачи беспроводного канала, активности беспроводной базовой станции и ограничений мощности передачи. Например, состояния канала могут быть определены на основании текущей скорости данных уровня МАС, бит обратной активности (RAB) и ограничения усилителя мощности (РА).

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

Модуль 34 PHY уровня системы 14 декодера идентифицирует пакеты уровня МАС из пакетов PHY уровня и выполняет повторную сборку содержимого в пакеты МАС RLP. Затем модуль 36 уровня МАС выполняет повторную сборку содержимого пакетов МАС RLP, чтобы предоставить видео- и аудиопакеты для вставки в очередь 38 RLP. Модуль 40 RTP/UDP/IP/PPP удаляет сопровождающую информацию заголовка и предоставляет видеопакеты в видеодекодер 42, а аудиопакеты в аудиодекодер 44.

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

Видеотелефония (VT) относится к обмену пакетами в реальном времени, несущих аудио- и видеоданные, по меньшей мере, между двумя устройствами, такими как системы 12 и 14. Первое устройство 12 VT включает в себя видеокодер 20, который получает видео из устройства 18 захвата видео, такого как видеокамера или видеоархив, и генерирует видеопакеты. Подобным образом аудиодекодер 22 в устройстве 12 VT получает аудио из устройства 17 захвата аудио, такого как микрофон или синтезатор речи, и генерирует аудиопакеты. Видеопакеты и аудиопакеты помещают в очередь 28 RLP. Модуль 30 уровня МАС генерирует пакеты уровня МАС из содержимого очереди 28 RLP. Пакеты уровня МАС преобразуют в пакеты PHY уровня для передачи через канал 16 связи во второе устройство 14 VT.

В приложениях мобильной VT устройство VT (беспроводной терминал) принимает пакеты PHY уровня через беспроводную прямую линию связи (FL) (т.е. нисходящую линию связи) из базовой станции. Устройство VT передает пакеты PHY уровня через беспроводную обратную линию связи (RL) (т.е. восходящую линию связи) в базовую станцию. Каждое устройство VT включает в себя PHY уровень и уровень МАС, чтобы преобразовывать принятые пакеты PHY уровня и уровня МАС и выполнять повторную сборку полезных нагрузок пакетов в аудиопакеты и видеопакеты. Видеодекодер 42 в устройстве VT декодирует видеоданные для представления пользователю через устройство 48 отображения (видеовыход). Аудиодекодер 44 в устройстве VT декодирует аудиоданные для вывода через аудиогромкоговоритель 46 (аудиовыход).

Мобильная VT в беспроводной среде может быть проблемой, поскольку скорость передачи данных через беспроводный канал может быть ограничена и может изменяться со временем. Например, в сети CDMA2000 1x EV-DO версии 2 или версии А скорость передачи данных может изменяться вследствие состояний канала в беспроводной зоне обслуживания или перегрузки трафика среди множества пользователей VT. Состояния канала, чрезмерное видеосодержимое или и то, и другое могут вызывать значительные задержки при передаче видео. Например, при уменьшении пропускной способности RL передача видео может переполнить RL и увеличить задержку передачи видео. В результате мобильная VT может быть чувствительной к нежелательной задержке видео и/или аудио, что разрушает возможность обеспечивать беспрепятственное проведение видеоконференции в реальном времени.

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

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

Видеотелефония (VT) может быть важным приложением для сетей CDMA2000 1х EV-DO версии А. EV-DO версии А может обеспечивать скорости передачи данных до 3,1 Мбит/с в прямой линии связи (FL) (нисходящая линия связи) и 1,8 Мбит/с в RL (восходящая линия). EV-DO версии А также поддерживает внутреннее и взаимное качество обслуживания (QoS) пользователя. Внутреннее QoS пользователя дает аудиоданным более высокий приоритет, чем видеоданным, что уменьшает задержку аудио с помощью компромисса задержки видео, когда состояния канала ухудшаются. По сравнению с сетью EV-DO версии 0 поддержка большей симметричности, более высокой скорости передачи данных и QoS EV-DO версии А может быть более подходящей для того, чтобы нести требовательный к полосе частот, чувствительный к задержке трафик, и может увеличить общее качество VT.

Несмотря на то что сеть EV-DO версии А обеспечивает уникальные особенности, которые согласуют трафик VT, одной трудной проблемой может быть чрезмерная задержка видео, когда основные состояния канала становятся плохими. Это обычно случается, когда пользователь мобильного устройства VT испытывает затухающие каналы или перемещается к краю сектора и становится ограниченным в запасе. Поскольку поддерживается внутреннее QoS пользователя, аудио будет обслужено и передано с более высоким приоритетом, чем видео. Могут быть даже некоторые моменты, когда отсутствует полоса частот, чтобы передать видео. В результате видеоданные будут помещаться в очередь в буфере до тех пор, пока ресурс не освободят от аудиоданных или не улучшатся состояния канала.

Фиг.2А и фиг.2В иллюстрируют смоделированные данные, изображающие увеличенную задержку видео, когда состояния канала RL являются плохими. Моделирование посылает сжатое видео MPEG-4 со скоростью 48 кбит/с, 15 кадров в секунду (кадров/сек), и кодер с увеличенной переменной скоростью (EVRC) кодирует аудио с 3-кадровым пакетированием через эмуляторы канала RL EV-DO версии А. FL также может вызывать дополнительную задержку видео, но проблема FL не зависит от RL. Способы адаптации скорости RL, описанные ниже, могут помочь уменьшить комплексную задержку видео.

Фиг.2А изображает разные состояния канала в моделировании. В этом моделировании нагрузка сети является небольшой, т.е. в одном и том же секторе имеется несколько пользователей. В этом моделировании схема уровня МАС для потоков VT не реагирует на нагрузку сектора. Это означает, что назначение ресурса RL будет гарантировать передачу видео со скоростью 48 Кбит/с до тех пор, пока терминал доступа не будет ограничен в запасе мощности. Когда запас мощности ограничен (или состояние RL становится плохим), уровень 30 МАС будет передавать аудиоданные до видеоданных. На фиг.2А разные состояния канала смоделированы с помощью разных ситуаций медленного затухания. Состояние 2 на фиг.2А использует изменяющуюся во времени мертвую зону канала А, которая моделирует медленное движение терминала доступа (АТ) со скоростью 3 километра в час (км/ч). Когда АТ движется в зонах замирания, он будет стремиться оставаться там в течение более длительного периода времени по сравнению с состояниями 4 и 6, в которых АТ движется быстрее со скоростью около 10 км/ч и 120 км/ч соответственно. Также были выполнены моделирования с мягкой передачей обслуживания и без мягкой передачи обслуживания. Обычно состояния канала без мягкой передачи обслуживания являются хуже, чем состояния с мягкой передачей обслуживания.

Фиг.2В изображает задержки аудио и видео, когда аудио и видео передают через все тестовые состояния канала фиг.2А. Как изображает фиг.2В, задержка аудио незначительно увеличивается для всех состояний канала. Это вследствие того, что QoS, поддерживаемое обратной линии связи EV-DO версии А, предоставляет приоритетную передачу для аудиоданных относительно видео. Когда полоса частот RL уменьшается, RL будет назначать имеющиеся ресурсы сначала аудиоданным, а затем назначать остающиеся ресурсы передаче видеоданных. Когда состояние RL является плохим, аудиоданные используют большую часть ресурсов (или полосы частот), в то время как видеоданные будут буферизированы в очередь передачи (или очередь 28 RLP потока видео). В результате задержка видео существенно увеличивается, как изображено на фиг.2В.

Моделирование собирало данные с помощью посылки аудио и видео в течение пяти минут. Задержка измерена для каждого видеокадра. Для состояний со 2 по 5 видео имеет большие задержки, в среднем до 2 секунд. Распределение накопительной задержки при 95% может составлять до 12,5 секунд. Эти значения являются результатами пяти минут времени эксперимента при допущении, что очередь RLP имеет неограниченную физическую память, чтобы запоминать видеоданные.

Если время было увеличено до 20 минут, эти значения были бы даже хуже. То есть очередь RLP потока видео будет увеличиваться больше, поскольку АТ не может поддерживать передачу видео со скоростью 48 кбит/с. Это является неприемлемым для приложений VT реального времени. Главной причиной является то, что видеокодер 20 не знает об ухудшении канала и продолжает создавать видео со скоростью 48 кбит/с, чтобы посылать через RL. Поскольку RL не может поддерживать видеоданные с такой высокой скоростью во время затухания сигнала, большая часть видеоданных будет буферизирована. Эта буферизация вызывает задержку.

Таким образом, очень желательно регулировать скорость кодирования видео таким образом, чтобы она соответствовала той скорости, которую может поддерживать RL, чтобы исключить буферизацию любых видеоданных, чтобы уменьшить задержку видео. Цель задержки видео при 95% может быть 200 мс.

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

Одним предложенным способом является схема межуровневой оптимизации, которая принимает во внимание характеристики RL EV-DO версии А и использует информацию из уровня 30 МАС и уровня 28 RLP, переданную в видеокодер 20. Видеокодер 20 использует эту информацию, чтобы выполнять мониторинг состояний RL и регулировать свою скорость кодирования в соответствии с состоянием канала.

Результаты моделирования показывают, что способ может эффективно уменьшить среднюю задержку видео до 94%, и задержка в 95 процентилей (величина задержки, в пределах которой декодер 42 будет принимать 95% видеопакетов, переданных с помощью кодера 20) может быть уменьшена до 98% для разных состояний канала при допущении, что очередь RLP имеет неограниченную физическую память, чтобы запоминать видеоданные. Кроме того, эффективная пропускная способность видео может быть увеличена на величину вплоть до 4 килобит в секунду (кбит/с). Вычислительная сложность предложенного способа может быть низкой, таким образом, он может быть осуществлен в мобильных устройствах, ограниченных вычислительно.

Корреляция между задержкой видео и информацией нижнего уровня

Фиг.3 иллюстрирует корреляцию между (а) задержкой видео (в миллисекундах и деленную на 100) каждого кадра в соответствии с моментом времени, когда кадр был сгенерирован, и (b) информацией нижнего уровня, например размером очереди RLP потока видео (в байтах и деленным на 100) из уровня RLP и ограничением запаса мощности из уровня МАС. Ограничение запаса мощности измеряют в децибелах (дБ), и оно ограничивает максимально возможный объем полезной нагрузки пакетов уровня МАС. Чем меньше значение ограничения запаса мощности, тем меньше максимально возможный объем нагрузки и, следовательно, меньше пропускная способность. Ограничение запаса может указывать максимальную скорость, которую разрешают использовать при передаче, на основании текущей мощности передачи. Ограничение РА представляет запас мощности передачи и указывает, когда состояния канала ухудшились.

Фиг.3 изображает сильную корреляцию между размером очереди RLP потока видео и задержкой видео. Когда размер очереди RLP увеличивается, задержка видео также увеличивается, например, в 2,62, 2,8 и 2,9 раз вдоль оси х на фиг.3.

Также имеется сильная корреляция между ограничением запаса мощности и задержкой видео. Когда ограничение запаса мощности ниже 10 дБ, как отмечено с помощью окружностей на фиг.3, задержка видео увеличивается. Чем ниже ограничение запаса мощности, тем больше задержка видео. На основании этих наблюдений размер очереди RLP потока видео и ограничение запаса мощности представляются очень полезной информацией для адаптации скорости видео.

Адаптация скороcти видео с использованием параметров МАС RL EV-DO версии А

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

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

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

Первый способ адаптации скорости

Могут быть два разных ограничения для адаптации скорости. Первое возможное ограничение может быть ограничением скорости передачи в битах, которая может гарантировать скорость передачи видеоданных 48 кбит/с, даже когда канал 16 может позволить более высокие скорости. Некоторые системы или сети могут не иметь это ограничение скорости передачи в битах. Второе ограничение является ограничением канала, которое будет ограничивать скорость видео на основании текущих состояний канала.

Фиг.4 иллюстрирует первый способ адаптации скорости с примерами структур и потоков данных. Видеокодер 400 кодирует видеоданные из источника 401 видео с использованием скорости кодирования видео из блока 402 управления скоростью видео. Видеокодер 400 посылает закодированные видеоданные в блок 406 RTP/UDP/IP/PPP, которое посылает видеопакеты в очередь 410 RLP потока видео. Очередь 410 RLP потока видео посылает видеопакеты в обратный канал трафика МАС (RTCMAC) 412. RTCMAC осуществляет протокол, чтобы обеспечить процедуры, которым следует устройство связи, чтобы передавать через RL канала 16.

Большой размер очереди RLP потока видео может указывать, что видеоданные имеют большую задержку. Видеокодер 400 и/или другие блоки на фиг.4 могут постоянно выполнять мониторинг размера очереди RLP потока видео и регулировать скорость кодирования видео, когда необходимо.

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

Видеокодер 400 может назначать биты для каждого кадра (т.е. определять размер кадра) на покадровой основе. Например, для видео 15 кадров/сек блок 404 информации размера кадра может выбирать размер каждого кадра каждые 66 мс. Если запас мощности RL не ограничен и сектор не нагружен, блок 404 информации размера кадра назначает размер кадра на основании ограничения 414 целевой скорости передачи в битах. Иначе блок 408 оценки размера кадра, ограниченного каналом, должен знать количество данных, чтобы генерировать и не переполнить RL. Таким образом, блок 408 оценки размера кадра, ограниченного каналом, оценивает максимальное количество данных, которые может обработать RL между двумя последовательными видеокадрами. Погрешность оценки будет отражена в размере очереди RLP потока видео, и это может быть принято во внимание, когда блок 408 оценки размера кадра, ограниченного каналом, выбирает размер следующего кадра.

Этап 1: получить размер очереди потока видео RLP

Блок 408 оценки размера кадра, ограниченного каналом, будет периодически запрашивать уровень RLP, чтобы найти размер V очереди RLP потока видео.

Фиг.5А иллюстрирует частоту запросов прикладного уровня в уровень RLP, чтобы получить размер очереди потока видео RLP, где частота основана на скорости аудиокадра (каждые 20 мс) и скорости видеокадра (каждые 66 мс, если закодировано со скоростью 15 кадров/сек). Скорость видеокадра на фиг.5А является периодом времени для видеокодера 400, чтобы закодировать кадр n-1 размера Bn-1. Блок 408 оценки размера кадра, ограниченного каналом, может разделять информацию, запрошенную на основании таймера аудио и таймера видео. Когда размер очереди RLP запрашивают на основании таймера аудио, блок 408 оценки размера кадра, ограниченного каналом, может записывать/запоминать размер очереди и запрошенное время как (Vm, tm). Таймер аудио обычно действует каждые 20 мс, но может действовать каждые 10 мс или 30 мс в зависимости от того, какой используют кодер речи.

Когда размер очереди RLP запрашивают на основании таймера видео, блок 408 оценки размера кадра, ограниченного каналом, может записывать/запоминать размер очереди и запрошенное время как (Vm, tm), как проиллюстрировано на фиг.5А. Таймер видео имеет интервал времени между двумя последовательными кадрами и основан на скорости кадра. Для скорости видеокадров 15 кадров/с