20.02.2014
216.012.a37d

СИСТЕМА ДЛЯ УСКОРЕНИЯ ДОСТАВКИ ВЕБ-СТРАНИЦЫ

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
№ охранного документа
0002507568
Дата охранного документа
20.02.2014
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение относится к области систем обработки данных, которые улучшают способность пользователей манипулировать аудио- и видеоносителями. Технический результат заключается в уменьшении времени ожидании отклика веб-страницы. Способ ускоренной доставки веб-страницы заключается в исполнении на удаленном сервере приложения веб-браузера, используемого пользователем посредством интерактивного сжатого потокового видео, обеспечении пользователю доступа к веб-странице посредством приложения веб-браузера и отображения веб-страницы на клиентском устройстве в ответ на запрос пользователя. 9 з.п. ф-лы, 40 ил.
Реферат Свернуть Развернуть

Эта заявка является частичным продолжением (CIP) заявки с порядковым номером 10/315460, поданной 10 декабря 2002 г., озаглавленной "APPARATUS AND METHOD FOR WIRELESS VIDEO GAMING", права на которую принадлежат заявителю настоящей заявки CIP.

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

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

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

Записываемые аудионосители и киноносители являются одной стороной общественной жизни со времен Томаса Эдисона. В начале 20-го века были широко распространены записываемые аудионосители (валики и грампластинки) и киноносители (синематограф и фильмы), но обе технологии находились, однако, в своей ранней стадии развития. В конце 1920-х годов кинофильмы были объединены со звуковым сопровождением на основе рынка товаров широкого потребления, вслед за этим появились цветные кинофильмы со звуковым сопровождением. Радиовещание постепенно приняло форму широковещательных средств распространения аудиоинформации рынка товаров широкого потребления, пользующихся поддержкой рекламы. Когда в середине 1940-х годов был установлен стандарт телевизионного (TV) вещания, телевидение присоединилось к радио как форма широковещательных средств распространения рынка товаров широкого потребления, и ранее записанные кинофильмы или киноизображения в прямом эфире пришли в дом.

К середине 20-го века в большинстве американских домов были граммофоны для воспроизведения записанных аудионосителей, радиоприемник для приема прямых аудиопередач и телевизор для воспроизведения аудио/видео (A/V) носителей прямой передачи. Очень часто эти 3 "медиаплеера" (проигрыватель, радиоприемник и телевизор) были объединены в одном корпусе с совместным использованием обычных динамиков, который стал "медиа-центром" для дома. Несмотря на то что выбор носителей информации был ограничен для потребителя, "экосистема" носителей информации была довольно устойчивой. Большинство потребителей знали, как пользоваться "медиаплеерами", и могли в полной мере использовать их функциональные возможности. Вместе с тем, издатели мультимедиа (в значительной степени киностудии и телестудии и музыкальные компании) могли поставлять свои носители информации и в театры, и для домашнего использования и не страдали от широко распространенного пиратства или "вторичных продаж", т.е. перепродаж используемого носителя информации. Как правило, издатели не получают доход от "вторичных продаж", и, по существу, это уменьшает доход, который издатели иначе могли бы получить от покупателя используемого носителя информации вследствие новых продаж. Несмотря на то что в середине 20-го века, конечно, использовались проданные грампластинки, такие продажи не оказывали большого влияния на издателей грампластинок, потому что в отличие от кино или видеопрограммы, которые взрослый человек, как правило, смотрит один раз или только несколько раз, музыкальная фонограмма может прослушиваться сотни или даже тысячи раз. Поэтому носитель музыкальной информации является гораздо менее "преходящим" (т.е. он имеет непреходящую ценность для взрослого потребителя), чем кино/видео носители. После покупки грампластинки, если потребителю понравилась музыка, то он, вероятно, будет хранить ее в течение длительного времени.

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

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

В настоящее время потребители сталкиваются с большим выбором мультимедиа, а также с множеством устройств хранения данных, многие из которых привязаны к конкретным видам мультимедиа или конкретным издателям. Страстный потребитель мультимедиа может иметь стек устройств, подключенных к телевизорам и компьютерам, находящимся в различных помещениях дома, что в результате приводит к паутине кабелей, ведущих к одному или нескольким телевизорам и/или персональным компьютерам (PC), а также к группе пультов дистанционного управления. (В контексте настоящей заявки термин "персональный компьютер" или "PC" относится к любому виду компьютера, пригодного для дома или офиса, включающего в себя настольный компьютер, Macintosh® или другие компьютеры, не требующие использования операционной системы Windows, совместимые с Windows устройствами, разновидности UNIX, ноутбуки и т.д.) Эти устройства могут включать в себя видеоигровую консоль, кассетный видеомагнитофон, DVD-плеер, звуковой процессор/усилитель объемного звука, спутниковую телевизионную абонентскую приставку, телевизионную абонентскую приставку кабельного телевидения и т.д. И для страстного потребителя может существовать множество устройств с аналогичными функциями из-за вопросов совместимости. Например, потребителю могут принадлежать как HD-DVD, так и Blu-ray DVD плеер, или как Microsoft Xbox®, так и Sony Playstation® игровая видеосистема. На самом деле из-за несовместимости некоторых игр по всем версиям игровых консолей потребителю могут принадлежать как XBox, так и более поздняя версия, например, Xbox 360®. Часто потребителей сбивает с толку то, какой видеовход и какой пульт дистанционного управления использовать. Даже после того, как диск вставлен в соответствующий плеер (например, DVD, HD-DVD, Blu-ray, Xbox или Playstation), выбраны видеовход и аудиовход для этого устройства и найден соответствующий пульт дистанционного управления, потребитель, тем не менее, сталкивается с техническими проблемами. Например, в случае широкоэкранного DVD пользователю может потребоваться сначала определить и затем установить соответствующий формат изображения на своем экране монитора или телевизора (например, 4:3, Full, Zoom, Wide Zoom, Cinema Wide и т.д.). Аналогично, пользователю может потребоваться сначала определить и затем установить соответствующий аудиоформат системы объемного звучания (например, AC3, Dolby Digital, DTS и т.д.). Часто потребитель не сознает, что он, возможно, не использует мультимедийное содержимое в полном объеме функциональных возможностей своей телевизионной или аудиосистемы (например, при просмотре фильма в сжатом виде при неправильном формате изображения или при прослушивании аудио со стереофоническим звуком, а не с объемным звуком).

Все больше и больше устройств хранения данных, основанных на Internet-технологиях, добавляются к стеку устройств. Звуковые устройства, подобные системе Sonos® Digital Music, передают потоком аудио непосредственно из Internet. Аналогично, устройства, подобные телевизионной приставке Slingbox™, записывают видео и передают его потоком через домашнюю сеть или через Internet, где его можно смотреть удаленно на PC. И службы IP-телевидения (IPTV) предлагают услуги, подобные кабельному телевидению, через цифровую абонентскую линию (DSL) или другие соединения с Internet в доме. Недавно также предпринимались попытки для интеграции множества мультимедиа-функций в одном устройстве, например, Moxi® Media Center и PC под управлением операционной системы Windows XP Media Center Edition. Несмотря на то что каждое из этих устройств предлагает элемент механизма для функций, которые оно выполняет, в каждом отсутствует повсеместно распространенный и простой доступ к большинству носителей информации. Кроме того, производство таких устройств часто стоит сотни долларов часто из-за необходимости дорогостоящей обработки и/или локального запоминающего устройства. Кроме того, эти современные потребительские электронные устройства, как правило, потребляют много мощности, даже в режиме ожидания, что означает, что они требуют больших затрат со временем и нерационально используют энергоресурсы. Например, устройство может продолжать работать, если потребитель забыл выключить его или переключился на другой видеовход. И так как ни одно из устройств не является законченным решением, то оно должно быть интегрировано с другим стеком устройств в доме, что по-прежнему оставляет пользователя с паутиной проводов и большим количеством пультов дистанционного управления.

Кроме того, когда многие новейшие устройства, основанные на Internet-технологиях, действительно работают должным образом, они, как правило, предлагают мультимедиа в более общей форме, чем оно могло иначе быть доступным. Например, устройства, которые передают потоком видео через Internet, часто передают потоком только видеоматериал, а не интерактивные "дополнительные материалы", которые часто сопровождают DVD, подобные "мнению о" видео, играм или комментариям кинорежиссера. Это происходит вследствие того, что часто интерактивный материал выводится в конкретном формате, предназначенном для конкретного устройства, которое обрабатывает интерактивность локально. Например, каждый из дисков DVD, HD-DVD и Blu-ray имеет свой собственный конкретный интерактивный формат. Любое домашнее устройство хранения данных или локальный компьютер, который мог быть разработан для поддержки всех популярных форматов, могут потребовать некоторого уровня усложнения и гибкости, что, вероятно, сделало бы их функционирование недопустимо дорогим и сложным для потребителя.

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

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

Современные видеоигровые приложения в основном разделены на четыре главные машинозависимые аппаратные платформы: Sony PlayStation® 1, 2 и 3 (PS1, PS2 и PS3), Microsoft Xbox® и Xbox 360® и Nintendo Gamecube® и Wii™, а также основанные на PC игры. Каждая из этих платформ отличается от других так, что игры, написанные для исполнения на одной платформе, обычно не исполняются на другой платформе. Могут также существовать проблемы совместимости устройства от поколения к поколению. Несмотря на то что большинство разработчиков игровых программ создают игровые программы, независимые от конкретной платформы, для исполнения конкретной игры на конкретной платформе, причем требуется собственный слой программного обеспечения (часто называемый "механизмом разработки игровых программ") для адаптации игры для использования на конкретной платформе. Каждая платформа продается потребителю как "консоль" (т.е. автономный блок, подсоединяемый к телевизору или монитору/динамикам), или она сама является PC. Как правило, видеоигры продаются на оптическом носителе информации, например, DVD Blu-ray, DVD-ROM или CD-ROM, который содержит видеоигру, воплощенную как усложненное приложение реального времени. Так как скорости домашнего широкополосного доступа увеличились, видеоигры становятся все более и более доступными для загрузки.

