АДАПТАЦИЯ СКОРОСТИ ВИДЕО К СОСТОЯНИЯМ ОБРАТНОЙ ЛИНИИ СВЯЗИ Российский патент 2011 года по МПК H04N7/26 H04W72/00 H04L1/20 

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

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

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

Сотовый телефон может включать в себя устройство захвата аудио, такое как микрофон или синтезатор речи, и аудиокодер, чтобы генерировать аудиопакеты (или кадры). Телефон может использовать уровни протоколов связи, такие как уровень протокола радиоканала (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 кадров/сек таймер видео действует каждые 66 мс.

Если блок 408 оценки размера кадра, ограниченного каналом, запрашивает размер очереди RLP только с использованием таймера видео, Vn мог бы быть равен нулю и блок 408 оценки размера кадра, ограниченного каналом, не знал бы, когда RL закончит передачу в очереди 410 в течение tn и tn-1. Следовательно, пропускная способность канала может быть недооценена. Это является причиной для использования таймера аудио, чтобы запрашивать размер очереди RLP более часто. При разрешении более частых запросов в уровень RLP блок 408 оценки размера кадра, ограниченного каналом, может отслеживать, когда очередь 410 RLP становится пустой.

Способ, предназначенный для поиска Vx и tx, может быть выражен как:

if (Vn>0) or (Vm>0)

Vx=Vn; tx=tn;

else

i=1;

loop

{

if ((tm-1>tn-1) and (Vm-1>0)) or (tm-1<=tn-1)

{

Vx=Vm-i+1; tx=tm-i+1;

Done and stop the loop;

{

else i=i+1;

}

(Vx, tx) будут использованы, чтобы вычислять пропускную способность видео, как описано ниже. Фиг.5А изображает только 3 запроса на основании таймера аудио. Это основано на скорости кадров, равной 15 кадров/сек. Если используют более низкую скорость кадров, такую как 7,5 кадров/сек или 5 кадров/сек, будет больше запросов и процесс, описанный выше, должен быть модифицирован, чтобы быть более общим. Способ, описанный выше, предназначен для поиска, когда очередь 410 видео RLP становится нулевой, если Vn равен нулю. Если Vn не равен нулю, блок 408 оценки размера кадра, ограниченного каналом, будет использовать tn в качестве момента времени tx и оценивать пропускную способность (описанную ниже), поскольку канал не может избавиться от данных, которые были сгенерированы в момент времени tn-1.

Фиг.5В-5Е иллюстрируют примеры определения размера очереди RLP с использованием способа, описанного выше. На фиг.5В способ определяет, выполняются ли условия (Vn>0) или (Vm>0). Поскольку Vm>0, способ устанавливает Vx=Vn и tx=tn, поскольку tn является моментом времени, когда размер очереди RLP становится нулевым. Это означает, что канал потребляет 550 байт между tn-1 и tn.

На фиг.5С способ определяет, выполняются ли условия (Vn>0) или (Vm>0). Ответом является “нет”, что означает, что размер очереди RLP становится нулевым раньше, чем Vm. В этом случае способ не может установить Vx=Vn; tx=tn. Способ должен найти, когда размер очереди RLP становится нулевым. Способ ищет от Vm до всех более ранних моментов времени Vm-1, Vm-2, чтобы найти, когда размер очереди RLP становится нулевым. Способ устанавливает i=1. Способ определяет, равен ли Vm-i нулю (где i=1). Ответом является “нет”, поскольку Vm-i равен 150 байт. Затем способ узнает, что tm является моментом времени, когда размер очереди RLP становится нулевым. Затем способ может установить Vx=Vn и tx=tn (где m-i+1=m в этом случае).

На фиг.5D способ определяет, выполняются ли условия (Vn>0) или (Vm>0). Ответом является “нет”, что означает, что размер очереди RLP становится нулевым раньше, чем Vm. В этом случае способ не может установить Vx=Vn; tx=tn. Способ должен определить, когда размер очереди RLP становится нулевым. Способ ищет от Vm до всех более ранних моментов времени Vm-1, Vm-2, чтобы найти, когда размер очереди RLP становится нулевым. Способ устанавливает i=1. Способ определяет, равен ли Vm-i нулю (где i=1). Ответом является “да”, и способ увеличивает i на 1. Теперь i=2. Способ определяет, равен ли Vm-i нулю (где i=2). Ответом является “нет”, Vm-i равен 250 байт. Затем способ знает, что tm-1 (где m-i+1=m-1) является моментом времени, когда размер очереди RLP становится нулевым. Затем способ может установить Vx=Vm-1; tx=tm-1.

На фиг.5Е способ определяет, выполняются ли условия (Vn>0) или (Vm>0). Ответом является “нет”, что означает, что размер очереди RLP становится нулевым раньше, чем Vm. В этом случае способ не может установить Vx=Vn; tx=tn. Способ должен определить, когда размер очереди RLP становится нулевым. Способ ищет от Vm до всех более ранних моментов времени Vm-1, Vm-2, чтобы найти, когда размер очереди RLP становится нулевым. Способ устанавливает i=1. Способ определяет, равен ли Vm-i нулю (где i=1). Ответом является “да”, и способ увеличивает i на 1. Теперь i=2. Способ определяет, равен ли Vm-i нулю (где i=2). Ответом является “да”, и способ увеличивает i на 1. Теперь i=3. Теперь tm-1 раньше, чем tn-1. Это означает, что способ проверил все размеры очереди RLP между двумя видеокадрами. В этом случае способ установит Vx=Vm-2; tx=tm-2 (где m-i+1=m-2).

В этом способе, который использует размер очереди RLP, основной идеей определения Vx и tx является поиск, когда размер очереди RLP становится нулевым, если Vn равен нулю. Это вследствие того, если Vn равен нулю, способ не знает, когда RL передаст все данные и, следовательно, оценка может недооценить полосу пропускания. Если Vn не равен нулю, способ может просто использовать tn в качестве момента времени и оценить пропускную способность видео.

Этап 2: оценить пропускную способность видео

Пропускная способность видео (VTP) с последнего момента времени, когда кадр послан в момент времени tn-1, до текущего кадра в момент времени tn, до кодирования может быть оценена с помощью блока 408 оценки размера кадра, ограниченного каналом, следующим образом:

где Bn-1 - размер кадра n-1, tx - момент времени, когда размер очереди RLP потока видео становится нулевым или равным tn, если Vn не равен нулю.

Этап 3: определить максимальный размер кадра, ограниченный каналом

После того как пропускная способность видео VTP оценена, блок 408 оценки размера кадра, ограниченного каналом, определяет максимальный размер кадра, который может позволить RL, при допущении, что канал не изменяется, следующим образом:

где F - скорость кадра. A(VTP) - корректирующий коэффициент, чтобы управлять тем, насколько видеокодер 400 реагирует на канал. A(VTP) может быть функцией оцененной пропускной способности видео. A(VTP) является полезным, когда предыдущий видеокадр был небольшим и VTP недооценивает истинную полосу пропускания канала 16. A(VTP) также может быть использован, чтобы управлять задержкой видео в соответствии с разными ограничениями задержки из разных приложений. Например, проведение видеоконференций может использовать меньшие величины A(VTP), в то время как коллективное использование видео может использовать большие значения. A(VTP) может быть постоянным или переменным. Пример A(VTP) равен 100 байт.

Этап 4: определить целевой размер кадра

Блок 404 информации размера кадра может определить целевой размер кадра для кадра n следующим образом:

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

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

Блок 404 информации размера кадра посылает целевой размер кадра в блок 402 управления скоростью видео. Скорость видео равна размеру кадра видеоданных в период времени (например, 66 мс).

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

Второй способ адаптации скорости

Фиг.6 иллюстрирует второй способ адаптации скорости с примерами структур и потоков данных. Во втором способе адаптации скорости устройство 608 оценки пропускной способности видео, ограниченной каналом, использует дополнительную информацию (например, ограничение запаса усилителя мощности (РА)) из уровня 612 МАС, чтобы оценить пропускную способность видео. Этот второй способ предварительно оценивает (или предсказывает) пропускную способность видео на основании ограничения запаса мощности вместо зависимости от статистических данных первого порядка размера очереди потока видео RLP. Уровень 612 МАС использует ограничение запаса мощности в качестве ограничивающего коэффициента, чтобы определять размер полезной нагрузки пакетов МАС. Блок 608 оценки пропускной способности видео, ограниченной каналом, также мог бы использовать ограничение запаса мощности, чтобы оценивать пропускную способность видео, поскольку ограничение запаса мощности обычно существенно не изменяется между двумя последовательными видеокадрами.

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

Этап 1: получить ограничение запаса мощности и размер очереди потока видео

Блок 608 оценки пропускной способности видео, ограниченной каналом, запрашивает уровень RLP, чтобы получить размер очереди потока видео, и запрашивает уровень 612 МАС, чтобы получить ограничение запаса мощности. Частота запроса может быть каждые 66 мс. В этом втором способе адаптации скорости не нужно использовать таймер аудио. Блок 608 может запоминать ограничение запаса мощности и размер очереди потока видео RLP.

Этап 2: получить размер полезной нагрузки МАС на основании просмотра таблицы

Уровень 612 МАС может определять размер полезной нагрузки МАС с помощью просмотра таблицы. Уровень 612 МАС может поддерживать таблицу, как изображено на фиг.7А и/или фиг.7В, чтобы преобразовывать ограничение запаса мощности в максимальный размер полезной нагрузки. Это преобразование также может быть использовано, чтобы определять максимальную пропускную способность видео на следующем этапе. Это преобразование может быть выполнено в самом уровне 612 МАС, т.е. уровень 612 МАС может передать размер полезной нагрузки, ограниченный запасом мощности, в прикладной уровень. Фиг.7А иллюстрирует таблицу преобразования для ограничения запаса мощности (самый левый столбец) в размер полезной нагрузки МАС. Фактическая скорость передачи данных также показана с разными целями окончания.

Таблица на фиг.7А является одним примером. Могут быть другие таблицы, используемые в МАС, чтобы оценивать размер полезной нагрузки, в зависимости от определения целей и режима передачи (высокая пропускная способность (HiCap) или малое запаздывание (LoLat)). Фиг.7В иллюстрирует другие преобразования размера полезной нагрузки на основании ограничения запаса мощности.

Этап 3: Оценить пропускную способность видео

Блок 608 оценки пропускной способности видео, ограниченной каналом, может предсказывать пропускную способность видео следующим образом:

VTP = Размер полезной нагрузки × возможности TX

Возможности ТХ - оценка того, сколько возможностей передачи предоставлено видео каждые 66 мс. Возможности ТХ определяют с помощью принятия во внимание текущей схемы МАС, характеристик RL, таких как тройное чередование, и аудиоданных. Например, возможности TХ могут быть равны 3, но также могут быть использованы другие значения.

Этап 4: Определить максимальный размер кадра, ограниченный каналом

Блок 608 оценки пропускной способности видео, ограниченной каналом, может определять максимальный размер кадра, ограниченный каналом, с помощью следующего уравнения:

.

Этап 5: Определить целевой размер кадра

Блок 604 информации размера кадра может определять целевой размер для текущего кадра.

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

Способы, описанные в этом раскрытии, могут быть осуществлены в универсальном микропроцессоре, процессоре цифровых сигналов (DSP), интегральной прикладной схеме (ASIC), вентильной программируемой матрице (FPGA) или в других эквивалентных логических устройствах. Например, система 12 видеокодера и ее компоненты и модули могут быть осуществлены как части процесса кодирования или процесса кодирования/декодирования (CODEC), выполняющегося в процессоре цифровых сигналов (DSP), микропроцессоре, встроенном ядре или в другом устройстве обработки. Таким образом, компоненты, описанные как модули, могут формировать компоненты аппаратного обеспечения или программируемые признаки процесса кодирования или отдельный процесс.

В некоторых вариантах осуществления функции кодирования могут быть разделены между разными компонентами аппаратного обеспечения. Например, управление скоростью уровня кадра может быть выполнено во встроенном логическом ядре, а управление скоростью уровня МВ может быть выполнено в DSP. В качестве иллюстрации, при заданной целевой скорости передачи в битах (R кбит/сек) и скорости кадра (F кадров/сек) управление скоростью уровня кадра во встроенном логическом ядре может включать в себя обновление параметров модели управления скоростью, например, параметрами модели области значений коэффициента корреляции после кодирования каждого кадра, оценку бюджета кадра В для следующего кадра и преобразование бюджета кадра в QP кадра (например, от 1 до 31) с использованием преобразований бюджета в коэффициент корреляции и коэффициента корреляции в QP, например, посредством либо таблицы коэффициентов корреляции, либо параметрического уравнения коэффициента корреляции.

После постобработки значений QP, включающей любые дополнительные ограничения на QP кадра, встроенное логическое ядро посылает QP кадра, бюджет коэффициента корреляции и новые параметры модели в DSP. Затем DSP вычисляет QP для каждого МВ с использованием преобразования коэффициента корреляции в QP и выполняет постобработку значений QP. DSP может сохранять правило, что значение дельта QP МВ находится в пределах +2 и -2, а также любые дополнительные ограничения на QP МВ. После обновления параметров модели области значений коэффициента корреляции после кодирования МВ DSP повторяет процесс для других МВ в применяемом видеокадре. После того как кодирование МВ завершено, процесс возвращается во встроенное логическое ядро, чтобы обработать следующий кодируемый видеокадр.

Система 12 видеокодера может иметь выделенную память, предназначенную для хранения инструкций и данных, а также выделенное аппаратное обеспечение, программное обеспечение, программно-аппаратное обеспечение или их комбинации. Если осуществлены в программном обеспечении, способы могут быть осуществлены как инструкции на компьютерно-читаемом носителе, таком как память произвольного доступа (RAM), память только для чтения (ROM), энергонезависимая память произвольного доступа (NVRAM), электрически стираемая программируемая память только для чтения (EEPROM), флэш-память или тому подобное. Инструкции заставляют один или более процессоров выполнять определенные аспекты выполняемых функций, описанных в этом раскрытии.

Способы, описанные в этом раскрытии, могут быть осуществлены в универсальном микропроцессоре, процессоре цифровых сигналов (DSP), интегральной прикладной схеме (ASIC), вентильной программируемой матрице (FPGA) или в других эквивалентных логических устройствах. Например, система 12 видеокодера, система 14 видеодекодера и связанные компоненты и модули могут быть осуществлены как части процесса кодирования или процесса кодирования/декодирования (CODEC), выполняющегося в процессоре цифровых сигналов (DSP) или в другом устройстве обработки. Таким образом, компоненты, описанные как модули, могут формировать программируемые признаки такого процесса или отдельный процесс.

Система 12 видеокодера может иметь выделенную память, предназначенную для хранения инструкций и данных, а также выделенное аппаратное обеспечение, программное обеспечение, программно-аппаратное обеспечение или их комбинации. Если осуществлены в программном обеспечении, способы могут быть осуществлены как инструкции, выполняемые с помощью одного или более процессоров. Инструкции могут быть сохранены на компьютерно-читаемом носителе, таком как память произвольного доступа (RAM), память только для чтения (ROM), энергонезависимая память произвольного доступа (NVRAM), электрически стираемая программируемая память только для чтения (EEPROM), флэш-память, магнитное или оптическое устройство хранения или тому подобное. Инструкции заставляют один или более процессоров выполнять определенные аспекты выполняемых функций, описанных в этом раскрытии.

Описаны различные варианты осуществления. Эти и другие варианты осуществления находятся в рамках объема следующей формулы изобретения.

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

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

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

3. Способ по п.2, в котором этап, на котором используют первый размер (Vx), предыдущий размер (Vn-1) очереди видео, связанной с предыдущим видеокадром, размер (Вn-1) предыдущего видеокадра, первый момент времени (tx) и момент времени (tn-1), связанный с предыдущим размером очереди видео, чтобы определить пропускную способность (VTP) видео, содержит

4. Способ по п.2, в котором этап, на котором используют более ранний размер (Vx), предыдущий размер (Vn-1) очереди видео, связанной с предыдущим видеокадром, размер (Вn-1) предыдущего видеокадра, более ранний момент времени (tx) и момент времени (tn-1), связанный с предыдущим размером очереди видео, чтобы определить пропускную способность видео (VTP), содержит

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

6. Способ по п.2, в котором очереди видео назначают, чтобы хранить только пакеты видео.

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

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

9. Способ по п.2, дополнительно содержащий этапы, на которых используют скорость кодирования видео, чтобы кодировать видео, и передают закодированное видео через беспроводной канал с использованием протоколов развития, оптимизированного относительно данных множественного доступа с кодовым разделением версии A (CDMA EV-DO версии А).

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

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

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

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

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

15. Способ по п.11, дополнительно содержащий этапы, на которых используют скорость кодирования видео, чтобы кодировать видео, и передают закодированное видео через беспроводной канал с использованием протоколов развития, оптимизированного относительно данных множественного доступа с кодовым разделением версии A (CDMA EV-DO версии А).

16. Способ по п.11, в котором очереди видео назначают, чтобы хранить только пакеты видео.

17. Устройство кодирования видеоданных, содержащее процессор и машиночитаемую память, хранящую множество инструкций, которые при исполнении процессором предписывают устройству выполнять этапы:
определения первого размера Vn очереди видео на уровне протокола радиоканала (RLP) в первый момент времени tn на основании скорости видеокадра, определения второго размера Vm очереди видео во второй момент времени tm на основании скорости аудиокадра, если первый размер Vn или второй размер Vm больше нуля, тогда использования первого размера Vn, предыдущего размера Vn-1 очереди видео, связанной с предыдущим видеокадром, размера Вn-1 предыдущего видеокадра, первого момента времени tn и момента времени tn-1, связанного с предыдущим размером очереди видео, чтобы определить пропускную способность (VTP) видео, если первый размер Vn и второй размер Vm равны нулю, тогда поиска более раннего момента времени на основании скорости аудиокадра, когда размер очереди видео был больше нуля, после нахождения более раннего момента времени на основании скорости аудиокадра, когда размер очереди видео был больше нуля, использования более раннего размера очереди Vm-1 на основании скорости аудиокадра, предыдущего размера Vn-1 очереди видео, связанной с предыдущим видеокадром, размера Вn-1 предыдущего видеокадра, более раннего момента времени tm-1 и момента времени tn-1, связанного с предыдущим размером очереди видео, чтобы определить пропускную способность (VТР) видео, использования определенной пропускной способности (VTP) видео, чтобы определить размер видеокадра, ограниченный каналом, и использования размера видеокадра, ограниченного каналом, чтобы управлять скоростью кодирования видео,

18. Устройство по п.17, в котором инструкции выполняются на прикладном уровне над уровнем RLP.

19. Устройство по п.17, в котором уровень управления доступом к среде (MAC) для видеопотоков устройства не реагирует на нагрузку сектора.

20. Устройство по п.17, в котором использование первого размера (Vx), предыдущего размера (Vn-1) очереди видео, связанной с предыдущим видеокадром, размера (Вn-1) предыдущего видеокадра, первого момента времени (tx) и момента времени (tn-1), связанного с предыдущим размером очереди видео, чтобы определить пропускную способность(VТР) видео, содержит

21. Устройство по п.17, в котором использование более раннего размера (Vx), предыдущего размера (Vn-1) очереди видео, связанной с предыдущим видеокадром, размера (Вn-1) предыдущего видеокадра, более раннего момента времени (tx) и момента времени (tn-1), связанного с предыдущим размером очереди видео, чтобы определить пропускную способность (VTP) видео, содержит

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

23. Устройство по п.17, в котором очереди видео назначают, чтобы хранить только пакеты видео.

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

25. Устройство по п.24, в котором корректирующий коэффициент имеет первое значение для проведения видеоконференций и второе значение для коллективного использования видео.

26. Устройство по п.17, дополнительно содержащее видеокодер, сконфигурированный с возможностью использования скорости кодирования видео, чтобы кодировать видео, и передатчик, сконфигурированный с возможностью передачи закодированного видео через беспроводной канал с использованием протоколов развития оптимизированного относительно данных множественного доступа с кодовым разделением версии A (CDMA EV-DO версии А).

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

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

29. Устройство по п.28, в котором использование определенной пропускной способности видео и определенного размера очереди видео на уровне RLP, чтобы определить размер видеокадра, ограниченный каналом, дополнительно использует корректирующий коэффициент, который управляет тем, насколько скорость кодирования видео реагирует на состояния канала, при этом размер видеокадра определяют на основании скорости видеокадра, а определенную пропускную способность видео увеличивают с помощью корректирующего коэффициента.

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

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

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

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