Требования к специфике для достижения совместимости платформы с программным обеспечением видеоигры являются чрезвычайно высокими из-за характера режима реального времени и высоких вычислительных требований усовершенствованных видеоигр. Например, можно было бы ожидать полную совместимость видеоигр от поколения к поколению (например, от XBox к XBox 360 или от Playstation 2 ("PS2") к Playstation 3 ("PS3"), аналогично тому, как существует общая совместимость рабочих приложений (например, Microsoft Word) от одного PC к другому с более быстрым процессором или ядром. Однако с видеоиграми это не так. Так как производители видеоигр при выпуске поколения видеоигр, как правило, пытаются добиться максимально возможной производительности для данной ценовой точки, то часто существенно изменяют архитектуру системы так, что многие игры, написанные для системы предшествующего поколения, не исполняются на системе более позднего поколения. Например, XBox выполнен на основе семейства процессоров x86, тогда как XBox 360 выполнен на основе семейства PowerPC.

Могут быть использованы способы эмуляции предшествующей архитектуры, но с учетом того, что видеоигры являются приложениями реального времени, часто невозможно достичь идентичного поведения при эмуляции. Это наносит ущерб потребителю, производителю видеоигровой консоли и издателю программного обеспечения видеоигры. Для потребителя это означает необходимость наличия видеоигровых консолей, как старого, так и нового поколения, подключенных к телевизору для возможности ведения всех игр. Для производителя консоли это означает затраты, связанные с эмуляцией, и более медленное внедрение новых консолей. И для издателя это означает необходимость выпуска множества версий новых игр для охвата всех возможных потребителей - не только выпуск версии для каждого бренда видеоигры (например, XBox, Playstation), но часто версии для каждой версии данного бренда (например, PS2 и PS3). Например, отдельная версия "Madden NFL 08" Electronic Arts была разработана для XBox, XBox 360, PS2, PS3, Gamecube, Wii и PC наряду с другими платформами.

Портативные устройства, например, сотовые ("cell") телефоны и портативные медиаплееры также представляют проблемы для разработчиков игр. Все большее количество таких устройств подключаются к беспроводным сетям передачи данных и могут загружать видеоигры. Но на рынке существует широкий выбор сотовых телефонов и устройств хранения данных с широким диапазоном разных разрешающих способностей дисплея и вычислительных возможностей. Кроме того, так как такие устройства, как правило, имеют ограничения по потреблению мощности, стоимости и весу, у них, как правило, отсутствует усовершенствованное аппаратное обеспечение ускорения выполнения графических операций, подобные графическому процессору ("GPU"), например, устройства, изготавливаемые корпорацией NVIDIA, Santa Clara, CA (Санта-Клара, Калифорния). Следовательно, разработчики игровых программ, как правило, разрабатывают данную компьютерную игру одновременно для множества разных типов портативных устройств. Пользователь может обнаружить, что данная компьютерная игра не доступна конкретно для его сотового телефона или портативного медиаплеера.

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

Для издателей игровой консольной и компьютерной программы затраты не ограничиваются этим. Для распространения игр через розничные каналы издатели назначают оптовую цену ниже продажной цены для розничных торговцев для получения чистой прибыли. Издатель также, как правило, должен оплачивать затраты на производство и распространение физических носителей информации, содержащих игру. Розничный торговец также часто возлагает на издателя расход по "оплате ценовой защиты" для покрытия возможных непредвиденных расходов, например, когда игра не раскупается, или если цена игры снижается, или если розничный торговец должен возместить часть или всю оптовую цену и/или принять обратно игру от покупателя. Кроме того, розничные торговцы также, как правило, возлагают на издателей расходы по оплате поддержки сбыта игр в рекламных листовках. Кроме того, розничные торговцы все чаще выкупают игры у пользователей, которые перестали играть в них, и затем продают их как подержанные игры, как правило, не разделяя дохода от их продажи с издателем игр. Дополнением к бремени расходов, возложенных на издателей игр, является тот факт, что игры часто нелицензионно переиздают и распространяют через Internet для загрузки пользователями и изготовления ими бесплатных копий.

Так как скорости широкополосного доступа в Internet увеличиваются и широкополосные соединения стали более широко распространенными в США и во всем мире, в частности к дому и к Internet-"кафе", где арендуются PC, подключенные к Internet, игры все чаще распространяются посредством загрузки в PC или консоли. Кроме того, широкополосные соединения все чаще используют для ведения многопользовательских онлайновых игр и массовых многопользовательских онлайновых игр (и те и другие в настоящем раскрытии предмета изобретения обозначены аббревиатурой "MMOG"). Эти изменения уменьшают некоторые затраты и вопросы, связанные с распространением в розницу. Загрузка онлайновых игр направлена на преодоление некоторых неблагоприятных условий для издателей игр за счет того, что затраты на распространение, как правило, уменьшаются, и затраты из-за непроданного носителя информации являются небольшими или отсутствуют. Но загруженные игры по-прежнему подвержены пиратству, и из-за своего размера (часто размером в много гигабайтов) они могут загружаться очень долго. Кроме того, множество игр могут заполнить дисководы небольшой (емкости), как те, которые продаются с портативными компьютерами или с видеоигровыми консолями. Однако для игр большого размера или MMOG требуется, чтобы можно было вести эту игру по онлайновому соединению, проблема пиратства уменьшается, так как обычно требуется, чтобы пользователь имел действительную учетную запись пользователя. В отличие от линейных мультимедиа (например, видео и музыка), которые можно скопировать камерой при съемке видео с экрана дисплея или микрофоном при записи аудио с динамиков, каждый опыт использования видеоигры уникален и не может быть скопирован с использованием простой видео/аудио записи. Соответственно, даже в регионах, где не обеспечивается строгое выполнение законов об авторском праве и пиратство сильно распространено, MMOG могут быть ограждены от пиратства, и, следовательно, может поддерживаться предпринимательская деятельность. Например, MMOG "World of Warcraft" медиаконгломерата Vivendi SA с успехом введен во всем мире и не страдает от пиратства. И многие онлайновые игры или игры MMOG, например, MMOG "Second Life" ("Вторая Жизнь") компании Linden Lab формируют доход для операторов игр через экономические модели, встроенные в игры, где можно покупать, продавать и даже создавать ресурсы с использованием онлайновых инструментальных средств. Соответственно, для оплаты использования онлайновых игр могут использоваться механизмы в дополнение к обычным покупкам игровых программ или абонентским обслуживаниям.

Несмотря на то что пиратство во многих случаях может быть уменьшено из-за характера онлайновых (игр) или MMOG, оператор интерактивных игр, тем не менее, сталкивается с остальными проблемами. Многие игры для исполнения их должным образом требуют значительных локальных (т.е. домашних) ресурсов обработки для онлайновых (игр) или MMOG. Если производительность локального компьютера пользователя является низкой (например, такой компьютер без GPU, как ноутбук младшей модели), то он, возможно, не сможет вести игру. Кроме того, так как игровые консоли устаревают, то они также отстают от современного уровня развития и, возможно, не могут обрабатывать усовершенствованные игры. Даже если предположить, что локальный PC пользователя может удовлетворять вычислительным требованиям игры, то часто существует сложность инсталляции. Может существовать несовместимость драйверов (например, если новая игра загружена, то она может инсталлировать новую версию графического драйвера, который визуализирует ранее инсталлированную игру, зависящую от старой версии графического драйвера, которая не будет функционировать). Консоль может исчерпать пространство на локальном диске, когда загружается большее количество игр. Сложные игры, как правило, принимают загружаемые заплаты от разработчика игр с течением времени, так как обнаружены и исправлены ошибки, или если в игре выполнены модификации (например, если разработчик игр считает, что уровень игры является слишком сложным или слишком простым). Эти заплаты требуется снова загружать. Но иногда не все пользователи выполняют загрузку всех заплат. В других случаях загруженные заплаты вводят другие вопросы совместимости или расхода пространства на диске.

Кроме того, во время ведения игры может потребоваться загрузка большого количества данных для обеспечения графической или поведенческой информации в локальный PC или консоль. Например, если пользователь входит в комнату в MMOG и сталкивается со сценой или персонажем, составленными из графических данных, или с линиями поведения, которых нет на локальной машине пользователя, тогда эти данные персонажа или сцены должны быть загружены. Это может в результате привести к значительной задержке во время ведения игры, если подключение к Internet не является достаточно быстрым. И если персонаж или сцена, с которыми сталкиваются, требуют объем памяти или вычислительную мощность, превышающие возможности локального PC или консоли, то может создаться ситуация, когда пользователь не может продолжать игру или должен продолжать с графикой худшего качества. Соответственно, онлайновые игры или игры MMOG часто ограничивают свои требования к вычислительной сложности и/или по памяти. Кроме того, они часто ограничивают количество передач данных во время игры. И онлайновые игры или игры MMOG также могут сузить рынок пользователей, которые могут вести эти игры.

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

Стоимость разработки новой игры выросла, когда PC и консоли стали в состоянии выводить все более усложненные игры (например, с более реалистичной графикой, например трассировка лучей в реальном времени, и более реалистичными линиями поведения, например, моделирование физики в реальном времени). На заре видеоигровой промышленности разработка видеоигр была процессом очень похожим на разработку прикладного программного обеспечения, то есть большую часть стоимости разработки составляла разработка программного обеспечения в отличие от разработки таких графических, звуковых и поведенческих элементов или "ресурсов", как те, которые могут быть разработаны для киноифильма с пространственными спецэффектами. В настоящее время многие программы работ по разработке усложненных видеоигр больше напоминают разработку кинофильмов со спецэффектами, чем разработку программного обеспечения. Например, многие видеоигры обеспечивают имитации 3D (трехмерных) миров и формируют все более фотореалистичные (т.е. компьютерную графику, которая кажется такой реалистичной, как кадр с изображением игры актеров, фотографически) персонажи, реквизит и окружающую обстановку. Одним из самых перспективных аспектов разработки фотореалистичных игр является создание сформированного компьютером человеческого лица, которое нельзя отличить от человеческого лица при игре актеров. Технология захвата лица, как Contour™ Reality Capture, разработанный Mova, San Francisco, CA (Сан-Франциско, Калифорния), захватывает и отслеживает точную геометрию лица актера с высоким разрешением, когда оно находится в движении. Эта технология обеспечивает возможность визуализации лица 3D на PC или игровой консоли, которое практически нельзя отличить от захваченного лица при игре актеров. Точный захват и визуализация "фотореального" человеческого лица полезны в нескольких отношениях. Во-первых, в видеоиграх часто используются очень легко узнаваемые знаменитости или спортсмены (часто высокооплачиваемые), и недостатки могут быть очевидными для пользователя, что отвлекает во время игры или делает просмотр неприятным. Часто требуется высокая степень детализации для достижения высокой степени фотореалистичности с требованием визуализации большого количества многоугольников и текстур с высоким разрешением, возможно, с многоугольниками и/или текстурами, изменяющимися на покадровой основе во время движения лица.

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

Наблюдение за медленным перемещением индикатора выполнения по экрану при выводе на экран PC или консоли сообщения наподобие "Loading..." ("Загрузка...") принимается современными пользователями как неотъемлемый недостаток сложных видеоигр. Задержка при загрузке следующей сцены с диска ("диск" в этом описании, если не оговорено иное, относится к энергонезависимым оптическим или магнитным носителям информации, а также к недисковым носителям информации, например, к полупроводниковой "Флэш"-памяти) может занимать несколько секунд или даже несколько минут. Это является пустой тратой времени и может совершенно разочаровать игрока. Как обсуждалось ранее, большая часть или вся задержка может происходить из-за времени загрузки многоугольника, текстуры или других данных с диска, но также может случиться так, что часть времени загрузки тратится на подготовку процессором и/или GPU в PC или консоли данных для сцены. Например, видеоигра в футбол может обеспечивать возможность игрокам отбирать из большого количества игроков, команд, стадионов и метеорологических условий. Так, в зависимости от того, какая конкретная комбинация выбрана, для сцены могут потребоваться разные многоугольники, текстуры и другие данные (обобщенно "объекты") (например, разные команды имеют разные цвета и рисунки на своей форме). Может оказаться возможным перечислить многие или все различные перемены и предварительно вычислить многие или все объекты заранее и сохранить эти объекты на диске, используемом для хранения игры. Но если количество перемен является большим, то объем памяти, требуемый для всех объектов, может быть слишком большим и не соответствовать диску (или слишком нереальным для загрузки). Соответственно, существующие PC и консольные системы, как правило, являются ограниченными как по сложности, так и по продолжительности воспроизведения данных сцен и страдают от долгого времени загрузки для сложных сцен.

Другим существенным ограничением систем прикладного программного обеспечения и игровых видеосистем на предшествующем уровне техники является то, что они все чаще используют большие базы данных, например, таких 3D объектов, как многоугольники и текстуры, которые требуется загружать в PC или игровую консоль для обработки. Как обсуждалось выше, загрузка таких баз данных может занимать много времени при хранении на локальном диске. Время загрузки, однако, обычно намного больше, если база данных хранится удаленно, и доступ к ней осуществляется через Internet. В таком случае могут потребоваться минуты, часы или даже дни для загрузки большой базы данных. Кроме того, создание таких баз данных часто связано с большими расходами (например, 3D модель детализированного парусного судна, снабженного высокой мачтой, для использования в игре, фильме или историческом документальном фильме), и они предназначены для продажи локальному конечному пользователю. Однако база данных подвергается риску несанкционированного использования после ее загрузки локальным пользователем. Во многих случаях пользователю требуется загрузка базы данных просто для ее оценки, чтобы проверить, удовлетворяет ли она его потребностям (например, имеет ли 3D костюм для персонажа игры удовлетворительный вид, когда пользователь выполняет конкретное перемещение). Длительное время загрузки может быть сдерживающим фактором для пользователя, оценивающего 3D базу данных до того, как принять решение о покупке.

Аналогичные вопросы имеют место в MMOG, в частности, как, например, в играх, которые обеспечивают возможность пользователям использовать все более настраиваемых самостоятельно персонажей. Чтобы PC или игровая консоль выводили на экран персонажа, у них должен быть доступ к базе данных 3D геометрии (многоугольники, текстуры и т.д.), а также линий поведения (например, имеет ли персонаж щит, достаточно ли прочный этот щит, чтобы отклонить копье или нет) для этого персонажа. Как правило, когда пользователь впервые ведет MMOG, большое количество баз данных для персонажа уже поставляется с исходной копией игры, которая доступна локально на оптическом диске игры или загружается на диск. Но по мере продвижения игры, если пользователь сталкивается с персонажем или объектом, база данных которого не доступна локально (например, если другой пользователь создал персонажа, настраиваемого самостоятельно), то до того, как этот персонаж или объект могут быть выведены на экран, их база данных должна быть загружена. Это в результате может привести к значительной задержке игры.

С учетом уровня усложненности и сложности видеоигр другой проблемой для разработчиков видеоигр и издателей, связанной с видеоигровыми консолями предшествующего уровня техники, является то, что разработка видеоигры часто занимает от двух до трех лет при стоимости десятки миллионов долларов. С учетом того, что новые платформы видеоигровой консоли вводят со скоростью примерно по одной через каждые пять лет, разработчики игр должны начинать разработку этих игр за годы до выпуска новой игровой консоли, чтобы видеоигры появились в продаже одновременно с выпуском новой платформы. Иногда выпускают несколько консолей от конкурирующих производителей примерно в одно время (например, с интервалом один или два года), но еще неизвестна популярность каждой консоли, например, какая консоль сделает самые большие объемы продаж программного обеспечения видеоигры. Например, в недавнем цикле консолей было запланировано ввести Microsoft XBox 360, Sony Playstation 3 и Nintendo Wii примерно в один общий период времени. Но за годы до упомянутых введений разработчики игр по существу должны были "делать свои ставки" на то, какие платформы консоли будут более успешными, чем другие, и отдавать свои ресурсы разработки соответственно. Кинокомпании также должны соразмерно распределять свои ограниченные производственные ресурсы исходя из того, что, как они оценивают, будет вероятным успехом фильма, задолго до выпуска этого фильма. С учетом роста уровня инвестиций, требуемых для видеоигр, производство игр все больше становится похожим на производство кинофильмов, и компании по производству игр обычно отдают свои производственные ресурсы исходя из своей оценки будущего успеха конкретной видеоигры. Но в отличие от (они) кинокомпаний эта ставка основана не просто на успехе самого производства, скорее она основана на успехе игровой консоли, на которой эта игра должна исполняться. Выпуск игры на многих консолях одновременно может уменьшить риск, но из-за этой дополнительной программы работ возрастает стоимость, и часто происходит задержка фактического выпуска игры.

Условия работы пользователя и условия разработки прикладного программного обеспечения на PC требуют все большого объема вычислений, становятся динамичными и интерактивными не только, чтобы сделать их более привлекательными визуально для пользователей, но также и сделать их более полезными и интуитивно понятными. Например, как новая операционная система Windows Vista™, так и последующие версии операционной системы Macintosh®, включают в себя визуальные анимационные эффекты. Усовершенствованные графические средства, например, Maya™ от Autodesk, Inc., обеспечивают способность к воспроизведению динамических изображений и самой усложненной 3D визуализации, которые расширяют границы современных CPU и GPU. Однако вычислительные требования этих новых инструментальных средств вызывают несколько практических вопросов у пользователей и разработчиков программного обеспечения таких продуктов.

Так как визуальное отображение операционной системы (OS) должно работать на широком диапазоне классов компьютеров - в том числе на компьютерах предшествующего поколения, которые больше не продаются, но на которых, тем не менее, можно заменить операционную систему (OS) на новую - графические требования OS ограничены в значительной степени "наименьшим общим знаменателем" компьютеров, для которых предназначена эта OS, который, как правило, включает в себя компьютеры, которые не включают в себя GPU. Это очень ограничивает функциональные возможности графических средств OS. Кроме того, портативные компьютеры c батарейным питанием (например, ноутбуки) ограничивают возможности визуального отображения, так как высокий уровень вычислительной активности CPU или GPU, как правило, в результате приводит к более высокому уровню потребляемой мощности и меньшему времени работы аккумулятора. Портативные компьютеры, как правило, включают в себя программное обеспечение, которое автоматически понижает активность процессора для уменьшения потребляемой мощности, когда процессор не используется. В некоторых моделях компьютера пользователь может понизить активность процессора вручную. Например, ноутбук VGN-SZ280P корпорации Sony содержит переключатель, обозначенный "Stamina", с одной стороны (для низкого уровня производительности, большего времени работы аккумулятора) и "Speed" с другой (для высокого уровня производительности, меньшего времени работы аккумулятора). OS, под управлением которой работает портативный компьютер, должна быть пригодной к использованию даже в случае, если компьютер работает с производительностью, равной доле от своей максимальной производительности. Соответственно, производительность графической подсистемы OS часто остается гораздо ниже доступной на современном уровне техники вычислительной мощности.

Приложения с широкими функциональными возможностями, требующие большого объема вычислений, подобные Maya, часто продают с ожиданием того, что они будут использоваться на высокопроизводительных PC. Этим, как правило, определяется требование к "наименьшему общему знаменателю" более дорогому и менее портативному с гораздо большей производительностью. Как следствие, у таких приложений гораздо более ограниченная целевая аудитория, чем у универсальной OS (или универсального рабочего приложения, подобного Microsoft Office), и, как правило, (их) продают в гораздо меньшем объеме, чем программное обеспечение универсальной OS или универсальное прикладное программное обеспечение. Потенциальная аудитория также ограничена, потому что потенциальному пользователю часто трудно испытать такие приложения, требующие большого объема вычислений, заранее. Например, предположим, что студенту требуется узнать, как пользоваться Maya, или потенциальному покупателю, которому уже хорошо известны такие приложения, требуется испытать Maya до того, как вкладывать деньги в покупку (что также может включать в себя покупку машины старшей модели, которая может исполнять Maya). Несмотря на то что студент или потенциальный покупатель могут загрузить демонстрационную версию Maya или получить физическую копию носителя информации с демонстрационной версией Maya, если у них нет компьютера, который может исполнять Maya со всеми его потенциальными возможностями (например, c обработкой сложной 3D сцены), то они не смогут полностью оценить этот продукт. Это существенно ограничивает аудиторию для таких приложений с широкими функциональными возможностями. Это также способствует увеличению продажной цены, так как стоимость разработки обычно погашается гораздо меньшим количеством покупок, чем в случае универсального приложения.

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

Это относится и к пользователям пиратских видеоигр с высокими характеристиками. Несмотря на то что пираты могут получить игры за цену, равную доле от их фактической цены, они, тем не менее, должны покупать дорогостоящую вычислительную технику (например, PC с усовершенствованным GPU или высокопроизводительную видеоигровую консоль, подобную XBox 360), необходимую для ведения игры должным образом. С учетом того, что видеоигры, как правило, являются времяпрепровождением для потребителей, дополнительные затраты на высокопроизводительную игровую видеосистему могут являться препятствием. Эта ситуация ухудшается в странах (например, в Китае), где среднегодовой доход рабочих в настоящее время является довольно низким относительно среднегодового дохода рабочих в США. В результате гораздо меньший процент людей владеет высокопроизводительной игровой видеосистемой или высокопроизводительным PC. В таких странах весьма распространены "Internet кафе", в которых пользователи оплачивают использование компьютера, подключенного к Internet. Часто такие Internet кафе имеют старую модель или низкопроизводительный PC без высокопроизводительных признаков, например, GPU, которые могли бы иначе обеспечить возможность игрокам вести видеоигры, требующие большого объема вычислений. Это является решающим фактором успеха игр, которые исполняются на низкопроизводительных PC, например, "World of Warcraft" медиаконгломерата Vivendi, которая является очень успешной в Китае, и там в нее обычно играют в Internet кафе. Напротив, в игру, требующую большого объема вычислений, подобную "Second Life", с гораздо меньшей вероятностью можно играть на PC, установленном в китайском Internet кафе. Такие игры фактически недоступны пользователям, которые имеют доступ только к низкопроизводительным PC в Internet кафе.

Препятствия также существуют для пользователей, которые рассматривают покупку видеоигры и хотели бы сначала испытать демонстрационную версию игры с загрузкой ее через Internet в свой дом(ашний компьютер). Демонстрационная версия видеоигры часто является полнофункциональной версией игры с некоторыми недоступными признаками или с ограничениями, наложенными на количество проведений игры. Может подразумеваться длительный процесс (возможно, часы) загрузки гигабайтов данных до того, как игра будет инсталлирована и исполняться на PC или на консоли. В случае PC может также подразумеваться выяснение того, какие специальные драйверы необходимы (например, драйверы OpenGL или DirectX) для этой игры, загрузка соответствующей версии, инсталляция их, и затем определение того, можно ли на PC вести эту игру. Этот последний этап может включать в себя определение того, существуют ли у PC достаточные возможности для обработки (CPU и GPU), достаточная RAM и совместимая OS (например, некоторые игры исполняются на Windows XP, но не исполняются на Vista). Соответственно, после длительного процесса при попытке запуска демонстрационной версии видеоигры, пользователь может обнаружить, что демонстрационная версия видеоигры, возможно, не может быть воспроизведена с учетом конфигурации PC пользователя. Хуже, если после загрузки новых драйверов пользователем для испытания демонстрационной версии, эти версии драйверов могут оказаться несовместимыми с другими играми или приложениями, которые пользователь постоянно использует на PC, соответственно, инсталляция демонстрационной версии может привести ранее работающие игры или приложения в неработающее состояние. Эти препятствия не только разочаровывают пользователя, но они создают препятствия издателям программного обеспечения видеоигры и разработчикам видеоигр для сбыта своих игр.

Другая проблема, которая в результате приводит к экономической неэффективности, имеет отношение к тому, что данные PC или игровая консоль обычно предназначены для обеспечения определенного уровня требования к производительности для приложений и/или игр. Например, некоторые PC имеют большую или меньшую RAM, более медленные или более быстрые CPU и более медленные или более быстрые GPU, если они вообще имеют GPU. Некоторые игры или приложения используют преимущества всей вычислительной мощности данного PC или консоли, в то время как многие игры или приложения не используют их. Если игре или приложению, которую выбирает пользователь, требуется производительность меньше максимальной производительности локального PC или консоли, то пользователь может зря потратить деньги на неиспользуемые признаки PC или консоли. В случае консоли производитель консоли может заплатить больше, чем было необходимо для финансирования затрат на консоль.

Другая проблема, которая существует в сбыте и использовании видеоигр, включает в себя учет того, что пользователь просматривает другие игры до того, как он совершает покупку этой игры. На предшествующем уровне техники существует несколько подходов для записи видеоигр для повторного воспроизведения в дальнейшем. Например, в патентной заявке США № 5558339 сообщается о записи информации о состоянии игры, включающей в себя операции игрового контроллера, в течение "геймплей" (процесс игры) в компьютере клиента видеоигры (принадлежащего идентичному или другому пользователю). Эта информация о состоянии может быть использована в дальнейшем для повторного воспроизведения некоторых или всех операций игры на компьютере клиента видеоигры (например, PC или консоли). Существенным недостатком этого подхода является то, что для того, чтобы пользователю просмотреть записанную игру, он должен иметь компьютер клиента видеоигры, который может воспроизводить игру, и должен иметь видеоигровое приложение, исполняющееся на этом компьютере так, что геймплей является идентичным при повторном воспроизведении состояния записанной игры. Кроме того, видеоигровое приложение должно быть написано таким способом, что не существует возможности различия исполнения между записанной игрой и повторно воспроизводимой игрой.

Например, графическое представление игры обычно вычисляется на покадровой основе. Для многих игр игровая логика иногда может занимать меньше или больше времени, чем один период кадра, для вычисления графического представления, выводимого на экран для следующего кадра, в зависимости от того, является ли сцена особенно сложной, или существуют ли другие задержки, которые замедляют исполнение (например, на PC может исполняться другой процесс, который забирает циклы CPU у игровых приложений). В такой игре может со временем встретиться "пороговый" кадр, который вычисляется за несколько меньшее время, чем один период кадра (скажем, на несколько тактов CPU меньше). Когда снова вычисляется идентичная сцена с использованием идентичной информации о состоянии игры, она может легко занять на несколько тактов CPU больше, чем один период кадра (например, если внутренняя шина CPU немного не совпадает по фазе с внешней шиной DRAM, и это вводит несколько единиц времени цикла CPU задержки, даже если не существует большой задержки из-за другого процесса, забирающего миллисекунды процессорного времени у обработки игры). Следовательно, когда игра повторно воспроизводится, кадр вычисляется в течение двух периодов кадра, а не в течение одного периода кадра. Некоторые линии поведения основаны на том, как часто в игре вычисляется новый кадр (например, когда игра производит выборку входных данных из игровых контроллеров). Когда ведется игра, это несоответствие в привязке ко времени для разных линий поведения не влияет на ведение игры, но это может в результате привести к тому, что при повторном воспроизведении игры выведется другой результат. Например, если баллистика баскетбола вычисляется с устойчивой скоростью 60 кадр/с, но выборка входных данных игрового контроллера производится на основе скорости вычисленных кадров, то скорость вычисленных кадров могла быть 53 кадр/с, когда игра записывалась, но 52 кадр/с, когда игра повторно воспроизводится, что может привести к несовпадению между тем, вошел ли баскетбольный мяч в корзину или нет, что в результате приведет к другому исходу. Соответственно, использование состояния игры для записи видеоигр требует очень осторожного проектирования игровой программы для обеспечения того, что повторное воспроизведение с использованием идентичной информации о состоянии игры выведет идентичный исход.

Другим подходом предшествующего уровня техники для записи видеоигры является простая запись видеовыхода PC или игровой видеосистемы (например, на VCR, устройство записи на диски DVD или на плату захвата видео на PC). Видео после этого может быть перемотано и повторно воспроизведено, или в качестве альтернативы записанное видео может быть выгружено в Internet, как правило, после сжатия. Недостатком этого подхода является то, что, когда последовательность кадров 3D игры повторно воспроизводится, пользователь ограничен просмотром этой последовательности кадров только с точки обзора, с которой эта последовательность кадров была записана. Другими словами, пользователь не может изменить точку обзора сцены.

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

Другой подход предшествующего уровня техники обеспечивает возможность зрителю, имеющему телевизор, просматривать видеоигры в прямом эфире, но только под управлением телевизионной производственной группы. Некоторые телевизионные каналы, как в США, так и в других странах, обеспечивают каналы для просмотра видеоигр, по которым телевизионная аудитория может смотреть определенных пользователей видеоигры (например, игроков с самым высоким рейтингом, участвующих в соревнованиях). Это выполняется при наличии видеовыхода игровых видеосистем (PC и/или консолей), подаваемого в оборудование для обработки и распространения видео для телевизионного канала. Это мало чем отличается от трансляции по телевизионному каналу баскетбольной игры в прямом эфире, в которой несколько камер обеспечивают линии передачи в прямом эфире под разными углами вокруг баскетбольной площадки. После этого телевизионный канал может использовать свое оборудование для спецэффектов и обработки видео/аудио для манипуляции выходом из различных игровых видеосистем. Например, телевизионный канал может накладывать текст поверх видео из видеоигры, в которой указывается статус разных игроков (аналогично тому, как можно накладывать текст во время баскетбольной игры в прямом эфире), и телевизионный канал может накладывать дополнительное аудио от комментатора, который может обсуждать действия, происходящие во время игр. Кроме того, видеоигровой выход может быть комбинирован с камерами, записывающими видео фактических игроков игр (например, с показом их эмоциональной реакции на игру).

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

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

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

Другой недостаток игровых видеосистем предшествующего уровня техники и систем прикладного программного обеспечения состоит в том, что они являются сложными и обычно страдают от ошибок, аварийных отказов и/или непреднамеренных и нежелательных линий поведения (обобщенно "ошибки"). Несмотря на то что игры и приложения, как правило, проходят через процесс настройки и отладки (часто называемый "гарантии качества программного обеспечения" или SQA) перед выпуском, почти неизменно, после выпуска игры или приложения для широкой аудитории, в условиях эксплуатации неожиданно возникают ошибки. К сожалению, разработчику программного обеспечения трудно идентифицировать и обнаружить многие из ошибок после выпуска. Разработчикам программного обеспечения может быть трудно узнать об ошибках. Даже когда они узнают об ошибке, у них может иметься в распоряжении только ограниченный объем информации для идентификации причины этой ошибки. Например, пользователь может позвонить по телефону в службу поддержки клиентов разработчика игры и оставить сообщение о том, что при ведении игры экран начал мерцать, потом стал темно-синим и PC завис. Это дает группе SQA очень мало полезной информации для обнаружения ошибки. Некоторые игры или приложения, с которыми устанавливают связь в режиме онлайн, могут иногда давать больше информации в определенных случаях. Например, иногда может использоваться "сторожевой" процесс для осуществления текущего контроля игры или приложения на предмет "аварийного отказа". Сторожевой процесс может собирать статистику о статусе процесса приложений или игры (например, о статусе стека, использовании памяти, того, как далеко игра или приложения продвинулись и т.д.), когда происходит аварийный отказ, и затем передавать эту информацию в группу SQA через Internet. Но в сложной игре или приложении расшифровка такой информации может занять очень много времени для точного определения того, что пользователь делал во время аварийного отказа. Даже после этого может оказаться невозможным определить последовательность событий, которая привела к аварийному отказу.

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

На фиг.1 изображена игровая видеосистема предшествующего уровня техники, например, Sony Playstation® 3, Microsoft Xbox 360®, Nintendo Wii™, персональный компьютер на базе Windows или Macintosh корпорации Apple. Each of these systems includes a central processing unit (CPU) for executing program code, typically a graphical processing unit (GPU) for performing advanced graphical operations, and multiple forms of input/output (I/O) for communicating with external devices and users. Каждая из этих систем включает в себя центральный процессор (CPU) для исполнения управляющей программы, как правило, графический процессор (GPU) для выполнения усовершенствованных графических операций и разнообразные виды ввода/вывода (I/O) для обмена информацией с внешними устройствами и пользователями. Для простоты эти компоненты изображены объединенными вместе как один блок 100. Также изображено, что игровая видеосистема предшествующего уровня техники по фиг.1 включает в себя накопитель 104 на оптических носителях информации (например, накопитель высокой емкости для дисков), накопитель 103 на жестких дисках для хранения данных и управляющей программы видеоигры, сетевое соединение 105 для ведения игр с нескольким участниками, для загрузки игр, заплат, демонстрационных версий или другого мультимедиа, оперативное запоминающее устройство (RAM) 101 для хранения управляющей программы, в настоящее время исполняемой CPU/GPU 100, игровой контроллер 106 для приема входных команд от пользователя во время геймплей и дисплей 102 (например, SDTV/HDTV или компьютерный монитор).

Система предшествующего уровня техники, изображенная на фиг.1, имеет несколько ограничений. Во-первых, накопители 104 на оптических дисках и накопители 103 на жестких дисках, как правило, имеют гораздо более медленные скорости доступа по сравнению со скоростью доступа RAM 101. При работе непосредственно через RAM 101, CPU/GPU 100 может, на практике, обрабатывать гораздо больше многоугольников в секунду, чем это возможно, когда управляющая программа и данные считываются непосредственно с накопителя 103 на жестких дисках или накопителя 104 на оптических дисках вследствие того, что RAM 101 обычно имеет гораздо большую полосу пропускания и не страдает от задержек дисковых механизмов относительно долгого поиска. Но в этих системах предшествующего уровня техники обеспечен только ограниченный объем RAM (например, 256-512 МБайт). Следовательно, часто требуется последовательность кадров "Загрузка...", во время которой RAM 101 периодически заполняется данными для следующей сцены видеоигры.

В некоторых системах делается попытка совмещать загрузку управляющей программы одновременно с геймплей, но это можно сделать только, когда известна последовательность событий (например, если автомобиль едет по дороге, то может быть загружена геометрия для приближающихся зданий, находящихся на краю дороги, в то время как автомобиль едет). Для сложной и/или быстрой смены сцен этот тип совмещения обычно не работает. Например, в случае, когда пользователь находится в середине сражения, и RAM 101 полностью заполнена данными, представляющими объекты, находящиеся в поле зрения в этот момент, если пользователь быстро перемещает изображение влево для просмотра объектов, которые в настоящее время не загружены в RAM 101, то в результате произойдет нарушение непрерывности в действии, так как не будет достаточно времени, чтобы загрузить новые объекты из накопителя 103 на жестких дисках или оптического носителя 104 информации в RAM 101.

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

Один способ, используемый для решения этой последней проблемы, заключается в том, чтобы в игре предварительно вычислять карты отображения текстуры и карты окружения после того, как они выбраны пользователем. Это может включать в себя несколько процессов, требующих большого объема вычислений, в том числе восстановление сжатых изображений, 3D отображение, затенение, организация структур данных и т.д. В результате для пользователя может иметь место задержка, в то время как в видеоигре выполняются эти вычисления. Одним способом уменьшения этой задержки, в принципе, является выполнение всех этих вычислений - включающих в себя каждую перемену команды, состава команды и стадиона - когда игра первоначально разрабатывалась. Выпускаемая версия игры тогда может включать в себя все эти предварительно обработанные данные, хранящиеся на оптическом носителе 104 информации, или на одном или нескольких серверах в Internet с только переключаемыми предварительно обработанными данными для данных команды, состава команды, выбора стадиона, загружаемыми через Internet в накопитель 103 на жестких дисках, когда пользователь делает выбор. Как практический вопрос, однако, такие предварительно загруженные данные каждой перемены, возможной при ведении игры, могут легко составлять терабайты данных, что намного превышает емкость современных оптических устройств хранения данных. Кроме того, данные для данных команды, состава команды, выбора стадиона могут легко составлять сотни мегабайтов данных или больше. В отношении домашнего сетевого подключения, скажем, 10 Мбит/с, загрузка этих данных через сетевое соединение 105 может занимать больше времени, чем вычисление упомянутых данных локально.

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

Другая проблема, связанная с такими подходами предшествующего уровня техники, как тот, который изображен на фиг.1, состоит в том, что со временем видеоигры становятся более усовершенствованными и требуют большей вычислительной мощности CPU/GPU. Соответственно, даже при предположении неограниченного объема RAM требования к аппаратному обеспечению видеоигры превышают максимальный уровень вычислительной мощности, имеющейся в этих системах. В результате пользователи должны модернизировать игровую аппаратуру через каждые несколько лет, чтобы не отставать (или вести более новые игры при более низких уровнях качества). Одним последствием тенденции еще большего усовершенствования видеоигр является то, что домашние видеоигровые вычислительные машины, как правило, являются экономически неэффективными, потому что их стоимость обычно определяется в соответствии с требованиями игры самой высокой производительности, которую они могут поддерживать. Например, XBox 360 может использоваться для ведения игры, подобной "Gears of War", которая требует высокоэффективных CPU, GPU и сотни мегабайтов RAM, или XBox 360 может использоваться для игры Pac Man, игры из 1970-ых, которая требует только килобайты RAM и CPU очень низкой производительности. На самом деле, XBox 360 обладает достаточной вычислительной мощностью для размещения многих параллельных игр Pac Man одновременно.

Видеоигровые вычислительные машины, как правило, выключены в течение большего количества времени в неделю. Согласно исследованию Nielsen Entertainment в июле 2006 г. активных игроков в возрасте 13 лет и старше, в среднем, активные игроки проводят четырнадцать часов в неделю за игрой в консольные видеоигры, или только 12% всего времени в неделю. Это означает, что средняя видеоигровая консоль не используется 88% времени, что является неэффективным использованием дорогостоящего ресурса. Это особенно важно с учетом того, что видеоигровые консоли часто финансируются производителем для снижения покупной цены (с ожиданием, что эта дотация будет возвращена вследствие лицензионных платежей от будущих покупок программного обеспечения видеоигры).

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

Кроме того, основной проблемой видеоигровой промышленности является пиратство. Механизмы безопасности, используемые фактически на каждой основной игровой видеосистеме, "взламывают" со временем, что в результате приводит к несанкционированному копированию видеоигр. Например, система безопасности Xbox 360 была взломана в июле 2006 г., и пользователи теперь могут загружать нелегальные копии в режиме онлайн. Игры, которые можно загружать (например, игры для PC или Mac), являются особенно уязвимыми для пиратства. В определенных регионах мира, где пиратство слабо контролируется, по существу, не существует жизнеспособного рынка для автономного программного обеспечения видеоигры, потому что пользователи могут покупать пиратские копии так же легко, как и легальные копии за цену, равную очень незначительной доле от цены. Кроме того, во многих частях мира цена игровой консоли составляет такой высокий процент от дохода, что, даже если бы пиратство контролировали, то мало людей могли бы позволить себе современную игровую систему.

Кроме того, рынок подержанных игр уменьшает доход видеоигровой промышленности. Когда пользователь теряет интерес к игре, он может продать игру розничному торговцу, который перепродает эту игру другим пользователям. Это несанкционированная, но обычная практика значительно уменьшает доходы издателей игр. Аналогично, обычно происходит сокращение продаж приблизительно на 50% при переходе на другую платформу каждые несколько лет. Это происходит потому, что пользователи перестают покупать игры для старых платформ, когда они узнают, что скоро должна быть выпущена новая версия платформы (например, когда собираются выпустить Playstation 3, пользователи перестают покупать игры для Playstation 2). Вместе взятые, уменьшение продаж и увеличение затрат на разработку, связанные с новыми платформами, могут оказать очень существенное неблагоприятное влияние на рентабельность разработчиков игр.

Новые игровые консоли также являются очень дорогими. Xbox 360, Nintendo Wii и Sony Playstation 3 - все в розницу продаются за сотни долларов. Мощные игровые системы персональных компьютеров могут стоить до 8000 долларов. Это представляет для пользователей существенное вложение денег, особенно с учетом того, что аппаратное обеспечение устаревает после нескольких лет, и того, что многие системы покупают для детей.

Одним подходом к решению вышеизложенных проблем являются онлайновые игры, в которых программа, управляющая игрой, и данные размещены на сервере и доставляются в клиентские машины по требованию как сжатое видео и аудио, которые передаются потоком по широкополосной цифровой сети. Некоторые компании, например, G-Cluster в Финляндии (теперь дочерняя компания японской корпорации SOFTBANK Broadmedia) в настоящее время оказывают эти услуги в режиме онлайн. Аналогичные игровые услуги стали доступны в локальных сетях, например, в локальных сетях гостиниц, и предлагаются провайдерами DSL и кабельного телевидения. Основным недостатком этих систем является проблема времени ожидания, т.е. время, которое требуется сигналу для прохождения до и от игрового сервера, который обычно расположен в "центральной станции" оператора. Динамичные видеоигры-боевики (также известные как видеоигры "twitch" ("подергивания")) требуют очень малого времени ожидания между временем, когда пользователь выполняет операцию с игровым контроллером, и временем, когда экран дисплея обновляется и показывает результат операции пользователя. Малое время ожидания требуется для того, чтобы у пользователя было ощущение, что игра отвечает "немедленно". Пользователи могут быть удовлетворены разными интервалами времени ожидания в зависимости от типа игры и уровня мастерства пользователя. Например, время ожидания 100 мс может быть допустимым для медленной бессистемной игры (подобной бакгаммон) или медленной ролевой игры, но в динамичной игре-боевике время ожидания, превышающее 70 или 80 мс, может ухудшать игру пользователя и, соответственно, является неприемлемым. Например, в игре, которая требует быстрого времени реакции, резко ухудшается точность по мере увеличения времени ожидания от 50 до 100 мс.

Когда игровой сервер или сервер приложений установлены в близлежащей, управляемой сетевой среде, или там, где сетевой тракт до пользователя является предсказуемым, и/или он может выдерживать пики полосы пропускания, намного проще управлять временем ожидания и с точки зрения максимального времени ожидания, и с точки зрения постоянства времени ожидания (например, так, что пользователь наблюдает устойчивое движение от цифрового видео, передаваемого потоком через сеть). Такого уровня управления можно достичь между распределительным устройством сети кабельного телевидения до дома абонента кабельного телевидения, или от центральной АТС DSL до дома абонента DSL, или в среде коммерческой учрежденческой локальной сети (LAN) от сервера или пользователя. Также можно получить специально разделенные частные соединения точка-точка между компаниями, которые имеют гарантированную полосу пропускания и время ожидания. Но в игровой или прикладной системе, которая размещает игры в серверном центре, подключенном к общему Internet, и затем передает потоком сжатое видео пользователю через широкополосное соединение, многие факторы воздействуют на время ожидания, что в результате приводит к серьезным ограничениям в применении систем предшествующего уровня техники.

В типичном доме, подключенном к широкополосному каналу, пользователь может иметь DSL или кабельный модем для услуг широкополосного доступа. Для таких услуг широкополосного доступа время передачи сигнала туда и обратно между домом пользователя и общим Internet обычно составляет 25 мс (а иногда и больше). Кроме того, существуют величины времени ожидания передачи сигнала туда и обратно, которые являются следствием маршрутизации данных через Internet в серверный центр. Время ожидания передачи через Internet меняется в зависимости от маршрута, который задается данным, и задержек, которые происходят вследствие маршрутизации по нему. В дополнение к задержкам маршрутизации время передачи сигнала туда и обратно также является следствием скорости света, проходящего через светопровод, который соединяет большую часть Internet. Например, на каждые 1000 миль (1600 км) время передачи сигнала туда и обратно приблизительно равно 22 мс вследствие скорости света через светопровод и других потерь.

Дополнительное время ожидания может произойти из-за скорости передачи данных, передаваемых потоком через Internet. Например, если пользователю предоставляется услуга DSL, которую продают как "услугу DSL 6 мегабит в секунду", то на практике пользователь, вероятно, получит меньше 5 мегабит в секунду пропускной способности нисходящего потока данных в лучшем случае и, вероятно, будет наблюдать, что соединение периодически ухудшается из-за различных факторов, например, перегрузки во время периодов пиковой нагрузки в мультиплексоре доступа к цифровой абонентской линии (DSLAM). Аналогичный вопрос может возникнуть с уменьшением скорости передачи данных кабельного модема (используемого) для соединения, проданного как "услуга кабельной модемной связи 6 мегабит в секунду", до скорости, гораздо меньшей, чем указанная, если произойдет перегрузка в локальном общем коаксиальном кабеле, образующем линию связи через окрестности, или в другом месте в сети системы кабельных модемов. Если пакеты данных с устойчивой скоростью 4 Мбит/с будут передаваться потоком в одном направлении в формате протокола передачи дейтаграмм пользователя (UDP) от серверного центра через такие соединения, если все будет работать исправно, то пакеты данных будут передаваться без дополнительного времени ожидания, но в случае перегрузки (или других препятствий) и если потоковым данным к пользователю доступно только 3,5 Мбит/с, то в типичной ситуации или пакеты будут сброшены, что в результате приведет к потере данных, или пакеты будут стоять в очереди в точке перегрузки, пока они не будут отправлены, следовательно, с введением дополнительного времени ожидания. В разных точках перегрузки существует разная вместимость очереди для хранения задерживаемых пакетов, соответственно, в некоторых случаях пакеты, которые не могут пройти через точку перегрузки, немедленно сбрасываются. В других случаях в очереди стоят несколько мегабитов данных и в итоге отправляются. Но почти во всех случаях, очереди в точках перегрузки ограничены по вместимости, и после превышения этих ограничений очереди переполняются, и пакеты сбрасываются. Соответственно, для устранения дополнительного времени ожидания (или, что еще хуже, потери пакетов) необходимо устранение превышения возможностей скорости передачи данных из игрового сервера или сервера приложений пользователю.

Время ожидания также является следствием времени, требуемого для сжатия видео в сервере и восстановления сжатого видео в клиентском устройстве. Время ожидания также имеет место, когда в видеоигре, исполняющейся на сервере, вычисляется следующий кадр, который должен быть выведен на экран. Имеющиеся в настоящее время доступные алгоритмы сжатия видео страдают или из-за высоких скоростей передачи данных, или из-за большого времени ожидания. Например, алгоритм сжатия движущихся изображений MJPEG является только-внутрикадровым алгоритмом сжатия с потерями, который отличается малым временем ожидания. Каждый кадр видео сжимается независимо от каждого другого кадра видео. Когда клиентское устройство принимает кадр видео, сжатого по алгоритму сжатия движущихся изображений MJPEG, то оно может немедленно восстановить сжатый кадр и вывести его на экран с получающимся в результате очень малым временем ожидания. Но из-за того, что каждый кадр сжимается отдельно, упомянутый алгоритм не может использовать сходные черты между последовательными кадрами, и в результате только-внутрикадровые алгоритмы сжатия видео страдают от очень высоких скоростей передачи данных. Например, видео 640×480, 60 кадр/с (кадров в секунду), сжатое по алгоритму сжатия движущихся изображений MJPEG, может потребоваться 40 Мбит/с (мегабит в секунду) или большая (скорость передачи) данных. Такие высокие скорости передачи данных для видеоокна с таким низким разрешением требуют чрезмерно больших затрат во многих широкополосных приложениях (и, конечно, для большинства потребительских приложений, основанных на Internet-технологиях). Кроме того, из-за того, что каждый кадр сжимается независимо, артефакты в кадрах, которые могут получиться в результате сжатия с потерями, вероятно, будут появляться в разных местах в последовательных кадрах. Это может в результате привести к тому, что для зрителя выглядит как движущиеся визуальные артефакты, когда восстанавливается сжатое видео.

Другие алгоритмы сжатия, например, MPEG2, H.264 или VC9 от корпорации "Майкрософт", как они используются в конфигурациях предшествующего уровня техники, могут достигать высоких коэффициентов сжатия, но за счет большого времени ожидания. Такие алгоритмы используют межкадровое, а также внутрикадровое сжатие. Периодически такие алгоритмы выполняют только-внутрикадровое сжатие кадра. Такой кадр известен как ключевой кадр (как правило, называемый I-кадр). После этого эти алгоритмы, как правило, сравнивают I-кадр с предшествующими кадрами и с последующими кадрами. Вместо того чтобы сжимать предшествующие кадры и последующие кадры независимо, упомянутый алгоритм определяет то, что изменилось в изображении предшествующих и последующих кадров по сравнению с I-кадром, и после этого сохраняет эти изменения, как так называемые B-кадры для изменений, предшествующих I-кадру, и P-кадры для изменений, следующих за I-кадром. Это в результате приводит к гораздо меньшим скоростям передачи данных, чем только-внутрикадровое сжатие. Но это, как правило, достигается за счет большего времени ожидания. I-кадр обычно намного больше, чем B-кадр или P-кадр (часто в 10 раз больше), и в результате его передача занимает пропорционально больше времени при данной скорости передачи данных.

Рассмотрим, например, ситуацию, когда I-кадры в 10 раз больше B-кадров и P-кадров, и существует 29 B-кадров+30 P-кадров=59 промежуточных кадров для каждого отдельного I-интракадра, или всего 60 кадров для каждой "Группы Кадров" (GOP). Соответственно, при 60 кадр/с, каждую секунду существует 1 60-кадровая GOP. Предположим, что максимальная скорость передачи данных на канале передачи равна 2 Мбит/с. Для получения видео высшего качества в этом канале алгоритм сжатия может выводить поток данных 2 Мбит/с, и, с учетом вышеупомянутых коэффициентов, в результате этого получается 2 мегабита (Мбит)/(59+10)=30 394 бита в каждом интракадре и 303 935 битов в каждом I-кадре. Когда алгоритм восстановления сжатых данных принимает сжатый видеопоток, для устойчивого воспроизведения видео, требуется восстанавливать каждый сжатый кадр и выводить их на экран с постоянным интервалом (например, 60 кадр/с). Для получения этого результата, если для какого-либо кадра существует время ожидания передачи, то все кадры должны быть задержаны, по меньшей мере, на время этого времени ожидания, соответственно, самое большое время ожидания кадра определяет время ожидания для каждого видеокадра. I-кадры вводят самые большие величины времени ожидания передачи, так как они являются наибольшими, и весь I-кадр должен быть принят до того, как может быть восстановлен сжатый I-кадр и выведен на экран (или любой промежуточный кадр, зависящий от I-кадра). С учетом того, что скорость передачи данных по каналу равна 2 Мбит/с, передача I-кадра займет 303 935/2 Мбит = 145 мс.

В системе межкадрового сжатия видео, как описано выше, с использованием большого процента полосы пропускания канала передачи существуют большие величины времени ожидания из-за большого размера I-кадра относительно среднего размера кадра. Или, другими словами, несмотря на то что при алгоритмах межкадрового сжатия предшествующего уровня техники достигается меньшая средняя покадровая скорость передачи данных, чем при только-внутрикадровых алгоритмах сжатия (например, 2 Мбит/с по сравнению с 40 Мбит/с), они, тем не менее, страдают от высокой пиковой покадровой скорости передачи данных (например, 303 935×60=18,2 Мбит/с) из-за больших I-кадров. Однако следует принимать во внимание то, что вышеупомянутый анализ предполагает, что все P-кадры и B-кадры намного меньше I-кадров. Несмотря на то что это в общем справедливо, это несправедливо для кадров с высоким уровнем сложности изображения, некоррелированных с предшествующим кадром, с большим перемещением или со сменами сцен. В таких ситуациях P-кадры или B-кадры могут становиться такими большими, как I-кадры (если P-кадр или B-кадр становится больше I-кадра, то усложненный алгоритм сжатия, как правило, "обеспечивает" I-кадр и заменяет P-кадр или B-кадр I-кадром). Соответственно, в цифровом видеопотоке в любой момент могут иметь место пики скорости передачи данных, имеющие размер I-кадра. Соответственно, в случае со сжатым видео, когда средняя скорость передачи данных видео приближается к пропускной способности скорости передачи данных каналов передачи (как это часто происходит, с учетом требований высокой скорости передачи данных для видео), высокие пиковые скорости передачи данных из-за I-кадров или больших P-кадров или B-кадров в результате приводят к большому времени ожидания кадра.

Несомненно, в вышеизложенном обсуждении описывается только время ожидания алгоритма сжатия, создаваемое большими B-кадрами, P-кадрами или I-кадрами в GOP. Если используются B-кадры, то время ожидания будет еще больше. Причиной, по которой это происходит, является то, что до того, как B-кадр может быть выведен на экран, все B-кадры, следующие за B-кадром и I-кадром, должны быть приняты. Соответственно, в последовательности группы изображений (GOP), например, BBBBBIPPPPPBBBBBIPPPPP, в которой существуют 5 B-кадров перед каждым I-кадром, первый B-кадр не может быть выведен на экран устройством восстановления сжатого видео до тех пор, пока не будут приняты последующие B-кадры и I-кадр. Соответственно, если видео передают потоком со скоростью 60 кадр/с (т.е. 16,67 мс/кадр), то до того, как может быть восстановлен сжатый первый B-кадр, потребуется 16,67×6=100 мс для приема пяти B-кадров и I-кадра, независимо от скорости полосы пропускания канала, и это только с 5 B-кадрами. Сжатые видеопоследовательности с 30 B-кадрами являются довольно распространенными. И при небольшой полосе пропускания канала, как 2 Мбит/с, влияние времени ожидания, вызванного размером I-кадра, является большим дополнением к влиянию времени ожидания из-за ожидания поступления B-кадров. Соответственно, на канале 2 Мбит/с с большим количеством B-кадров довольно просто превысить время ожидания 500 мс или больше с использованием технологии сжатия видео предшествующего уровня техники. Если B-кадры не используются (за счет меньшего коэффициента сжатия для данного уровня качества), то B-кадр не вызывает время ожидания, но по-прежнему время ожидания вызывают пиковые размеры кадра, описанные выше.

Проблема усугубляется самим характером многих видеоигр. Алгоритмы сжатия видео, использующие структуру GOP, описанную выше, в значительной степени оптимизированы для использования с видео в прямом эфире или материалом кинофильма, предназначенного для пассивного просмотра. Как правило, камера (либо реальная камера или виртуальная камера в случае создаваемой компьютером анимации) и сцена являются относительно устойчивыми, просто потому, что если камера или сцена перемещаются слишком отрывисто, то материал фильма или видео (a) как правило, не приятно смотреть, и (b) если его смотрят, то обычно зритель не внимательно следит за действием, когда камера внезапно резко поворачивается (например, если камера ударяется при съемке, когда ребенок задувает свечи на торте ко дню рождения, и внезапно резко поворачивается в сторону от торта и возвращается обратно, то зрители, как правило, сосредоточены на ребенке и торте и не обращают внимания на краткое прерывание, когда камера внезапно перемещается). В случае видеоинтервью или видеотелеконференции камера может удерживаться в фиксированном положении и совсем не двигаться, что в результате приводит к совсем очень маленькому количеству пиков данных. Но 3D видеоигра с высокой активностью отличается постоянным движением (например, рассмотрим 3D гонки, где весь кадр находится в быстром движении в течение гонки, или рассмотрим игры-боевики от первого лица, где виртуальная камера постоянно перемещается рывками). Такие видеоигры могут в результате привести к последовательностям кадров с большими и частыми пиками, где пользователю может быть необходимо ясно видеть то, что происходит в течение этих внезапных движений. Как таковые, артефакты сжатия гораздо менее приемлемы в 3D видеоиграх с высокой активностью. Соответственно, видеовыход многих видеоигр, вследствие их характера, выводит сжатый видеопоток с очень высокими и частыми пиками.

С учетом того, что пользователи динамичных видеоигр-боевиков не терпимы к большому времени ожидания, и с учетом всех вышеупомянутых причин времени ожидания до настоящего времени существовали ограничения для размещенных на сервере видеоигр, которые передавали потоком видео в Internet. Кроме того, пользователи приложений, которые требуют высокой степени интерактивности, страдают от аналогичных ограничений, если эти приложения размещены в общем Internet и передают видеопотоком. Такие услуги требуют конфигурации сети, в которой хостинговые серверы устанавливаются непосредственно в распределительном устройстве (в случае кабельного широкополосного канала), или в центральной АТС (в случае цифровых абонентских линий (DSL)), или в пределах LAN (или на специально разделенном частном соединении) в коммерческой обстановке так, что маршрутом и расстоянием от клиентского устройства до сервера управляют для минимизации времени ожидания, и пики могут быть адаптированы так, что они не будут вызывать время ожидания. Сети LAN (как правило, имеющие скорость в пределах 100 Мбит/с-1 Гбит/с) и арендуемые линии связи с соответствующей полосой пропускания, как правило, могут поддерживать требования по пиковой полосе пропускания (например, пиковая полоса пропускания 18 Мбит/с равна незначительной доле от пропускной способности LAN 100 Мбит/с).

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

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

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

На фиг.1 изображена архитектура игровой видеосистемы предшествующего уровня техники.

На фиг.2a-фиг.2b изображена архитектура системы высокого уровня согласно одному варианту осуществления.

На фиг.3 изображены фактические, оцененные и требуемые скорости передачи данных для передачи информации между клиентом и сервером.

На фиг.4a изображена служба хостинга и клиент, применяемые согласно одному варианту осуществления.

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

На фиг.4c изображено клиентское устройство согласно одному варианту осуществления.

На фиг.4d изображено клиентское устройство согласно другому варианту осуществления.

На фиг.4e изображена иллюстративная блок-схема клиентского устройства по фиг.4c.

На фиг.4f изображена иллюстративная блок-схема клиентского устройства по фиг.4d.

На фиг.5 изображена иллюстративная форма сжатия видео, которая может быть применена согласно одному варианту осуществления.

На фиг.6a изображена иллюстративная форма сжатия видео, которая может быть применена в другом варианте осуществления.

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

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

На фиг.7a-фиг.7b изображены иллюстративные способы сжатия видео, применяемые в одном варианте осуществления.

На фиг.8 изображены дополнительные иллюстративные способы сжатия видео, применяемые в одном варианте осуществления.

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

На фиг.10a-фиг.10b изображен один вариант осуществления, который эффективно упаковывает фрагменты внутри пакетов.

На фиг.11a-фиг.11d изображены варианты осуществления, которые применяют способы прямого исправления ошибок.

На фиг.12 изображен один вариант осуществления, который использует многоядерные процессоры для сжатия.

На фиг.13a-фиг.13b изображено географическое положение и связь между службами хостинга согласно различным вариантам осуществления.

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

На фиг.15 изображена иллюстративная архитектура серверного центра службы хостинга.

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

На фиг.17 изображен интерфейс пользователя по фиг.16 после выбора конкретного видеоокна.

На фиг.18 изображен интерфейс пользователя по фиг.17 после распахивания упомянутого конкретного видеоокна во весь экран.

На фиг.19 изображены иллюстративные совместные пользовательские видеоданные, совмещенные на экране игры с нескольким участниками.

На фиг.20 изображена иллюстративная страница пользователя для игрока в службе хостинга.

На фиг.21 изображена иллюстративная 3D интерактивная реклама.

На фиг.22 изображена иллюстративная последовательность этапов для вывода фотореального изображения, имеющего текстурированную поверхность, исходя из захвата поверхности живого исполнения.

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

Фиг.24 - график, который иллюстрирует время, которое пройдет до того, как web-страница станет активной, по сравнению со скоростью соединения.

Описание иллюстративных вариантов осуществления

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

На фиг.2a-фиг.2b обеспечена архитектура высокого уровня двух вариантов осуществления, в которых видеоигры и приложения размещаются службой 210 хостинга и к ним получают доступ клиентские устройства 205, находящиеся на территории 211 пользователя (отметим, что "территория пользователя" означает любое место, где находится пользователь, в том числе на открытом воздухе, если он использует мобильное устройство), через Internet 206 (или другую общедоступную или частную сеть) согласно абонентскому обслуживанию. Клиентские устройства 205 могут быть универсальными компьютерами, например, PC Windows Microsoft или PC Linux или компьютерами Macintosh корпорации Apple, Inc. с проводным или беспроводным соединением с Internet, с встроенным или внешним дисплеем 222, или они могут быть специализированными клиентскими устройствами, например, телевизионной абонентской приставкой (с проводным или беспроводным соединением с Internet), которая выводит видео и аудио на монитор или телевизор 222, или они могут быть мобильными устройствами, предположительно с беспроводным соединением с Internet.

Любое из этих устройств может иметь свои собственные устройства ввода пользователя (например, клавиатуры, кнопки, сенсорные экраны, трекпад или световое перо, камеры видеозахвата и/или камеры, отслеживающие движение, и т.д.), или они могут использовать внешние устройства 221 ввода (например, клавиатуры, мыши, игровые контроллеры, световое перо, камеры видеозахвата и/или камеры, отслеживающие движение, и т.д.), подключенные посредством проводов или беспроводным способом. Как описано более подробно ниже, служба 210 хостинга включает в себя серверы различных уровней производительности, в том числе серверы с мощными средствами обработки CPU/GPU. Во время ведения игры или использования приложения в службе 210 хостинга домашнее или офисное клиентское устройство 205 принимает входные данные контроллера и/или клавиатуры от пользователя, и затем оно отправляет эти входные данные контроллера через Internet 206 в службу 210 хостинга, который в ответ исполняет программу, управляющую игрой, и формирует последовательные кадры видеовыхода (последовательность видеоизображений) для игры или прикладного программного обеспечения (например, если пользователь нажимает на кнопку, которая может перемещать персонажа на экране вправо, тогда игровая программа создает последовательность видеоизображений, на которых изображен персонаж, перемещающийся вправо). Эта последовательность видеоизображений после этого сжимается с использованием устройства сжатия видео с малым временем ожидания, и после этого служба 210 хостинга передает видеопоток с малым временем ожидания через Internet 206. Домашнее или офисное клиентское устройство после этого декодируют сжатый видеопоток и визуализируют восстановленные видеоизображения на мониторе или телевизоре. Следовательно, требования к вычислительной и графической технике клиентского устройства 205 значительно уменьшаются. Требуется, чтобы клиент 205 имел вычислительную мощность только для пересылки входных данных клавиатуры/контроллера в Internet 206 и декодирования и восстановления сжатого видеопотока, принятого из Internet 206, что в настоящее время фактически любой персональный компьютер может выполнять в программном обеспечении на своем центральном процессоре (например, двухядерный процессор корпорации Intel (Intel Corporation Core Duo CPU)), работающий с тактовой частотой приблизительно 2 ГГц, может восстанавливать сжатое HDTV 1280×720, закодированное с использованием таких устройств сжатия, как H.264 и Windows Media VC9). И в случае любых клиентских устройств также специализированные интегральные схемы могут выполнять восстановление сжатого видео для таких стандартов в реальном времени с гораздо меньшими затратами и с гораздо меньшим потреблением мощности, чем универсальный CPU, например, который может потребоваться для современного PC. А именно для выполнения функции пересылки входных данных контроллера и восстановления сжатого видео, в домашних клиентских устройствах 205 не требуются никакие специализированные графические процессоры (GPU), накопитель на оптических дисках или накопители на жестких дисках, например, игровая видеосистема предшествующего уровня техники, изображенная на фиг.1.

По мере того как игры и прикладное программное обеспечение становится более сложным и более фотореалистичным, они требуют GPU, CPU более высокой производительности, большего количества RAM и более быстрых накопителей на магнитных дисках большей емкости, и вычислительная мощность службы 210 хостинга может непрерывно модернизироваться, но конечному пользователю не потребуется обновлять домашнюю или офисную клиентскую платформу 205, так как требования к ее обработке будут оставаться постоянными для разрешающей способности дисплея и частоты кадров при данном алгоритме восстановления сжатого видео. Соответственно, аппаратные ограничения и вопросы совместимости, имеющиеся в настоящее время, не существуют в системе, изображенной на фиг.2a-фиг.2b.

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

В одном варианте осуществления служба 210 хостинга обеспечивает инструментальные средства разработки программного обеспечения разработчикам 220 прикладного программного обеспечения или игры (что, как правило, относится к компаниям по разработке программного обеспечения, игровым или телевизионным студиям или издателям прикладного программного обеспечения или игры), которые проектируют видеоигры, для того чтобы они могли проектировать игры, которые можно будет исполнять в службе 210 хостинга. Такие инструментальные средства обеспечивают возможность разработчикам использовать признаки службы хостинга, которые обычно не доступны в автономном PC или игровой консоли (например, быстрый доступ к очень большим базам данных сложной геометрии ("геометрия", если не оговорено иное, используется в этом описании для ссылки на многоугольники, текстуры, снаряжение, освещение, линии поведения и другие компоненты и параметры, которые определяют базы данных 3D)).

Разные бизнес-модели возможны по этой архитектуре. По одной модели служба 210 хостинга получает абонентскую плату от конечного пользователя и платит лицензионный платеж разработчикам 220, как изображено на фиг. 2a. В альтернативной реализации, изображенной на фиг.2b, разработчики 220 получают абонентскую плату непосредственно от пользователя и платят службе 210 хостинг за хостинг содержимого приложения или игры. Эти лежащие в основе принципы не ограничены какой-либо конкретной бизнес-моделью для обеспечения хостинга приложения или онлайновых игр.

Характеристики сжатого видео

Как обсуждалось ранее, одной существенной проблемой, связанной с оказанием услуг по видеоиграм или услуг по прикладному программному обеспечению в режиме онлайн, является проблема времени ожидания. Время ожидания 70-80 мс (от момента, когда устройство ввода приводится в действие пользователем, до момента, когда ответ выводится на экран дисплея) находится на верхней границе для игр и приложений, требующих малого времени отклика. Однако достичь такой задержки очень трудно в контексте архитектуры, изображенной на фиг.2a и фиг.2b, из-за нескольких практических и физических ограничений.

Как указано на фиг.3, когда пользователь подписывается на Internet-услугу, соединение обычно оценивается номинальной максимальной скоростью 301 передачи данных до офиса или дома пользователя. В зависимости от политики провайдеров и характеристик оборудования для маршрутизации может быть более или менее обеспечено строгое выполнение этой максимальной скорости передачи данных, но, как правило, фактическая доступная скорость передачи данных является более низкой по одной или нескольким разным причинам. Например, в центральной АТС DSL или в локальной линии кабельной модемной связи может находиться слишком много сетевого трафика, или в кабельной сети может присутствовать шум, вызывающий сброс пакетов, или провайдер может установить максимальное количество битов в месяц для каждого пользователя. В настоящее время, максимальная скорость передачи нисходящего потока данных для услуг DSL и кабельной связи, как правило, колеблется от нескольких сотен килобит в секунду (Кбит/с) до 30 Мбит/с. Услуги сотовой связи обычно ограничены до сотен Кбит/с нисходящего потока данных. Однако скорость услуг широкополосного доступа и количество пользователей, которые подписываются на услуги широкополосного доступа, существенно увеличатся со временем. В настоящее время, некоторые аналитики оценивают, что 33% американских абонентов широкополосного доступа имеют скорость передачи нисходящего потока данных 2 Мбит/с или больше. Например, некоторые аналитики предсказывают, что к 2010 г. свыше 85% американских абонентов широкополосного доступа будут иметь скорость передачи данных 2 Мбит/с или больше.

Как указано на фиг.3, фактическая доступная максимальная скорость 302 передачи данных может колебаться с течением времени. Соответственно, в контексте прикладного программного обеспечения или онлайновых игр с малым временем ожидания иногда трудно предсказать фактическую доступную скорость передачи данных для конкретного видеопотока. Если скорость 303 передачи данных, требуемая для поддержки данного уровня качества при данном количестве кадров в секунду (кадр/с) с данной разрешающей способностью (например, 640×480, 60 кадр/с) для определенной величины сложности сцены и перемещения, поднимается выше фактической доступной максимальной скорости 302 передачи данных (как указано посредством пика на фиг.3), то может возникнуть несколько проблем. Например, в некоторых Internet-услугах будут просто сбрасываться пакеты, что в результате приведет к потере данных и искаженным/потерянным изображениям на видеоэкране пользователя. В других услугах дополнительные пакеты будут временно помещены в буфер (т.е. поставлены в очередь), и эти пакеты будут обеспечены клиенту с имеющейся скоростью передачи данных, что в результате приведет к увеличению времени ожидания - неприемлемый результат для многих видеоигр и приложений. Наконец, некоторые провайдеры Internet-услуг будут рассматривать увеличение скорости передачи данных как злонамеренную атаку, например, как атаку типа отказ в обслуживании (известный способ, (используемый) хакерами для блокирования сетевых соединений), и прервут соединение пользователя с Internet на определенный период времени. Соответственно, в вариантах осуществления, описанных в этом документе, предпринимаются шаги для обеспечения того, что скорость передачи данных, требуемая для видеоигры, не будет превышать максимальную имеющуюся скорость передачи данных.

Архитектура службы хостинга

На фиг.4a изображена архитектура 210 службы хостинга согласно одному варианту осуществления. Служба 210 хостинга или может быть расположена в одном серверном центре, или может быть распределена по всему множеству серверных центров (для обеспечения соединений с пользователями с меньшим временем ожидания, которые имеют маршруты с меньшим временем ожидания до определенных серверных центров, чем другие, для обеспечения выравнивания нагрузки среди пользователей и обеспечения избыточности на случай отказа одного или нескольких серверных центров). Служба 210 хостинга может со временем включать в себя сотни тысяч или даже миллионов серверов 402, обслуживающих очень большое количество пользователей. Система 401 управления службы хостинга обеспечивает централизованное управление для службы 210 хостинга и управляет маршрутизаторами, серверами, системами сжатия видео, системами учета и формирования счетов и т.д. В одном варианте осуществления система 401 управления службы хостинга реализована в распределенной системе обработки данных на основе операционной системы Linux, соединенной с дисковыми массивами типа RAID, используемыми для хранения баз данных для пользовательской информации, информации для сервера и статистических данных системы. В вышеизложенных описаниях различные операции, реализованные службой 210 хостинга, если они не отнесены к другим специальным системам, инициируются и управляются системой 401 управления службы хостинга.

Служба 210 хостинга включает в себя несколько серверов 402, например, таких серверов, которые в настоящее время имеются в продаже, от Intel, IBM, Hewlett Packard, и других. В качестве альтернативы серверы 402 могут быть собраны в заказной конфигурации из компонентов, или, в конце концов, они могут быть интегрированы так, что весь сервер будет реализован как однокристальная интегральная схема. Несмотря на то что на этой схеме для примера изображено небольшое количество серверов 402, при фактическом применении может быть только один сервер 402 или миллионы серверов 402 или больше. Все серверы 402 могут быть сконфигурированы одинаково (в качестве примера некоторых параметров конфигурации, с одинаковыми производительностью и типом CPU, с или без GPU, и если с GPU, то с одинаковыми производительностью и типом GPU, с одинаковым количеством CPU и GPU, с одинаковыми объемом и типом/скоростью RAM и с одинаковой конфигурацией RAM), или различные подмножества серверов 402 могут иметь одинаковую конфигурацию (например, 25% серверов могут быть выполнены определенным способом, 50% другим способом и 25% еще одним способом), или все серверы 402 могут быть разными.

В одном варианте осуществления серверы 402 без диска, т.е. вместо того, чтобы иметь свое собственное локальное массовое запоминающее устройство (независимо от того, является ли оно оптическим или магнитным запоминающим устройством, или запоминающим устройством на полупроводниках, например флэш-памятью, или другим средством массовой памяти, выполняющим аналогичную функцию), каждый сервер имеет доступ к общей массовой памяти через быстродействующую магистраль или ускоренное сетевое соединение. В одном варианте осуществления этим высокоскоростным соединением является сеть 403 хранения данных (SAN), соединенная с набором матриц 405 независимых дисковых накопителей с избыточностью (RAID) с соединениями между устройствами, реализованными с использованием технологии Gigabit Ethernet. Как известно специалистам в данной области техники, SAN 403 можно использовать для объединения множества дисковых массивов 405 типа RAID вместе, что в результате приводит к чрезвычайно широкой полосе пропускания - приближающейся или, возможно, превышающей полосу пропускания, доступную из RAM, используемой в современных игровых консолях и PC. И в то время как дисковые массивы типа RAID на основе вращающихся носителей информации, например, магнитных носителей информации, часто имеют существенное время ожидания доступа во время поиска, дисковые массивы типа RAID на основе полупроводниковой памяти могут быть реализованы с гораздо меньшим временем ожидания доступа. В другой конфигурации некоторые или все серверы 402 предоставляют некоторые или все свои собственные массовые запоминающие устройства локально. Например, на сервере 402 может храниться информация, к которой часто обращаются, например ее операционная система и копия видеоигры или приложения, на локальном запоминающем устройстве на основе флеш-памяти с малым временем ожидания, но он может использовать SAN для доступа к дисковым массивам 405 типа RAID, на основе вращающихся носителей информации с большим временем поиска, для получения доступа к большим базам данных геометрии или информации о состоянии игры с меньшей частотой.

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

При операции во время ведения видеоигры или использования приложения на территории 211 пользователя посредством клавиатуры, мыши, игрового контроллера или другого устройства 421 ввода, логика 413 управляющего сигнала на клиенте 415 передает управляющие сигналы 406a-406b (как правило, в виде пакетов UDP), представляющие нажатия клавиши (и другие виды вводов пользователя), приводимые в действие пользователем, в службу 210 хостинга 210. Управляющие сигналы от данного пользователя маршрутизируются в соответствующий сервер 402 (или серверы, если на устройство ввода пользователя реагируют множество серверов). Как изображено на фиг.4a, управляющие сигналы 406a могут маршрутизироваться в серверы 402 через SAN. В качестве альтернативы или в дополнение управляющие сигналы 406b могут маршрутизироваться непосредственно в серверы 402 по сети службы хостинга (например, по локальной сети Ethernet). Независимо от того как они были переданы, сервер или серверы исполняют игру или прикладное программное обеспечение в ответ на управляющие сигналы 406a-406b. Несмотря на то что на фиг.4a не изображены различные сетевые компоненты, например, брандмауэр(ы) и/или шлюз(ы), они могут обрабатывать входящий и исходящий трафик на границе службы 210 хостинга (например, между службой 210 хостинга и Internet 410) и/или на границе территории 211 пользователя между Internet 410 и домашним или офисным клиентом 415. Графический выход и аудиовыход исполняемой игры или прикладного программного обеспечения - т.е. новые последовательности видеоизображений - обеспечиваются в логику 404 сжатия видео с малым временем ожидания, которая сжимает последовательности видеоизображений согласно способам сжатия видео с малым временем ожидания, например, согласно способам, описанным в этом документе, и передает сжатый видеопоток, обычно со сжатым или несжатым аудио, назад в клиента 415 через Internet 410 (или, как описано ниже, через оптимизированную высокоскоростную сетевую службу, которая предает в обход общего Internet). После этого логика 412 восстановления сжатого видео с малым временем ожидания в клиенте 415 восстанавливает сжатые видео- и аудиопотоки и визуализирует восстановленный видеопоток и, как правило, воспроизводит восстановленный аудиопоток на дисплее 422. В качестве альтернативы аудио может быть воспроизведено в динамиках, отделенных от дисплея 422, или совсем не воспроизводиться. Отметим, что, несмотря на то что устройство 421 ввода и дисплей 422 изображены на фиг.2a и фиг.2b как автономные устройства, они могут быть интегрированы внутри клиентских устройств, например, портативных компьютеров или мобильных устройств.

Домашний или офисный клиент 415 (описанный ранее на фиг.2a и фиг.2b как домашний или офисный клиент 205) могут быть очень экономичным устройством с малым энергопотреблением, с очень ограниченной вычислительной производительностью или производительностью графической подсистемы, и может иметь очень ограниченную локальную массовую память, или она совсем может отсутствовать. Напротив, каждый сервер 402, соединенный с SAN 403 и множеством RAID 405, может быть исключительно высокопроизводительной вычислительной системой, и, безусловно, если совместно используются множество серверов в конфигурации параллельной обработки, то почти не существует ограничений по вычислительной производительности системы и производительности графической подсистемы, которые могут быть использованы. И из-за сжатия 404 видео с малым временем ожидания и сжатия 412 видео с малым временем ожидания у пользователя создается впечатление, что упомянутая вычислительная мощность серверов 402 предоставляются пользователю. Когда пользователь нажимает клавишу на устройстве 421 ввода, изображение на дисплее 422 обновляется в ответ на нажатие этой клавиши без значимой задержки с точки зрения восприятия так, как в случае локального исполнения игры или прикладного программного обеспечения. Соответственно, с домашним или офисным клиентом 415, который является компьютером с очень низкой производительностью или только экономичной интегральной схемой, в которой реализовано восстановление сжатого видео с малым временем ожидания и логика 413 управляющего сигнала, пользователь обеспечен фактически произвольно выбираемой вычислительной мощностью из удаленного местоположения, причем создается впечатление, что они находятся локально. Это дает пользователям возможность запускать наиболее усовершенствованные, требующие интенсивной работы процессора (обычно новые) видеоигры и самые высокопроизводительные приложения.

На фиг.4c изображено очень элементарное и экономичное домашнее или офисное клиентское устройство 465. Это устройство является вариантом осуществления домашнего или офисного клиента 415 по фиг.4a и фиг.4b. Длина его приблизительно равна 5 сантиметрам. У него есть гнездо 462 Ethernet, которое обеспечивает интерфейс с кабелем Ethernet с питанием через Ethernet (PoE), через которое оно получает питание и получает соединение с Internet. Оно может исполнять преобразование сетевых адресов (NAT) внутри сети, которая поддерживает NAT. В офисной обстановке многие новые коммутаторы Ethernet имеют PoE и доводят PoE непосредственно до гнезда Ethernet в офисе. (В) таком случае все, что требуется, - это кабель Ethernet от настенного гнезда до клиента 465. Если имеющееся соединение Ethernet не переносит энергию (например, в доме с DSL или кабельным модемом, но без PoE), то в продаже имеются экономичные настенные "модули" (т.е. источники питания), которые принимают кабель Ethernet без питания и выводят Ethernet с PoE.

Клиент 465 содержит логику 413 управляющего сигнала (по фиг.4a), которая соединена с беспроводным интерфейсом Bluetooth, который обеспечивает интерфейс с устройствами 479 ввода Bluetooth, например, клавиатурой, мышью, игровым контроллером и/или микрофоном и/или наушниками. Кроме того, один вариант осуществления клиента 465 может выводить видео со скоростью 120 кадр/с, при соединении с дисплеем 468 может поддерживать видео 120 кадр/с и передавать сигналы (как правило, через инфракрасное излучение) в затворные очки 466 для попеременного закрытия то одного глаза, то другого с каждым последовательным кадром. Результатом, воспринимаемым пользователем, является стереоскопическое 3D изображение, которое "выскакивает" из экрана дисплея. Одним таким дисплеем 468, который поддерживает такую операцию, является Samsung HL-T5076S. Так как видеопоток для каждого глаза является отдельным, в одном варианте осуществления два независимых видеопотока сжимаются службой 210 хостинга, кадры чередуются во времени, и сжатые кадры восстанавливаются как два независимых процесса восстановления сжатых данных внутри клиента 465.

Клиент 465 также содержит логику 412 восстановления сжатого видео с малым временем ожидания, которая восстанавливает сжатое входящее видео и аудио и выводит через HDMI (мультимедийный интерфейс высокой четкости), соединительный кабель 463, который подключают к SDTV (телевидение стандартной четкости) или HDTV (телевидение высокой четкости) 468, в случае, если телевизор с видео и аудио, или к монитору 468, который поддерживает HDMI. Если монитор 468 пользователя не поддерживает HDMI, то может быть использован HDMI-DVI (цифровой видеоинтерфейс), но аудио будет утрачено. Согласно стандарту HDMI, характеристики 464 дисплея (например, поддерживаемые разрешающие способности, частоты кадров) передаются из дисплея 468, и эта информация затем возвращается через подключение 462 к Internet обратно в службу 210 хостинга, поэтому она может передавать потоком сжатое видео в формате, подходящем для дисплея.

На фиг.4d изображено домашнее или офисное клиентское устройство 475, которое является идентичным домашнему или офисному клиентскому устройству 465, изображенному на фиг.4c, за исключением того, что у него больше внешних интерфейсов. Кроме того, клиент 475 может принимать любой PoE для питания, или он может работать от внешнего адаптера источника питания (не изображен), который вставляется в контактное гнездо на стене. С использованием входа USB клиента 475 видеокамера 477 обеспечивает сжатое видео в клиент 475, которое выгружается клиентом 475 в службу 210 хостинга для использования, описанного ниже. Устройство сжатия с малым временем ожидания, использующее способы сжатия, описанные ниже, является встроенным в камеру 477.

В дополнение к разъему Ethernet для подключения к Internet клиент 475 также имеет беспроводной интерфейс 802.11g с Internet. Оба интерфейса могут использовать NAT внутри сети, которая поддерживает NAT.

Кроме того, в дополнение к разъему HDMI для вывода видео и аудио клиент 475 также имеет разъем Dual Link DVI-I (двухканальный DVI-I), который включает в себя аналоговый выход (и с эталонным кабелем адаптера обеспечивает выход VGA). Он также имеет аналоговые выходы для композитного видео и S-видео.

Для аудио клиент 475 имеет левое/правое гнезда RCA аналогового стерео, и для вывода цифрового аудио он имеет выход TOSLINK (оптический выход).

В дополнение к беспроводному интерфейсу Bluetooth с устройствами 479 ввода он также имеет гнезда USB для обеспечения интерфейса с устройствами ввода.

На фиг.4e изображен один вариант осуществления внутренней архитектуры клиента 465. Или все или некоторые из устройств, изображенные на схеме, могут быть реализованы в программируемой пользователем логической матрице, заказной схеме ASIC или в нескольких отдельных устройствах, или заказных или имеющихся в готовом виде.

Ethernet с PoE 497 подсоединяется к интерфейсу 481 Ethernet. Питание 499 подается из Ethernet с PoE 497 и соединяется с остальными устройствами в клиенте 465. Шина 480 является общей шиной для обмена информацией между устройствами.

Управляющий CPU 483 (почти любой небольшой CPU, например, CPU серии R4000 с быстродействием миллион команд в секунду (MIPS) и тактовой частотой 100 МГц со встроенной RAM отвечает требованиям), исполняющий небольшое клиентское управляющее приложение из флэш-памяти 476, обеспечивает выполнение стека протоколов для сети (т.е. интерфейс Ethernet) и также осуществляет связь со службой 210 хостинга и конфигурирует все устройства в клиенте 465. Он также управляет интерфейсами с устройствами 469 ввода и отправляет пакеты обратно в службу 210 хостинга с пользовательскими данными контроллера, защищенными посредством прямого исправления ошибок, в случае необходимости. Кроме того, управляющий CPU 483 осуществляет текущий контроль пакетного трафика (например, если пакеты утеряны или задержаны, а также делает отметку времени их поступления). Эта информация отправляется обратно в службу 210 хостинга так, чтобы она могла постоянно осуществить текущий контроль сетевого соединения и корректировать то, что она отправляет, соответственно. Во флэш-память 476 первоначально во время изготовления загружают управляющую программу для управляющего CPU 483, а также серийный номер, который является уникальным для конкретной клиентской 465 единицы оборудования. Этот серийный номер обеспечивает возможность службе 210 хостинга однозначно идентифицировать клиентскую 465 единицу оборудования.

Интерфейс 484 Bluetooth осуществляет связь с устройствами 469 ввода беспроводным способом через свою антенну, находящуюся внутри клиента 465.

Устройство 486 восстановления сжатого видео является устройством восстановления сжатого видео с малым временем ожидания, сконфигурированным для реализации восстановления сжатого видео, описанного в этом документе. Существует большое количество устройств восстановления сжатого видео, или имеющихся в готовом виде, или в виде интеллектуальной собственности (IP) конструкции, которая может быть интегрирована в FPGA или заказную схему ASIC. Одной компанией, предлагающей IP для декодера H.264, является Ocean Logic, Manly, NSW Australia. Преимуществом использования IP является то, что способы сжатия, используемые в этом описании, не соответствуют стандартам сжатия. Некоторые стандартные устройства восстановления сжатых данных являются достаточно гибкими для обеспечения способов сжатия, описанных в этом документе, но некоторые не могут (их обеспечивать). Но посредством IP существует полная гибкость для перепроектирования устройства восстановления сжатых данных так, как требуется.

Выход устройства восстановления сжатого видео соединен с подсистемой 487 вывода видео, которая соединяет видео с видеовыходом интерфейса 490 HDMI.

Подсистема 488 восстановления сжатого аудио реализуется или с использованием стандартного устройства восстановления сжатого аудио, которое имеется в продаже, или она может быть реализована как IP, или восстановление сжатого аудио может быть реализовано внутри управляющего процессора 483, который может, например, реализовывать устройство восстановления сжатого аудио Vorbis.

Устройство, которое осуществляет восстановление сжатого аудио, соединено с подсистемой 489 вывода аудио, которая соединяет аудио с аудиовыходом интерфейса 490 HDMI.

На фиг.4f изображен один вариант осуществления внутренней архитектуры клиента 475. Как можно видеть, эта архитектура является идентичной архитектуре клиента 465 за исключением дополнительных интерфейсов и необязательного внешнего питания DC от адаптера источника питания, который вставляют в контактное гнездо на стене, и если так используется, заменяет питание, которое может поступать из PoE 497 Ethernet. Функциональные возможности, которые присутствуют у клиента 465, не будут повторяться ниже, но дополнительные функциональные возможности описываются следующим образом.

CPU 483 осуществляет связь с дополнительными устройствами и конфигурирует их.

Подсистема 482 WiFi обеспечивает беспроводной доступ к Internet, в качестве альтернативы, к Ethernet 497 через свою антенну. В продаже имеются подсистемы WiFi от широкого круга производителей, включающих в себя Atheros Communications, Santa Clara, CA (Санта-Клара, Калифорния).

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

Подсистема 487 вывода видео выводит более широкий диапазон видеовыходов, чем внутри клиента 465. В дополнение к обеспечению видеовыхода HDMI 490 она обеспечивает DVI-I 491, S-видео 492 и композитное видео 493. Кроме того, когда для цифрового видео используется интерфейс DVI-I 491, характеристики 464 дисплея передаются обратно из дисплея в управляющий CPU 483 для того, чтобы он мог уведомлять службу 210 хостинга о характеристиках дисплея 478. Все интерфейсы, обеспечиваемые подсистемой 487 вывода видео, являются довольно стандартными интерфейсами и общедоступными во многих видах.

Подсистема 489 вывода аудио выводит аудио в цифровой форме через цифровой интерфейс 494 (S/PDIF и/или TOSLINK) и аудио в аналоговой форме через стереофонический аналоговый интерфейс 495.

Анализ времени передачи сигнала туда и обратно

Несомненно, для реализации преимуществ, изложенных в предыдущем разделе, время передачи сигнала туда и обратно между действием пользователя с использованием устройства 421 ввода и появлением результата этого действия на дисплее 420 не должно превышать 70-80 мс. Это время ожидания должно учитывать все факторы на пути от устройства 421 ввода на территории 211 пользователя до службы 210 хостинга и обратно до территории 211 пользователя, до дисплея 422. На фиг.4b изображены различные компоненты и сети, через которые должны проходить сигналы, и выше этих компонентов и сетей находится временная шкала, на которой выведены в упорядоченном виде иллюстративные величины времени ожидания, которые можно ожидать в практической реализации. Отметим, что фиг.4b является упрощенной и изображена только маршрутизация по критическому пути. Другая маршрутизация данных, используемая для других признаков системы, описана ниже. Двунаправленные стрелки (например, стрелка 453) указывают время передачи сигнала туда и обратно, и однонаправленные стрелки (например, стрелка 457) указывают время передачи сигнала в одну сторону, и "~" обозначают приблизительное измерение. Следует указать, что будут реальные ситуации, в которых нельзя будет получить перечисленные величины времени ожидания, но в большинстве случаев в США, с использованием соединений посредством кабельного модема и DSL с территорией 211 пользователя, эти величины времени ожидания могут быть получены в случаях, описанных в следующем разделе. Также отметим, что, несмотря на то, что сотовая беспроводная связь с Internet безусловно будет функционировать в изображенной системе, в большинстве современных американских сотовых систем передачи данных (например EVDO) существуют очень большие величины времени ожидания, и не могут быть получены величины времени ожидания, изображенные на фиг.4b. Однако эти лежащие в основе принципы могут быть реализованы в будущих сотовых технологиях, в которых может быть реализован этот уровень времени ожидания.

Начиная с устройства 421 ввода на территории 211 пользователя, после того, как пользователь приводит в действие устройство 421 ввода, управляющий сигнал пользователя отправляется в клиент 415 (который может быть автономным устройством, например, телевизионной абонентской приставкой, или он может быть программным обеспечением или аппаратным обеспечением, функционирующими в другом устройстве, например, PC или мобильном устройстве), и разбивается на пакеты (в формате UDP в одном варианте осуществления), и пакету дается адрес назначения для передачи в службу 210 хостинга. Пакет будет также содержать информацию для указания того, от какого пользователя поступают управляющие сигналы. После этого пакет(ы) управляющего сигнала пересылается(ются) через устройство 443 брандмауэра/маршрутизатора/NAT (преобразование сетевых адресов) в интерфейс 442 WAN. Интерфейс 442 WAN является интерфейсным устройством, обеспечиваемым для территории 211 пользователя провайдером ISP пользователя (провайдер Internet-услуг). Интерфейс 442 WAN может быть кабелем или модемом DSL, приемопередатчиком WiMax, приемопередатчиком для волоконно-оптической линии связи, интерфейсом сотовой системы передачи данных, интерфейсом передачи данных по протоколу IP через электросеть (Internet Protocol-over-powerline) или любым другим из множества интерфейсов с Internet. Кроме того, устройство 443 брандмауэра/маршрутизатора/NAT (и, возможно, интерфейс 442 WAN) может быть интегрировано в клиента 415. Примером этого может быть мобильный телефон, который включает в себя программное обеспечение для реализации функциональных возможностей домашнего или офисного клиента 415, а также средство для маршрутизации и подключения к Internet беспроводным способом через некоторый стандарт (например, 802.11g).

После этого интерфейс 442 WAN маршрутизирует управляющие сигналы в то, что называется в этом описании "точка входа в Internet" 441 для провайдера Internet-услуг (ISP) пользователя, которая является средством, которое обеспечивает интерфейс между средством передачи данных WAN, соединенным с территорией 211 пользователя, и общим Internet или частной сетью. Характеристики точки входа в Internet изменяются в зависимости от характера обеспечиваемой Internet-услуги. Для DSL это, как правило, будет центральная АТС телефонной компании, где расположен DSLAM. Для кабельных модемов это, как правило, будет центральная станция мультисистемного оператора (MSO) кабельной линии. Для систем сотовой связи это, как правило, будет диспетчерская, связанная с антенной мачтой сотовой связи. Но какова бы ни была природа точки входа в Internet, она далее маршрутизирует пакет(ы) управляющего сигнала в общий Internet 410. Пакет(ы) управляющего сигнала далее маршрутизируются в интерфейс 441 WAN со службой 210 хостинга через то, что наиболее вероятно будет интерфейсом приемопередатчика для волоконно-оптической линии связи. WAN 441 далее маршрутизирует пакеты управляющего сигнала в логику 409 маршрутизации (которая может быть реализована многими различными способами, включающими в себя коммутатор Ethernet и серверы маршрутизации), которая определяет адрес пользователя и маршрутизирует управляющий(ие) сигнал(ы) в соответствующий сервер 402 для данного пользователя.

После этого сервер 402 принимает управляющие сигналы как входные сигналы для игры или прикладного программного обеспечения, которые исполняются на сервере 402, и использует их для обработки следующего кадра игры или приложения. После формирования следующего кадра видео и аудио выводятся из сервера 402 в устройство 404 сжатия видео. Видео и аудио могут быть выведены из сервера 402 в устройство 404 сжатия посредством различных средств. Во-первых, устройство 404 сжатия может быть встроено в сервер 402, соответственно, сжатие может быть реализовано локально внутри сервера 402. Или видео и/или аудио могут выводиться в виде пакетов через сетевое соединение, например соединение Ethernet, в сеть, которая является любой частной сетью между сервером 402 и устройством 404 сжатия видео, или через совместно использованную сеть, например, SAN 403. Или видео может выводиться через разъем видеовыхода из сервера 402, например, разъем VGA или DVI, и затем захватываться устройством сжатия 404 видео. Кроме того, аудио может выводиться из сервера 402 или как цифровое аудио (например, через разъем S/PDIF или TOSLINK), или как аналоговое аудио, который оцифрован и закодирован логикой сжатия аудио внутри устройства 404 сжатия видео.

После захвата устройством 404 сжатия видео видеокадра и аудио, формируемого в течение этого периода кадра, из сервера 402 устройство сжатия видео сжимает видео и аудио с использованием способов, описанных ниже. После сжатия видео и аудио формируются пакеты с адресом для отправки обратно в клиент 415 пользователя, и их маршрутизируют в интерфейс 441 WAN, который далее маршрутизирует видео и аудио пакеты через общий Internet 410, который далее маршрутизирует видео и аудио пакеты в точку 441 входа в Internet ISP пользователя, которая маршрутизирует видео и аудио пакеты в интерфейс 442 WAN на территории пользователя, который маршрутизирует видео и аудио пакеты в устройство 443 брандмауэра/маршрутизатора/NAT, которое далее маршрутизирует видео и аудио пакеты в клиента 415.

Клиент 415 восстанавливает сжатые видео и аудио и после этого выводит видео на экран дисплея 422 (или на встроенный дисплей клиента) и отправляет аудио на дисплей 422, или в отдельные усилитель/динамики, или в усилитель/динамики, встроенные в клиента.

Для того чтобы пользователь воспринимал весь только описанный процесс без запаздывания, двухсторонняя задержка должна быть меньше 70 или 80 мс. Некоторые из задержек времени ожидания в описанном пути туда и обратно контролируются службой 210 хостинга и/или пользователем, а другие не контролируются. Однако следующие измерения, основанные на анализе и тестировании большого количества реальных сценариев, являются приблизительными.

Время передачи в одном направлении для отправки управляющих сигналов 451 обычно меньше 1 мс, маршрутизация туда и обратно через территорию 452 пользователя обычно выполняется с использованием общедоступных коммутаторов потребительского уровня брандмауэра/маршрутизатора/NAT по локальной сети Ethernet приблизительно за 1 мс. I (Соединения) пользователь ISP значительно отличаются по их задержкам 453 передачи сигнала туда и обратно, но с провайдерами кабельной модемной связи и DSL, как правило, наблюдается (задержка) между 10 и 25 мс. Время передачи сигнала туда и обратно по общему Internet 410 может очень отличиться в зависимости от того, как маршрутизируется трафик, и существуют ли какие-нибудь отказы на маршруте (и эти вопросы обсуждаются ниже), но, как правило, общий Internet обеспечивает довольно оптимальные маршруты, и время ожидания в значительной степени определяется скоростью света через светопровод с учетом расстояния до пункта назначения. Как также обсуждается ниже, авторы установили службу 210 хостинга самое большее на расстоянии примерно 1000 миль (1600 км), на котором, как ожидается, она будет располагаться от территории 211 пользователя. Фактическое время передачи сигнала через Internet на (расстояние) 1000 миль (1600 км) (2000 миль (3200 км) туда и обратно) приблизительно равно 22 мс. Интерфейс 441 WAN со службой 210 хостинга является обычно интерфейсом волоконно-оптической линии связи с высокой скоростью коммерческого уровня с незначительным временем ожидания. Соответственно, время 454 ожидания общего Internet обычно находится между 1 и 10 мс. Может быть достигнуто время ожидания маршрутизации 455 в одном направлении через службу 210 хостинга меньше 1 мс. Сервер 402, как правило, вычисляет новый кадр для игры или приложения за время меньшее, чем один период кадра (который при 60 кадр/с равен 16,7 мс), соответственно, 16 мс является приемлемым для использования максимальным временем 456 передачи сигнала в одну сторону. В оптимизированной аппаратной реализации алгоритмов сжатия аудио и сжатия видео, описанных в этом документе, сжатие 457 может быть выполнено за 1 мс. В менее оптимизированных версиях сжатие может занимать 6 мс (несомненно, еще менее оптимизированные версии могут занимать больше времени, но такие реализации могут влиять на общее время ожидания передачи туда и обратно, и может потребоваться, чтобы другие величины времени ожидания были меньше (например, может быть уменьшено допустимое расстояние через общий Internet) для поддержания целевого времени ожидания 70-80 мс). Величины времени передачи сигнала туда и обратно для Internet 454, (соединения) 453 пользователь ISP, и маршрутизации 452 по территории пользователя уже были рассмотрены, поэтому остается рассмотреть время ожидания восстановления 458 сжатого видео, которое, в зависимости от того, реализовано ли восстановление 458 сжатого видео в специализированном аппаратном обеспечении, или реализовано ли оно в программном обеспечении на клиентском устройстве 415 (например, PC или мобильном устройстве), может изменяться в зависимости от размера дисплея и производительности CPU для восстановления сжатых данных. Как правило, восстановление 458 сжатых данных занимает между 1 и 8 мс.

Соответственно, посредством суммирования всех величин времени ожидания в самом плохом случае, наблюдаемом на практике, можно определить время передачи сигнала туда и обратно в самом плохом случае, которое, как можно ожидать, будет испытывать пользователь системы, изображенной на фиг.4a. Они равны: 1+1+25+22+1+16+6+8=80 мс. И, безусловно, на практике (с оговорками, обсуждаемыми ниже) это примерно равно времени передачи сигнала туда и обратно, наблюдаемому при использовании версии пилотной модели, изображенной на фиг.4a с использованием имеющихся в готовом виде PC Windows в качестве клиентских устройств и домашних соединений кабельной модемной связи и DSL в пределах США. Несомненно, сценарии, которые лучше самого плохого случая, могут в результате привести к гораздо меньшим величинам времени ожидания, но на них нельзя основываться при разработке коммерческой услуги, которая широко используется.

Для получения величин времени ожидания, выведенных в упорядоченном виде на фиг.4b, (при передаче сигнала) через общий Internet, требуется, чтобы устройство 404 сжатия видео и устройство 412 восстановления сжатого видео по фиг.4a в клиенте 415 формировало поток пакетов (с) очень конкретными характеристиками, например, последовательность пакетов, формируемая на всем пути от службы 210 хостинга до дисплея 422, не подвергалась задержкам или чрезмерной потере пакетов и, в частности, постоянно удовлетворяла ограничениям полосы пропускания, доступной пользователю по подключению к Internet пользователя через интерфейс 442 WAN и брандмауэр/маршрутизатор/NAT 443. Кроме того, устройство сжатия видео должно создавать поток пакетов, который достаточно устойчив, чтобы он мог допускать неизбежную потерю пакетов и изменение порядка следования пакетов, которое происходит в обычном Internet и сетевых передачах.

Сжатие видео с малым временем ожидания

Для достижения вышеизложенных целей в одном варианте осуществления используется новый подход к сжатию видео, посредством которого уменьшают время ожидания и требования по пиковой полосе пропускания для передачи видео. До описания этих вариантов осуществления будет обеспечен анализ современных способов сжатия видео согласно фиг.5 и фиг.6a-фиг.6b. Несомненно, эти способы могут быть применены согласно лежащим в основе принципам, если пользователь будет обеспечен полосой пропускания, достаточной для обработки данных со скоростью передачи, требуемой этими способами. Отметим, что в этом описании не рассматривается сжатие аудио, за исключением констатации того, что оно реализуется одновременно и синхронно со сжатием видео. Существуют способы сжатия аудио предшествующего уровня техники, которые удовлетворяют требованиям для этой системы.

На фиг.5 изображен один конкретный способ предшествующего уровня техники для сжатия видео, в котором каждый отдельный видеокадр 501-503 сжимается посредством логики 520 сжатия с использованием конкретного алгоритма сжатия для формирования последовательности сжатых кадров 511-513. Одним вариантом осуществления этого способа является "алгоритм сжатия движущихся изображений MJPEG", в котором каждый кадр сжимается согласно алгоритму сжатия неподвижного изображения, разработанный Объединенной группой экспертов по машинной обработке фотографических изображений (JPEG) на основе дискретного косинусного преобразования (DCT). Однако могут быть применены различные другие типы алгоритмов сжатия, хотя по-прежнему с выполнением этих лежащих в основе принципов (например, алгоритмы сжатия, основанные на вейвлете, например, JPEG-2000).

Одна проблема, связанная с этим типом сжатия, состоит в том, что оно уменьшает скорость передачи данных каждого кадра, но оно не использует сходные черты между последовательными кадрами для уменьшения скорости передачи данных всего видеопотока. Например, как изображено на фиг.5, предположим, что частота кадров 640×480×24 бит/пиксел=640×480×24/8/1024=900 Килобайт/кадр (Кбайт/кадр), для данного качества изображения, посредством алгоритма сжатия движущихся изображений MJPEG можно сжать поток с коэффициентом 10, что в результате приводит к потоку данных 90 Кбайт/кадр. При 60 кадров/сек потребовалась бы полоса пропускания канала 90 Кбайт×8 бит×60 кадров/сек=42,2 Мбит/с, которая была бы слишком широкой полосой пропускания почти для всех домашних подключений к Internet в США в настоящее время и слишком широкой полосой пропускания для многих офисных подключений к Internet. Безусловно, с учетом того, что при этом потребуется постоянный поток данных с такой широкой полосой пропускания, и он будет обслуживать только одного пользователя, даже в офисной среде LAN, он будет потреблять большую часть полосы пропускания LAN Ethernet 100 Мбит/с и сильно нагружать коммутаторы Ethernet, поддерживающие LAN. Соответственно, сжатие для движущегося видео неэффективно при сравнении с другими способами сжатия (например, способами сжатия, описанными ниже). Кроме того, алгоритмы сжатия одного кадра, подобные JPEG и JPEG-2000, которые используют алгоритмы сжатия с потерями, выводят артефакты сжатия, которые могут быть не заметны на неподвижных изображениях (например, артефакт внутри густой листвы в сцене может не казаться артефактом, так как глаз не знает точно, как густая листва должна выглядеть). Но если сцена движется, то артефакт может быть заметным, потому что глаз замечает, что артефакт (изменяется) от кадра к кадру, несмотря на то, что артефакт находится в области сцены, где он мог быть незаметным в неподвижном изображении. Это в результате приводит к восприятию "фоновых помех" в последовательности кадров, сходных по виду с помехами "снег", видимых во время граничного аналогового телевизионного приема. Несомненно, этот тип сжатия может, тем не менее, использоваться в определенных вариантах осуществления, описанных в этом документе, но, вообще говоря, для данного качества восприятия требуется устранение фоновых помех в сцене, высокая скорость передачи данных (т.е. низкий коэффициент сжатия).

Другие типы сжатия, например, H.264 или Windows Media VC9, MPEG2 и MPEG4, все являются более эффективными при сжатии видеопотока, потому что они используют сходные черты между последовательными кадрами. Все эти способы основаны на одинаковых общих способах сжатия видео. Соответственно, несмотря на то, что будет описан стандарт H.264, однако идентичные общие принципы относятся к различным другим алгоритмам сжатия. Большое количество устройств сжатия H.264 и устройство восстановления сжатых данных имеются в наличии, в том числе библиотека программного обеспечения с открытым исходным текстом ×264 для сжатия H.264 и библиотека программного обеспечения с открытым исходным текстом FFmpeg для восстановления сжатых данных H.264.

На фиг.6a и фиг.6b изображен иллюстративный способ сжатия предшествующего уровня техники, в котором последовательность несжатых видеокадров 501-503, 559-561 сжимают посредством логики 620 сжатия в последовательность "I-кадров" 611, 671, "P-кадров" 612-613 и "B-кадров" 670. Вертикальная ось на фиг.6a в общем обозначает получающийся в результате размер каждого из закодированных кадров (несмотря на то, что кадры не вычерчены в масштабе). Как описано выше, кодирование видео с использованием I-кадров, B-кадров и P-кадров понятно специалистам в данной области техники. В нескольких словах, I-кадр 611 является сжатием на основе DCT полного несжатого кадра 501 (аналогичным сжатому изображению JPEG, как описано выше). P-кадры 612-613, в общем, значительно меньше по размеру, чем I-кадры 611, потому что они используют данные предыдущего I-кадра или P-кадра, то есть они содержат данные, указывающие на изменения между предыдущим I-кадром или P-кадром. B-кадры 670 являются аналогичными P-кадрам за исключением того, что B-кадры используют кадр в следующем опорном кадре, а также, возможно, кадр в предыдущем опорном кадре.

В нижеследующем обсуждении будет предполагаться, что требуемая частота кадров равна 60 кадров/секунда, что каждый I-кадр равен приблизительно 160 Кбит, средний P-кадр и B-кадр равен 16 Кбит и что новый I-кадр формируется каждую секунду. С этим набором параметров средняя скорость передачи данных равна: 160 Кбит+16 Кбит×59=1,1 Мбит/с. Эта скорость передачи данных вполне находится в пределах максимальной скорости передачи данных для многих современных высокоскоростных подключений к Internet в домах и офисах. Посредством этого способа также можно решать проблему фоновых помех при только-внутрикадровом кодировании, потому что P- и B-кадры отслеживают различия между кадрами, поэтому артефакты сжатия не должны появляться и исчезать от кадра к кадру, следовательно, уменьшается проблема фоновых помех, описанная выше.

Одна проблема, связанная с вышеизложенными видами сжатия, состоит в том, что, несмотря на то, что средняя скорость передачи данных является относительно низкой (например, 1,1 Мбит/с), передача одного I-кадра может занимать несколько периодов кадра. Например, с использованием способов предшествующего уровня техники, сетевого соединения 2,2 Мбит/с (например, DSL или кабельный модем с пиком 2,2 Мбит/с максимальной доступной скорости передачи данных 302 по фиг.3a) обычно достаточно для передачи потоком видео со скоростью 1,1 Мбит/с с I-кадром 160 Кбит/с каждые 60 кадров. Это может быть выполнено, если устройство восстановления сжатых данных будет ставить в очередь 1 секунду видео до восстановления сжатого видео. За 1 секунду передается 1,1 Мбит данных, что может быть легко обеспечено при максимальной доступной скорости передачи данных 2,2 Мбит/с, даже с предположением, что доступная скорость передачи данных может периодически снижаться на 50%. К сожалению, этот подход предшествующего уровня техники в результате приводит ко времени ожидания в 1 секунду для видео из-за 1-секундного видеобуфера в приемнике. Такая задержка отвечает требованиям многих приложений предшествующего уровня техники (например, воспроизведение линейного видео), но является слишком долгим временем ожидания для динамичных видеоигр-боевиков, в которых не допускается время ожидания более 70-80 мс.

Если попытаться исключить 1-секундный видеобуфер, то это по-прежнему не приведет к сокращению времени ожидания, достаточному для динамичных видеоигр-боевиков. Например, использование B-кадров, как описано ранее, неизбежно влечет за собой прием всех B-кадров, предшествующих I-кадру, а также I-кадра. Если предположить, что 59 кадров не-I-кадров примерно разделены между P- и B-кадрами, то принимается, по меньшей мере, 29 B-кадров и I-кадр до того, как любой B-кадр может быть выведен на экран. Соответственно, независимо от доступной полосы пропускания канала, это неизбежно влечет за собой задержку 29+1=30 кадров длительностью 1/60 секунды каждый, или 500 мс времени ожидания. Очевидно, что это слишком долго.

Соответственно, другой подход должен исключать B-кадры и использовать только I- и P-кадры. (Одним следствием этого является то, что скорость передачи данных увеличивается для данного уровня качества, но для согласованности в этом примере, будем продолжать предполагать, что размер каждого I-кадра равен 160 Кбит, и среднего P-кадра равен 16 Кбит, и, соответственно, скорость передачи данных по-прежнему равна 1,1 Мбит/с.) Этот подход исключает неизбежное время ожидания, вводимое B-кадрами, так как декодирование каждого P-кадра зависит только от предыдущего принятого кадра. Проблема, которая остается при этом подходе, состоит в том, что I-кадр настолько больше среднего P-кадра, что на канале с небольшой полосой пропускания, как обычно бывает в большинстве домов и во многих офисах, передача I-кадра добавляет значительное время ожидания. Это изображено на фиг.6b. Скорость 624 передачи данных видеопотока ниже доступной максимальной скорости 621 передачи данных за исключением I-кадров, где пиковая скорость передачи данных, требуемая для I-кадров 623, намного превышает доступную максимальную скорость 622 передачи данных (и даже номинальную максимальную скорость 621 передачи данных). Скорость передачи данных, требуемая P-кадрами, меньше доступной максимальной скорости передачи данных. Даже если пики в 2,2 Мбит/с доступной максимальной скоростью передачи данных постоянно остаются на своей пиковой скорости 2,2 Мбит/с, то передача I-кадра займет 160 Кбит/2,2 Мбит=71 мс, и если доступная максимальная скорость 622 передачи данных снизится на 50% (1,1 Мбит/с), то передача I-кадра займет 142 мс. Соответственно, время ожидания при передаче I-кадра находится приблизительно между 71-142 мс. Это время ожидания является дополнением к величинам времени ожидания, идентифицированным на фиг.4b, которые в самом плохом случае составляют в сумме 70 мс, поэтому в результате общее время передачи сигнала туда и обратно, от момента, когда пользователь приводит в действие устройство 421 ввода, до того, как изображение появляется на дисплее 422, равно 141-222 мс, которое является слишком большим. И если доступная максимальная скорость передачи данных становится меньше 2,2 Мбит/с, то время ожидания увеличивается дополнительно.

Отметим также, что, в общем, существуют серьезные последствия "создания пробки" ISP посредством пиковой скорости 623 передачи данных, которая намного превышает доступную скорость 622 передачи данных. Оборудование у разных ISP ведет себя по-разному, но следующие линии поведения являются довольно распространенными среди ISP кабельной модемной связи и DSL при приеме пакетов с гораздо большей скоростью передачи данных, чем доступная скорость 622 передачи данных: (a) задержка пакетов посредством постановки их в очередь (введение времени ожидания), (b) сброс некоторых или всех пакетов, (c) прерывание соединения на некоторый период времени (скорее всего, потому что ISP будет обеспокоен тем, что это является злонамеренной атакой, например, атакой "отказ в обслуживании"). Соответственно, передача потока пакетов с полной скоростью передачи данных с такими характеристиками, как характеристики, изображенные на фиг.6b, не является практически осуществимым вариантом. Пики 623 могут стоять в очереди в службе 210 хостинга и отправляться со скоростью передачи данных ниже доступной максимальной скорости передачи данных, что вводит неприемлемое время ожидания, описанное в предыдущем абзаце.

Кроме того, последовательность 624 скорости передачи данных видеопотока, изображенная на фиг.6b, является очень "нормальной" последовательностью скорости передачи данных видеопотока и может быть видом последовательности скорости передачи данных, которая, как можно ожидать, получается в результате сжатия видео из видеопоследовательности, которая не изменяется очень сильно и обнаруживает очень мало движения (например, как обычно бывает при проведении видеотелеконференции, где камеры находятся в фиксированном положении и их мало передвигают, и объекты в сцене, например, разговаривающие сидящие люди, мало двигаются).

Последовательность 634 скорости передачи данных видеопотока, изображенная на фиг.6c, является последовательностью, которую обычно можно ожидать наблюдать из видео с гораздо большим количеством действий, например, которая может формироваться в кинофильме или видеоигре, или в некотором прикладном программном обеспечении. Отметим, что наряду с пиками 633 I-кадра существуют также пики P-кадра, например 635 и 636, которые являются довольно большими и превышают доступную максимальную скорость передачи данных во многих случаях. Несмотря на то что эти пики P-кадра не совсем такие большие, как пики I-кадра, они, тем не менее, являются слишком большими для передачи их по каналу с полной скоростью передачи данных, и как и в случае с пиками I-кадра, они, пики P-кадра, должны передаваться медленно (следовательно, с возрастающим временем ожидания).

На канале с широкой полосой пропускания (например, LAN 100 Мбит/с или частное соединение с широкой полосой пропускания 100 Мбит/с) в сети могут допускаться большие пики, например, пики 633 I-кадра или пики 636 P-кадра, и, в принципе, может поддерживаться малое время ожидания. Но такие сети часто совместно используются многими пользователями (например, в офисной обстановке), и такие данные "с пиками" влияют на производительность LAN, в частности, если сетевой трафик маршрутизируется к частному, совместно используемому соединению (например, из удаленного центра обработки и хранения данных в офис). Прежде всего следует учитывать, что в этом примере видеопоток с относительно низким разрешением 640×480 пикселей с 60 кадр/с. Потоки HDTV 1920×1080 с 60 кадр/с легко обрабатываются современными компьютерами и дисплеями, и все больше имеется в продаже дисплеев с разрешающей способностью 2560×1440 с 60 кадр/с (например, дисплей 30" корпорации Apple, Inc). Видеопоследовательности с высокой активностью с 1920×1080 с 60 кадр/с может потребоваться 4,5 Мбит/с с использованием сжатия H.264 для приемлемого уровня качества. Если предположить, что I-кадры достигают пика при номинальной скорости передачи данных 10X, то в результате получаются пики 45 Мбит/с, а также меньший, но, тем не менее, значительный, пик P-кадра. Если несколько пользователей принимают видеопотоки по идентичной сети 100 Мбит/с (например, частное сетевое соединение между офисом и центром обработки и хранения данных), то легко увидеть, как пики видеопотока нескольких пользователей могут объединяться с переполнением полосы пропускания сети и с возможным переполнением полосы пропускания магистрали коммутаторов, поддерживающих пользователей в сети. Даже в случае сети по технологии Gigabit Ethernet, если достаточное количество пиков достаточного количества пользователей объединяются одновременно, то это может переполнить сеть или сетевые коммутаторы. И когда видео с разрешающей способностью 2560×1440 станет более обычным явлением, средняя скорость передачи данных видеопотока может быть равна 9,5 Мбит/с, что в результате, возможно, приведет к пиковой скорости передачи данных 95 Мбит/с. Не вызывает сомнения, что соединение 100 Мбит/с между центром обработки и хранения данных и офисом (которое в настоящее время является исключительно высокоскоростным соединением) будет полностью переполнено пиковым трафиком отдельного пользователя. Соответственно, несмотря на то, что LAN и частные сетевые соединения могут допускать потоковое видео с пиками, потоковое видео с высокими пиками не желательно, и может потребоваться специальное планирование и адаптация отделом IT офиса.

Несомненно, для стандартных приложений линейного видео эти вопросы не являются проблемой, потому что скорость передачи данных "сглаживается" в момент передачи, и данные для каждого кадра ниже максимальной доступной скорости 622 передачи данных, и в буфере в клиенте сохраняется последовательность I-, P- и B-кадров до того, как они будут восстановлены. Соответственно, скорость передачи данных по сети остается близкой к средней скорости передачи данных видеопотока. К сожалению, это вводит время ожидания, даже если B-кадры не используются, что является неприемлемым для приложений с малым временем ожидания, например, видеоигры и приложения требуют малого времени отклика.

Одним решением предшествующего уровня техники для уменьшения видеопотоков, которые имеют высокие пики, является использование способа, часто называемого кодирование "Постоянный битрейт" (постоянная скорость передачи битов, CBR). Несмотря на то, что представляется, что термин CBR подразумевает, что все кадры сжимаются так, чтобы у них была одинаковая скорость передачи битов (т.е. размер), он обычно относится к схеме сжатия, в которой допускается максимальная скорость передачи битов по определенному количеству кадров (в нашем случае, 1 кадр). Например, в случае фиг.6c, если ограничение CBR применяется к кодированию, которое ограничивает скорость передачи битов, например, до 70% номинальной максимальной скорости 621 передачи данных, тогда алгоритм сжатия ограничивает сжатие каждого из кадров так, чтобы любой кадр, который обычно сжимается с использованием больше 70% номинальной максимальной скорости 621 передачи данных, сжимается посредством меньшего количества битов. Результатом этого является то, что кадры, которым обычно требуется больше битов для поддержания данного уровня качества, "испытывают недостаток" в битах, и качество изображения этих кадров хуже, чем качество изображения других кадров, которым не требуется большее количество битов, чем 70% (скорости) максимальной скорости 621 передачи данных. Этот подход может привести к приемлемым результатам для определенных типов сжатого видео, когда (a) ожидается мало движения или изменений сцены, и (b) пользователи могут считать приемлемым периодическое ухудшение качества. Хорошим примером применения, подходящего для CBR, является проведение видеотелеконференции, так как в ней мало пиков, и если качество ухудшается на короткий период (например, если камерой выполняют панорамирование, что в результате приводит к существенному движению сцены и большим пиками, то во время панорамирования может быть не достаточно битов для сжатия высококачественного изображения, что в результате может привести к ухудшенному качеству изображения), это является приемлемым для большинства пользователей. К сожалению, CBR плохо подходят для многих других применений, в которых существуют сцены высокого уровня сложности или с большим движением, и/или в которых требуется достаточно постоянный уровень качества.

Логика 404 сжатия с малым временем ожидания, применяемая в одном варианте осуществления, использует несколько разных способов для решения круга проблем, связанных с передачей потоком сжатого видео с малым временем ожидания, при поддержании высокого уровня качества. Во-первых, логика 404 сжатия с малым временем ожидания формирует только I-кадры и P-кадры, следовательно, уменьшается необходимость ожидания в течение нескольких периодов кадра для декодирования каждого B-кадра. Кроме того, как изображено на фиг.7a, в одном варианте осуществления, логика 404 сжатия с малым временем ожидания разбивает каждый несжатый кадр 701-760 в последовательность "фрагментов" ("tile", "тайл") и отдельно кодирует каждый фрагмент или как I-кадр или как P-кадр. Группа сжатых I-кадров и P-кадров называется в этом описании "R-кадры" 711-770. В конкретном примере, изображенном на фиг.7a, каждый несжатый кадр разбивается в матрицу 4×4 из 16 фрагментов. Однако эти лежащие в основе принципы не ограничены никакой конкретной схемой подразделения.

В одном варианте осуществления логика 404 сжатия с малым временем ожидания разделяет видеокадр на несколько фрагментов и кодирует (т.е. сжимает) один фрагмент из каждого кадра как I-кадр (т.е. этот фрагмент сжимается так, как если бы он был отдельным видеокадром размером 1/16 полного изображения, и сжатие, используемое для этого "мини"-кадра, является сжатием I-кадра), а остальные фрагменты изображения как P-кадры (т.е. сжатие, используемое для каждой "мини" 1/16 (части) кадра, является сжатием P-кадра). Фрагменты, сжатые как I-кадры и как P-кадры, должны называться "I- фрагментами" и "P- фрагментами", соответственно. С каждым последующим видеокадром фрагмент, который должен быть закодирован как I-фрагмент, меняется. Соответственно, в данный период кадра, только один фрагмент из фрагментов в видеокадре является I-фрагментом, а остальные фрагменты являются P-фрагментами. Например, на фиг.7a фрагмент 0 несжатого кадра 701 закодирован как I-фрагмент I0, а остальные 1-15 фрагменты закодированы как P-фрагменты с P1 по P15 для вывода R-кадра 711. В следующем несжатом видеокадре 702 фрагмент 1 несжатого кадра 701 закодирован как I-фрагмент I1, а остальные фрагменты 0 и с 2 по 15 закодированы как P-фрагменты, P0 и с P2 по P15, для вывода R-кадра 712. Соответственно, I-фрагменты и P-фрагменты для фрагментов постепенно чередуются во времени по последовательным кадрам. Процесс продолжается до тех пор, пока не будет сформирован R-(кадр) 770 с последним фрагментом в матрице, закодированным как I-фрагмент (т.е. I15). После этого процесс повторяется с формированием еще одного R-кадра, например, кадра 711 (т.е. кодирование I-фрагмента для фрагмента 0) и т.д. Несмотря на то что на фиг.7a не изображено, в одном варианте осуществления, первый R-кадр видеопоследовательности из R-кадров содержит только I-фрагменты (т.е. последующие (R)-кадры содержат данные опорного изображения, исходя из которого вычисляется движение). В качестве альтернативы в одном варианте осуществления последовательность в начальный момент использует схему I-фрагмента, идентичную обычной, но не включает в себя P-фрагменты для тех фрагментов, которые еще не закодированы посредством I-фрагмента. Другими словами, определенные фрагменты не кодируются никакими данными до тех пор, пока не поступит первый I-фрагмент, следовательно, устраняются начальные пики в скорости 934 передачи данных видеопотока по фиг.9a, что более подробно объясняется ниже. Кроме того, как описано ниже, различные другие размеры и формы могут использоваться для фрагментов, хотя по-прежнему с выполнением этих лежащих в основе принципов.

Логика 412 восстановления сжатого видео, исполняющаяся в клиенте 415, восстанавливает каждый сжатый фрагмент, как если бы это была отдельная видеопоследовательность маленьких I- и P-кадров, и затем передает каждый фрагмент в буфер кадров, управляющий дисплеем 422. Например, I0 и P0 из R-кадров 711-770 используются для восстановления сжатого фрагмента 0 видеоизображения и его визуализации. Точно так же I1 и P1 из R-кадров 711-770 используются для восстановления фрагмента 1 и так далее. Как упоминалось выше, восстановление сжатых I-кадров и P-кадров известно в данной области техники, а восстановление сжатых I-фрагментов и P-фрагментов может выполняться посредством наличия множества устройств восстановления сжатого видео, функционирующих в клиенте 415. Несмотря на то что представляется, что увеличение количества процессов увеличивает затраты вычислительных ресурсов в клиенте 415, это фактически не так, потому что сам фрагмент пропорционально меньше относительно количества дополнительных процессов, поэтому количество выводимых на экран пикселей является идентичным, как если бы существовал один процесс и использовались обычные I- и P-кадры полного размера.

Этот способ R-кадра значительно уменьшает пики полосы пропускания, обычно связанные с I-кадрами, изображенными на фиг.6b и фиг.6c, потому что любой данный кадр обычно составлен из P-кадров, которые обычно меньше I-кадров. Например, снова предположим, что обычный I-кадр равен 160 Кбит, тогда I-фрагменты каждого из кадров, изображенных на фиг.7a, примерно равны 1/16 этой величины или 10 Кбит. Аналогично, предположим, что обычный P-кадр равен 16 Кбит, тогда P-кадры для каждого из фрагментов, изображенные на фиг.7a, могут быть примерно равны 1 Кбит. Конечным результатом является R-кадр приблизительно 10 Кбит+15×1 Кбит=25 Кбит. Соответственно, каждая последовательность из 60 кадров равна 25 Кбит×60=1,5 Мбит/с. Соответственно, при 60 кадров/секунда потребуется канал с возможностью поддержки полосы пропускания 1,5 Мбит/с, но с гораздо меньшими пиками, появляющимися из-за I-фрагментов, распределенных по всему интервалу из 60 кадров.

Отметим, что в предыдущих примерах с идентичным предположением о скоростях передачи данных для I-кадров и P-кадров средняя скорость передачи данных была равна 1,1 Мбит/с. Причиной этого является то, что в предыдущих примерах новый I-кадр вводится только один раз каждые 60 периодов кадра, тогда как в этом примере 16 фрагментов, которые составляют I-кадр, циклически повторяются через 16 периодов кадра, и, по существу, эквивалент I-кадра вводится каждые 16 периодов кадра, что в результате приводит к несколько более высокой средней скорости передачи данных. На практике, тем не менее, более частое введение I-кадров не увеличивает скорость передачи данных линейно. Это происходит вследствие того, что P-кадр (или P-фрагмент) первоначально кодирует отличие последующего кадра от предшествующего. Соответственно, если предшествующий кадр является довольно похожим на следующий кадр, то P-кадр является очень маленьким, если предшествующий кадр весьма отличается от следующего кадра, то P-кадр является очень большим. Но так как P-кадр в значительной степени получается из предыдущего кадра, а не из фактического кадра, то получающийся в результате закодированный кадр может содержать больше ошибок (например, визуальные артефакты), чем I-кадр с соответствующим количеством битов. И когда один P-кадр следует за другим P-кадром, то может произойти накопление ошибок, которое ухудшается при наличии длинной последовательности P-кадров. Далее, усложненное устройство сжатия видео обнаруживает, что качество изображения ухудшается после последовательности P-кадров, и, в случае необходимости, оно выделяет больше битов последующим P-кадрам для повышения качества или, если это будет наиболее эффективным образом действия, заменяет P-кадр I-кадром. Соответственно, когда используются длинные последовательности P-кадров (например, 59 P-кадров, как в предыдущих примерах выше), в частности, когда сцена очень сложная и/или в ней много движения, обычно требуется больше битов для P-кадров по мере их удаления от I-кадра.

Другими словами, если посмотреть на P-кадры с противоположной точки зрения, P-кадры, которые непосредственно следуют за I-кадром, как правило, требуют меньшего количества битов, чем P-кадры, которые являются более удаленными от I-кадра. Так, в примере, изображенном на фиг.7a, все P-кадры удалены от предшествующего им I-кадра не более чем на 15 кадров, тогда как, например, в предыдущем примере P-кадр может находиться на расстоянии 59 кадров от I-кадра. Соответственно, при большей частоте I-кадров P-кадры меньше. Несомненно, точные относительные размеры меняются в зависимости от характера видеопотока, но в примере по фиг.7a, если I-фрагмент равен 10 Кбит, то размер P-фрагментов в среднем может быть равен только 0,75 Кбит, что в результате приводит к 10 Кбит+15×0,75 Кбит=21,25 Кбит, или при (скорости) 60 кадров в секунду скорость передачи данных равна 21,25 Кбит×60=1,3 Мбит/с, или приблизительно на 16% больше, чем скорость передачи данных потока с I-кадром, за которым следуют 59 P-кадров, в 1,1 Мбит/с. И опять же, относительные результаты этих двух подходов к сжатию видео меняются в зависимости от видеопоследовательности, но, как правило, опыт показывает, что использование R-кадров требует приблизительно на 20% больше битов для данного уровня качества, чем использование последовательностей I/P-кадров. Но, несомненно, R-кадры существенно уменьшают пики, что намного уменьшает время ожидания при использовании упомянутых видеопоследовательностей по сравнению со временем ожидания для последовательности I/P-кадров.

R-кадры могут быть сконфигурированы множеством различных способов в зависимости от характера видеопоследовательности, надежности канала и доступной скорости передачи данных. В альтернативном варианте осуществления используется количество фрагментов, отличное от 16 в конфигурации 4×4. Например, может использоваться 2 фрагмента в конфигурации 2×1 или 1×2, может использоваться 4 фрагмента в конфигурации 2×2, 4×1 или 1×4, может использоваться 6 фрагментов в конфигурации 3×2, 2×3, 6×1 или 1×6, или может использоваться 8 фрагментов в конфигурации 4×2 (как изображено на фиг.7b), 2×4, 8×1 или 1×8. Отметим, что фрагменты не обязательно должны быть квадратными, также видеокадр не обязательно должен быть квадратным или даже прямоугольным. Фрагменты могут принимать любую форму, которая лучшие всего подходит для используемого приложения или видеопотока.

В другом варианте осуществления циклическое повторение I- и P-фрагментов не фиксировано количеством фрагментов. Например, в конфигурации 4×2 с 8 фрагментами может, однако, использоваться последовательность с периодическим повторением через 16 элементов, как изображено на фиг.7b. Последовательные несжатые кадры 721, 722, 723, каждый, разделены на 8 фрагментов, 0-7, и каждый фрагмент сжимают отдельно. В R-кадре 731 только фрагмент 0 сжат как I-фрагмент, а остальные фрагменты сжаты как P-фрагменты. В следующем R-кадре 732 все 8 фрагментов сжаты как P-фрагменты, и далее в следующем R-кадре 733 фрагмент 1 сжат как I-фрагмент, а остальные фрагменты все сжаты как P-фрагменты. И такое установление последовательности продолжается для 16 кадров, при этом I-фрагмент формируется только через кадр, соответственно, последний I-фрагмент будет сформирован для фрагмента 7 в течение периода 15-ого кадра (на фиг.7b не изображен) и в течение периода 16-ого кадра сжимают R-кадр 780 с использованием всех P-фрагментов. Далее последовательность снова начинается с фрагмента 0, сжатого как I-фрагмент, при этом другие фрагменты сжаты как P-фрагменты. Как в предшествующем варианте осуществления, самый первый кадр всей видеопоследовательности обычно состоит из всех I-фрагментов для обеспечения опорных элементов (reference) для P-фрагментов, начиная с этого момента. Циклическое повторение I-фрагментов и P-фрагментов даже не должно быть четным, кратным числом количества фрагментов. Например, с 8 фрагментами, за каждым кадром с I-фрагментом может следовать 2 кадра со всеми P-фрагментами, прежде, чем будет использован другой I-фрагмент. В еще одном варианте осуществления для определенных фрагментов может устанавливаться последовательность I-фрагментов чаще, чем для других фрагментов, если, например, известно, что в определенных областях экрана больше движения, что требует частых I-фрагментов, в то время как другие являются более статическими (например, с изображением счета в игре), что требует менее частых I-фрагментов. Кроме того, несмотря на то, что каждый кадр на фиг.7a-фиг.7b изображен с одним I-фрагментом, в одном кадре может быть закодировано множество I-фрагментов (в зависимости от полосы пропускания канала передачи). И наоборот, определенные кадры или последовательности кадров могут быть переданы без I-фрагментов (т.е. только P-фрагменты).

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

В другом варианте осуществления, логика 404 сжатия видео с малым временем ожидания по фиг.7a и фиг.7b управляет выделением битов различным фрагментам в R-кадрах или с предварительным конфигурированием посредством установок, на основе известных характеристик видеопоследовательности, которая должна быть сжата, или автоматически, на основе непрерывного анализа качества изображения в каждом фрагменте. Например, в некоторых видеоиграх-гонках, передняя часть автомобиля игрока (которая является относительно неподвижной в сцене) занимает большую часть нижней половины экрана, тогда как верхняя половина экрана полностью заполнена надвигающимся шоссе, зданиями и пейзажем, которые почти всегда находятся в движении. Если логика 404 сжатия выделяет равное количество битов каждому фрагменту, то фрагменты в нижней половине экрана (фрагменты 4-7) в несжатом кадре 721 по фиг.7b будут, в общем, сжиматься с более высоким качеством, чем фрагменты (чем фрагменты) в верхней половине экрана (фрагменты 0-3) в несжатом кадре 721 по фиг.7b. Если известно, что эта конкретная игра или эта конкретная сцена игры имеют такие характеристики, то операторы 210 службы хостинга могут сконфигурировать логику 404 сжатия для выделения большего количества битов фрагментам, находящимся в верней части экрана, чем фрагментам, находящимся в нижней части экрана. Или логика 404 сжатия может оценивать качество сжатия фрагментов после сжатия кадров (с использованием одного или нескольких из множества показателей качества сжатия, например, пиковое отношение сигнал/шум (PSNR)), и если она определяет, что за определенное временное окно качество определенных фрагментов постоянно улучшается, тогда она постепенно выделяет большее количество битов фрагментам, качество которых ухудшается до тех пор, пока уровень качества различных фрагментов не станет примерно одинаковым. В альтернативном варианте осуществления логика 404 устройства сжатия выделяет биты для получения более высокого качества в конкретном фрагменте или группе фрагментов. Например, с более высоким качеством в центре экрана, чем на краях, она может обеспечивать лучшее общее восприятие.

В одном варианте осуществления для улучшения разрешающей способности определенных участков видеопотока логика 404 сжатия видео использует меньшие фрагменты для кодирования областей видеопотока с относительно большей сложностью сцены и/или большим движением, чем для областей видеопотока с относительно меньшей сложностью сцены и/или меньшим движением. Например, как изображено на фиг.8, меньшие фрагменты применяются вокруг движущегося персонажа 805 в одной области одного R-кадра 811 (за которым, возможно, следует последовательность R-кадров с идентичными размерами фрагментов (не изображены)). Далее, когда персонаж 805 перемещается в новую область изображения, меньшие фрагменты используются вокруг этой новой области внутри другого R-кадра 812, как изображено. Как упоминалось выше, различные другие размеры и формы могут быть применены как "фрагменты", хотя по-прежнему с выполнением этих лежащих в основе принципов.

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

Как обсуждалось ранее, это просто имеет место, что с большинством подключений к Internet потребительского уровня (и многими офисными соединениями), просто не выполнимо для данных, (оздающих "пробку", которые превышают доступную максимальную скорость передачи данных, изображенную позицией 622 на фиг.6c, вместе с номинальной максимальной скоростью 621 передачи данных. Отметим, что номинальная максимальная скорость 621 передачи данных (например, "DSL 6 Мбит/с") является, по существу, цифрой сбыта для пользователей, рассматривающих покупку подключения к Internet, но, в общем, она не гарантирует уровень производительности. Для целей этой заявки это не имеет отношение к делу, так как единственной проблемой является доступная максимальная скорость 622 передачи данных во время передачи потоком видео через соединение. Следовательно, на фиг.9a и фиг.9c, так как мы описываем решение проблемы пиков, номинальная максимальная скорость передачи данных не изображена на графике, и изображена только доступная максимальная скорость 922 передачи данных. Скорость передачи данных видеопотока не должна превышать доступную максимальную скорость 922 передачи данных.

Для решения этой проблемы первым, что делает устройство 404 сжатия видео, является определение пиковой скорости 941 передачи данных, которая является скоростью передачи данных, которую канал в состоянии обрабатывать устойчиво. Эта скорость может быть определена несколькими способами. Один такой способ состоит в постепенной отправке тестового потока с все более высокой скоростью передачи данных из службы по 210 размещению информации на сервере в клиента 415 по фиг.4a и фиг.4b и обеспечении клиентом обратной связи в службу хостинга относительно уровня потери пакетов и времени ожидания. Когда потеря пакетов и/или время ожидания начинают резко увеличиваться, это указывает на приближение к доступной максимальной скорости 922 передачи данных. После этого служба 210 хостинга может постепенно уменьшать скорость передачи данных тестового потока до тех пор, пока клиент 415 не сообщит, что за достаточный период времени тестовый поток был принят с приемлемым уровнем потери пакетов и время ожидания является почти минимальным. Это устанавливает пиковую максимальную скорость 941 передачи данных, которая далее используется как пиковая скорость передачи данных для потокового видео. С течением времени пиковая скорость 941 передачи данных будет колебаться (например, если другой пользователь, живущий в этом доме, начнет интенсивно использовать подключение к Internet), и клиент 415 должен будет постоянно осуществлять текущий контроль над увеличением времени ожидания или потери пакетов с указанием того, что доступная максимальная скорость 922 передачи данных падает ниже ранее установленной пиковой скорости 941 передачи данных, и если это так, то пиковую скорость 941 передачи данных. Аналогично, если с течением времени клиент 415 находит, что потеря пакетов и время ожидания остаются на оптимальных уровнях, то он может отправлять запрос, чтобы устройство сжатия видео медленно увеличивало скорость передачи данных для проверки того, увеличилась ли доступная максимальная скорость передачи данных (например, прекратил ли другой пользователь, живущий в доме, интенсивно использовать подключение к Internet), и снова ожидать до тех пор пока потеря пакетов и/или более высокое время ожидания не будут указывать на то, что доступная максимальная скорость 922 передачи данных была превышена, и снова может быть найден более низкий уровень для пиковой скорости 941 передачи данных, но тот, который может быть выше, чем уровень, который был до тестирования на увеличение скорости передачи данных. Соответственно, с использованием этого способа (и других способов, подобных этому) может быть найдена пиковая скорость 941 передачи данных и периодически корректироваться, по мере необходимости. Пиковая скорость 941 передачи данных устанавливает максимальную скорость передачи данных, которая может использоваться устройством 404 сжатия видео для передачи потоком видео пользователю. Логика для определения пиковой скорости передачи данных может быть реализована на территории 211 пользователя и/или в службе 210 хостинга. На территории 211 пользователя клиентское устройство 415 выполняет вычисления для определения пиковой скорости передачи данных и передает эту информацию обратно в службу 210 хостинга, в службе 210 хостинга сервер 402 в службе хостинга выполняет вычисления для определения пиковой скорости передачи данных на основе статистики, принятой из клиента 415 (например, потеря пакетов, время ожидания, максимальная скорость передачи данных и т.д.).

На фиг.9a изображена иллюстративная скорость 934 передачи данных видеопотока, который содержит значительную сложность сцены и/или значительное движение, сформированное с использованием способа сжатия циклического I/P-фрагмента, описанного ранее и изображенного на фиг.7a, фиг.7b и фиг.8. Устройство 404 сжатия видео было сконфигурировано для вывода сжатого видео со средней скоростью передачи данных, которая ниже пиковой скорости 941 передачи данных, и отметим, что почти все время скорость передачи данных видеопотока остается ниже пиковой скорости 941 передачи данных. При сравнении скорости 934 передачи данных со скоростью 634 передачи данных видеопотока, изображенной на фиг.6c, создаваемой с использованием I/P/B- или I/P-кадров, видно, что на выходе сжатия циклического I/P-фрагмента получается гораздо более гладкая скорость передачи данных. Однако в пике 952 2× кадра (который приближается к пиковой скорости 942 передачи данных 2×) и пике 954 4× кадра (который приближается к пиковой скорости 944 передачи данных 4×) скорость передачи данных превышает пиковую скорость 941 передачи данных, что является неприемлемым. На практике, даже с видео с высокой активностью в видеоиграх с быстрым изменением, пики, превышающие пиковую скорость 941 передачи данных, встречаются меньше, чем в 2% кадров, пики, превышающие пиковую скорость 942 передачи данных 2×, встречаются редко, а пики, превышающие пиковую скорость 943 передачи данных 3×, не встречаются почти никогда. Но когда они действительно встречаются (например, во время монтажного перехода), требующаяся им скорость передачи данных является необходимой для вывода видеоизображения хорошего качества.

Один способ решения этой проблемы состоит в том, чтобы просто сконфигурировать устройство 404 сжатия видео так, что выход его максимальной скорости передачи данных является пиковой скоростью 941 передачи данных. К сожалению, получающееся в результате качество видео на выходе во время пиковых кадров является плохим, так как алгоритм сжатия "испытывает недостаток" в битах. В результате появляются артефакты сжатия, когда осуществляются внезапные переходы или быстрое движение, и со временем пользователь понимает, что артефакты всегда неожиданно возникают, когда происходят внезапные изменения или быстрое движение, и это может его весьма раздражать.

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

Фактически, когда происходят такие внезапные изменения, оказывается, что зрительная система человека занята отслеживанием изменений, и она не замечает, если частота кадров на короткое время падает с 60 кадр/с до 30 кадр/с и затем сразу возвращается к 60 кадр/с. И в случае очень значительного перехода, подобного внезапному изменению сцены, зрительная система человека не замечает, если частота кадров падает до 20 кадр/с или даже 15 кадр/с и затем сразу возвращается к 60 кадр/с. До тех пор пока уменьшение частоты кадров происходит редко, человеку-наблюдателю кажется, что видео непрерывно передается со скоростью 60 кадр/с.

Это свойство зрительной системы человека используется в способах, изображенных на фиг.9b. Сервер 402 (по фиг.4a и фиг.4b) выводит несжатый выходной видеопоток с устойчивой частотой кадров (с 60 кадр/с в одном варианте осуществления). На временной шкале изображено, что каждый кадр 961-970 выводится каждую 1/60-ую долю секунды. Каждый несжатый видеокадр, начиная с кадра 961, выводится в устройство 404 сжатия видео с малым временем ожидания, которое сжимает кадр за время, меньшее, чем период кадра, с выводом для первого кадра сжатого кадра 981 1. Данные, выводимые для сжатого кадра 981 1, могут быть большего размера или меньшего размера, в зависимости от многих факторов, как описано ранее. Если размер данных такой маленький, что они могут быть переданы клиенту 415 в течение периода кадра (1/60-ая доля секунды) или меньше с пиковой скоростью 941 передачи данных, то они передаются в течение периода 991 передачи (xmit time) (длина стрелки указывает на продолжительность периода передачи). В течение следующего периода кадра сервер 402 выводит несжатый кадр 962 2, он сжимается в сжатый кадр 982 2, и он передается в клиент 415 в течение периода 992 передачи, который меньше, чем период кадра, с пиковой скоростью 941 передачи данных.

Далее, в течение следующего периода кадра сервер 402 выводит несжатый кадр 963 3. Когда он сжимается устройством 404 сжатия видео, получающийся в результате сжатый кадр 983 3 является большим количеством данных, чем может быть передано с пиковой скоростью 941 передачи данных в течение одного периода кадра. Соответственно, он передается в течение периода 993 передачи (пик 2×), который занимает весь период кадра и часть следующего периода кадра. Далее, в течение следующего периода кадра сервер 402 выводит другой несжатый кадр 964 4 и выводит его в устройство 404 сжатия видео, но данные игнорируются, и они изображены посредством позиции 974. Это происходит потому, что устройство 404 сжатия видео сконфигурировано для игнорирования последующих несжатых видеокадров, которые поступают, когда оно все еще передает предыдущий сжатый кадр. Несомненно, устройство восстановления сжатого видео клиента 415 не примет кадр 4, но оно просто будет продолжать выводить на экран дисплея 422 кадр 3 в течение двух периодов кадра (т.е. на короткое время уменьшит частоту кадров с 60 кадр/с до 30 кадр/с).

В течение следующего кадра 5 сервер 402 выводит несжатый кадр 965 5, который сжимается в сжатый кадр 985 5 и передается внутри 1 кадра в течение периода 995 передачи. Устройство восстановления сжатого видео клиента 415 восстанавливает сжатый кадр 5 и выводит его на экран дисплея 422. Далее, сервер 402 выводит несжатый кадр 966 6, устройство 404 сжатия видео сжимает его в сжатый кадр 986 6, но на этот раз размер получившихся в результате данных является очень большим. Сжатый кадр передается в течение периода 996 передачи (пик 4×) с пиковой скоростью 941 передачи данных, но передача кадра занимает почти 4 периода кадра. В течение следующих 3 периодов кадра устройство 404 сжатия видео игнорирует 3 кадра из сервера 402, и устройство восстановления сжатых данных клиента 415 постоянно выводит кадр 6 на дисплей 422 в течение 4 периодов кадра (т.е. на короткое время уменьшает частоту кадров с 60 кадр/с до 15 кадр/с). И наконец, сервер 402 выводит кадр 970 10, устройство 404 сжатия видео сжимает его в сжатый кадр 987 10, и он передается в течение периода 997 передачи, и устройство восстановления сжатых данных клиента 415 восстанавливает сжатый кадр 10 и выводит его на экран дисплея 422, и снова вывод видео возобновляется со скоростью 60 кадр/с.

Отметим, что, несмотря на то, что устройство 404 сжатия видео сбрасывает видеокадры видеопотока, формируемого сервером 402, оно не сбрасывает аудиоданные, независимо от того, в какой форме поступает аудио, и оно продолжает сжимать аудиоданные, когда видеокадры сбрасываются, и передает их в клиент 415, который продолжает восстанавливать сжатые аудиоданные и обеспечивать аудио в устройство, которое использует пользователь для воспроизведения аудио, каково бы оно ни было. Соответственно, аудио продолжает воспроизводиться полностью в течение периодов, когда кадры сбрасываются. Сжатое аудио использует относительно маленький процент от полосы пропускания по сравнению со сжатым видео и в результате не оказывает значительного влияния на общую скорость передачи данных. Несмотря на то, что это не изображено ни в одной из схем скорости передачи данных, всегда существует пропускная способность скорости передачи данных, зарезервированная для сжатого аудиопотока в пределах пиковой скорости 941 передачи данных.

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

Если только что описанный механизм уменьшения частоты кадров применяется к скорости передачи данных видеопотока, изображенной на фиг.9a, то получающаяся в результате скорость передачи данных видеопотока изображена на фиг.9c. В этом примере пик 952 2× был уменьшен до сглаженного пика 953 2×, и пик 955 4× был уменьшен до сглаженного пика 955 4×, и вся скорость 934 передачи данных видеопотока остается на уровне пиковой скорости 941 передачи данных или ниже его.

Соответственно, с использованием способов, описанных выше, видеопоток с высокой активностью может быть передан с малым временем ожидания через общий Internet и через подключение к Internet потребительского уровня. Кроме того, в офисной обстановке в LAN (например, Ethernet 100 Мбит или беспроводная связь 802.11g) или в частной сети (например, соединение 100 Мбит/с между центром обработки и хранения данных и офисами) видеопоток с высокой активностью может передаваться без пиков так, что множество пользователей (например, передающих 1920×1080 с 60 кадр/с с 4,5 Мбит/с) могут использовать LAN или совместно используемое частное информационное соединение без накладывающихся пиков, переполняющих сеть или магистрали сетевого коммутатора.

Корректировка скорости передачи данных

В одном варианте осуществления служба 210 хостинга сначала оценивает доступную максимальную скорость 622 передачи данных и время ожидания канала для определения соответствующей скорости передачи данных для видеопотока и затем динамически корректирует скорость передачи данных в ответе. Для корректировки скорости передачи данных служба 210 хостинга может, например, модифицировать разрешающую способность изображения и/или количество кадров/секунда видеопотока, который должен быть отправлен в клиент 415. Кроме того, служба хостинга может корректировать уровень качества сжатого видео. При изменении разрешающей способности видеопотока, например, с разрешающей способности 1280×720 на 640×360 логика 412 восстановления сжатого видео в клиенте 415 может приводить к масштабу изображение для поддержания идентичного размера изображения на экране дисплея.

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

Сброшенные или задержанные пакеты

В одном варианте осуществления, если данные потеряны из-за потери пакетов между устройством 404 сжатия видео и клиентом 415 по фиг.4a или фиг.4b, или из-за пакета, принимаемого не по порядку, который поступает слишком поздно, для восстановления сжатого кадра и удовлетворения требований ко времени ожидания восстановленного кадра, логика 412 восстановления сжатого видео может уменьшать визуальные артефакты. При реализации потокового I/P-кадра, если существует потерянный/задержанный пакет, то это влияет на весь экран, возможно, вызывая полное зависание экрана на некоторый период времени или показ других визуальных артефактов по всему экрану. Например, если потерянный/задержанный пакет вызывает потерю I-кадра, то в устройстве восстановления сжатых данных будет отсутствовать опорный элемент для всех последующих P-кадров до тех пор, пока не будет принят новый I-кадр. Если P-кадр будет потерян, то это повлияет на P-кадры для всего экрана, которые за ним следуют. В зависимости от того, сколько времени пройдет до того, как появится I-кадр, это окажет более длительное или более короткое визуальное воздействие. С использованием чередующихся I/P-фрагментов, как изображено на фиг.7a и фиг.7b, гораздо менее вероятно, что потерянный/задержанный пакет повлияет на весь экран, так как он только повлияет на фрагменты, содержащиеся в затронутом пакете. Если данные каждого фрагмента отправляют в отдельном пакете, то, если пакет потерян, то это повлияет только на один фрагмент. Несомненно, продолжительность визуального артефакта будет зависеть от того, потерян ли пакет I-фрагмента, и, если P-фрагмент потерян, то через какое количество кадров появится I-фрагмент. Но с учетом того, что разные фрагменты на экране обновляются посредством I-кадров очень часто (возможно, каждый кадр), даже если затрагивается один фрагмент на экране, то другие фрагменты могут не затрагиваться. Кроме того, если некоторое событие вызывает потерю нескольких пакетов одновременно (например, всплеск напряжения электропитания рядом с линией DSL, который на короткое время прерывает поток данных), тогда некоторые из фрагментов будут затронуты больше, чем другие, но вследствие того, что некоторые фрагменты будут быстро обновлены посредством нового I-фрагмента, то их это затронет только на короткое время. Кроме того, с реализацией потокового I/P-кадра, I-кадры являются не только наиболее важным кадром, но и I-кадры являются чрезвычайно большими, поэтому, если существует событие, которое вызывает сброс/задержку пакета, то существует большая вероятность того, что будет затронут I-кадр (т.е. если какая-либо часть I-кадра потеряна, то маловероятно, что I-кадр может быть вообще восстановлен), чем намного меньший I-фрагмент. Вследствие всех этих причин использование I/P-фрагментов в результате приводит к гораздо меньшим визуальным артефактам, когда пакеты сбрасываются/задерживаются, чем с I/P-кадрами.

Один вариант осуществления направлен на уменьшение влияния потерянных пакетов посредством рациональной упаковки сжатых фрагментов внутри пакетов TCP (протокол управления передачей) или пакетов UDP (протокол передачи дейтаграмм пользователя). Например, в одном варианте осуществления фрагменты выравниваются по границам пакета всегда, когда это возможно. На фиг.10a изображено то, как фрагменты могут быть упакованы внутри последовательности пакетов 1001-1005 без реализации этого признака. А именно на фиг.10a фрагменты пересекают границы пакета и упакованы неэффективно так, что потеря одного пакета в результате приводит к потере множества кадров. Например, если потеряны пакеты 1003 или 1004, то потеряны три фрагмента, что в результате приводит к визуальным артефактам.

В отличие от этого на фиг.10b изображена логика 1010 упаковки фрагмента для рациональной упаковки фрагментов внутри пакетов для уменьшения влияния потери пакета. Сначала логика 1010 упаковки фрагмента выравнивает фрагменты по границам пакета. Соответственно, фрагменты T1, T3, T4, T7 и T2 выровнены по границе пакетов 1001-1005, соответственно. Логика упаковки фрагмента также направлена на размещение фрагментов внутри пакетов наиболее эффективным возможным способом без пересечения границ пакета. На основе размера каждого из фрагментов фрагменты T1 и T6 объединены в один пакет 1001, T3 и T5 объединены в один пакет 1002, фрагменты T4 и T8 объединены в один пакет 1003, фрагмент T(7) добавлен в пакет 1004 и фрагмент T2 добавлен в пакет 1005. Соответственно, согласно этой схеме, потеря одного пакета в результате приведет к потере не больше чем 2 фрагментов (а не 3 фрагментов, как изображено на фиг.10a).

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

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

Коды FEC увеличивают скорость передачи данных передачи, поэтому предпочтительно они используются только там, где они больше всего необходимы. Если отправляются данные, которые не могут в результате привести к очень заметному визуальному артефакту, то может оказаться предпочтительным не использовать коды FEC для защиты данных. Например, потерянный P-фрагмент, который непосредственно идет пред I-фрагментом, создаст на экране визуальный артефакт (т.е. на фрагменте на экране не будет обновлен) только на 1/60-ю долю секунды. Человеческий глаз не замечает такой визуальный артефакт. Чем дальше P-фрагменты отстоят от следующего I-фрагмента, тем все более заметной становится потеря P-фрагмента. Например, если циклической схемой фрагмента является I-фрагмент, за которым следуют 15 P-фрагментов до того, как I-фрагмент будет снова доступен, то, если потерян P-фрагмент, непосредственно следующий за I-фрагментом, то это в результате приведет к тому, что этот фрагмент будет показывать неправильное изображение в течение 15 периодов кадра (при 60 кадр/с это равно 250 мс). Человеческий глаз легко замечает разрыв в потоке продолжительностью 250 мс. Соответственно, чем дальше отстоит P-фрагмент от следующего нового I-фрагмента (т.е. чем ближе P-фрагменты расположены к предыдущему I-фрагменту), тем более заметным становится артефакт. Как обсуждалось ранее, несмотря на то, что, в общем, чем ближе P-фрагмент расположен к предыдущему I-фрагменту, тем меньше данные для этого P-фрагмента. Соответственно, P-фрагменты, которые следуют за I-фрагментами, не только более важно защищать от потери, но и они меньше по размеру. И, в общем, чем меньше данных, которые необходимо защищать, тем меньший код FEC нужен для их защиты.

Соответственно, как изображено на фиг.11a, в одном варианте осуществления, из-за важности I-фрагментов в видеопотоке только I-фрагменты обеспечиваются кодами FEC. Соответственно, FEC 1101 содержит код исправления ошибок для I-фрагмента 1100, и FEC 1104 содержит код исправления ошибок для I-фрагмент 1103. В этом варианте осуществления FEC не формируется для P-фрагментов.

В одном варианте осуществления, изображенном на фиг.11b, коды FEC также формируются для P-фрагментов, которые, наиболее вероятно, вызовут визуальные артефакты, если будут потеряны. В этом варианте осуществления коды FEC 1105 обеспечивают коды исправления ошибок для первых 3 P-фрагментов, но не для последующих P-фрагментов. В другом варианте осуществления коды FEC формируются для P-фрагментов, размер данных которых является наименьшим (которые будут, как правило, самостоятельно выбирать P-фрагменты, раньше всего встречающиеся после I-фрагмента, защита которых наиболее важна).

В другом варианте осуществления, вместо того чтобы отправлять код FEC с фрагментом, фрагмент передается два раза, причем каждый раз в другом пакете. Если потерян/задержан один пакет, то используется другой пакет.

В одном варианте осуществления, изображенном на фиг.11c, коды 1111 и 1113 FEC формируются для аудиопакетов, 1110 и 1112, соответственно, передаются из службы хостинга одновременно с видео. Особенно важно поддерживать целостность аудио в видеопотоке, потому что искаженное аудио (например, щелканье или шипенье) в результате приводит к особенно неприятному практическому опыту пользователя. Коды FEC способствуют обеспечению представления содержимого аудио в компьютере 415 клиента без искажения.

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

Кроме того, в одном варианте осуществления, изображенном на фиг.11d, коды 1121 и 1123 FEC используются для команд 1120 и 1122 ввода пользователя, соответственно (например, нажатие клавиши), передаваемых в восходящем направлении из клиента 415 в службу 210 хостинга. Это важно, потому что потеря нажатия клавиши или движения мыши в видеоигре или приложении могут в результате привести к неприятному практическому опыту пользователя.

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

В одном варианте осуществления служба 210 хостинга оценивает качество канала связи с клиентом 415 для определения того, использовать ли FEC, и если да, то какие части видео, аудио и команд пользователя с какими FEC следует применять. Оценка "качества" канала может включать в себя такие функции, как оценка потери пакетов, времени ожидания и т.д., как описано выше. Если канал является особенно ненадежным, то служба 210 хостинга может применять FEC ко всем I-фрагментам, P- фрагментам, аудио и командам пользователя. Напротив, если канал является надежным, то служба 210 хостинга может применять FEC только к аудио и командам пользователя, или может не применять FEC ни к аудио ни к видео, или может совсем не использовать FEC. Могут применяться различные другие перестановки применения FEC, хотя по-прежнему с выполнением этих лежащих в основе принципов. В одном варианте осуществления, служба 210 хостинга непрерывно осуществляет текущий контроль условий на канале и соответственно изменяет политику FEC.

В другом варианте осуществления согласно фиг.4a и фиг.4b, когда пакет потерян/задержан, что в результате приводит к потере данных фрагмента, или если, возможно, из-за особенно большой потери пакетов FEC не может исправить потерянные данные фрагмента, то клиент 415 оценивает, сколько кадров остается до того, как новый I-фрагмент будет принят, и сравнивает это количество со временем передачи сигнала туда и обратно, от клиента 415 до службы 210 хостинга. Если время передачи сигнала туда и обратно меньше, чем количество кадров, оставшееся до ожидаемого поступления нового I-фрагмента, то клиент 415 отправляет сообщение в службу по размещению 210 информации на сервере с запросом нового I-фрагмента. Это сообщение маршрутизируется в устройство 404 сжатия видео, и вместо формирования P-фрагмента для фрагмента, данные которого были потеряны, оно формирует I-фрагмент. С учетом того, что система, изображенная на фиг.4a и фиг.4b, предназначена для обеспечения времени передачи сигнала туда и обратно, которое, как правило, меньше 80 мс, в результате получим, что фрагмент исправляется в пределах 80 мс (при 60 кадр/с, продолжительность кадров равна 16,67 мс, соответственно, в полных периодах кадра, время ожидания 80 мс в результате приводит к исправлению фрагмента в пределах 83,33 мс, которые равны 5 периодам кадра - заметный разрыв, но намного менее заметный, чем, например, разрыв 250 мс для 15 кадров). Когда устройство 404 сжатия формирует такой I-фрагмент вне его обычного циклического порядка, если I-фрагмент вызывает то, что полоса пропускания этого кадра превышает доступную полосу пропускания, то устройство 404 сжатия задерживает циклы других фрагментов так, что другие фрагменты принимают P-фрагменты в течение этого периода кадра (даже если один фрагмент обычно должен принимать I-фрагмент в течение этого кадра), и далее, начиная со следующего кадра, продолжается обычное циклическое повторение, и фрагмент, который обычно принимал I-фрагмент в предыдущем кадре, принимает I-фрагмент. Несмотря на то, что это действие на короткое время задерживает фазу циклического повторения R-кадра, визуально это обычно не заметно.

Реализация устройства сжатия/устройства восстановления сжатого видео и аудио

На фиг.12 изображен один конкретный вариант осуществления, в котором используется многоядерный процессор и/или мультипроцессор 1200 для сжатия 8 фрагментов параллельно. В одном варианте осуществления используется компьютерная система с четырехядерным CPU Xeon, сдвоенный процессор, функционирующая с тактовой частотой 2,66 ГГц или выше, причем каждое ядро реализует устройство сжатия H.264 ×264 с открытым исходным текстом как независимый процесс. Однако могут использоваться различные другие конфигурации аппаратного/программного обеспечения, хотя по-прежнему с выполнением этих лежащих в основе принципов. Например, каждое из ядер CPU может быть заменено устройством сжатия H.264, реализованным в FPGA. В примере, изображенном на фиг.12, ядра 1201-1208 используются для одновременной обработки I-фрагментов и P-фрагментов как восемь независимых потоков. Как известно в данной области техники, современные многоядерные и мультипроцессорные компьютерные системы по своей природе могут осуществлять многопоточность при интеграции с многопоточными операционными системами, например, Microsoft Windows XP Professional Edition (или 64-разрядная или 32-разрядная версия) и Linux.

В варианте осуществления, изображенном на фиг.12, так как каждое из этих 8 ядер отвечает только за один фрагмент, то оно функционирует в значительной степени независимо от других ядер, причем каждое исполняет отдельный экземпляр ×264. Карта захвата DVI, на основе PCI Express ×1, например, Sendero Video Imaging IP Development Board от Microtronix, Oosterhout, Нидерланды, используется для захвата несжатого видео с разрешающей способностью 640×480, 800×600 или 1280×720, и FPGA на карте использует прямой доступ к памяти (DMA) для передачи захваченного видео через DVI в системную RAM. Фрагменты компонуются в компоновку 1205 4×2 (несмотря на то, что они изображены как квадратные фрагменты, в этом варианте осуществления они имеют разрешающую способность 160×240). Каждый экземпляр ×264 сконфигурирован для сжатия одного из 8 фрагментов 160×240, и они синхронизированы так, что после начального сжатия I-фрагмента каждое ядро входит в цикл, причем каждый кадр не совпадает по фазе с другим, для сжатия одного I-фрагмента, за которым следуют семь P-фрагментов, и изображенный на фиг.12.

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

Несмотря на то что не изображено на фиг.12, если скорость передачи данных объединенных 8 фрагментов превышает заданную пиковую скорость 941 передачи данных, то все 8 процессов x264 откладываются на такое количество периодов кадра, которое необходимо до тех пор, пока все данные упомянутых объединенных 8 фрагментов не смогут быть переданы.

В одном варианте осуществления клиент 415 реализован в виде программного обеспечения на PC, на котором исполняются 8 экземпляров FFmpeg. Принимающий процесс принимает 8 фрагментов, и каждый фрагмент маршрутизируется в экземпляр FFmpeg, который восстанавливает сжатый фрагмент и визуализирует его в соответствующем месте расположения фрагмента на дисплее 422.

Клиент 415 принимает ввод клавиатуры, мыши или игрового контроллера из драйверов устройства ввода PC и передает его в сервер 402. Сервер 402 далее применяет принятые данные устройства ввода и применяет их к игре или приложению, исполняющемуся на сервере 402, который является PC, работающим под управлением Windows с использованием двухядерного (Core Duo) CPU Intel 2,16 ГГц. Сервер 402 далее выводит новый кадр и выводит его через свой выход DVI, или из расположенной на системной плате графической системы, или через выход DVI платы PCI 8800GTX NVIDIA.

Одновременно сервер 402 выводит аудио, выводимое игрой или приложениями, через свой цифровой аудиовыход (например, S/PDIF), который соединен с цифровым аудиовходом на сдвоенном четырехядерном PC на основе Xeon, который реализует сжатие видео. Устройство сжатия аудио с открытым исходным текстом Vorbis используется для сжатия аудио одновременно с видео с использованием любого ядра, доступного для потока обработки. В одном варианте осуществления ядро, которое выполняет сжатие своего фрагмента, сначала исполняет сжатие аудио. Сжатое аудио далее передается вместе со сжатым видео и восстанавливается в клиенте 415 с использованием устройства восстановления сжатого аудио Vorbis.

Распределение серверного центра службы хостинга

Свет через стекло, например светопровод, проходит со скоростью, равной некоторой доле от скорости света в вакууме, и, соответственно, может быть определена точная скорость распространения света в светопроводе. Но на практике с учетом времени из-за задержек маршрутизации, неэффективности передач и других потерь авторы наблюдали, что оптимальные величины времени ожидания в Internet отражают скорости передачи ближе к 50% от скорости света. Соответственно, оптимальное время передачи сигнала туда и обратно на расстояние 1000 миль (1600 км) равно приблизительно 22 мс, и оптимальное время передачи сигнала туда и обратно на расстояние 3000 миль (4800 км) равно приблизительно 64 мс. Соответственно, один сервер, находящийся на одном побережье США, находится слишком далеко для обслуживания клиентов на другом побережье (которое может находиться на расстоянии 3000 миль (4800 км)) с требуемым временем ожидания. Однако, как изображено на фиг.13a, если серверный центр 1300 службы 210 хостинга расположен в центре США (например, в Канзасе, в Небраске и т.д.) так, что расстояние до любой точки в континентальных США равно приблизительно 1500 миль (2400 км) или меньше, то время передачи сигнала туда и обратно по Internet может быть равно только 32 мс. Согласно фиг.4b, отметим, что, несмотря на то что величины времени ожидания в самом плохом случае, допустимые для (соединения) 453 пользователь ISP, равны 25 мс, как правило, авторы наблюдали величины времени ожидания ближе к 10-15 мс с системами кабельной модемной связи и DSL. Кроме того, согласно фиг.4b предполагается, что максимальное расстояние от территории 211 пользователя до хостинг-центра 210 равно 1000 миль (1600 км). Соответственно, при типичном используемом времени передачи сигнала туда и обратно (по соединению) пользователь ISP 15 мс и максимальном расстоянии через Internet 1500 миль (2400 км) для времени передачи сигнала туда и обратно 32мс, общее время передачи сигнала туда и обратно от момента, когда пользователь приводит в действие устройство 421 ввода и наблюдает ответ на дисплее 422, равно 1+1+15+32+1+16+6+8=80 мс. Соответственно, (при передаче) по Internet на расстояние 1500 миль (2400 км), как правило, может получаться время ответа 80 мс. Это может обеспечить любую территорию пользователя достаточно коротким временем 453 ожидания (для соединения) пользователь ISP в континентальных США для доступа к одному серверному центру, который расположен в центре.

В другом варианте осуществления, изображенном на фиг.13b, серверные центры, HS1-HS6, службы 210 хостинга стратегически размещены по Соединенным Штатам (или другому географическому региону), причем определенные большие серверные центры службы хостинга расположены близко к центрам с высокой плотностью населения (например, HS2 и HS5). В одном варианте осуществления серверные центры HS1-HS6 обмениваются информацией через сеть 1301, которая может быть Internet, или частной сетью, или комбинацией обоих. В отношении множества серверных центров услуги могут оказываться с меньшим временем ожидания для пользователей, у которых время 453 ожидания ISP пользователя является большим.

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

В одном варианте осуществления, когда клиент 415 пользователя вначале соединяется со службой 210 хостинга для воспроизведения видеоигры или использования приложения, клиент осуществляет связь с каждым из серверных центров HS1-HS6 службы хостинга, доступных после запуска (например, с использованием способов, описанных выше). Если время ожидания является достаточно малым для конкретного соединения, то используется это соединение. В одном варианте осуществления клиент осуществляет связь со всеми серверными центрами службы хостинга или их подмножеством, причем выбирается серверный центр с соединением с самым малым временем ожидания. Клиент может выбирать центр обслуживания с соединением с самым малым временем ожидания, или центры обслуживания могут идентифицировать центр обслуживания с соединением с самым малым временем ожидания и обеспечивать эту информацию (например, в виде адреса Internet) в клиент.

Если конкретный серверный центр службы хостинга перегружен и/или для приложения или игры пользователя время ожидания для соединения с другим, менее загруженным серверным центром службы хостинга является допустимым, то клиент 415 может быть перенаправлен в другой серверный центр службы хостинга. В такой ситуации игра или приложение, исполняемые пользователем, приостанавливаются на сервере 402 в перегруженном серверном центре пользователя, и данные о состоянии приложения или игры передаются в сервер 402, находящийся в другом серверном центре службы хостинга. После этого игра или приложение возобновляются. В одном варианте осуществления служба 210 хостинга ожидает до тех пор, пока игра или приложение не достигнут естественной точки приостановки (например, между уровнями в игре, или после того, как пользователь инициирует операцию "сохранение" в приложении), для упомянутой передачи. В еще одном варианте осуществления служба 210 хостинга ожидает до тех пор, пока активность пользователя не прекратится на заданный период времени (например, на 1 минуту), и тогда инициирует упомянутую передачу в это время.

Как описано выше, в одном варианте осуществления служба 210 хостинга абонирует услугу 440 по обходу Internet по фиг.14 с целью обеспечения своим клиентам гарантируемого времени ожидания. Услуги по обходу Internet, как используется в этом описании, являются услугами, которые обеспечивают маршруты через частную сеть от одной точки до другой (точки) в Internet с гарантируемыми характеристиками (например, время ожидания, скорость передачи данных и т.д.). Например, если служба 210 хостинга принимает большой объем трафика от пользователей, использующих услугу DSL AT&T, предлагаемую в Сан-Франциско, то вместо маршрутизации в находящиеся в Сан-Франциско центральные АТС AT&T служба 210 хостинга может арендовать частное информационное соединение с большой пропускной способностью у провайдера услуг (возможно, у компании AT&T непосредственно или у другого провайдера) между находящимися в Сан-Франциско центральными АТС и одним или несколькими серверными центрами для службы 210 хостинга. Тогда, если маршруты от всех серверных центров HS1-HS6 службы хостинга через общий Internet до пользователя, находящегося в Сан-Франциско, с использованием DSL AT&T в результате приводят к слишком большому времени ожидания, то вместо них может быть использовано частное информационное соединение. Несмотря на то что частные информационные соединения, как правило, являются более дорогими, чем маршруты через общий Internet, до тех пор пока они составляют небольшой процент от соединений службы 210 хостинга с пользователями, общее влияние на стоимость будет оставаться на низком уровне, и пользователи будут испытывать более постоянный практический опыт обслуживания.

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

В одном варианте осуществления каждая из служб HS1-HS5 хостинга совместно использует пользовательские данные так, что, если в одном серверном центре происходит отказ в системе питания, то он может приостановить игры и приложения, которые находятся в процессе (исполнения), и затем передает данные о состоянии приложения или игры из каждого сервера 402 в серверы 402, находящиеся в других серверных центрах, и затем уведомят клиента 415 каждого пользователя и предписывает, чтобы он передавал информацию в новый сервер 402. С учетом того, что такие ситуации происходят редко, может оказаться приемлемой передача пользователя серверному центру службы хостинга, который не может обеспечивать оптимальное время ожидания (т.е. пользователь просто должен будет мириться с более высоким временем ожидания в течение отказа в системе питания), что обеспечивает гораздо более широкие возможности для передачи пользователей. Например, с учетом разных часовых поясов в США, пользователи на Восточном побережье могут ложиться сыпать в 23:30, в то время как пользователи на Западном Побережье в 20:30 начинают максимально использовать видеоигры. Если в это время происходит отказ в системе питания в серверном центре службы хостинга, находящемся на Западном Побережье, то, возможно, нет достаточного количества серверов 402, находящихся на Западном Побережье, в других серверных центрах службы хостинга для управления всеми пользователями. В такой ситуации некоторые пользователи могут быть переданы в серверные центры службы хостинга, находящиеся на Восточном побережье, в которых существуют доступные серверы 402, и единственным последствием для пользователей будет большее время ожидания. После передачи пользователей из серверного центра, который остался без электричества, серверный центр может начать в должном порядке отключение своих серверов и оборудования так, чтобы все оборудование было отключено до разрядки батарей (или другого немедленно подключаемого резервного питания). Следовательно, серверный центр может избежать затрат на генератор.

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

Признаки службы хостинга

На фиг.15 изображен вариант осуществления компонентов серверного центра для службы 210 хостинга, используемый в нижеследующем описании признаков. Как и в случае со службой 210 хостинга, изображенной на фиг.2a, компонентами этого серверного центра управляет и (их работу) координирует система 401 управления службы 210 хостинга, если не оговорено иное.

Входящий трафик 1501 в internet из клиентов 415 пользователя направляется во входящую маршрутизацию 1502. Как правило, входящий трафик 1501 в internet входит в серверный центр через высокоскоростное оптоволоконное соединение с Internet, но будет достаточно любых средств сетевого соединения с отвечающими требованиям полосой пропускания, надежностью и малым временем ожидания. Входящая маршрутизация 1502 является системой сетевых (сеть может быть реализована как сеть Ethernet, сеть волоконно-оптических каналов или посредством любых других транспортных средств) коммутаторов и серверов маршрутизации, поддерживающих коммутаторы, которая принимает поступающие пакеты и маршрутизирует каждый пакет в соответствующий сервер 1521-1525 приложения/игры ("app/game"). В одном варианте осуществления пакет, который доставляется на конкретный сервер приложения/игры, представляет подмножество данных, принимаемых из клиента, и/или может быть преобразован/изменен другими сетевыми компонентами (например, такими сетевыми компонентами, как шлюзы и маршрутизаторы) в центре обработки и хранения данных. В некоторых случаях пакеты маршрутизируются в несколько серверов 1521-1525 одновременно, например, если игра или приложение исполняются параллельно одновременно на множестве серверов. Дисковый массив 1511-1512 типа RAID соединен с сетью 1502 с входящей маршрутизацией так, что серверы 1521-1525 приложения/игры могут считывать с дисковых массивов 1511-1512 типа RAID и записывать на них. Кроме того, дисковый массив 1515 типа RAID (который может быть реализован как множество дисковых массивов типа RAID) также соединен с входящей маршрутизацией 1502, и данные из дискового массива 1515 типа RAID могут быть считаны из серверов 1521-1525 приложения/игры. Входящая маршрутизация 1502 может быть реализована в широком диапазоне архитектур сети предшествующего уровня техники, включающих в себя древовидную структуру коммутаторов, с входящим трафиком 1501 в internet в его корне, в ячеистой структуре, соединяющей все различные устройства, или как набор взаимосвязанных подсетей с трафиком, сосредоточенным между (устройствами) внутренней связи, отделенным от трафика, сосредоточенного среди других устройств. Одним типом конфигурации сети является SAN, которая, несмотря на то что она, как правило, используется для запоминающих устройств, она также может использоваться для обычной высокоскоростной передачи данных между устройствами. Кроме того, серверы 1521-1525 приложение/игра каждый может иметь множество сетевых соединений во входящую маршрутизацию 1502. Например, сервер 1521-1525 может иметь сетевое соединение с подсетью, подсоединенной к дисковым массивам 1511-1512 типа RAID, и другое сетевое соединение с подсетью, подсоединенной к другим устройствам.

Серверы 1521-1525 приложения/игры могут все быть сконфигурированы одинаково, некоторые - по-разному, или все - по-разному, как описано ранее в отношении серверов 402 в варианте осуществления, изображенном на фиг.4a. В одном варианте осуществления каждый пользователь при использовании службы хостинга обычно (использует), по меньшей мере, один сервер 1521-1525 приложения/игры. Для простоты объяснения предположим, что данный пользователь использует сервер 1521 приложения/игры, но множество серверов могут использоваться одним пользователем, и множество пользователей могут совместно использовать один сервер 1521-1525 приложения/игры. Ввод сигнала управления пользователя, отправленный из клиента 415, как описано ранее, принимается как входящий трафик 1501 в Internet и маршрутизируется через входящую маршрутизацию 1502 в сервер 1521 приложения/игры. Сервер 1521 приложения/игры использует ввод сигнала управления пользователя как ввод сигнала управления в игру или приложение, исполняющиеся на сервере, и вычисляет следующий кадр видео и аудио, связанного с ним. Сервер 1521 приложения/игры после этого выводит несжатое видео/аудио 1529 в совместно используемое сжатие 1530 видео. Сервер приложения/игры может выводить несжатое видео посредством любых средств, включающих в себя одно или несколько соединений по технологии Gigabit Ethernet, но в одном варианте осуществления видео выводится через соединение DVI, а аудио и другие сжатые данные и информация о состоянии канала связи выводятся через соединение универсальной последовательной шины (USB).

Совместно используемое сжатие 1530 видео сжимает несжатое видео и аудио из серверов 1521-525 приложения/игры. Сжатие может быть реализовано полностью в аппаратном обеспечении, или в аппаратном обеспечении, исполняющем программное обеспечение. Для каждого сервера 1521-1525 приложения/игры может (существовать) выделенное устройство сжатия, или если устройства сжатия являются достаточно быстрыми, то данное устройство сжатия можно использовать для сжатия видео/аудио из нескольких серверов 1521-1525 приложения/игры. Например, при 60 кадр/с время видеокадра равно 16,67 мс. Если устройство сжатия может сжимать один кадр в 1 мс, то это устройство сжатия можно использовать для сжатия видео/аудио из 16 серверов 1521-1525 приложения/игры посредством приема ввода из одного сервера за другим, причем устройство сжатия сохраняет состояние каждого процесса сжатия видео/аудио и переключает контекст по мере того, как оно циклически переключается между потоками видео/аудио из серверов. Это в результате приводит к существенной экономии затрат на аппаратное обеспечение для сжатия. Так как разные серверы будут завершать кадры в разное время, в одном варианте осуществления ресурсы устройства сжатия находятся в совместно используемом пуле 1530 с совместно используемым средством хранения (например, RAM, флэш-память) для хранения состояния каждого процесса сжатия, и когда кадр сервера 1521-1525 закончен и готов для сжатия, средство управления определяет, какой ресурс сжатия является доступным в этот момент, обеспечивает ресурс сжатия состоянием процесса сжатия сервера и кадром несжатого видео/аудио для сжатия.

Отметим, что часть состояния процесса сжатия каждого сервера включает в себя информацию о самом сжатии, например, восстановленные данные буфера кадра предыдущего кадра, которые могут использоваться как опорный элемент для P-фрагментов, разрешающая способность видеовыхода, качество сжатия, мозаичная структура, выделение битов для каждых фрагментов, качество сжатия, аудиоформат (например, стерео, объемный звук, AC Dolby® 3). Но состояние процесса сжатия также включает в себя информацию о состоянии канала связи относительно пиковой скорости 941 передачи данных и того, выводится ли в настоящее время предыдущий кадр (как изображено на фиг.9b) (и в результате текущий кадр должен быть проигнорирован), и, возможно, того, существуют ли характеристики канала, которые должны учитываться при сжатии, например, чрезмерная потеря пакетов, которые влияют на принятие решений в отношении сжатия (например, с точки зрения частоты I-фрагментов и т.д.). По мере того, как пиковая скорость 941 передачи данных или другие характеристики канала изменяются со временем, как определяется сервером 1521-1525 приложения/игры, поддерживающим данные текущего контроля каждого пользователя, отправляемые из клиента 415, сервер 1521-1525 приложения/игры отправляет соответствующую информацию в совместно используемое аппаратное сжатие 1530.

Совместно используемое аппаратное сжатие 1530 также разбивает на пакеты сжатое видео/аудио с использованием средств, например, средств, описанных ранее, и если требуется, то с применением кодов FEC, дублированием определенных данных или принятием других мер для соответствующего обеспечения возможности принятия клиентом 415 потока видео/аудио данных и восстановления сжатых данных с максимально возможным качеством и надежностью.

Некоторые приложения, например, описанные ниже, требуют, чтобы видео/аудиовыход данного сервера 1521-1525 приложения/игры был доступным со многими разрешающими способностями (или в других разнообразных форматах) одновременно. Если сервер 1521-1525 приложения/игры так уведомляет ресурс совместно используемого аппаратного сжатия 1530, то несжатые видео и аудио 1529 этого сервера 1521-1525 приложения/игры будут одновременно сжаты в разных форматах, с разными разрешающими способностями и/или с разными структурами исправления ошибок/пакетов. В некоторых случаях некоторые ресурсы сжатия могут совместно использоваться множеством процессов сжатия, сжимающих идентичное видео/аудио (например, во многих алгоритмах сжатия, существует этап, на котором изображение масштабируется во множество размеров перед применением сжатия). Если требуется вывод изображений разных размеров, то этот этап может использоваться для обслуживания нескольких процессов сжатия одновременно. В других случаях для каждого формата требуются отдельные ресурсы сжатия. В любом случае, сжатое видео/аудио 1539 со всеми требуемыми различными разрешающими способностями и во всех требуемых различных форматах для данного сервера 1521-1525 приложения/игр (будь то один или много) выводится одновременно в исходящую маршрутизацию 1540. В одном варианте осуществления вывод сжатого видео/аудио 1539 осуществляется в формате UDP, соответственно, он является однонаправленным потоком пакетов.

Сеть 1540 исходящей маршрутизации содержит набор коммутаторов и серверов маршрутизации, которые направляют каждый поток сжатого видео/аудио пользователю(ям), которому(ым) он предназначен, или в другие пункты назначения через интерфейс исходящего трафика 1599 из Internet (которые, как правило, подключены к волоконно-оптическому интерфейсу с Internet), и/или обратно в буфер 1515 задержки, и/или обратно во входящую маршрутизацию 1502, и/или через частную сеть (не изображена) для распределения видео. Отметим, что (как описывается ниже) исходящая маршрутизация 1540 может выводить данный видео/аудио поток во множество пунктов назначения одновременно. В одном варианте осуществления это реализовано с использованием групповой передачи по протоколу Internet (IP), в которой передается данный поток UDP, предназначенный для передачи потоком в множество пунктов назначения одновременно, и это широковещание повторяется коммутаторами и серверами маршрутизации в исходящей маршрутизации 1540. Множеством пунктов назначения широковещания могут быть клиенты 415 множества пользователей, (доступные) через Internet, множество серверов 1521-1525 приложения/игры, (доступные) через входящую маршрутизацию 1502, и/или один или несколько буферов 1515 задержки. Соответственно, выход данного сервера 1521-1522 сжимают в один или множество форматов, и каждый сжатый поток направляется в один или множество пунктов назначения.

Кроме того, в другом варианте осуществления, если множество серверов 1521-1525 приложения/игры одновременно используются одним пользователем (например, в конфигурации параллельной обработки для создания 3D вывода сложной сцены) и каждый сервер выводит часть получающегося в результате изображения, то видеовыход из множества серверов 1521-1525 может объединяться совместно используемым аппаратным сжатием 1530 в комбинированный кадр, и с этого момента и далее он обрабатывается так, как описано выше, как если бы он выходил из одного сервера 1521-1525 приложения/игры.

Отметим, что в одном варианте осуществления копия (по меньшей мере, с разрешающей способностью видео, просматриваемого пользователем, или выше) всего видео, формируемого серверами 1521-1525 приложения/игры, записывается в буфер 1515 задержки, по меньшей мере, на некоторое количество минут (15 минут в одном варианте осуществления). Это обеспечивает возможность каждому пользователю "перематывать" видео из каждого сеанса для просмотра предыдущих действия или деяний (в случае игры). Соответственно, в одном варианте осуществления, в отношении каждого выходного 1539 потока сжатого видео/аудио, маршрутизируемого в клиент 415 пользователя, также осуществляется групповая передача в буфер 1515 задержки. Когда видео/аудио сохраняется в буфере 1515 задержки, каталог в буфере 1515 задержки обеспечивает перекрестную ссылку между сетевым адресом сервера 1521-1525 приложения/игры, который является источником задержанного видео/аудио, и местом в буфере 1515 задержки, где задержанное видео/аудио может быть найдено.

Игры в реальном масштабе времени, немедленно выводимые на экран, с возможностью немедленного ведения игры

Серверы 1521-1525 приложения/игры могут использоваться не только для исполнения данного приложения или видеоигры для пользователя, но они также могут использоваться для создания интерфейсных приложений пользователя для службы 210 хостинга, которые поддерживают навигацию в службе 210 хостинга и другие признаки. Моментальный снимок экрана одного такого интерфейсного приложения пользователя изображен на фиг.16, экран "Game Finder" ("средство поиска игры"). Этот конкретный экран интерфейса пользователя обеспечивает возможность пользователю смотреть 15 игр, которые ведутся в реальном масштабе времени (или отложены) другими пользователями. Каждое из "миниатюрных" видеоокон, например 1600, является окном с видео в реальном масштабе времени в движении, показывающим одно видео из игры одного пользователя. Вид, показанный в миниатюре, может быть видом, идентичным тому, который видит пользователь, или он может быть задержанным видом (например, если пользователь ведет боевую игру, то пользователю может потребоваться, чтобы другие пользователи не видели, где он скрывается, и он может решить задержать какой-либо вид его геймплей на некоторый период времени, скажем, на 10 минут). Вид также может быть полем зрения камеры игры, который отличается от вида любого пользователя. Посредством выбора пунктов меню (не изображено в этом примере) пользователь может отобрать выборку игр для одновременного просмотра исходя из различных критериев. Как небольшое осуществление выборки иллюстративных отборов, пользователь может выбрать случайную выборку игр (например, изображенную на фиг.16), все игры одного вида (все, которые ведут разн