RU2553101C2 - Расширенная система потоковой передачи с запросом блоков, использующая сигнализацию или создание блоков - Google Patents

Расширенная система потоковой передачи с запросом блоков, использующая сигнализацию или создание блоков Download PDF

Info

Publication number
RU2553101C2
RU2553101C2 RU2012116086/08A RU2012116086A RU2553101C2 RU 2553101 C2 RU2553101 C2 RU 2553101C2 RU 2012116086/08 A RU2012116086/08 A RU 2012116086/08A RU 2012116086 A RU2012116086 A RU 2012116086A RU 2553101 C2 RU2553101 C2 RU 2553101C2
Authority
RU
Russia
Prior art keywords
time
multimedia
segment
block
request
Prior art date
Application number
RU2012116086/08A
Other languages
English (en)
Other versions
RU2012116086A (ru
Inventor
Майкл Дж. ЛУБИ
Марк УОТСОН
Лоренцо ВИЧИЗАНО
Паям ПАКЗАД
Бинь Ван
Ин ЧЭНЬ
Томас ШТОКХАММЕР
Original Assignee
Квэлкомм Инкорпорейтед
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Квэлкомм Инкорпорейтед filed Critical Квэлкомм Инкорпорейтед
Publication of RU2012116086A publication Critical patent/RU2012116086A/ru
Application granted granted Critical
Publication of RU2553101C2 publication Critical patent/RU2553101C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Graphics (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Изобретение относится к системам потоковой передачи мультимедиа, а именно к системам и способам, которые адаптированы к условиям сети и буферов. Технический результат заключается в оптимизации представления, переданного в виде потока мультимедиа, и обеспечении эффективной одновременной, или распределенной во времени, доставки переданных в виде потока данных мультимедиа. Технический результат достигается за счет системы потоковой передачи с запросом блоков, которая предусматривает усовершенствования пользовательского восприятия и эффективности использования полосы частот таких систем, обычно использующих систему потребления, которая генерирует данные в форме, которая должна быть обслужена обычным файл-сервером (HTTP, FTP или аналогичным), при этом система потребления потребляет контент и готовит его в качестве файлов или элементов данных, которые должны быть обслужены файл-сервером. Система включает в себя управление последовательностью, тактированием и конструкцией запросов блоков, основанной на времени индексацией, изменением размеров блоков, оптимальным разделением на блоки, управлением размещением точек произвольного доступа, включающим версии множественных представлений, динамическим обновлением данных представления и/или эффективно представляя контент в реальном времени и временным смещением. 2 н. и 6 з.п. ф-лы, 32 ил.

Description

ПЕРЕКРЕСТНЫЕ ССЫЛКИ К СВЯЗАННЫМ ЗАЯВКАМ
[0001] Настоящая заявка является не предварительной заявкой на патент, испрашивающая приоритет следующих предварительных заявок, каждая на имя Michael G. Luby, и др. и каждая названная "Enhanced Block-Request Streaming System":
[0002] Предварительная заявка на патент США №61/244767, поданный 22 сентября 2009,
[0003] Предварительная заявка на патент США №61/257719, поданный 3 ноября 2009,
[0004] Предварительная заявка на патент США №61/258088, поданный 4 ноября 2009,
[0005] Предварительная заявка на патент США №61/285779, поданный 11 декабря 2009, и
[0006] Предварительная заявка на патент США №61/296725, поданный 20 января 2010.
[0009] Патент США Номер 6 307 487, Luby (в дальнейшем "Luby I");
[0010] Патент США Номер 7 068 729 к Shokrollahi, и др. (в дальнейшем "Shokrollahi I ");
[0011] Заявка на патент США № 11/423391 поданная 9 июня 2006 и названная "Forward Error-Correcting (FEC) Coding and Streaming" на имя Luby, и др. (в дальнейшем "Luby, II);
[0012] Заявка на патент США № 12/103605 поданная 15 апреля 2008, названная "Dynamic Stream Interleaving and Sub-Stream Based Delivery" на имя Luby, и др. (в дальнейшем "Luby III");
[0013] Заявка на патент США №12/705202 поданная 12 февраля 2010, названная "Block Partitioning for a Data Stream", на имя Pakzad, и др. (в дальнейшем "Pakzad"); и
[0014] Заявка на патент США №12/859161, поданная 18 августа 2010, названная "Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" на имя Luby, и др. (в дальнейшем "Luby IV").
ОБЛАСТЬ К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
[0015] Настоящее изобретение относится к усовершенствованным системам потоковой передачи мультимедиа и способам, более конкретно - к системам и способам, которые адаптированы к условиям сети и буферов, чтобы оптимизировать представление переданного в виде потока мультимедиа, и обеспечивают эффективную одновременную, или распределенную во времени, доставку переданных в виде потока данных мультимедиа.
УРОВЕНЬ ТЕХНИКИ
[0016] Доставка потокового мультимедиа может стать все более и более важной, поскольку она становится более распространенной для высококачественного аудио и видео, которое должно быть доставлено на основании сети пакетной передачи, такой как Интернет, сотовые и беспроводные сети, сети электропитания, и другие типы сетей. Качество, с которым может быть представлено доставленное потоковое мультимедиа, может зависеть от ряда факторов, включая разрешение (или другие атрибуты) первоначального контента, качество кодирования первоначального контента, способностей устройств приема декодировать и представить мультимедиа, своевременность и качество сигнала, принятого в приемниках, и т.д. Чтобы создать опыт воспринятого хорошего потокового мультимедиа, транспортировка и своевременность сигнала, принятого в приемниках, могут быть особенно важными. Хорошая транспортировка может обеспечить точность потока, принятого в приемнике, относительно того, что посылает отправитель, в то время как своевременность может представить, как быстро приемник может начать воспроизведение контента после начального запроса этого контента.
[0017] Система доставки мультимедиа может быть охарактеризована как система, имеющая источники мультимедиа, место назначения (адресат) мультимедиа, и каналы (во времени и/или пространстве), отделяющие источники и места назначения. Как правило, источник включает в себя передатчик с доступом к мультимедиа в электронно-управляемой форме, и приемник со способностью электронно управлять приемом мультимедиа (или его аппроксимацией) и предоставить его потребителю мультимедиа (например, пользователю, имеющему устройство отображения, соединенное некоторым образом с приемником, устройство или элемент хранения, другой канал, и т.д.).
[0018] В то время как много изменений возможны, в общем примере система доставки мультимедиа имеет один или более серверов, которые имеют доступ к мультимедийному контенту в электронной форме, и одна или более клиентских систем или устройств делают запрос мультимедиа к серверам, и серверы передают мультимедиа, используя передатчик в качестве части сервера, осуществляя передачу на приемник в клиенте так, чтобы принятое мультимедиа могло потребляться клиентом некоторым образом. В простом примере есть один сервер и один клиент, для заданного запроса, и ответ, но это не обязательно должно иметь место.
[0019] Традиционно системы доставки мультимедиа могут быть охарактеризованы или как модель "загрузки" или как модель "потоковой передачи". Модель "загрузки" может быть охарактеризована посредством независимости тактирования между доставкой данных мультимедиа и проигрыванием мультимедиа на устройстве пользователя или получателя.
[0020] Как пример, мультимедиа загружается достаточно заранее перед тем, когда оно необходимо или будет использоваться, и когда оно используется, столько сколько необходимо уже доступно в получателе. Доставка в контексте загрузки часто выполняется, используя протокол транспортировки файлов, такой как HTTP, FTP или Доставка Файла по Однонаправленному Транспортному каналу (FLUTE), и скорость доставки может быть определена лежащим в основе потоком и/или протоколом управления перегрузкой, таким как TCP/IP. Работа потока или протокола управления перегрузкой может быть независимой от проигрывания мультимедиа пользователю или устройству назначения, которое может иметь место одновременно с загрузкой или в некоторое другое время.
[0021] Режим "потоковой передачи" может быть охарактеризован тесным соединением между синхронизацией доставки данных мультимедиа и проигрыванием мультимедиа на устройстве пользователя или получателя. Доставка в этом контексте часто выполняется, используя протокол потоковой передачи, такой как Протокол потоковой передачи, в реальном времени (RTSP) для управления и Транспортный Протокол в реальном времени (RTP) для данных мультимедиа. Скорость доставки может быть определена сервером потоковой передачи, часто соответствуя скорости проигрывания данных.
[0022] Некоторые неудобства модели "загрузки" могут быть такими, что, из-за независимости тактирования доставки и проигрывания, какие-либо данные мультимедиа, возможно, не являются доступными, когда они необходимы для проигрывания (например, из-за доступной полосы частот, являющейся меньшей, чем скорость передачи данных мультимедиа), вызывая остановку на мгновение ("останавливающееся") проигрывания, что приводит к плохому пользовательскому опыту (восприятию), или данные мультимедиа могут быть запрошены, чтобы быть загруженными очень задолго перед проигрыванием (например из-за доступной полосы частот, являющейся большей, чем скорость передачи данных мультимедиа), потребляя ресурсы хранения на устройстве приема, которые могут быть недостаточными, и потребляя ценные ресурсы сети для доставки, которые могут быть потрачены впустую, если контент в конечном счете не проигрывается или иначе не используется.
[0023] Преимущество модели "загрузки" может состоять в том, что эта технология, которая должна выполнить такие загрузки, например HTTP, хорошо разработана, широко развернута и применима в широком диапазоне применений. Серверы загрузки и решений, предназначенных для массивной масштабируемости таких загрузок файлов (например, HTTP Web Серверы и Сети доставки контента) могут быть легко доступными, делая развертывание услуг, основанных на этой технологии, простым и низким по стоимости.
[0024] Некоторые неудобства модели "потоковой передачи" могут быть теми, что обычно скорость передачи доставки данных мультимедиа не приспособлена к доступной полосе частот в соединении от сервера к клиенту, и что требуются специализированные серверы потоковой передачи или более сложная архитектура сети, обеспечивающая полосу пропускания и гарантии задержки. Хотя существуют системы потоковой передачи, которые поддерживают изменение скорости передачи данных доставки согласно доступной полосе частот (например, Adobe Flash Adaptive Streaming), они обычно не столь эффективны как протоколы управления транспортными потоками загрузки, такие как TCP, при использовании всей доступной полосы частот.
[0025] Недавно, были развиты и развернуты новые системы доставки мультимедиа на основании комбинации моделей "потоковой передачи" и "загрузки". Пример такой модели, упомянут здесь как модель "потоковой передачи с запросом блоков", в которой клиент мультимедиа запрашивает блоки данных мультимедиа от обслуживающей инфраструктуры, используя протокол загрузки, такой как HTTP. Проблемой в таких системах может быть способность начать воспроизведение потока, например, декодирование и воспроизведение принятых аудио и видео потоков, используя персональный компьютер и отображение видео на экране компьютера и проигрывание аудио через встроенные громкоговорители, или, в качестве другого примера, декодирование и воспроизведение принятых аудио и видео потоков, используя телевизионную приставку и отображение видео на телевизионном устройстве отображения и проигрывание аудио через систему стерео.
[0026] Другие проблемы возникают, такие как способность декодировать исходные блоки достаточно быстро, чтобы не отставать от скорости потоковой передачи источника, чтобы минимизировать задержку декодирования и уменьшить использование доступных ресурсов центрального процессора. Другая проблема заключается в обеспечении решения надежной и масштабируемой доставки потоковой передачи, которая позволяет компонентам системы терпеть неудачу, не затрагивая неблагоприятно качество потоков, доставленных приемникам. Другие проблемы могут иметь место на основании быстро меняющейся информации о представлении, когда она распределяется. Таким образом, желательно иметь усовершенствованные процессы и устройство.
КРАТКАЯ СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0027] Система потоковой передачи с запросом блоков предусматривает усовершенствования эффективности пользовательского восприятия и полосы пропускания таких систем, типично используя систему потребления, которая генерирует данные в форме, которая должна обслуживаться обычным файл-сервером (HTTP, FTP, или подобным), при этом система потребления потребляет (принимает) контент и готовит его как файлы или элементы данных, которые должны быть обслужены файл-сервером, который может включать в себя или может не включать в себя кэш. Клиентское устройство может быть приспособлено, чтобы использовать преимущество процесса потребления, а так же включая усовершенствования, которые направлены на улучшение представления, независимого от процесса потребления.
[0028] Эти варианты осуществления включают в себя новые усовершенствования для способов, используемых в клиенте потоковой передачи с запросом блоков и в системе потребления с запросом блоков, чтобы определить последовательность, тактирование и конструкцию запросов блоков, включая предоставление основанного на времени индексирования. В некоторых вариантах осуществления предоставлены новые усовершенствования к способам конструирования блока и файла, включая переменный размер блока и оптимальное разделение блока. В некоторых вариантах осуществления предоставлены новые усовершенствования к способам случайного размещения точки доступа, включая случайное размещение точки доступа по множественным версиям представления. В некоторых вариантах осуществления предоставлены новые усовершенствования к способам динамического обновления данных представления, включая сигнализацию в пределах метаданных. В некоторых вариантах осуществления предоставлены новые усовершенствования к способам для того, чтобы эффективно представить «живой» контент и смещение во времени.
[0029] Нижеследующее подробное описание вместе с сопровождающими чертежами обеспечит лучшее понимание существа и преимуществ настоящего изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0030] Фиг. 1 изображает элементы системы потоковой передачи с запросом блоков согласно вариантам осуществления настоящего изобретения.
[0031] Фиг. 2 иллюстрирует систему потоковой передачи с запросом блоков согласно Фиг. 1, показывая большие подробности в элементах клиентской системы, которая подсоединена к инфраструктуре обслуживания блоков ("BSI"), чтобы принять данные, которые обработаны системой потребления контента.
[0032] Фиг. 3 иллюстрирует реализацию аппаратного обеспечения / программного обеспечения системы потребления.
[0033] Фиг. 4 иллюстрирует реализацию аппаратного обеспечения/программного обеспечения клиентской системы.
[0034] Фиг. 5 иллюстрирует возможные структуры хранилища контента, показанного на Фиг. 1, включая сегменты и файлы дескриптора представления мультимедиа ("MPD"), и разбиение сегментов, тактирование и другую структуру в файле MPD.
[0035] Фиг. 6 иллюстрирует подробности типичного исходного сегмента, который может быть сохранен в хранилище контента, проиллюстрированном на Фиг. 1 и 5.
[0036] Фиг. 7a и 7b иллюстрируют простую и иерархическую индексацию в пределах файлов.
[0037] Фиг. 8(a) иллюстрирует переменный размер блока с выровненными точками поиска по множеству версий потока мультимедиа.
[0038] Фиг. 8 (b) иллюстрирует переменный размер блока с не выровненными точками поиска по множеству версий потока мультимедиа.
[0039] Фиг. 9 (a) иллюстрирует таблицу метаданных.
[0040] Фиг. 9 (b) иллюстрирует передачу блоков и таблицы метаданных от сервера к клиенту.
[0041] Фиг.10 иллюстрирует блоки, которые являются независимыми от границ RAP.
[0042] Фиг. 11 иллюстрирует непрерывное и прерывающееся тактирование по сегментам.
[0043] Фиг. 12 является чертежом, показывающим аспекты масштабируемых блоков.
[0044] Фиг. 13 является графическим представлением развития (эволюции) некоторых переменных в системе потоковой передачи с запросом блоков в течение времени.
[0045] Фиг. 14 изображает другое графическое представление развития некоторых переменных в системе потоковой передачи с запросом блоков в течение времени.
[0046] Фиг. 15 изображает сетку состояний ячеек как функцию пороговых значений.
[0047] Фиг. 16 является последовательностью операций процесса, который может быть выполнен в приемнике, который может запрашивать одиночные блоки и множественные блоки в каждом запросе.
[0048] Фиг. 17 является последовательностью операций гибкого конвейерного процесса.
[0049] Фиг. 18 иллюстрирует пример набора запросов-кандидатов, их приоритетов, и на какие соединения они могут быть выданы, в некоторое время.
[0050] Фиг. 19 иллюстрирует пример набора запросов-кандидатов, их приоритетов, и на какие соединения они могут быть выданы, который изменяется от одного момента времени к другому.
[0051] Фиг. 20 является последовательностью операций последовательного кэширования выбора прокси-сервера на основании идентификатора файла.
[0052] Фиг. 21 иллюстрирует определение синтаксиса для подходящего языка выражения.
[0053] Фиг. 22 иллюстрирует пример подходящей хэш-функции.
[0054] Фиг. 23 иллюстрирует примеры правил построения идентификатора файла.
[0055] Фиг. 24 (a)-(e) иллюстрируют флуктуации полосы пропускания TCP-соединений.
[0056] Фиг. 25 иллюстрирует множественные HTTP-запросы в отношении исходных и исправленных данных.
[0057] Фиг. 26 иллюстрирует время переключения канала с и без FEC.
[0058] Фиг. 27 иллюстрирует подробности генератора исправленного сегмента, который в качестве части системы потребления, показанной на Фиг. 1, генерирует исправленные сегменты из исходных сегментов и параметров управления.
[0059] Фиг. 28 иллюстрирует соотношения между исходными блоками и исправленными блоками.
[0060] Фиг. 29 иллюстрирует процедуру для услуг в реальном времени в разное время в клиенте.
[0061] На чертежах аналогичные элементы обозначены аналогичными номерами, и подиндексы предоставлены в круглых скобках, чтобы указать множественные случаи аналогичных или идентичных пунктов. Если иначе не указано, оконечный подиндекс (например, "N" или "М") не предназначен, чтобы ограничиваться каким-либо конкретным значением, и количество экземпляров одного элемента может отличаться от количества экземпляров другого элемента, даже когда одно и то же количество проиллюстрировано, и подиндекс использован снова.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
[0062] Как описано здесь, цель системы потоковой передачи состоит в том, чтобы переместить мультимедиа от его местоположения хранения (или местоположения, где оно генерируется) к местоположению, где оно потребляется, то есть, представляется пользователю, или иначе "расходуется" человеческим или электронным потребителем. В идеале, система потоковой передачи может обеспечить непрерывное воспроизведение (или в более общем смысле, непрерывное "потребление") в конце приема и может начать проигрывать поток или коллекцию потоков вскоре после того, как пользователь запросил поток или потоки. По причинам эффективности также желательно, чтобы каждый поток был остановлен, как только пользователь указывает, что этот поток больше не необходим, например, тогда, когда пользователь переключается от одного потока к другому потоку, или руководствуется представлением потока, например, потока "субтитров". Если компонент мультимедиа, такой как видео, продолжается, чтобы быть представленным, но другой поток выбран, чтобы представить этот компонент мультимедиа, часто является предпочтительным занять ограниченную полосу частот с новым потоком и остановить старый поток.
[0063] Система потоковой передачи с запросом блоков согласно описанным вариантам осуществления предусматривает много выгод. Должно быть понятно, что жизнеспособная система не должна включать в себя все признаки, описанные здесь, поскольку некоторые применения могут обеспечить соответственно удовлетворяющее восприятие с меньшим, чем все, количеством признаков, описанных здесь.
ПОТОКОВАЯ ПЕРЕДАЧА HTTP
[0064] Потоковая передача HTTP является специфическим типом передачи в виде потока. С потоковой передачей HTTP источники могут быть стандартными web-серверами и сетями доставки контента (CDN) и могут использовать стандартный HTTP. Этот метод может вовлекать сегментацию потока и использование множественных потоков, все - в пределах контекста стандартизированных запросов HTTP. Мультимедиа, такое как видео, может быть закодированным при множестве скоростей передачи в битах, чтобы сформировать различные версии, или представления. Термины "версия" и "представление" использованы синонимично в этом документе. Каждая версия или представление могут быть разбиты на меньшие части, возможно, порядка нескольких секунд каждая, чтобы сформировать сегменты. Каждый сегмент может быть, затем сохранен на web-сервере или CDN как отдельный файл.
[0065] На стороне клиента запросы затем могут быть сделаны, используя HTTP, для индивидуальных сегментов, которые легко соединяются клиентом вместе. Клиент может переключиться на другие скорости передачи данных на основании доступной полосы частот. Клиент может также запросить множественные представления, каждое представляющее различный компонент мультимедиа, и может представить мультимедиа в этих представлениях совместно и синхронно. Инициаторы для переключения могут включать в себя заполнение буфера и измерения в сети, например. При работе в устойчивом состоянии клиент может направлять запросы к серверу, чтобы поддержать целевое заполнение буфера.
[0066] Преимущества потоковой передачи HTTP могут включать в себя адаптацию скорости передачи в битах, быстрый запуск и поиск, и минимальная не являющаяся необходимой доставка. Эти преимущества исходят из управления доставкой, чтобы быть только коротким временем перед проигрыванием, создавая максимальное использование доступной полосы частот (посредством мультимедиа с переменной скоростью передачи битов), и оптимизацию сегментации потока и интеллектуальных клиентских процедур.
[0067] Описание представления мультимедиа может быть предоставлено клиенту потоковой передачи HTTP таким образом, что клиент может использовать коллекцию файлов (например в форматах, определенных 3GPP, здесь названных 3gp-сегментами), чтобы предоставить пользователю услугу потоковой передачи. Описание представления мультимедиа, и возможно, обновления этого описания представления мультимедиа, описывают представление мультимедиа, которое является структурированной коллекцией сегментов, каждая содержащая компоненты мультимедиа таким образом, что клиент может представить (воспроизвести) включенное мультимедиа синхронизированным способом и может обеспечить улучшенные характеристики, такие как поиск, переключение скорости передачи в битах и совместное представление компонентов мультимедиа в различных представлениях. Клиент может использовать информацию описания представления мультимедиа различными способами для обеспечения обслуживания. В частности, из описания представления мультимедиа клиент потоковой передачи HTTP может определить, к каким сегментам в коллекции может быть получен доступ, так чтобы эти данные были полезны для возможностей клиента и пользователя в пределах услуги потоковой передачи.
[0068] В некоторых вариантах осуществления описание представления мультимедиа может быть статическим, хотя сегменты могут быть созданы динамически. Описание представления мультимедиа может быть настолько компактным, насколько это возможно, чтобы минимизировать доступ и время загрузки для обслуживания. Другая возможность соединения выделенного сервера может быть минимизирована, например, регулярная или частая синхронизация тактирования между клиентом и сервером.
[0069] Представление мультимедиа может быть построено, чтобы разрешить доступ с помощью терминалов с различными способностями, такими как доступ к различным типам сетей доступа, различные текущие сетевые условия, размеры отображения, скорости передачи в битах при доступе и поддержка кодеков. Клиент может затем извлечь соответствующую информацию, чтобы обеспечить услугу потоковой передачи пользователю.
[0070] Описание представления мультимедиа может также разрешить гибкость развертывания и компактность согласно требованиям.
[0071] В самом простом случае каждое Альтернативное Представление может быть сохранено в единственном 3GP файле, то есть, файле, соответствующем тому, что определено в 3GPP TS26.244, или любом другом файле, который соответствует базовому формату файла мультимедиа ISO, как определено в ISO/IEC 14496-12 или последующих спецификациях (такой как формат файла 3GP, описанный в 3GPP Technical Specification 26.244). В оставшейся части этого документа при упоминании 3GP файла должно быть понятно, что ISO/IEC 14496-12 и полученные на его основе спецификации могут отобразить все описанные особенности на более общий формат файла мультимедиа на основе ISO, как определено в ISO/IEC 14496-12 или любых полученных на его основе спецификациях. Клиент может затем запросить начальную часть файла, чтобы изучить метаданные мультимедиа (которые обычно хранятся в поле заголовка Movie (Кинофильм), также называемое полем "moov"), вместе с моментами времени фрагмента кино и смещениями в байтах. Клиент может затем выдать запросы получить частичный HTTP, чтобы получить фрагменты кино, как требуется.
[0072] В некоторых вариантах осуществления может быть желательно, разделить каждое представление на несколько сегментов, где сегменты. В случае если формат сегмента основан на формате 3GP файла, то сегменты содержат не накладывающиеся интервалы времени фрагментов кино, названных "временным разделением". Каждый из этих сегментов может содержать множественные фрагменты кино, и каждый может быть действительным 3GP файлом в его собственной правильности. В другом варианте осуществления представление разделяется на начальный сегмент, содержащий метаданные (обычно поле Заголовок Кино "moov") и ряд сегментов мультимедиа, каждый содержащий данные мультимедиа, и конкатенация начального сегмента и любого сегмента мультимедиа формирует действительный 3GP файл, так же как и конкатенация начального сегмента и всех сегментов мультимедиа одного представления формирует действительный 3GP файл. Полное представление может быть сформировано посредством проигрывания каждого сегмента в его очередь, отображение локальных отметок времени в пределах файла на глобальное время представления согласно начальному времени каждого представления.
[0073] Нужно отметить, что повсюду в этом описании ссылки на "сегмент" должна пониматься как включающая в себя любой объект данных, который полностью или частично построен или считан с носителя данных или иначе получен в результате запроса протокола загрузки файла, включая, например, запрос HTTP. Например, в случае HTTP объекты данных могут храниться в фактических файлах, постоянно находящихся на диске или другом носителе данных, соединенном с или являющемся частью сервера HTTP, или объекты данных могут быть построены с помощью CGI сценария или другой динамически выполняемой программой, которая выполняется в ответ на запрос HTTP. Термины "файл" и "сегмент" использованы синонимично в этом документе, если иначе не определено. В случае HTTP сегмент можно рассмотреть как тело объекта ответа на запрос HTTP.
[0074] Термины "представление" и "элемент контента" использованы синонимично в этом документе. Во многих примерах представлением является аудио, видео или другое мультимедийное представление, которое имеет определенное время "проигрывания", но возможны другие изменения.
[0075] Термины "блок" и "фрагмент" используются синонимично в этом документе, если иначе не определено, и обычно относятся к наименьшей агрегации данных, которые индексированы. На основании доступной индексации клиент может запрашивать различные части фрагмента в различных запросах HTTP или может запрашивать один или более последовательных фрагментов или частей фрагментов в одном запросе HTTP. В случае, когда используются сегменты, основанные на формате файла мультимедиа на основе ISO, или сегменты, основанные на формате 3GP файла, фрагмент обычно относится к фрагменту кино, определенному как комбинация поля ('moof) заголовка фрагмента кино и поля ('mdat') данных мультимедиа.
[0076] Здесь, сеть, несущая данные, как предполагается, основана на пакетной передаче, чтобы упростить описание здесь, с признанием, что после прочтения этого раскрытия специалист в данной области техники может применить варианты осуществления настоящего изобретения, описанного здесь, к другим типам сетей передачи, таким как сети с непрерывным потоком битов.
[0077] Здесь, коды FEC, как предполагается, обеспечивают защиту против длинных и переменных времен доставки данных, чтобы упростить описание здесь, с признанием, что после прочтения этого раскрытия специалист в данной области техники может применить варианты осуществления настоящего изобретения к другим типам проблем передачи данных, таким как повреждения, из-за изменения бита данных. Например, без FEC, если последняя часть требуемого фрагмента прибывает намного позже или имеет высокую дисперсию в ее времени прибытия, чем предыдущие части фрагмента, то время переключения контента может быть большим и переменным, тогда как, используя FEC и параллельные запросы, только большинство данных, запрошенных для фрагмента, должны прибыть прежде, чем он сможет быть восстановлен, таким образом уменьшая время переключения контента и изменчивость во времени переключения контента. В этом описании можно предположить, что данные, которые должны быть закодированы (то есть, исходные данные), были разбиты на равной длины "символы", которые могут иметь любую длину (вплоть до единственного бита), но символы могут иметь различные длины для различных частей данных, например, различные размеры символа могут быть использованы для различных совокупностей данных.
[0078] В этом описании, чтобы упростить описания, предполагается, что FEC применяется к "блоку" или "фрагменту" данных один раз, то есть, "блок" является "исходным блоком" для целей кодирования и декодирования с FEC. Клиентское устройство может использовать индексацию сегментов, описанную здесь, чтобы помочь определить структуру исходного блока сегмента. Специалист в данной области техники может применить варианты осуществления настоящего изобретения к другим типам структур исходного блока, например, исходный блок может быть частью фрагмента или охватывать один или более фрагментов или частей фрагментов.
[0079] Коды FEC, рассматриваемые для использования с потоковой передачей с запросом блоков, являются обычно систематическими кодами FEC, то есть, исходные символы исходного блока могут быть включены в качестве части кодирования исходного блока, и таким образом исходные символы передаются. Как понятно специалисту в данной области техники, варианты осуществления, описанные здесь, применяются одинаково хорошо к кодам FEC, которые не являются систематическими. Систематический кодер FEC генерирует из исходного блока исходных символов некоторое количество исправленных символов, и комбинация из, по меньшей мере, некоторых исходных и исправленных символов являются закодированными символами, которые посылаются по каналу, представляя исходный блок. Некоторые коды FEC могут быть полезными для эффективного генерирования стольких многих исправленных символов, сколько необходимо, таких как "информационные добавочные коды" или "коды заполнения", и примеры этих кодов включают в себя "коды цепной реакции" и "многоступенчатые коды цепной реакции". Другие FEC коды, такие как коды Рида-Соломона, могут фактически генерировать только ограниченное число исправленных символов для каждого исходного блока.
[0080] Предполагается во многих из этих примеров, что клиент подсоединен к серверу мультимедиа или множеству серверов мультимедиа, и клиент запрашивает потоковое мультимедиа по каналу или множеству каналов от сервера мультимедиа или множества серверов мультимедиа. Однако, также возможны более сложные компоновки.
ПРИМЕРЫ ВЫГОД
[0081] При потоковой передаче с запросом блоков клиент мультимедиа поддерживает взаимосвязь между тактированием этих запросов блока и тактированием проигрывания мультимедиа пользователю. Эта модель может сохранить преимущества модели "загрузки", описанной выше, избегая некоторых из неудобств, которые происходят из обычного разъединения проигрывания мультимедиа от доставки данных. Модель потоковой передачи с запросом блоков использует механизмы управления скоростью передачи и потребления, доступные в транспортных протоколах, таких как TCP, чтобы гарантировать, что максимальная доступная полоса частот используется для данных мультимедиа. Дополнительно, подразделение представления мультимедиа на блоки позволяет выбрать каждый блок закодированных данных мультимедиа из ряда множественных доступных кодирований.
[0082] Этот выбор может быть основан на любом количестве критериев, включая соответствие скорости передачи данных мультимедиа доступной полосе частот, даже когда доступная полоса частот изменяется в течении времени, согласование разрешения мультимедиа или сложности декодирования со возможностями клиента или конфигурации, или согласование с пользовательским предпочтением, таким как языки. Выбор может также включать в себя загрузку и представление вспомогательных компонентов, таких как компоненты доступности, закрытый ввод субтитров, подзаголовки, видео с языком жестов, и т.д. Примеры существующих систем, использующих модель потоковой передачи с запросом блоков, включают в себя Move Networks (ТМ), Microsoft Smooth Streaming и Протокол потоковой передачи Apple iPhone (ТМ).
[0083] Обычно каждый блок данных мультимедиа может быть сохранен на сервере как индивидуальный файл, и затем протокол, такой как HTTP, используется совместно с программным обеспечением сервера HTTP, выполняемым на сервере, чтобы запрашивать файл как единицу. Как правило, клиенту предоставляются файлы метаданных, которые могут, например быть в формате на расширяемом языке разметки (XML) или в текстовом формате списка воспроизведения или в двоичном формате, которые описывают особенности представления мультимедиа, такие как доступные кодирования (например, требуемая полоса частот, разрешения, параметры кодирования, тип мультимедиа, язык), обычно называемые "представлениями" в этом документе, и способ, которым кодирования были разделены на блоки. Например, метаданные могут включать в себя Унифицированный указатель ресурса (URL) для каждого блока. Сами URL могут обеспечить схему, такую как имеющую предшествующую последовательность "http://", чтобы указать, что протоколом, который должен использоваться, чтобы получить доступ к зарегистрированному ресурсу, является HTTP. Другим примером является "ftp://", чтобы указать, что протоколом, который должен использоваться, является FTP.
[0084] В других системах, например, блоки мультимедиа могут быть построены "на-лету" сервером в ответ на запрос от клиента, который указывает часть представления мультимедиа, в то время, которое запрошено. Например, в случае HTTP со схемой "http://" выполнение запроса этого URL обеспечивает ответ на запрос, который содержит некоторые специфические данные в теле объекта этого ответа на запрос. Реализация в сети относительно того, как генерировать этот ответ на запрос, может быть весьма различной, в зависимости от реализации сервера, обслуживающего такие запросы.
[0085] Как правило, каждый блок может быть независимо декодируемым. Например, в случае видео мультимедиа, каждый блок может начаться с «начальной точки». В некоторых схемах кодирования начальные точки упоминаются как "точки произвольного доступа" или "RAPs", хотя не все RAP могут определяться как начальная точка. Аналогично, в других схемах кодирования начальная точка начинается в кадре "обновления независимых данных", или "IDR", в случае кодирования видео H.264, хотя не все IDRs могут определяться как начальная точка. Начальная точка является позицией в видео (или другом) мультимедиа, где декодер может начать декодирование, не требуя никаких данных о предшествующих кадрах или данных или выборок, как может иметь место, когда кадр или выборка, которая декодируется, были закодированы не автономным способом, но как, например, разность между текущим кадром и предшествующим кадром.
[0086] Проблемой в таких системах может быть возможность начать проигрывание потока, например, декодируя и воспроизводя принятые аудио и видео потоки, используя персональный компьютер, и отображая видео на экране компьютера и проигрывая аудио через встроенные громкоговорители, или в качестве другого примера, декодирование и воспроизведение принятых аудио и видео потоков, используя телевизионную приставку и отображая видео на телевизионном устройстве отображения и поигрывая аудио через стерео систему. Первичной проблемой может быть необходимость минимизировать задержку между тем, когда пользователь решает просматривать новый контент, доставленный как поток, и предпринимает действие, которое выражает это решение, например, пользователь, нажимает на ссылку в окне браузера или на кнопку проигрывания устройства дистанционного управления, и когда контент начинает отображаться на экране пользователя, в дальнейшем названном "временем переключения контента". К каждой из этих проблем могут относиться элементы расширенной системы, описанной здесь.
[0087] Примером переключения контента является то, когда пользователь просматривает первый контент, доставленный посредством первого потока, и затем пользователь решает смотреть второй контент, доставленный посредством второго потока, и начинает действие, чтобы начать смотреть второй контент. Второй поток может быть послан от того же самого набора или другого набора серверов, как и первый поток. Другим примером переключения контента является то, когда пользователь посещает вебсайт и решает начать смотреть первый контент, доставленный посредством первого потока, нажимая на ссылку в пределах окна браузера. Аналогичным образом, пользователь может решить начать проигрывать контент не с начала, а с некоторого времени в пределах потока. Пользователь указывает на своем клиентском устройстве, чтобы искать на временную позицию, и пользователь может ожидать, что выбранное время будет воспроизведено мгновенно. Уменьшение времени переключения контента важно для просмотра видео, чтобы обеспечить пользователям, воспринимать высококачественный быстрый просмотр контента, посредством поиска и выборки широкого диапазона доступных контентов.
[0088] Недавно стало обычной практикой рассматривать использование кодов с прямой коррекцией ошибок (FEC) для защиты потокового мультимедиа во время передачи. Когда послан по сети пакетной передачи, примеры которой включают в себя Интернет и беспроводные сети, такие как стандартизированные группами, такими как 3GPP, 3GPP2 и DVB, исходный поток помещается в пакеты, когда он генерируется, или сделан доступным, и таким образом пакеты могут быть использованы, чтобы переносить исходный поток или поток контента в порядке, в котором он генерируется, или сделан доступным, на приемники.
[0089] В типичном применении кодов FEC к этим типам сценариев, кодер может использовать код FEC в создании исправленных пакетов, которые затем посылают в дополнение к первоначальным исходным пакетам, содержащим исходный поток. Исправленные пакеты имеют то свойство, что когда происходит потеря исходного пакета, принятые исправленные пакеты могут быть использованы, чтобы восстановить данные, содержавшиеся в потерянных исходных пакетах. Исправленные пакеты могут быть использованы, чтобы восстановить контент потерянных исходных пакетов, которые потеряны полностью, но могут также использоваться, чтобы восстановить из имеющихся частичных потерь пакета или полностью принятые исправленные пакеты или даже частично принятые исправленные пакеты. Таким образом, полностью или частично принятые исправленные пакеты могут быть использованы, чтобы восстановить полностью или частично потерянные исходные пакеты.
[0090] В еще других примерах другие типы повреждения могут произойти с посланными данными, например, значения битов могут переключиться в противоположное состояние, и таким образом исправленные пакеты могут быть использованы, чтобы исправить такое повреждение и обеспечить как можно более точное восстановление исходных пакетов. В других примерах исходный поток не обязательно посылают в дискретных пакетах, но вместо этого может быть послан, например, как непрерывный битовый поток.
[0091] Есть много примеров кодов FEC, которые могут быть использованы, чтобы обеспечить защиту исходного потока. Коды Рида-Соломона являются хорошо известными кодами для коррекции ошибок и стираний в системах связи. Для коррекции стираний, например, в сетях пакетных данных, известная эффективная реализация кодов Рида-Соломона использует матрицы Каучи (Cauchy) или Вандермонда (Vandermonde), как описано в L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", ", Computer Communication Review, 27(2):24-36 (апрель 1997) (в дальнейшем "Rizzo") и Bloemer, et al, "An XOR-Based Erasure-Resilient Coding Scheme", Technical Report TR-95-48, International Computer Science Institute, Berkeley, California (1995) (в дальнейшем "XOR-Reed-Solomon") или в другом месте.
[0092] Другие примеры кодов FEC включают в себя коды LDPC, коды цепной реакции, такие как описаны в Luby I и коды многоступенчатой цепной реакции, такие как в Shokrollahi I.
[0093] Примеры процесса FEC декодирования для вариантов кодов Рида-Соломона, описаны в Rizzo и XOR-Reed-Solomon. В этих примерах декодирование может быть применено после того, как были приняты достаточные исходные и исправленные пакеты данных. Процесс декодирования может быть в вычислительном отношении интенсивным и, в зависимости от доступных ресурсов центрального процессора, он может занять большое количество времени для завершения относительно отрезка времени, занятого посредством мультимедиа в блоке. Приемник может учесть этот отрезок времени, требуемый для декодирования, при вычислении задержки, требуемой между началом приема потока мультимедиа и проигрыванием мультимедиа. Эта задержка из-за декодирования воспринимается пользователем как задержка между своим запросом конкретного потока мультимедиа и началом воспроизведения. Таким образом, желательно минимизировать эту задержку.
[0094] Во многих применениях пакеты могут быть дополнительно подразделены на символы, к которым применяется процесс FEC. Пакет может содержать один или более символов (или меньше чем один символ, но обычно символы не разделены на группы пакетов, если только не известно, что условия возникновения ошибок среди групп пакетов высоко коррелированы). Символ может иметь любой размер, но часто размер символа самое большее равен размеру пакета. Исходные символы являются символами, которые кодируют данные, которые должны быть переданы. Исправленные символы являются символами, генерируемыми из исходных символов, прямо или косвенно которые предназначены в дополнение к исходным символам (то есть, данные, которые должны быть переданы, могут быть полностью восстановлены, если все исходные символы доступны, и ни один из исправленных символов не доступен).
[0095] Некоторые коды FEC могут быть основаны на блоке в том, что операции кодирования зависят от символа(ов), которые находятся в блоке и могут быть независимыми от символов не в этом блоке. С основанным на блоках кодированием кодер FEC может генерировать исправленные символы для блока из исходных символов в этом блоке, затем переходить дальше к следующему блоку, и нет необходимости обращаться к исходным символам, отличным от таковых для текущего закодированного блока. При передаче исходный блок, содержащий исходные символы, может быть представлен закодированным блоком, содержащим закодированные символы (которые могут быть некоторыми исходными символами, некоторыми исправленными символами, или обоими). При наличии исправленных символов не все из исходных символов требуются в каждом закодированном блоке.
[0096] Для некоторых FEC кодов, особенно Кодов Рида-Соломона, время кодирования и декодирования может стать непрактичным, когда количество закодированных символов в исходном блоке растет. Таким образом, на практике, часто есть практическая верхняя граница (255 является приблизительным практическим пределом для некоторых применений) в отношении общего количества закодированных символов, которые могут быть сгенерированы для каждого исходного блока, особенно в типичном случае, когда процесс кодирования или декодирования по Риду-Соломону выполняется специализированным аппаратным обеспечением, например, процессы MPE-FEC, которые используют коды Рида-Соломона, включенные как часть стандарта DVB-H для того, чтобы защитить потоки от потерь пакетов, реализованы в специализированном аппаратном обеспечении в сотовом телефоне, который ограничен 255-ю полными закодированными по Риду-Соломону символами на каждый исходный блок. Так как символы часто обязаны быть помещенными в отдельные полезные данные пакета, это устанавливает практическую верхнюю границу в отношении максимальной длины исходного закодированного блока. Например, если полезные данные пакета ограничены 1024 байтами или меньше, и каждый пакет несет один закодированный символ, то закодированный исходный блок может быть самое большее 255 килобайт, и это также, конечно, является верхней границей размера в отношении самого исходного блока.
[0097] Другие проблемы, такие как способность, декодировать исходные блоки достаточно быстро, чтобы сохранить исходную скорость потоковой передачи, чтобы минимизировать время ожидания декодирования, внесенное декодированием FEC, и использовать только малую часть доступного центрального процессора на устройстве приема в любой точке во времени во время декодирования FEC, решаются с помощью элементов, описанных здесь.
[0098] Необходимость обеспечить устойчивое и масштабируемое решение доставки посредством потоковой передачи, которое позволяет компонентам системы давать сбой, неблагоприятно не затрагивая качество потоков, доставленных приемникам.
[0099] Система потоковой передачи с запросом блоков должна поддерживать изменения в структуре или метаданных представления, например, изменения в количестве кодирований доступного мультимедиа или изменения в параметрах кодирований мультимедиа, таких как скорость передачи в битах, разрешение, соотношение сторон изображения, кодеки или кодек аудио или видео, или параметрах изменений в других метаданных, таких как URL, ассоциированных с файлами контента. Такие изменения могут требоваться по ряду причин, включая редактирование вместе контента из различных источников, таких как реклама или различные сегменты большего представления, модификация URL, или другие параметры, которые становятся необходимыми в результате изменений в обслуживающей инфраструктуре, например, из-за изменений конфигурации, отказов оборудования или восстановления из отказов оборудования или других причин.
[0100] Существуют способы, в которых представление может быть управляемым посредством непрерывного обновленного файла списка воспроизведения. Так как этот файл непрерывно обновляется, то, по меньшей мере, некоторые из изменений, описанных выше, могут быть сделаны в этих обновлениях. Недостатком обычного способа является то, что клиентские устройства должны непрерывно извлекать, также называемое "опросом", файл списка воспроизведения, помещать нагрузку в обслуживающую инфраструктуру, и что этот файл может не быть кэширован дольше, чем интервал обновления, делая задачу обслуживания инфраструктуры намного более трудной. На это направлены элементы здесь, так чтобы обновления вида, описанного выше, были предоставлены без необходимости в непрерывном опросе клиентами в поисках файла метаданных.
[0101] Другой проблемой, особенно в услугах в реальном времени, обычно известной из распределения вещания, является нехватка способности у пользователя, чтобы просмотреть контент, который был передан, раньше, чем время, когда пользователь присоединился к программе. Как правило, локальная персональная регистрация потребляет ненужное локальное запоминающее устройство, или является невозможной, поскольку клиент не был настроен на программу или запрещен по правилам защиты контента. Регистрация в сети и сдвинутый во времени просмотр является предпочтительным, но требуют индивидуальных подсоединений пользователя к серверу и отдельному протоколу и инфраструктуре доставки, чем услуги в реальном времени, приводя к дублированной инфраструктуре и существенным серверным затратам. Этому также посвящены элементы, описанные здесь.
КРАТКИЙ ОБЗОР СИСТЕМЫ
[0102] Один вариант осуществления изобретения описан со ссылками на Фиг. 1, которая показывает упрощенную диаграмму системы потоковой передачи с запросом блоков, воплощающей изобретение.
[0103] На Фиг. 1 проиллюстрирована система 100 потоковой передачи блоков, содержащая инфраструктуру 101 обслуживания блоков ("BSI"), в свою очередь содержащую систему 103 потребления для того, чтобы потреблять контент 102, подготавливая этот контент и упаковывая его для обслуживания сервером 104 потоковой передачи HTTP посредством сохранения его в хранилище 110 контента, которое доступно и для системы 103 потребления и для сервера 104 потоковой передачи HTTP. Как показано, система 100 может также включать в себя кэш 106 HTTP. Во время работы клиент 108, такой как клиент потоковой передачи HTTP, посылает запросы 112 в сервер 104 потоковой передачи HTTP и принимает ответы 114 от сервера 104 потоковой передачи HTTP или кэша 106 HTTP. В каждом случае элементы, показанные на Фиг. 1, могут быть реализованы, по меньшей мере, частично, в программном обеспечении, содержащем программный код, который выполняется на процессоре или другой электронике.
[0104] Контент может содержать кинофильмы, аудио, 2D простое видео, видео 3D, другие типы видео, изображений, рассчитанный текст, тактированные метаданные или подобное. Некоторый контент может включать в себя данные, которые должны быть представлены или потреблены тактированным образом, например, данные для представления вспомогательной информации (идентификационная информация станции, реклама, биржевые цены, Flash(ТМ) - последовательности, и т.д.) вместе с другим проигрываемым мультимедиа. Другие гибридные представления могут также использоваться, которые комбинируют другое мультимедиа и/или находятся вне просто аудио и видео.
[0105] Как проиллюстрировано на Фиг. 2, блоки мультимедиа могут быть сохранены в инфраструктуре 101(1) обслуживания блоков, которая может быть, например, сервером HTTP, устройством сети доставки контента, прокси - HTTP, прокси - FTP или сервером, или некоторым другим сервером или системой мультимедиа. Инфраструктура 101(1) обслуживания блоков связана с сетью 122, которая может быть, например, сетью на основе Интернет-протокола ("IP"), такой как Интернет. Клиент системы потоковой передачи с запросом блоков показан имеющим шесть функциональных компонентов, а именно, селектор 123 блоков, снабженный метаданными, описанными выше, и выполняющий функцию выбора блоков или частичных блоков, которые должны быть запрошены из числа множества доступных блоков, указанных метаданными, запросчик 124 блоков, который принимает инструкции запроса от селектора 123 блоков и выполняет операции, необходимые, чтобы послать запрос об указанном блоке, частях блока, или множественных блоках на инфраструктуру 101(1) обслуживания блоков по сети 122 и принять данные, содержащие блок в ответ, так же как буфер 125 блоков, монитор 126 буфера, декодер 127 мультимедиа и один или более преобразователей 128 мультимедиа, которые облегчают потребление мультимедиа.
[0106] Данные блока, принятые запросчиком 124 блоков, передают для временного хранения в буфер 125 блоков, который сохраняет данные мультимедиа. Альтернативно, принятые данные блоков могут храниться непосредственно в буфере 125 блоков, как проиллюстрировано на Фиг. 1. Декодер 127 мультимедиа снабжается данными мультимедиа буфером 125 блоков и выполняет такие преобразования над этими данными, как необходимо, чтобы обеспечить подходящий ввод в преобразователи 128 мультимедиа, которые воспроизводят мультимедиа в форме, подходящей для пользователя или другого потребления. Примеры преобразователей мультимедиа включают в себя устройства визуального отображения, такие, которые могут быть найдены в мобильных телефонах, компьютерных системах или телевизорах, и могут также включать в себя устройства воспроизведения аудио, такие как громкоговорители или наушники.
[0107] Примером декодера мультимедиа может быть функция, которая преобразовывает данные в формат, описанный в стандарте H.264 кодирования видео, в аналоговые или цифровые представления видео кадров, такой как пиксельная карта YUV-формата с ассоциированными отметками времени представления для каждого кадра или выборки.
[0108] Монитор 126 буфера принимает информацию относительно содержимого буфера 125 блоков и на основании этой информации и, возможно другой информации, обеспечивает ввод в селектор 123 блоков, который используется, чтобы определить выбор блоков для запроса, как описано здесь.
[0109] В терминологии, используемой здесь, каждый блок имеет "время проигрывания" или "продолжительность", которое представляет величину времени, которое оно может потребовать для приемника, чтобы проигрывать мультимедиа, включенное в этот блок при нормальной скорости. В некоторых случаях проигрывание мультимедиа в пределах блока может зависеть от того, приняты ли данные от предыдущих блоков. В редких случаях проигрывание некоторого мультимедиа в блоке может зависеть от последующего блока, в этом случае проигрывание для этого блока определяется относительно мультимедиа, которое может быть проиграно в пределах этого блока без ссылки на последующий блок, и время проигрывания для последующего блока увеличивается на время проигрывания мультимедиа в этом блоке, который может проигрываться только после приема последующего блока. Так как включение мультимедиа в блок, который зависит от последующих блоков, является редким случаем, в оставшейся части настоящего раскрытия предполагается, что мультимедиа в одном блоке не зависит от последующих блоков, но следует отметить, что специалистам ясно, что этот вариант может быть легко добавлен к вариантам осуществления, описанным ниже.
[0110] Приемник может иметь средства управления, такие как "пауза", "быстрый переход вперед", "обратный переход", и т.д., которые могут привести к блоку, потребляемому посредством проигрывания с различной скоростью передачи, но если приемник может получить и декодировать каждую последовательную последовательность блоков в совокупное время, равное или меньшее, чем их агрегированное время проигрывания, исключая последний блок в последовательности, то приемник может представить мультимедиа пользователю без остановки. В некоторых описаниях здесь, конкретная позиция в потоке мультимедиа упоминается как конкретное "время" в мультимедиа, соответствующее времени, которое может пройти между началом проигрывания мультимедиа и временим, когда достигнута конкретная позиция в видео потоке. Время или позиция в потоке мультимедиа является обычным понятием. Например, когда видео поток содержит 24 кадра в секунду, первый кадр, можно сказать, имеет позицию или время t=0,0 секунд, и можно сказать, что 241-й кадр имеет позицию или время t=10,0 секунд. Естественно, в основанном на кадрах видео потоке, позиции или время не должны быть непрерывными, когда каждый из битов в потоке от первого бита 241-ого кадра до непосредственно перед первым битом 242-ого кадра могут все иметь одно и то же значение времени.
[0111] Принимая вышеупомянутую терминологию, система потоковой передачи с запросом блоков (BRSS) содержит один или более клиентов, которые делают запросы к одному или более серверам контента (например, серверам HTTP, серверам FTP, и т.д.). Система потребления содержит один или более процессоров потребления, в которой процессор потребления принимает контент (в реальном времени или нет), обрабатывает контент для использования BRSS и сохраняет его в запоминающем устройстве, доступном для серверов контента, возможно также вместе с метаданными, генерируемыми процессором потребления.
[0112] BRSS также может содержать кэши контента, которые взаимодействуют с серверами контента. Серверы контента и кэши контента могут быть обычными серверами HTTP и кэшами HTTP, которые принимают запросы файлов или сегментов в форме запросов HTTP, которые включают в себя URL, и могут также включать в себя диапазон байтов, чтобы запросить менее чем весь файл или сегмент, указанный посредством URL. Клиенты могут включать в себя обычного клиента HTTP, который делает запросы к серверам HTTP и оперирует с ответами на эти запросы, где клиент HTTP управляется новой клиентской системой, которая формулирует запросы, передает их клиенту HTTP, получает ответы от клиента HTTP и обрабатывает их (или сохраняет, преобразовывает и т.д.), чтобы предоставить их блоку воспроизведения представления для проигрывания клиентским устройством. Как правило, клиентская система не знает заранее, какое мультимедиа должно быть необходимо (поскольку потребности могут зависеть от пользовательского ввода, изменений в пользовательском вводе, и т.д.), таким образом, это есть, как говорят, система "потоковой передачи", в которой "потребляется" мультимедиа, как только оно принято, или вскоре после этого. В результате, задержки ответа и ограничения полосы частот могут вызвать задержки представления, такие как появление паузы, в представлении, поскольку поток захватывается там, где пользователь потребляет представление.
[0113] Чтобы обеспечить представление, которое воспринимается с хорошим качеством, многие подробности могут быть реализованы в BRSS, или в клиентском оконечном устройстве, на конце потребления, или в обоих. В некоторых случаях детали, которые реализованы, сделаны с учетом и для того, чтобы иметь дело с, интерфейсом клиент-сервер в сети. В некоторых вариантах осуществления и клиентская система, и система потребления знают об усовершенствовании, тогда как в других вариантах осуществления только одна сторона знает об усовершенствовании. В таких случаях вся система извлекает выгоду из усовершенствования даже притом, что одна сторона не знает об этом, в то время как в других выгода только накапливается, если обе стороны знают об этом, но когда одна сторона не знает, она все же работает без сбоев.
[0114] Как проиллюстрировано на Фиг. 3, система потребления может быть реализована как комбинация компонентов аппаратного обеспечения и программного обеспечения, согласно различным вариантам осуществления. Система потребления может содержать ряд инструкций, которые могут быть выполнены, чтобы заставить систему выполнять любой один или более способов, описанных здесь. Система может быть реализована как конкретная машина в форме компьютера. Система может быть серверным компьютером, персональным компьютером (PC), или любой системой, способной к выполнению ряда инструкций (последовательных или иных), которые определяют действия, которые должны быть предприняты этой системой. Далее, в то время как иллюстрирована только единственная система, термин "система" должен также быть принят, чтобы включать в себя любую коллекцию систем, которые индивидуально или совместно выполняют набор (или множественные наборы) инструкций, чтобы выполнить любой один или более способов, описанных здесь.
[0115] Система потребления может включать в себя процессор 302 потребления (например, центральный процессор (CPU)), память 304, которая может хранить программный код во время выполнения, и дисковое запоминающее устройство 306, все из которых обмениваются друг с другом через шину 300. Система может далее включать в себя блок 308 отображения видео (например, жидкокристаллический дисплей (LCD) или электронно-лучевая трубка (CRT)). Система также может включать в себя алфавитно-цифровое устройство ввода 310 (например, клавиатуру), и устройство 312 сетевого интерфейса для приема источника контента и предоставить хранилище контента.
[0116] Блок 306 дискового запоминающего устройство может включать в себя машиносчитываемый носитель, на котором может быть сохранен один или более наборов инструкций (например, программное обеспечение), воплощающих любые один или более способов или функций, описанных здесь. Инструкции могут также постоянно находиться, полностью или, по меньшей мере, частично, в памяти 304 и/или в процессоре 302 потребления во время его выполнения системой, с памятью 304 и процессором 302 потребления, также составляющими машино-считываемые носители.
[0117] Как проиллюстрировано на Фиг. 4, клиентская система может быть реализована как комбинация компонентов аппаратного обеспечения и программного обеспечения, согласно различным вариантам осуществления. Клиентская система может содержать ряд инструкций, которые могут быть выполнены, чтобы заставить систему выполнять любые один или более способов, описанных здесь. Система может быть реализована как конкретная машина в форме компьютера. Система может быть серверным компьютером, персональным компьютером (PC), или любой системой, способной к выполнению ряда инструкций (последовательных или иначе), которые задают действия, которые должны быть предприняты этой системой. Далее, в то время как иллюстрирована только единственная система, термин "система" должен также быть принят, чтобы включать в себя любую коллекцию систем, которые индивидуально или совместно выполняют набор (или множественные наборы) инструкций, чтобы выполнить любой один или более способов, описанных здесь.
[0118] Клиентская система может включать в себя процессор 402 клиента (например, центральный процессор (CPU)), память 404, которая может хранить программный код во время выполнения, и дисковое запоминающее устройство 406, все из которых обмениваются друг с другом через шину 400. Система может также включать в себя блок 408 отображения видео (например, жидкокристаллический дисплей (LCD) или электронно-лучевая трубка (CRT)). Система также может включать в себя алфавитно-цифровое устройство ввода 410 (например, клавиатуру), и устройство 412 сетевого интерфейса для того, чтобы посылать запросы и принимать ответы.
[0119] Блок 406 дискового запоминающего устройство может включать в себя машиносчитываемый носитель, на котором может быть сохранен один или более наборов инструкций (например, программное обеспечение), воплощающих любые один или более способов или функций, описанных здесь. Инструкции могут также постоянно находиться, полностью или, по меньшей мере, частично, в памяти 404 и/или в процессора 402 клиента во время его выполнения системой, с памятью 404 и процессором 402 клиента также составляющими машиносчитываемые носители.
ИСПОЛЬЗОВАНИЕ ФОРМАТОВ ФАЙЛОВ 3GPP
[0120] Формат файла 3GPP или любой другой файл, основанный на формате файла мультимедиа, на базе ISO, таком как формат файла MP4 или формат файла 3GPP2, могут быть использованы как формат контейнера для потоковой передачи HTTP со следующими признаками. Индекс сегментов может быть включен в каждый сегмент, чтобы сигнализировать смещения времени и диапазоны байтов таким образом, что клиент может загрузить соответствующие части файлов или сегментов мультимедиа как требуется. Глобальное тактирование представления всего представления мультимедиа и локальное тактирование в пределах каждого файла 3GP или сегмента мультимедиа могут быть точно выровнены. Дорожки в пределах одного файла 3GP или сегмента мультимедиа могут быть точно выровнены. Дорожки по представлениям также могут быть выровнены посредством назначения каждой из них шкале глобального времени таким образом, что переключение в представлении может быть плавным и объединенное представление компонентов мультимедиа в различных представлениях может быть синхронным.
[0121] Формат файла может содержать профиль для адаптивной потоковой передачи со следующими свойствами. Все данные кино могут содержаться во фрагментах кино - поле "moov" может не содержать информации выборки. Данные выборки аудио и видео могут перемежаться, с аналогичными требованиями относительно профиля прогрессивной загрузки, как определено в TS26.244. Поле "moov" может быть помещено в начале файла с последующими данными смещения фрагмента, также называемыми индексом сегмента, содержащим информацию смещения во времени и диапазоны байтов (в байтах) для каждого фрагмента или, по меньшей мере, поднаборов фрагментов в содержащемся сегменте.
[0122] Для Описания Представления Мультимедиа также может быть, возможно, сослаться на файлы, которые следуют за существующим профилем Прогрессивной Загрузки. В этом случае клиент может использовать Описание Представления Мультимедиа, просто чтобы выбрать соответствующую альтернативную версию из множественных доступных версий. Клиенты могут также использовать запросы получения частичного HTTP с файлами, совместимыми с профилем Прогрессивной Загрузки, чтобы запрашивать поднаборы каждой альтернативной версии и таким образом реализовывать менее эффективную форму адаптивной потоковой передачи. В этом случае различные представления, содержащие мультимедиа в профиле прогрессивной загрузки, могут все еще придерживаться общей шкалы глобального времени, чтобы разрешить плавное переключение между представлениями.
КРАТКИЙ ОБЗОР УСОВЕРШЕНСТВОВАННЫХ СПОСОБОВ
[0123] В следующих секциях описаны способы для улучшенных систем потоковой передачи с запросом блоков. Должно быть понятно, что некоторые из этих усовершенствований могут быть использованы с или без других этих усовершенствований, в зависимости от потребностей приложения. Во время обычной работы приемник делает запросы сервера или другого передатчика о конкретных блоках или частях блоков данных. Файлы, также называемые сегментами, могут содержать множественные блоки и быть ассоциированы с одним представлением (воспроизведением) представления мультимедиа.
[0124] Предпочтительно, генерируется информация индексации, также называемая "индексация сегментов" или "карта сегментов", которая обеспечивает преобразование из времен проигрывания или декодирования в смещения в байтах соответствующих блоков или фрагментов в пределах сегмента. Эта индексация сегментов может быть включена в пределы сегмента, обычно в начале сегмента (по меньшей мере, часть карты сегментов находится в начале), и является часто малой. Индекс сегментов также может быть предоставлен в отдельном индексном сегменте или файле. Особенно в случаях, когда индекс сегментов содержится в этом сегменте, приемник может загрузить некоторую часть или всю эту карту сегментов быстро и впоследствии использовать ее, чтобы определить преобразование между временными смещениями и соответствующими байтовыми позициями фрагментов, ассоциированных с этими временными смещениями в пределах файла.
[0125] Приемник может использовать смещение в байтах, чтобы запросить данные от фрагментов, ассоциированных с конкретными временными смещениями, не имея необходимость загружать все данные, ассоциированные с другими фрагментами, не ассоциированными с временными смещениями, представляющими интерес. Таким образом, карта сегментов или индексация сегментов могут значительно улучшить способность приемника в непосредственном доступе к частям сегмента, которые являются релевантными текущим временным смещениям, представляющим интерес, с выгодами, включающими улучшенные времена переключения контента, способность быстро изменяться от одного представления к другому, когда условия сети изменяются, и уменьшенный расход сетевых ресурсов, загружающих мультимедиа, которое не проигрывается в приемнике.
[0126] В случае, когда рассматривают переключение от одного представления (упомянутого здесь как представление "переключение-от") к другому представлению (упомянутому здесь как представление "переключение-к"), индекс сегментов может также использоваться, чтобы идентифицировать начальное время точки произвольного доступа в представлении переключение-к, чтобы идентифицировать количество данных, которые должны быть запрошены в представлении переключение-от, чтобы гарантировать, что плавное переключение разрешено в смысле, что мультимедиа в представлении переключение-от загружается вплоть до времени представления таким образом, что проигрывание представления переключение-к может начаться легко с точки произвольного доступа.
[0127] Эти блоки представляют сегменты видео мультимедиа или другого мультимедиа, в которой запрашивающий приемник нуждается, чтобы генерировать выходной сигнал для пользователя приемника. Приемник мультимедиа может быть клиентским устройством, например, когда приемник принимает контент от сервера, который передает контент. Примеры включают в себя телевизионные приставки, компьютеры, игровые пульты, специально оборудованные телевизоры, переносные устройства, специально оборудованные мобильные телефоны, или другие клиентские приемники.
[0128] Множество усовершенствованных способов управления буфером описаны здесь. Например, способ управления буфером позволяет клиентам запрашивать блоки мультимедиа самого высокого качества, которые могут быть приняты вовремя, чтобы быть проиграны непрерывно. Признак переменного размера блока улучшает эффективность сжатия. Способность иметь множественные соединения для передачи блоков на запрашивающее устройство, в то же время, ограничивая частоту запросов, обеспечивает улучшенную производительность передачи. Частично принятые блоки данных могут быть использованы, чтобы продолжить представление мультимедиа. Соединение может быть повторно используемым для множественных блоков, не имея необходимости обновлять соединение в начале конкретного набора блоков. Постоянство в выборе серверов из числа множественных возможных серверов множественными клиентами улучшается, что уменьшает частоту удваивания контента в соседних серверах и повышает вероятность, что сервер содержит весь файл. Клиенты могут запросить блоки мультимедиа на основании метаданных (таких как доступные кодирования мультимедиа), которые внедрены в URL для файлов, содержащих блоки мультимедиа. Система может предусмотреть вычисление и минимизацию величины требуемого времени буферизации прежде, чем проигрывание контента сможет начаться, не подвергаясь последующим паузам при проигрывании мультимедиа. Доступная полоса частот может быть совместно использована среди множественных блоков мультимедиа, отрегулированной, когда подходит время проигрывания каждого блока так, чтобы в случае необходимости большая доля доступной полосы частот была назначена блоку с самым близким временем проигрывания.
[0129] Потоковая передача HTTP может использовать метаданные. Метаданные уровня представления включают в себя, например, длительность потока, доступные кодирования (скорости передачи в битах, кодеки, пространственные разрешения, частота кадров, язык, типы мультимедиа), указатели на метаданные потока для каждого кодирования, и защиту контента (информацию цифрового управления правами (DRM)). Метаданные потока могут быть указателем URL для файлов сегмента.
[0130] Метаданные сегмента могут включать в себя диапазон в байтах в зависимости от информации времени для запросов в пределах сегмента и идентификационную информацию Точек Произвольного доступа (RAPs) или других точек поиска, где некоторая или вся эта информация может быть частью индексации сегментов или карты сегмента.
[0131] Потоки могут содержать множественные кодирования одного и того же контента. Каждое кодирование может быть, затем разбито в сегменты, где каждый сегмент соответствует блоку хранения или файлу. В случае HTTP сегментом обычно является ресурс, на который можно сослаться посредством URL, и запрос таких URL приводит к получению сегмента в качестве тела объекта сообщения ответа на запрос. Сегменты могут содержать множественные группы картинок (GoPs). Каждая GoP может также содержать множественные фрагменты, где индексация сегментов предоставляет информацию времени/смещения в байтах для каждого фрагмента, то есть, блоком индексации является фрагмент.
[0132] Фрагменты или части фрагментов могут быть запрошены через параллельные соединения TCP, чтобы увеличить пропускную способность. Это может смягчить проблемы, которые возникают при совместном использовании соединения на линии связи с «узким местом» или когда соединения потеряны из-за перегрузки, таким образом, увеличивая полную скорость и надежность доставки, что может существенно повысить скорость и надежность времени переключения контента. Полоса частот может быть заменена на время ожидания посредством перезапроса, но необходимо позаботиться, чтобы избежать делать запросы слишком далеко в будущее, что может увеличить риск зависания.
[0133] Множественные запросы сегментов на одном и том же сервере могут быть конвейеризованы (делая следующий запрос прежде, чем текущий запрос завершен), чтобы избежать повторяющихся задержек запуска TCP. Запросы последовательных фрагментов могут быть агрегированы в один запрос.
[0134] Некоторые CDNs предпочитают большие файлы и могут вызвать фоновые выборки всего файла из исходного сервера, сначала просматривая запрос диапазона. Большинство CDNs, однако, будет обслуживать запросы диапазона из кэша, если данные будут доступны. Может поэтому быть, выгодно иметь некоторую часть клиентских запросов целого файла сегмента. Эти запросы могут позже быть отменены в случае необходимости.
[0135] Действительные точки переключения могут быть точками установки, в частности RAPs, например, в целевом потоке. Различные реализации возможны, например, фиксированные структуры GoP или выравнивание точек RAP по потокам (на основании начала мультимедиа или на основании групп GoP).
[0136] В одном варианте осуществления сегменты и группы GoP могут быть выровнены по потокам с различной скоростью передачи. В этом варианте осуществления группы GoP могут иметь переменный размер и могут содержать множественные фрагменты, но фрагменты не выровнены между потоками с различной скоростью передачи.
[0137] В некоторых вариантах осуществления избыточность файла может использоваться для усовершенствования. В этих вариантах осуществления код стирания применяется к каждому фрагменту, чтобы генерировать избыточные версии данных. Предпочтительно, исходное форматирование не изменяется из-за использования FEC, и дополнительные сегменты исправления, например, в качестве зависимого представления первоначального представления, содержащие данные исправления FEC, генерируются и делаются доступными в качестве дополнительного этапа в системе потребления. Клиент, который в состоянии восстановить фрагмент, используя только исходные данные для этого фрагмента, может только запросить исходные данные для этого фрагмента в пределах сегмента от серверов. Если серверы недоступны, или соединение с серверами являются медленными, что может быть определено или прежде или после запроса исходных данных, дополнительные данные исправления могут быть запрошены для фрагмента из исправленного сегмента, что уменьшает время, чтобы надежно доставить достаточно данных, чтобы восстановить фрагмент, возможно используя декодирование FEC, чтобы использовать комбинацию принятых исходных данных и данных исправления, чтобы восстановить исходные данные фрагмента. Кроме того, дополнительные данные исправления могут быть запрошены, чтобы разрешить восстановление фрагмента, если фрагмент становится срочным, то есть, его время проигрывания приближается, что увеличивает совместное использование данных для этого фрагмента на линии связи, но является более эффективным, чем закрытие других соединений на линии связи, чтобы освободить полосу частот. Это может также смягчить риск зависания от использования параллельных соединений.
[0138] Формат фрагмента может быть сохраненным потоком пакетов транспортного протокола в реальном времени (RTP) с аудио/видео синхронизацией, достигнутой через транспортный протокол управления в реальном времени RTCP.
[0139] Формат сегмента также может быть сохраненным потоком пакетов MPEG-2 TS, с аудио/видео синхронизацией, достигнутой с помощью внутреннего тактирования MPEG-2 TS.
ИСПОЛЬЗОВАНИЕ СОЗДАНИЯ БЛОКОВ И/ИЛИ СИГНАЛИЗАЦИИ, ЧТОБЫ СДЕЛАТЬ БОЛЕЕ ЭФФЕКТИВНУЮ ПОТОКОВУЮ ПЕРЕДАЧУ
[0140] Многие признаки могут быть использованы или не использованы в системе потоковой передачи с запросом блоков, чтобы предусмотреть улучшенную производительность. Производительность может относиться к способности проигрывать представление без остановки, получению данных мультимедиа в пределах ограничений полосы пропускания, и/или выполнению этого в пределах ограниченных ресурсов процессора в клиенте, сервере и/или системе потребления. Некоторые из этих признаков описаны ниже.
ИНДЕКСАЦИЯ В ПРЕДЕЛАХ СЕГМЕНТОВ
[0141] Чтобы сформулировать частичные запросы GET Фрагментов Кино, клиент может быть информирован о смещении в байтах и начальном времени во время декодирования или представления всех компонентов мультимедиа, содержащихся во фрагментах в пределах файла или сегмента, а также какие фрагменты начинают или содержат Точки Произвольного доступа (и таким образом являются подходящими, чтобы использоваться как точки переключения между альтернативными представлениями), при этом эта информация часто упоминается как карта индексации или карта сегментов. Начальное время во время декодирования или представления может быть выражено непосредственно или может быть выражено как дельты (разности) относительно опорного времени.
[0142] Эта информация индексации времени и смещения в байтах может потребовать, по меньшей мере, 8 байт данных на каждый фрагмент кино. В качестве примера, для двухчасового кино, содержащегося в пределах единственного файла, с фрагментами кино по 500 мс, это будет в общей сложности приблизительно 112 килобайт данных. Загрузка всех этих данных при начале представления может привести к существенной дополнительной задержке запуска. Однако эти данные времени и смещения в байтах могут быть закодированы иерархически, так чтобы клиент мог быстро найти маленький кусок данных времени и смещения в байтах, релевантный к точке в представлении, с которой он желает начать. Эта информация также может быть распределена в пределах сегмента таким образом, что некоторое уточнение индекса сегментов может быть расположено перемежаемым с данными мультимедиа образом.
[0143] Следует отметить, что если представление сегментировано во времени во множественные сегменты, использование этого иерархического кодирования, возможно, не является необходимым, так как полные данные времени и смещения для каждого сегмента могут уже быть весьма малыми. Например, если сегментами является одна минута вместо двух часов в вышеупомянутом примере, информация индексации времени - смещение в байтах составляет приблизительно 1 килобайт данных, которые могут быть обычно вставлены в единственный пакет TCP/IP.
[0144] Различные варианты возможны, чтобы добавить данные времени и смещения в байтах фрагмента к файлам 3GPP:
[0145] Во-первых, Поле Произвольного доступа Фрагмента Кино ("MFRA") может использоваться с этой целью. MFRA обеспечивает таблицу, которая может помочь считывателям в обнаружении точек произвольного доступа в файле, использующем фрагменты кино. Для поддержки этой функции MFRA в связи с этим содержит смещения в байтах полей MFRA, содержащих точки произвольного доступа. MFRA может быть помещено в конец или около конца файла, но это не является обязательным случаем. Просматривая от конца файла в поиске Поля Смещения Произвольного доступа Фрагмента Кино и используя информацию размера в нем, можно быть в состоянии определить местонахождение начала Поля Произвольного доступа Фрагмента Кино. Однако размещение MFRA в конце для потоковой передачи HTTP обычно требует по меньшей мере 3-4 HTTP запроса, чтобы получить доступ к желательным данным: по меньшей мере один, чтобы запросить MFRA от конца файла, один, чтобы получить MFRA, и наконец один, чтобы получить желательный фрагмент в файле. Поэтому, размещение в начале может быть желательным, так как затем MFRA может быть загружено вместе с первыми данными мультимедиа в единственном запросе. Кроме того, использование MFRA для потоковой передачи HTTP может быть неэффективным, так как ни одна из информации в "MFRA" не является необходимой, кроме времени и moof_offset, и задание смещений вместо длин могут потребовать большего количества битов.
[0146] Во-вторых, Поле Местоположения Элемента ("ILOC") может использоваться. "ILOC" обеспечивает каталог ресурсов метаданных в этом или других файлах, посредством определения местонахождения их содержащего файла, их смещения в пределах этого файла и их длины. Например, система может интегрировать все ресурсы метаданных, на которые внешне ссылаются, в один файл, повторно корректируя смещения файла и ссылки на файл соответственно. Однако, "ILOC" предназначено для того, чтобы задать местоположение метаданных таким образом, что может быть трудно для этого сосуществовать с реальными метаданными.
[0147] Последняя, и возможно самая подходящая, спецификация нового поля, названного Поле Индекса Времени ("TIDX"), специально назначенная с целью обеспечить точные времена или длительности фрагмента и смещение в байтах эффективным образом. Это описано более подробно в следующем разделе. Альтернативное поле с теми же самыми функциональными возможностями может быть Полем Индекса Сегмента ("SIDX"). Здесь, если иначе не обозначено, эти два могут быть взаимозаменяемыми, поскольку оба поля обеспечивают способность обеспечить точные времена или длительности фрагмента и смещение в байтах эффективным образом. Разность между TIDX и SIDX представлена ниже. Должно быть, очевидно, как взаимозаменять поля TIDX и поля SIDX, поскольку оба поля реализовывают индекс сегментов.
ИНДЕКСАЦИЯ СЕГМЕНТОВ
[0148] Сегмент имеет идентифицированное начальное время и идентифицированное количество байтов. Множественные фрагменты могут быть конкатенированы в единственный сегмент, и клиенты могут выдавать запросы, которые идентифицируют конкретный диапазон в байтах в пределах сегмента, которые соответствуют требуемому фрагменту или поднабору из этого фрагмента. Например, когда HTTP используется как протокол запроса, то заголовок Диапазон HTTP может использоваться с этой целью. Этот подход требует, чтобы клиент имел доступ к "индексу сегментов" сегмента, который задает позицию в пределах сегмента различных фрагментов. Этот "индекс сегментов" может быть предоставлен в качестве части метаданных. Этот подход имеет тот результат, что гораздо меньше файлов должно быть создано и управляться по сравнению с подходом, когда каждый блок сохранен в отдельном файле. Управление созданием, передачей и хранением очень большого количества файлов (которое может простираться на многие тысячи для представления, скажем, 1 часа), может быть сложным и подвержено ошибкам, и таким образом сокращение в количестве файлов предоставляет преимущество.
[0149] Если клиент знает только желательное начальное время меньшей части сегмента, можно запросить целый файл, затем считать файл, чтобы определить соответствующее начальное местоположение проигрывания. Чтобы улучшить использование полосы частот, сегменты могут включать в себя индексный файл в качестве метаданных, где индексный файл сопоставляет диапазоны байтов отдельных блоков с диапазонами времени, которым эти блоки соответствуют, называемое индексацией сегментов или картой сегментов. Эти метаданные могут быть отформатированы как данные XML, или они могут быть двоичными, например, следуя структуре элементарной единицы или поля упомянутого формата 3GPP файла. Индексация, может быть, простой, в которой время и диапазоны в байтах каждого блока являются абсолютными относительно начала файла, или они могут быть иерархическими, в которой некоторые блоки сгруппированы в родительские блоки (а те в прародительские блоки, и т.д.) и время и диапазон в байтах для заданного блока выражены относительно времени и/или диапазона в байтах блока родительского блока.
ПРИМЕРНАЯ СТРУКТУРА КАРТЫ ИНДЕКСАЦИИ
[0150] В одном варианте осуществления первоначальные исходные данные для одного представления потока мультимедиа могут содержаться в одном или более файлах мультимедиа, здесь названных "сегментом мультимедиа", при этом каждый сегмент мультимедиа содержит данные мультимедиа, используемые для воспроизведения непрерывного во времени сегмента мультимедиа, например, 5 минут воспроизведения мультимедиа.
[0151] Фиг. 6 показывает пример полной структурой сегмента мультимедиа. В каждом сегменте или вначале или распределенной по исходному сегменту, может быть также информация индексации, которая содержит карту сегментов времени/смещения в байтах. Карта сегментов времени/смещения в байтах в одном варианте осуществления может быть списком пар времени/смещения в байтах (T (0), B (0)), (T (1), B (1)), (T (i), B (i)), (T (n), B (n)), в котором T (i-1) представляет начальное время в пределах сегмента для воспроизведения i-го фрагмента мультимедиа относительно начального стартового времени мультимедиа среди всех сегментов мультимедиа, T(i) представляет время окончания для i-го фрагмента (и таким образом начальное время для следующего фрагмента), и смещение в байтах B (i-1) является соответствующим индексом байта начала данных в пределах этого исходного сегмента, где i-й фрагмент мультимедиа начинается относительно начала исходного сегмента, и B(i) является соответствующим индексом байта конца i-го фрагмента (и таким образом индексом первого байта следующего фрагмента). Если сегмент содержит множественные компоненты мультимедиа, то T(i) и B(i) могут быть предоставлены для каждого компонента в сегменте абсолютным образом или они могут быть выражены относительно другого компонента мультимедиа, который служит опорным компонентом мультимедиа.
[0152] В этом варианте осуществления количество фрагментов в исходном сегменте равно n, где n может изменяться от сегмента к сегменту.
[0153] В другом варианте осуществления смещение времени в индексе сегментов для каждого фрагмента может быть определено с абсолютным временем начала первого фрагмента и длительностями каждого фрагмента. В этом случае индекс сегментов может документировать начальное время первого фрагмента и длительность всех фрагментов, которые включены в сегмент. Индекс сегментов может также только документировать поднабор фрагментов. В этом случае индекс сегментов документирует длительность подсегмента, который определен как один или более последовательных фрагментов, заканчиваясь или в конце содержащего сегмента или в начале следующего подсегмента.
[0154] Для каждого фрагмента также может быть значение, которое указывает, начинается ли фрагмент в, или содержит ее, точке поиска, то есть, в точке, в которой никакое мультимедиа после этой точки не зависит от какого-либо мультимедиа до той точки, и таким образом мультимедиа от этого фрагмента вперед может быть проиграно независимо от предыдущих фрагментов. Точками поиска обычно являются точки в мультимедиа, в которых проигрывание может начаться независимо от всего предыдущего мультимедиа. Фиг. 6 также показывает простой пример возможной индексации сегментов для исходного сегмента. В этом примере значение смещения времени выражается в единицах миллисекунд, и таким образом первый фрагмент этого исходного сегмента начинается 20 секунд с начала мультимедиа, и первый фрагмент имеет время проигрывания 485 миллисекунд. Смещение в байтах начала первого фрагмента равно 0, и смещение в байтах конца первого фрагмента/начала второго фрагмента равно 50245, и таким образом первый фрагмент имеет размер 50245 байтов. Если фрагмент или подсегмент не начинаются в точке произвольного доступа, но точка произвольного доступа содержится во фрагменте или подсегменте, то время декодирования или разница во времени представления между временем начала и фактическим временем RAP могут быть заданы. Это позволяет то, что в случае переключения к этому сегменту мультимедиа, клиент может точно знать необходимое время до переключения от представления, которое должно быть представлено.
[0155] В дополнение к, или вместо, могут использоваться простая или иерархическая индексация, гирляндная индексация и/или гибридная индексация.
[0156] Поскольку типовые длительности для различных дорожек не могут быть одинаковыми (например, видео выборки могут быть показаны в течение 33 миллисекунд, тогда как аудио выборка может длиться 80 миллисекунд), различные дорожки во Фрагменте Кино не могут начаться и закончиться в точно одно и то же время, то есть, аудио может начаться немного прежде или немного после видео, с противоположностью, верной для предыдущего фрагмента, чтобы обеспечить компенсацию. Чтобы избежать неопределенности, отметки времени, заданные в данных времени и смещения в байтах, могут быть заданы относительно конкретной дорожки, и это может быть одной и той же дорожкой для каждого представления. Обычно это будет видеодорожкой. Это позволяет клиенту идентифицировать точно следующий видео кадр, когда он переключает представления.
[0157] Может быть принята предосторожность во время представления, чтобы поддерживать строгое соотношение между шкалой времени дорожки и временем представления, чтобы гарантировать гладкое проигрывание и поддержание аудио/видео синхронизации, несмотря на вышеупомянутую проблему.
[0158] Фиг. 7 иллюстрирует некоторые примеры, такие как простой индекс 700 и иерархический индекс 702.
[0159] Два конкретных примера поля, которое содержит карту сегментов, предоставлены ниже, один назван полем индекса времени ('TIDX') и один назван ('SIDX'). Определение следует за структурой поля согласно формату файла мультимедиа на основе ISO. Другие исполнения для таких полей, чтобы определить аналогичный синтаксис и с той же самой семантикой и функциональными возможностями, должны быть очевидными для читателя.
ПОЛЕ ИНДЕКСА ВРЕМЕНИ
[0160] Определение
[0161] Тип поля: 'tidx'
[0162] Контейнер: Файл
[0163] Обязательность: Нет
[0164] Количество: Любое число ноль или один
[0165] Поле Индекса Времени может обеспечить набор индексов времени и смещений в байтах, которые ассоциируют некоторые области файла с некоторыми временными интервалами представления. Поле Индекса Времени может включать в себя поле targettype (тип цели), которое указывает тип данных, на которые ссылаются. Например, Поле Индекса Времени с targettype равным "moof” обеспечивает индекс на Фрагменты Мультимедиа, содержащиеся в файле в терминах, как времени, так и в терминах смещений в байтах. Поле Индекса Времени с targettype Поля Индекса Времени может использоваться, чтобы построить иерархический индекс времени, позволяя пользователям файла быстро перейти к требуемой части индекса.
[0166] Индекс сегментов может, например, содержать следующий синтаксис:
[0167] aligned(8) class TimelndexBox
extends FullBox('frai') {
unsigned int(32) targettype;
[0168] unsigned int(32) time_reference_track_ID;
unsigned int(32) number_of_elements;
unsigned int(64) first_element_offset;
unsigned int(64) first_element_time;
for(i=l; i<= number_of_elements; i++)
{
bit (1) random_access_flag;
unsigned int(31) length;
unsigned int(32) deltaT;
}
}
[0169] Семантика
[0170] targettype: является типом данных поля, на которые ссылаются с помощью этого Поля Индекса Времени. Оно может быть или Заголовком Фрагмента Кино ("moof”) или Полем Индекса Времени ("tidx").
[0171] time_reference_track_id: указывает дорожку, относительно которой заданы смещения во времени в этом индексном файле.
[0172] number_of_elements: набор элементов, индексированных этим Полем Индекса Времени.
[0173] first_element_offset: смещение в байтах от начала файла первого индексированного элемента.
[0174] first_element_time: начальное время первого индексированного элемента, используя шкалу времени, заданную в поле Заголовка Мультимедиа дорожки, идентифицированной этим time_reference_track_id.
[0175] random_access_flag: Единица, если начальное время этого элемента равно точке произвольного доступа. Ноль иначе.
[0176] length: длина индексированного элемента в байтах.
[0177] deltaT: разность в терминах шкалы времени, заданной в поле Заголовка Мультимедиа дорожки, идентифицированной посредством этого time_reference_track_id между временем начала этого элемента и начальным временем следующего элемента.
ПОЛЕ ИНДЕКСА СЕГМЕНТОВ
[0178] Поле Индекса сегментов ('sidx') обеспечивает компактный индекс (индексный файл) фрагментов кино, и другие поля Индекса Сегментов в сегменте. В Поле Индекса сегментов есть две структуры цикла. Первый цикл документирует первую выборку подсегментов, то есть, выборку в первом фрагменте кино, на которую ссылается второй цикл. Второй цикл обеспечивает индекс подсегмента. Контейнером для поля 'sidx' является файл или непосредственно сегмент.
[0179]
aligned(8) class SegmentlndexBox extends FullBox('sidx', version, 0) {
unsigned int(32) reference_track_ID;
unsigned int(16) track_count;
unsigned int(16) reference_count;
for (i=l ; i<= track_count; i++)
{
unsigned int(32) track_ID;
if (version=0)
{
unsigned int(32) decoding_time;
} else
{
unsigned int(64) decoding_time;
}
}
for(i=1 ; i<= reference_count; i++)
{ bit(1) reference_type;
unsigned int(31) reference_offset;
unsigned int(32) subsegment_duration;
bit(1) contains_RAP;
unsigned int(31) RAP_delta_time;
}
}
[0180] Семантика:
[0181] reference_track_ID обеспечивает ID дорожки для опорной дорожки.
[0182] track_count: количество дорожек, индексированных в следующем цикле (1 или больше);
[0183] reference_count: набор элементов, индексированных вторым циклом (1 или больше);
[0184] track_ID: ID дорожки, для которого фрагмент дорожки включен в первый фрагмент кино, идентифицированный этим индексом; точно один track_ID в этом цикле равен reference_track_ID;
[0185] decoding_time: время декодирования для первой выборки в дорожке, идентифицированной посредством track_ID во фрагменте кино, на который ссылается первый элемент во втором цикле, выраженное в шкале времени дорожки (как документировано в поле шкалы времени Поля Заголовка Мультимедиа дорожки);
[0186] reference_type: когда установлено в 0, указывает, что это ссылка на поле ('moof') фрагмента кино; когда установлено в 1, указывает, что это ссылка на поле ('sidx') индекса сегментов;
[0187] reference_offset: расстояние в байтах от первого байта после содержащего Поле Индекса Сегмента до первого байта поля, на которое ссылаются;
[0188] subsegment_duration: когда ссылка должна указывать на Поле Индекса Сегментов, это поле содержит сумму полей subsegment_duration во втором цикле этого поля; когда должна указывать на фрагмент кино, это поле содержит сумму длительностей выборок в опорной дорожке, в указанном фрагменте кино и последующих фрагментах кино вплоть до или первого фрагмента кино, задокументированного следующей записью в конце, или до конца подсегмента, что является более ранним; эта длительность выражена в шкале времени дорожки (как задокументировано в поле шкалы времени Поля Заголовка Мультимедиа дорожки);
[0189] contains_RAP: когда ссылка указывает на фрагмент кино, то этот бит может быть равен 1, если фрагмент дорожки в этом фрагменте кино для дорожки с track_ID, равным reference_track_ID, содержит, по меньшей мере, одну точку произвольного доступа, иначе этот бит, установлен в 0; когда ссылка указывает на индекс сегментов, то этот бит, установлен в 1, только если любая из ссылок в этом индексе сегментов имеет этот бит, установленный в 1, и 0 иначе;
[0190] RAP_delta_time: если contains_RAP равно 1, обеспечивает время представления (композиции) точки произвольного доступа (RAP); зарезервировано со значением 0, если contains_RAP равно 0. Время выражено как разность между временем декодирования первой выборки подсегмента, задокументированного этой записью, и временем представления (композиции) точки произвольного доступа, в дорожке с track_ID, равным reference_track_ID.
РАЗЛИЧИЯ МЕЖДУ TIDX И SIDX
[0191] SIDX и SIDX обеспечивают одни и те же функциональные возможности относительно индексации. Первой цикл SIDX обеспечивает в дополнение глобальное тактирование для первого фрагмента кино, но глобальное тактирование может также содержаться в самом фрагменте кино, или абсолютное или относительное к опорной дорожке.
[0192] Второй цикл SIDX реализовывает функциональные возможности TIDX. В частности, SIDX разрешает иметь смесь целей для ссылки для каждого индекса, указанного посредством reference_type, тогда как TIDX только указывает, или только TIDX, или только MOOF. Значение number_of_elements в TIDX соответствует reference_count в SIDX, time-reference_track_ID в TIDX соответствует reference_track_ID в SIDX, tfirst_element_offset в TIDX соответствует reference_offset в первой записи второго цикла, first_element_time в TIDX соответствует времени decoding_time для reference_track в первом цикле, random_access_flag в TIDX соответствует contains_RAP в SIDX с дополнительной свободой, что в SIDX RAP может не обязательно быть помещен в начале фрагмента, и поэтому, требуя RAP_delta_time, length в TIDX соответствует reference_offset в SIDX, и, наконец, deltaT в TIDX соответствует subsegment_duration в SIDX. Поэтому функциональные возможности этих двух полей эквивалентны.
РАЗДЕЛЕНИЕ НА БЛОКИ ПЕРЕМЕННОГО РАЗМЕРА И БЛОКИ SUB-GOP (ПОД-GOP)
[0193] Для видео мультимедиа отношения между структурой кодирования видео и структурой блоков для запросов могут быть важными. Например, если каждый блок начинается с точки поиска, такой как Точка Произвольного доступа ("RAP"), и каждый блок представляет равный период времени видео, то расположение, по меньшей мере, некоторых точек поиска в видео мультимедиа является фиксированным, и точки поиска будут иметь место равномерно при кодировании видео. Как известно специалистам в области кодирования видео, эффективность сжатия может быть улучшена, если точки поиска помещены согласно отношениям между видео кадрами, и в частности, если они размещены в кадрах, которые имеют немного общего с предыдущими кадрами. Это требование, чтобы блоки представляли равное количество времени, таким образом, устанавливает ограничение для кодирования видео, так что сжатие может быть субоптимальным.
[0194] Желательно разрешить, чтобы позиция точки поиска в пределах видео представления была выбрана системой кодирования видео, вместо требования, чтобы точки поиска были в фиксированных позициях. Разрешение системе кодирования видео выбрать точки поиска приводит к улучшенному сжатию видео и таким образом более высокое качество видео мультимедиа может быть предоставлено, используя заданную доступную полосу частот, приводя к улучшенному пользовательскому опыту (восприятию). Современные системы потоковой передачи с запросом блоков могут требовать, чтобы все блоки имели одну и ту же длительность (во времени видео), и что каждый блок должен начинаться с точки поиска, и это является, таким образом, неудобством существующих систем.
[0195] Новая система потоковой передачи с запросом блоков, которая обеспечивает преимущества перед вышеупомянутым, описана ниже. В одном варианте осуществления процесс кодирования видео первой версии видео компонента может быть сконфигурирован, чтобы выбрать позиции точек поиска, чтобы оптимизировать эффективность сжатия, но с требованием, чтобы был максимум относительно длительности между точками поиска. Это последнее требование действительно ограничивает выбор точек поиска посредством процесса кодирования, и таким образом уменьшает эффективность сжатия. Однако, уменьшение эффективности сжатия является малым по сравнению с таковым, если регулярные фиксированные позиции требуются для точек поиска, при условии, что максимум на длительности между точками поиска не является слишком малым (например, больше чем приблизительно секунда). Кроме того, если максимум на длительности между точками поиска составляет несколько секунд, то уменьшение эффективности сжатия по сравнению с полностью свободным расположением точек поиска является обычно очень малым.
[0196] Во многих вариантах осуществления, включая этот вариант осуществления, может случиться так, что некоторые точки RAP не являются точками поиска, то есть, может быть, кадр, который является RAP, которая находится между двумя последовательными точками поиска, который не выбран в качестве точки поиска, например, так как RAP слишком близка во времени к окружающим точкам поиска, или так как количество данных мультимедиа между точками поиска, предшествующей или последующей для этой RAP и этой RAP является слишком малым.
[0197] Позиция точек поиска во всех других версиях представления мультимедиа может быть ограничена, чтобы быть той же самой как у точек поиска в первой (например, самая высокая скорость данных мультимедиа) версии. Это действительно уменьшает эффективность сжатия для этой другой версия по сравнению с разрешением кодеру свободно выбирать точки поиска.
[0198] Использование точек поиска обычно требовало, чтобы кадр был, независимо декодируем, что обычно приводит к низкой эффективности сжатия для этого кадра. Кадры, которые не должны быть независимо декодируемыми, могут быть закодированы со ссылками на данные в других кадрах, что обычно увеличивает эффективность сжатия для этого кадра на величину, которая зависит от величины общности между кадром, который должен быть закодирован, и опорным кадром. Эффективный выбор позиционирования точки поиска предпочтительно выбирает в качестве кадра точки поиска кадр, который имеет низкую общность с предыдущими кадрами и таким образом минимизирует снижение эффективности сжатия, имеющей место посредством кодирования кадра способом, который является независимо декодируемым.
[0199] Однако, уровень общности между кадром и потенциальными опорными кадрами является высоко коррелированным через различные представления контента, так как первоначальный контент является одним и тем же. В результате ограничение точек поиска в других вариантах, чтобы иметь те же позиции, как точки поиска в первом варианте, не имеют большого значения в эффективности сжатия.
[0200] Структура точек поиска предпочтительно используется для определенной структуры блоков. Предпочтительно, каждая точки поиска определила начало блока, и могут быть один или более блоков, которые охватывают данные между двумя последовательными точками поиска. Так как длительность между точками поиска не является фиксированной для кодирования с хорошим сжатием, не требуется, чтобы все блоки имели одну и ту же длительность проигрывания. В некоторых вариантах осуществления блоки выровнены между версиями контента - то есть, если есть блок, охватывающий конкретную группу кадров в одной версии контента, то есть блок, охватывающий ту же группу кадров в другой версии контента. Блоки для заданной версии контента не накладываются, и каждый кадр контента содержится в пределах точно одного блока каждой версии.
[0201] Особенность предоставления возможности, которая разрешает эффективное использование переменных длительностей между точками поиска, и таким образом переменную длительность групп GoP, является индексация сегментов или карта сегментов, которая может быть включена в сегмент или предоставлена другим средством клиенту, то есть, это метаданные, ассоциированные с этим сегментом в этом представлении, которое может быть предоставлено, содержащее начальное время и длительность каждого блока представления. Клиент может использовать эти данные индексации сегментов для определения блока, с которого начать представление, когда пользователь запросил, чтобы представление началось в конкретной точке, которая находится в пределах сегмента. Если такие метаданные не предоставлены, то представление может начаться только в начале контента, или в случайной или приблизительной точке близко к желательной точке (например, выбирая начальный блок посредством деления запрошенной начальной точки (во времени) на среднюю длительность блока, чтобы получить индекс начального блока).
[0202] В одном варианте осуществления каждый блок может быть обеспечен как отдельный файл. В другом варианте осуществления множественные последовательные блоки могут быть соединены в единственный файл, чтобы сформировать сегмент. В этом втором варианте осуществления метаданные для каждой версии могут быть обеспечены, содержащие начальное время и длительность каждого блока и смещения в байтах в пределах файла, с которого начинается блок. Эти метаданные могут быть предоставлены в ответ на начальный запрос протокола, то есть, доступными отдельно от сегмента или файла, или могут содержаться в этом же самом файле или сегменте в качестве самих блоков, например в начале файла. Как будет ясно специалистам в данной области техники, эти метаданные могут быть закодированы в сжатой форме, такой как (в формате) gzip или кодирование дельты, или в двоичной форме, чтобы уменьшить ресурсы сети, требуемые для транспортировки метаданных клиенту.
[0203] Фиг. 6 показывает пример индексации сегментов, где блоки имеют переменный размер, и где размером блоков является частичная GoP, то есть, частичное количество данных мультимедиа между одной RAP и следующей RAP. В этом примере точки поиска обозначены индикатором RAP, в котором значение 1 индикатора RAP указывает, что блок начинается с или содержит RAP, или точку поиска, и в котором индикатор 0 RAP указывает, что блок не содержит RAP или точку поиска. В этом примере первые три блока, то есть байты 0 до 157033, содержат первую GoP, которая имеет длительность представления 1623 секунд, со временем представления, проходящим с 20 секунд в контенте до 21623 секунд. В этом примере первый из трех первых блоков содержит 0,485 секунды времени представления, и содержит первые 50245 байтов данных мультимедиа в сегменте. В этом примере блоки 4, 5 и 6 содержат вторую GoP, блоки 7 и 8 содержат третью GoP, и блоки 9, 10 и 11 содержат четвертую GoP. Следует отметить, что могут быть другие RAP в данных мультимедиа, которые не определяются как точки поиска, и таким образом не сообщаются в качестве RAP в карте сегментов.
[0204] Обращаясь снова к Фиг. 6, если клиент или приемник хотят получить доступ к контенту, начинающемуся при смещении во времени приблизительно 22 секунды в представлении мультимедиа, то клиент может сначала использовать другую информацию, такую как MPD, описанное более подробно, ниже, чтобы сначала определить, что релевантные данные мультимедиа находятся в пределах этого сегмента. Клиент может загрузить первую часть сегмента, чтобы получить индексацию сегментов, которая в этом случае является только несколькими байтами, например, используя запрос диапазона в байтах HTTP. Используя индексацию сегментов, клиент может определить, что первый блок, который он должен загрузить, является первым блоком со смещением во времени, которое равно самое большее 22 секунды, и он начинается с RAP, то есть, является точкой поиска. В этом примере, хотя блок 5 имеет смещение во времени, которое меньше чем 22 секунды, то есть, его смещение времени составляет 21,965 секунды, индексация сегментов указывает, что блок 5 не начинается с RAP, и таким образом вместо этого, на основании индексации сегментов, клиент выбирает загрузить блок 4, так как его начальное время равно самое большее 22 секундам, то есть, его смещение времени составляет 21,623 секунды, и он начинается с RAP. Таким образом, на основании индексации сегментов клиент сделает запрос диапазона HTTP, начинающийся при смещении в байтах, равном 157034.
[0205] Если индексация сегментов не была доступна, то клиенту, возможно, придется загрузить все предыдущие 157034 байта данных прежде, чем загрузить эти данные, приводя к намного более длительному времени запуска, или времени переключения каналов, и к расточительной загрузке данных, что не является полезным. Альтернативно, если индексация сегментов не была доступна, то клиент может аппроксимировать, где желательные данные начинаются в пределах сегмента, но эта аппроксимация может быть плохой, и можно пропустить подходящее время и затем требуется пойти назад, что снова увеличивает задержку запуска.
[0206] Обычно каждый блок охватывает часть данных мультимедиа, которые вместе с предыдущими блоками могут быть проиграны проигрывателем мультимедиа. Таким образом, структура блокирования и сигнализация структуры блокирования индексации сегментов клиенту, или содержащейся в пределах сегмента или предоставленной клиенту через другое средство, могут значительно улучшить способность клиента обеспечить быстрое переключение каналов, и плавное проигрывание перед лицом изменений и нарушений сети. Поддержка блоков переменной длительности и блоков, которые охватывают только части GoP, как разрешено индексацией сегментов, может значительно улучшить опыт потоковой передачи. Например, обращаясь снова к Фиг. 6 и примеру, описанному выше, где клиент хочет начать проигрывание с приблизительно 22 секунд в представлении, клиент может запрашивать, с помощью одного или более запросов, данные в блоке 4 и затем подавать это в проигрыватель мультимедиа, как только они доступны, чтобы начать воспроизведение. Таким образом, в этом примере проигрывание начинается, как только 42011 байтов блока 4 приняты в клиенте, таким образом, разрешая быстрое время переключения каналов. Если вместо этого клиенту требуется запросить всю GoP, прежде чем проигрывание должно было начаться, время переключения канала может быть более длинным, поскольку она равна 144 211 байтов данных.
[0207] В других вариантах осуществления, RAP или точки поиска могут также иметь место в середине блока, и могут иметься данные в индексации сегментов, которые указывают, где эта RAP или точка поиска находится в пределах блока или фрагмента. В других вариантах осуществления смещение во времени может быть временем декодирования первого кадра в пределах блока, вместо времени представления первого кадра в пределах блока.
[0208] Фиг. 8(a) и (b) иллюстрируют пример разделения на блоки переменного размера выровненной структуры точек поиска по множеству версий или представлений; Фиг. 8(a) иллюстрирует разделение на блоки переменного размера с выровненными точками поиска по множеству версий потока мультимедиа, в то время как Фиг. 8(b) иллюстрирует разделение на блоки переменного размера с не выровненными точками поиска по множеству версий потока мультимедиа.
[0209] Время показано сверху в секундах, и блоки и точки поиска двух сегментов для этих двух представлений показаны слева направо в терминах их тактирования относительно этой временной линии, и таким образом длина каждого показанного блока пропорциональна времени его проигрывания и не пропорциональна количеству байтов в блоке. В этом примере индексация сегментов для обоих сегментов этих двух представлений будут иметь одинаковые смещения во времени для точек поиска, но потенциально отличающиеся количества блоков или фрагментов между точками поиска и различные смещения в байтах для блоков из-за различного количества данных мультимедиа в каждом блоке. В этом примере, если клиент хочет переключиться от представления 1 к представлению 2 во время, приблизительно равное 23 секундам представления, то клиент может сделать запрос во время блока 1.2 в сегменте в течение представления 1, и начать запрашивать сегмент в течение представления 2, начинающееся в блоке 2.2, и таким образом переключение произойдет при представлении, совпадающем с точкой поиска 1.2 в представлении 1, которое является тем же временем, как точка поиска 2.2 в представлении 2.
[0210] Как должно быть ясно из предшествующего, описанная система потоковой передачи с запросом блоков не ограничивает кодирование видео помещением точек поиска в конкретные позиции в пределах контента, и это смягчает одну из проблем существующих систем.
[0211] В вариантах осуществления, описанных выше этого, организовано так, чтобы точки поиска для различных представлений одного и того же контента представления были выровнены. Однако, во многих случаях предпочтительно ослабить это требование выравнивания. Например, иногда имеет место случай, что кодирующие средства использовались, чтобы генерировать представления, которые не имеют способности генерировать представления с выровненными точками поиска. В качестве другого примера, представление контента может быть закодировано в различные представления независимо, без выравнивания точек поиска между различными представлениями. В качестве другого примера, представление может содержать больше точек поиска, поскольку оно имеет более низкие скорости передачи, и более обобщенно, оно должно быть переключено, или оно содержит, точки поиска для поддержки режимов таких операций, как быстрый переход вперед или назад или быстрый поиск. Таким образом, желательно обеспечить способы, которые делают систему потоковой передачи с запросом блоков способной эффективно и легко иметь дело с не выровненными точками поиска в различных представлениях для представления контента.
[0212] В этом варианте осуществления позиции точек поиска в представлениях, возможно, не являются выровненными. Блоки построены таким образом, что новый блок начинается в каждой точке поиска, и таким образом не может быть выравнивания между блоками различных версий представления. Пример такой структуры не выровненных точек поиска между различными представлениями показан на Фиг. 8 (b). Время показано сверху в секундах, и блоки и точки поиска двух сегментов для этих двух представлений показаны слева направо в терминах их тактирования относительно этой временной линии, и таким образом длина каждого показанного блока пропорциональна времени его проигрывания и не пропорциональна количеству байтов в блоке. В этом примере индексация сегментов для обоих сегментов этих двух представлений будет иметь потенциально различные смещения во времени для точек поиска, и также потенциально отличающиеся количества блоков или фрагментов между точками поиска, и различные смещения в байтах к блокам из-за различного количества данных мультимедиа в каждом блоке. В этом примере, если клиент хочет переключиться от представления 1 к представлению 2 во время представления, приблизительно равного 25 секундам, то клиент может осуществить запрос во время блока 1.3 в этом сегменте в течение представления 1, и начать запрашивать сегмент для представления 2, начинающийся в блоке 2.3, и таким образом переключение произойдет при представлении, совпадающем с точкой поиска 2.3 в представлении 2, которая находится в середине проигрывания блока 1.3 в представлении 1, и таким образом часть мультимедиа для блока 1.2 не будет, проигрывается (хотя данные мультимедиа для кадров блока 1.3, которые не проигрываются, вероятно, придется загрузить в буфер приемника для декодирования других кадров блока 1.3, которые проигрываются).
[0213] В этом варианте осуществления работа селектора 123 блоков может быть изменена таким образом, что всякий раз, когда он обязан выбирать блок из представления, которое отличается от ранее выбранной версии, выбирается последний блок, первый кадр которого находится не позже кадра, следующего за последним кадром последнего выбранного блока.
[0214] Этот последний описанный вариант осуществления может устранить требование, чтобы ограничить позиции точек поиска в версиях, отличных от первой версии, и таким образом увеличивает эффективность сжатия для этих версий, приводя к более высококачественному представлению для заданной доступной полосы частот и, таким образом, улучшенному пользовательскому опыту. Дальнейшее рассмотрение состоит в том, что инструменты кодирования видео, которые выполняют функцию выравнивания точек поиска по множественным кодированиям (версиям) контента, могут быть не широко доступны, и поэтому преимущество этого последнего описанного варианта осуществления состоит в том, что могут быть использованы в настоящее время доступные инструменты кодирования видео. Другое преимущество состоит в том, что кодирование различных версий контента может продолжиться параллельно без какой-либо необходимости в координации между процессами кодирования для различных версий. Другое преимущество состоит в том, что дополнительные версии контента могут быть закодированы и добавлены к представлению в более позднее время, не имея необходимости предоставлять инструменты кодирования со списками позиций конкретных точек поиска.
[0215] Обычно, когда картинки закодированы как группы картинок (группы GoP), первая картинка в последовательности может быть точкой поиска, но это не обязательно всегда должно иметь место.
ОПТИМАЛЬНОЕ РАЗДЕЛЕНИЕ НА БЛОКИ
[0216] Одной из проблем в системе потоковой передачи с запросом блоков является взаимодействие между структурой закодированного мультимедиа, например, видео мультимедиа, и структурой блоков, используемой для запросов блоков. Как известно специалистам в кодировании видео, часто имеет место случай, что количество битов, требуемых для закодированного представления каждого видео кадра, изменяется, иногда существенно, от кадра к кадру. В результате соотношение между количеством принятых данных и длительностью мультимедиа, закодированного этими данными, может не быть прямым. Кроме того, разделение данных мультимедиа в блоки в системе потоковой передачи с запросом блоков добавляет дополнительную сложность. В частности, в некоторых системах могут быть не проиграны данные мультимедиа блока, пока весь блок не будет принят, например, компоновка данных мультимедиа в блоке или зависимости между выборками мультимедиа в пределах блока использования кодов стирания могут привести к этому свойству. В результате этих сложных взаимодействий между размером блока и длительностью блока и возможной необходимостью принять весь блок прежде, чем начать проигрывание, для клиентских систем характерно принимать консервативный подход, в котором данные мультимедиа буферизуют, прежде чем начинается проигрывание. Такая буферизация приводит к долгому времени переключения каналов и таким образом плохому пользовательскому опыту.
[0217] Pakzad описывает "способы деления на блоки", которые являются новыми и эффективными способами, чтобы определить, как разделить поток данных на смежные блоки, на основании лежащей в основе структуры потока данных, и также описывает несколько преимуществ этих способов в контексте системы потоковой передачи. Дополнительный вариант осуществления изобретения для применения способов деления на блоки от Pakzad к системе потоковой передачи с запросом блоков описан ниже. Этот способ может содержать компоновку данных мультимедиа, которые должны быть представлены, в приблизительном порядке времени представления, таким образом, что время проигрывания любого заданного элемента данных мультимедиа (например, видео кадра или аудио выборки) отличается от такового любого смежного элемента данных мультимедиа меньше, чем на предоставленный порог. Данные мультимедиа, таким образом, упорядоченные, можно считать потоком данных на языке Pakzad, и любые из способов Pakzad, примененные к этому потоку данных, идентифицируют границы блока с потоком данных. Данные между любой парой границ смежных блоков считают "Блоком" на языке настоящего раскрытия, и способы этого раскрытия применяются, чтобы обеспечить представление данных мультимедиа в системе потоковой передачи с запросом блоков. Как будет ясно специалистам при прочтении этого раскрытия, несколько преимуществ способов, раскрытых в Pakzad, могут быть, затем реализованы в контексте системы потоковой передачи с запросом блоков.
[0218] Как описано в Pakzad, определение структуры блоков сегмента, включая блоки, которые охватывают частичные группы GoP или части более чем на GoP, может воздействовать на способность клиента разрешить быстрое время переключения канала. Согласно Pakzad, обеспечены способы, которые при заданном времени запуска обеспечивают структуру блоков и целевую скорость загрузки, которая может гарантировать, что, если клиент начал загружать представление с любой точки поиска и начал проигрывание после того, как целевое время запуска истекло, то проигрывание может продолжаться гладко, пока в каждой точке во времени количество данных, которые загрузил клиент, равно, по меньшей мере, целевой скорости загрузки, умноженной на истекшее время с начала загрузки. Выгодно для клиента иметь доступ к целевому времени запуска и целевой скорости загрузки, поскольку это предоставляет клиенту средство определить, когда начать проигрывать представление в самой ранней точке во времени, и позволяет клиенту продолжать проигрывать представление, пока загрузка удовлетворяет условию, описанному выше. Таким образом, способ, описанный ниже, обеспечивает средство для включения целевого времени запуска и целевой скорости загрузки в Описание Представления Мультимедиа, так чтобы оно могло использоваться в целях, описанных выше.
МОДЕЛЬ ДАННЫХ ПРЕДСТАВЛЕНИЯ МУЛЬТИМЕДИА
[0219] Фиг. 5 иллюстрирует возможные структуры хранилища контента, показанного на Фиг. 1, включая сегменты и файлы описания представления мультимедиа ("MPD"), и разбиение сегментов, тактирование и другую структуру в файле MPD. Подробности возможных реализаций структур MPD или файлов описаны ниже. Во многих примерах MPD описан как файл, но нефайловые структуры также могут быть использованы.
[0220] Как иллюстрировано, хранилище 110 контента хранит множество исходных сегментов 510, MPD 500 и исправленных сегментов 512. MPD может содержать записи 501 периодов, которые в свою очередь могут содержать записи 502 представления, которые содержат информацию 503 сегмента, такую как ссылки на сегменты 504 инициализации, и сегменты 505 мультимедиа.
[0221] Фиг. 9 (a) иллюстрирует примерную таблицу 900 метаданных, в то время как Фиг. 9 (b) иллюстрирует пример того, как клиент 902 потоковой передачи HTTP получает таблицу 900 метаданных и мультимедийные блоки 904 по соединению с сервером 906 потоковой передачи HTTP.
[0222] В способах, описанных здесь, обеспечивается "Описание Представления Мультимедиа", которое содержит информацию относительно представлений представления мультимедиа, которые доступны для клиента. Представления могут быть альтернативами в том смысле, что клиент выбирает одну из различных альтернатив, или они могут быть дополнительными друг другу в том смысле, что клиент выбирает несколько из представлений, каждое возможно также из набора альтернатив, и представляет их совместно. Представления могут быть выгодно назначены группам, клиентом, запрограммированным или конфигурируемым, чтобы понять, что для представлений в одной группе они являются каждая альтернативами друг другу, тогда как представления из различных групп таковы, что больше чем одно представление должно быть представлено совместно. Другими словами, если имеется больше чем одно представление в группе, клиент выбирает одно представление из этой группы, одно представление из следующей группы, и т.д., чтобы сформировать представление.
[0223] Информация, описывающая представления, может выгодно включать в себя подробности применяемых кодеков мультимедиа, включающих профили и уровни тех кодеков, которые требуются для декодирования представления, частоты кадров видео, разрешение видео и скорости передачи данных. Клиент, принимающий Описание Представления Мультимедиа, может использовать эту информацию, чтобы определить заранее, является ли представление подходящим для декодирования или представления. Это предоставляет преимущество, так как если бы только разностная информация содержалась бы в двоичных данных представления, может было быть необходимым запросить двоичные данные из всех представлений и проанализировать и извлечь релевантную информацию, чтобы обнаружить информацию о ее пригодности. Эти множественные запросы и анализ извлечения приложения данных могут занять некоторое время, что может привести к долгому времени запуска и поэтому плохому пользовательскому опыту.
[0224] Дополнительно, Описание Представления Мультимедиа может содержать информацию, ограничивающую запросы клиента, на основании времени дня. Например, для обслуживания «вживую» клиент может быть ограничен запрашивать части представления, которые являются близкими к "текущему времени вещания". Это представляет преимущество, так как для прямой («живой») передачи, может быть желательно, очистить данные от обслуживающей инфраструктуры для контента, который был передан больше предоставленного порога перед текущим временем вещания. Это может быть желательно для повторного использования ресурсов хранения в обслуживающей инфраструктуре. Это также может быть желательно в зависимости от типа предлагаемого обслуживания, например. В некоторых случаях представление может быть сделано доступным только «живым» (в реальном времени) из-за некоторой модели подписки принимающих клиентских устройств, тогда как другие представления мультимедиа могут быть сделаны доступными «вживую» и по требованию, и другие представления могут быть сделаны доступными только «вживую» первому классу клиентских устройств, только по требованию второму классу клиентских устройств, и комбинации или «вживую» или по требованию третьему классу клиентских устройств. Способы, описанные в Модели Данных Представления Мультимедиа (ниже), позволяют клиенту быть информированным о таких политиках, так чтобы клиент мог избежать делать запросы и регулировать предложения пользователю о данных, которые могут быть не доступны в обслуживающей инфраструктуре. В качестве альтернативы, например клиент, может представить уведомление пользователю, что эти данные не доступны.
[0225] В дополнительном варианте осуществления изобретения сегменты мультимедиа могут быть совместимыми с Форматом Файла Мультимедиа на основе ISO, описанного в ISO/IEC 14496-12 или выведенных из него спецификациях (таким как формат 3GP-файла, описанный в 3GPP Technical Specification 26.244). Секция Использование Формата Файла 3GPP (выше) описывает новые расширения к Формату Файла Мультимедиа на основе ISO, разрешая эффективное использование структур данных этого формата файла в системе потоковой передачи с запросом блоков. Как описано в этой ссылке, информация может быть предоставлена в пределах файла, разрешающего быстрое и эффективное отображение между временными сегментами представления мультимедиа и диапазонами в байтах в пределах файла. Данные самого мультимедиа могут быть структурированы согласно конструкции Movie Fragment (Фрагмента Кино), определенному в ISO/IEC14496-12. Эта информация, обеспечивающая время и смещения в байтах, может быть структурирована иерархически или как единственный блок информации. Эта информация может быть предоставлена в начале файла. Предоставление этой информации, используя эффективное кодирование, как описано в секции Использование Формата Файла 3GPP приводит к тому, что клиент будет способен извлечь эту информацию быстро, например, используя частичный HTTP запрос GET, в случае, когда протоколом загрузки файла, используемым системой потоковой передачи с запросом блоков, является HTTP, что приводит к короткому запуску, поиску или времени переключения потока и поэтому к улучшенному пользовательскому опыту.
[0226] Представления в представлении мультимедиа синхронизированы в шкале глобального времени, чтобы гарантировать плавное переключение по представлениям, обычно являющимися альтернативами, и гарантировать синхронное представление двух или более представлений. Поэтому, тактирование выборок включенного мультимедиа в представлениях в пределах адаптивного представления мультимедиа потокового HTTP может быть соотнесено с непрерывной шкалой глобального времени по множественным сегментам.
[0227] Блок закодированного мультимедиа, содержащий мультимедиа множественных типов, например аудио и видео, может иметь различные конечные времена представления для различных типов мультимедиа. В системе потоковой передачи с запросом блоков такие блоки мультимедиа могут быть проиграны последовательно таким образом, что каждый вид мультимедиа проигрывается непрерывно, и таким образом выборки мультимедиа одного типа из одного блока могут быть проиграны перед выборками мультимедиа другого типа предыдущего блока, что упомянуто здесь как "непрерывное соединение блоков”. В качестве альтернативы, такие блоки мультимедиа могут быть проиграны таким образом, что самая ранняя выборка любого типа одного блока проигрывается после последней выборки любого типа предыдущего блока, что упомянуто здесь как "прерывистое соединение блоков”. Непрерывное соединение блоков может быть подходящим, когда оба блока содержат мультимедиа из одного и того же элемента контента и одного и того же представления, закодированного в последовательности, или в других случаях. Как правило, в пределах одного представления непрерывное соединение блоков может быть применено, соединяя два блока. Это выгодно, так как существующее кодирование может быть применено, и сегментация может быть сделана без необходимости выравнивать дорожки мультимедиа по границам блоков. Это проиллюстрировано на Фиг. 10, где видео поток 1000 содержит блок 1202 и другие блоки, с RAP, такими как RAP 1204.
ОПИСАНИЕ ПРЕДСТАВЛЕНИЯ МУЛЬТИМЕДИА
[0228] Представление мультимедиа может быть просмотрено как структурированная коллекция файлов на сервере потоковой передачи HTTP. Клиент потоковой передачи HTTP может загрузить достаточную информацию, чтобы представить службу потоковой передачи пользователю. Альтернативные представления могут содержать один или более 3GP файлов или части 3GP файлов, соответствующие форматам файла 3GPP или, по меньшей мере, хорошо определенному набору структур данных, которые могут быть легко преобразованы из или в 3GP файл.
[0229] Представление мультимедиа может быть описано в соответствии с описанием представления мультимедиа. Описание Представления Мультимедиа (MPD) может содержать метаданные, которые клиент может использовать, чтобы построить соответствующие запросы файла, например, HTTP запросы GET, чтобы получить доступ к данным в подходящее время и предоставить услугу потоковой передачи пользователю. Описание представления мультимедиа может предоставить достаточную информацию для клиента потоковой передачи HTTP, чтобы выбрать соответствующее 3GPP файлы и части файлов. Единицы, которые сообщаются клиенту как доступные, упоминаются как сегменты.
[0230] Помимо прочего описание представления мультимедиа может содержать элементы и атрибуты, как указано ниже.
[0231] Элемент MediaPresentationDescription
[0232] Элемент, инкапсулирующий метаданные, используемые клиентом потоковой передачи HTTP, чтобы предоставить услугу потоковой передачи конечному пользователю. Элемент MediaPresentationDescription может содержать один или более следующих атрибутов и элементов.
[0233] Version: Номер версии для протокола, чтобы гарантировать расширяемость.
[0234] Presentationldentifier: Информация такая, что представление может быть уникально идентифицировано среди других представлений. Может также содержать частные поля или названия.
[0235] UpdateFrequency: частота обновления описания представления мультимедиа, то есть, как часто клиент может повторно загрузить фактическое описание представления мультимедиа. Если не присутствует, представление мультимедиа может быть статическим. Обновление представления мультимедиа может означать, что представление мультимедиа не может быть кэшировано.
[0236] MediaPresentationDescriptionURI: URI для того, чтобы датировать описание представления мультимедиа.
[0237] Stream: Описывает тип представления мультимедиа или потока: видео, аудио или текст. Тип потока Видео может содержать аудио и может содержать текст.
[0238] Service: Описывает тип услуги с дополнительными атрибутами. Типы услуг могут быть «вживую» и по требованию. Это может использоваться, чтобы сообщить клиенту, что поиск и доступ вне некоторого текущего времени не разрешены.
[0239] MaximumClientPreBufferTime: максимальное количество времени, в течение которого клиент может предварительно буферизовать поток мультимедиа. Это тактирование может различать передачу в виде потока от прогрессивной загрузки, если клиент ограничен загрузкой вне этого максимального времени предварительной буферизации. Это значение может не присутствовать, указывая, что никакие ограничения в терминах предварительной буферизации могут не применяться.
[0240] SafetyGuardlntervalLiveService: Информация относительно максимального времени цикла «живой» услуги в сервере. Предоставляет индикацию клиенту, какая информация уже доступна в текущее время. Эта информация может быть необходимой, если ожидается, что клиент и сервер будут работать во время UTC, и никакая жесткая синхронизация времени не предоставлена.
[0241] TimeShiftBufferDepth: Информация о том, как далеко назад клиент может двигаться в «живой» услуге относительно текущего времени. Расширяя эту глубину, услуги просмотра смещения во времени и захвата могут быть разрешены без специальных изменений в обеспечении услуги.
[0242] LocalCachingPermitted: Этот флаг указывает, может ли клиент HTTP кэшировать загруженные данные локально после того, как он был проигран.
[0243] LivePresentationlnterval: Содержит временные интервалы, во время которых представление может быть доступным, задавая StartTimes и EndTimes. StartTime указывает начальное время услуги, и EndTime указывает время окончания услуги. Если EndTime не определено, то время окончания неизвестно в текущее время, и UpdateFrequency может гарантировать, что клиенты получают доступ ко времени окончания перед фактическим временем окончания услуги.
[0244] OnDemandAvailabilityInterval: Интервал представления указывает доступность услуги в сети. Могут быть обеспечены множественные интервалы представления. Клиент HTTP может быть не в состоянии получить доступ к услуге вне какого-либо заданного временного окна. Обеспечивая OnDemandAvailabilityInterval, дополнительный просмотр смещения во времени может быть определен. Этот атрибут может также присутствовать для «живой» услуги. В случае, если он присутствует для «живой» услуги, сервер может гарантировать, что клиент может получить доступ к услуге как к услуге OnDemand (по требованию) во время всех предоставленных интервалов доступности. Поэтому, LivePresentationlnterval может не перекрываться ни с каким OnDemandAvailabilitylnterval.
[0245] MPDFilelnfoDynamic: Описывает динамическую конструкцию файлов по умолчанию в представлении мультимедиа. Более подробно описано ниже. Спецификация по умолчанию на уровне MPD может сэкономить не необходимое повторение, если используются одинаковые правила для нескольких или всех альтернативных представлений.
[0246] MPDCodecDescription: Описывает главные кодеки по умолчанию в представлении мультимедиа. Более подробно описано ниже. Спецификация по умолчанию на уровне MPD может сэкономить не необходимое повторение, если используются одинаковые кодеки для нескольких или всех представлений.
[0247] MPDMoveBoxHeaderSizeDoesNotChange: флаг, чтобы указать, изменяется ли Заголовок MoveBox по размеру среди отдельных файлов в пределах всего представления мультимедиа. Этот флаг может использоваться, чтобы оптимизировать загрузку и может присутствовать только в случае специфических форматов сегментов, особенно тех, для которых сегменты содержат заголовок moov.
[0248] FileURIPattern: шаблон, используемый клиентом, чтобы генерировать сообщения запроса для файлов в пределах представления мультимедиа. Различные атрибуты допускают генерирование уникальных указателей URI для каждого из файлов в пределах представления мультимедиа. Основные URI могут быть URI HTTP.
[0249] Альтернативное Представление: Описывает список представлений.
[0250] Элемент AlternativeRepresentation:
[0251] Элемент XML, который инкапсулирует все метаданные для одного представления. Элемент AlternativeRepresentation может содержать следующие атрибуты и элементы.
[0252] RepresentationID: уникальный ID для этого конкретного Альтернативного Представления в пределах представления мультимедиа.
[0253] FileslnfoStatic: Обеспечивает явный список начальных времен и URI всех файлов одного альтернативного представления. Статическое обеспечение списка файлов может обеспечить преимущество точного описания тактирования представления мультимедиа, но это может быть не компактным, особенно если альтернативное представление содержит много файлов. Кроме того, имена файлов могут иметь произвольные названия.
[0254] FilesInfoDynamic: Обеспечивает неявный способ построить список начальных времен и URI одного альтернативного представления. Динамическое обеспечение списка файлов может обеспечить преимущество более компактного представления. Если только последовательность начальных времен предоставлена, то преимущества тактирования также обеспечиваются здесь, но имена файлов должны быть построены динамически базируемыми в FilePatternURI. Если только длительность каждого сегмента предоставлена, то представление является компактным и может быть подходящим для использования в пределах услуг «вживую» (в реальном времени), но генерированием файлов может управлять глобальное тактирование.
[0255] APMoveBoxHeaderSizeDoesNotChange: флаг, который указывает, изменяется ли заголовок MoveBox по размеру среди отдельных файлов в пределах Альтернативного Описания. Этот флаг может использоваться, чтобы оптимизировать загрузку, и может только присутствовать в случае специфических форматов сегмента, особенно тех, для которых сегменты содержат заголовок moov.
[0256] APCodecDescription: Описывает главные кодеки файлов в альтернативном представлении.
[0257] Элемент Описания Мультимедиа
[0258] MediaDescription: элемент, который может инкапсулировать все метаданные для мультимедиа, которое содержится в этом представлении. В частности, он может содержать информацию о дорожках в этом альтернативном представлении, так же как рекомендованное группирование дорожек, если применимо. Атрибут MediaDescription содержит следующие атрибуты:
[0259] TrackDescription: атрибут XML, который инкапсулирует все метаданные для мультимедиа, которое содержится в этом представлении. Атрибут TrackDescription содержит следующие атрибуты:
[0260] TrackID: уникальный ID для дорожки в пределах альтернативного представления. Он может использоваться в случае, если дорожка является частью описания группирования.
[0261] Bitrate: скорость передачи в битах дорожки.
[0262] TrackCodecDescription: атрибут XML, который содержит все атрибуты о кодеке, используемом в этой дорожке. Атрибут TrackCodecDescription содержит следующие атрибуты:
[0263] MediaName: атрибут, определяющий тип мультимедиа. Виды мультимедиа включают в себя "аудио", "видео", "текст", "приложение", и "сообщение".
[0264] Codec: Тип кодека, включающий профиль и уровень.
[0265] LanguageTag: Тэг языка, если применимо.
[0266] Макс Width, MaxHeight: Для видео - высота и ширина содержащегося видео в пикселях.
[0267] SamplingRate: Для аудио - частота выборок
[0268] GroupDescription: атрибут, который обеспечивает рекомендацию клиенту о соответствующем группировании, основанном на различных параметрах.
[0269] GroupType: тип, на основании которого клиент может решить как группировать дорожки.
[0270] Информация в описании представления мультимедиа выгодно используется клиентом потоковой передачи HTTP, чтобы выполнить запросы файлов/сегментов или их частей в подходящее время, выбирая сегменты из адекватных представлений, которые соответствуют его способностям, например в терминах полосы частот доступа, возможностей отображения, возможностей кодека, и так далее, а также предпочтений пользователя, таких как язык, и так далее. Кроме того, поскольку описание Представления Мультимедиа описывает представления, которые выровнены во времени и отображены на шкалу глобального времени, клиент может также использовать эту информацию в MPD во время текущего представления мультимедиа для инициирования надлежащих действий, чтобы переключаться по представлениям, чтобы представить представления совместно или осуществить поиск в пределах представления мультимедиа.
СИГНАЛИЗАЦИЯ ВРЕМЕН НАЧАЛА СЕГМЕНТА
[0271] Представление может быть разбито во времени на множественные сегменты. Проблема тактирования между дорожками существует между последним фрагментом одного сегмента и следующим фрагментом следующего сегмента. Кроме того, другая проблема тактирования существует в случае, когда используются сегменты постоянной длительности.
[0272] Использование одной и той же длительности для каждого сегмента может иметь преимущество, что MPD является и компактным и статическим. Однако каждый сегмент может все еще начинаться в Точке Произвольного доступа. Таким образом, или кодирование видео может быть ограничено, чтобы обеспечивать Точки Произвольного доступа в этих конкретных точках, или фактические длительности сегмента могут не быть точно такими, как определено в MPD. Может быть желательно, чтобы система потоковой передачи не устанавливала ненужные ограничения для процесса кодирования видео, и таким образом вторая опция может быть предпочтительной.
[0273] В частности, если длительность файла задана в MPD как d секунд, то n-й файл может начаться с Точки Произвольного доступа в или немедленно после времени (n-1)d.
[0274] В этом подходе каждый файл может включать в себя информацию относительно точного начального времени сегмента в терминах глобального времени представления. Три возможных способа сигнализировать это включают в себя:
[0275] (1) Первый, ограничить начальное время каждого сегмента точным тактированием, как определено в MPD. Но тогда кодер мультимедиа может не иметь никакой гибкости по размещению кадров IDR и может требовать специального кодирования для потоковой передачи файла.
[0276] (2) Второй, добавить точное начальное время к MPD для каждого сегмента. Для случая «по требованию», компактность MPD может быть уменьшена. Для случая «вживую» это может потребовать регулярного обновления MPD, что может уменьшить масштабируемость.
[0277] (3) Третье, добавить глобальное время или точное начальное время относительно объявленного начального времени представления или объявленного начального времени сегмента в MPD для сегмента в том смысле, что сегмент содержит эту информацию. Она может быть добавлена к новому полю, выделенному адаптивной передаче в виде потока. Это поле может также включать в себя информацию в соответствии с полем "SIDX" или "TIDX". Следствием этого третьего подхода является то, что при поиске конкретной позиции около начала одного из сегментов клиент, на основании MPD, может выбрать последующий сегмент для того сегмента, который содержит необходимую точку поиска. Простым ответом в этом случае может быть переместить начальную точку вперед к началу извлеченного сегмента (то есть, к следующей Точке Произвольного доступа после этой точки поиска). Обычно, Точки Произвольного доступа предоставляются, по меньшей мере, каждые несколько секунд (и часто есть небольшой выигрыш кодирования от создания их менее частыми), и таким образом, в худшем случае точка поиска может быть перемещена, чтобы быть на несколько секунд позже, чем заданная. Альтернативно, клиент может определить при восстановлении информации заголовка для сегмента, что запрошенная точка поиска находится фактически в предыдущем сегменте и запросить вместо данной такой сегмент. Это может привести к случайному увеличению во времени, требуемом для выполнения операции поиска.
СПИСОК ДОСТУПНЫХ СЕГМЕНТОВ
[0278] Представление мультимедиа содержит набор представлений, каждое обеспечивает некоторую отличную версию кодирования для первоначального контента мультимедиа. Представления непосредственно предпочтительно содержат информацию относительно разностных параметров представления по сравнению с другими параметрами. Они также содержат, или явно или неявно, список доступных сегментов.
[0279] Сегменты могут быть дифференцированы в сегменты без времени, содержащие только метаданные, и сегменты мультимедиа, которые, прежде всего, содержат данные мультимедиа. Описание Представления Мультимедиа ("MPD") выгодно предпочтительно идентифицирует и назначает различные атрибуты на каждый из сегментов, или неявно или явно. Атрибуты, предпочтительно назначенные на каждый сегмент, содержат период, во время которого сегмент доступен, ресурсы и протоколы, посредством которых сегменты являются доступными. Кроме того, сегментам мультимедиа предпочтительно назначают атрибуты, такие как начальное время сегмента в представлении мультимедиа, и длительность сегмента в представлении мультимедиа.
[0280] Когда представление мультимедиа имеет тип "по требованию", как предпочтительно указано атрибутом в описании представления мультимедиа, таким как OnDemandAvailabilitylnterval, то описание представления мультимедиа обычно описывает все сегменты и также обеспечивает индикацию, когда сегменты доступны и когда сегменты не доступны. Начальные времена сегментов предпочтительно выражаются относительно начала представления мультимедиа таким образом, что два клиента, начинающие воспроизведение одних и тех же представлений мультимедиа, но в разное время, могут использовать одно и то же описание представления мультимедиа так же как и те же самые сегменты мультимедиа. Это выгодно улучшает способность кэшировать сегменты.
[0281] Когда представление мультимедиа имеет "живой" тип, что предпочтительно обозначено атрибутом в описании представления мультимедиа, таким как атрибут Service, то сегменты, содержащие это представление мультимедиа вне фактического времени дня обычно не генерируется, или, по меньшей мере, не доступны, несмотря на то, что эти сегменты полностью описаны в MPD. Однако, с индикацией, что услуга представления мультимедиа имеет "живой" тип, клиент может сформировать список доступных сегментов вместе с атрибутами тактирования для клиентского внутреннего времени NOW (Сейчас) по времени настенных часов, на основании информации, содержащейся в MPD и времени загрузки MPD. Сервер предпочтительно работает в том смысле, что он делает ресурс доступным таким образом, что эталонный клиент, оперирующий с экземпляром MPD по времени настенных часов NOW, может получить доступ к этим ресурсам.
[0282] В частности, эталонный клиент формирует список доступных сегментов вместе с атрибутами тактирования для клиентского внутреннего времени NOW по времени настенных часов, на основании информации, содержащейся в MPD, и времени загрузки MPD. При продвижении во времени клиент будет использовать один и тот же MPD и создаст новый список доступных сегментов, который может использоваться, чтобы непрерывно проигрывать представление мультимедиа. Поэтому, сервер может объявить о сегментах в MPD прежде, чем эти сегменты будут фактически доступны. Это выгодно, поскольку это уменьшает частое обновление и загрузку MPD.
[0283] Предположим, что список сегментов, каждый с начальным временем, tS, описан или явно посредством проигрывания в элементах, таких как FilelnfoStatic, или неявно посредством использования элемента, такого как FilelnfoDynamic. Предпочтительный способ, чтобы сгенерировать список сегментов, используя FilelnfoDynamic, описан ниже. На основании этом правила конструирования клиент имеет доступ к списку URI для каждого представления, r, упомянутого здесь как FileURI (r, z), и начальному времени tS (r, i) для каждого сегмента с индексом i.
[0284] Использование информации в MPD, чтобы создать доступное окно времени для сегментов может быть выполнено, используя следующие правила.
[0285] Для услуги типа "по требованию", что предпочтительно указано атрибутом, таким как Service, если текущее время настенных часов в клиенте NOW находится в пределах какого-нибудь диапазона доступности, предпочтительно выраженного элементом MPD, таким как OnDemandAvailabilitylnterval, то все описанные сегменты этого представления «по требованию» являются доступными. Если текущее время настенных часов в клиенте NOW находится вне какого-нибудь диапазона доступности, то ни один из описанных сегментов этого представления «по требованию» не доступен.
[0286] Для услуги "живого" типа, что предпочтительно указано атрибутом, таким как Service, начальное время tS (r, i) предпочтительно выражает время доступности во время настенных часов. Начальное время доступности может быть получено как комбинация услуги времени «живого» события и некоторого времени оборота в сервере для захвата, кодирования и публикации. Время для этого процесса может, например, быть задано в MPD, например, используя заданный защитный интервал tG безопасности, например, заданный как SafetyGuardlntervalLiveService в MPD. Это может обеспечить минимальную разность между временем UTC и доступностью данных на сервере потоковой передачи HTTP. В другом варианте осуществления MPD явно задает время доступности сегмента в MPD без предоставления времени оборота как разности между живым временем и временем оборота события. В следующих описаниях предполагается, что любые глобальные времена заданы как времена доступности. Специалист в области техники живого радиовещания мультимедиа может получить эту информацию из подходящей информации в описании представления мультимедиа после прочтения настоящего описания.
[0287] Если текущее время настенных часов в клиенте NOW находится вне какого-либо диапазона интервала «живого» представления, предпочтительно выраженного элементом MPD, таким как LivePresentationlnterval, то ни один из описанных сегментов этого живого представления не является доступным. Если текущее время настенных часов в клиенте NOW находится в пределах интервала «живого» представления, то, по меньшей мере, некоторые сегменты описанных сегментов этого «живого» представления могут быть доступными.
[0288] Ограничением доступных сегментов управляют следующие значения:
[0289] Время NOW настенных часов (в качестве доступного для клиента).
[0290] Глубина tTSB буфера разрешенного сдвига во времени, например, определенная как TimeShiftBufferDepth в описании представления мультимедиа.
[0291] Клиенту в относительное время t1 события может быть, только разрешено запросить сегменты с начальными временами tS (r, i) в интервале (NOW - tTSB) и NOW или в интервале таким образом, что время окончания сегмента с длительностью d также включено, приводя к интервалу (NOW - tTSB-d) и NOW.
ОБНОВЛЕНИЕ MPD
[0292] В некоторых вариантах осуществления сервер не знает заранее указатель файла или сегмента и начальные времена сегментов, когда, например, указатель сервера будет изменяться, или представление мультимедиа включает в себя некоторое объявление от другого сервера, или длительность представления мультимедиа неизвестна, или сервер хочет запутать указатель для следующих сегментов.
[0293] В таких вариантах осуществления сервер может только описать сегменты, которые уже доступны или становятся доступными вскоре после того, как этот экземпляр MPD опубликован. Кроме того, в некоторых вариантах осуществления, клиент предпочтительно потребляет мультимедиа близко к мультимедиа, описанному в MPD, таким образом, что пользователь воспринимает содержащуюся программу мультимедиа так близко насколько это возможно к генерированию контента мультимедиа. Как только клиент ожидает, что он достиг конца описанных сегментов мультимедиа в MPD, он предпочтительно запрашивает новый экземпляр MPD, чтобы продолжить непрерывное проигрывание в ожидании, что сервер опубликовал новое MPD, описывающее новые сегменты мультимедиа. Сервер предпочтительно генерирует новые экземпляры MPD и обновляет MPD таким образом, что клиенты могут положиться на процедуры для непрерывных обновлений. Сервер может адаптировать свои процедуры обновления MPD вместе с генерированием сегмента и публикацией к процедурам эталонного клиента, который действует так, как может действовать обычный клиент.
[0294] Если новый экземпляр MPD описывает только короткое продвижение во времени, то клиенты должны часто запрашивать новые экземпляры MPD. Это может привести к проблемам масштабируемости и ненужному трафику восходящей линии связи и нисходящей линии связи из-за ненужных частых запросов.
[0295] Поэтому, это релевантно, с одной стороны, описанию сегментов в максимально возможной степени в будущем без необходимости еще делать их доступными, и с другой стороны, разрешению непредвиденным обновлениям в MPD выразить новые местоположения сервера, разрешению вставить новый контент, такой как рекламные объявления, или обеспечить изменения в параметрах кодека.
[0296] Кроме того, в некоторых вариантах осуществления длительность сегментов мультимедиа может быть малой, такой как в диапазоне нескольких секунд. Длительность сегментов мультимедиа является предпочтительно гибкой, чтобы приспособиться к подходящим размерам сегмента, которые могут быть оптимизированы к свойствам доставки или кэширования, чтобы скомпенсировать сквозную задержку услуг в реальном времени или другие аспекты, которые имеют дело с хранением или доставкой сегментов, или по другим причинам. В частности, в случаях, когда сегменты являются малыми по сравнению с длительностью представления мультимедиа, то существенное количество ресурсов и начальных времен сегмента мультимедиа должно быть описано в описании представления мультимедиа. В результате, размер описания представления мультимедиа может быть большим, что может неблагоприятно затронуть время загрузки описания представления мультимедиа и поэтому влиять на задержку запуска представления мультимедиа и также использование полосы пропускания на линии связи доступа. Поэтому, предпочтительно не только разрешать описание списка сегментов мультимедиа, используя списки воспроизведения, но также разрешать описание посредством использования шаблонов или правил построения URL. Шаблоны и правила построения URL используются синонимично в этом описании.
[0297] Кроме того, шаблоны могут предпочтительно использоваться, чтобы описать указатель сегмента в «живых» случаях помимо текущего времени. В таких случаях обновления MPD являются по существу ненужными, поскольку указатели, так же как и список сегментов, описаны шаблонами. Однако, непредвиденные события все еще могут случаться, которые требуют изменений в описании представлений или сегментов. Изменения в адаптивном описании представления мультимедиа потокового HTTP могут быть необходимы, когда контент из множественных различных источников соединяется вместе, например, когда была вставлена реклама. Контент из различных источников может отличаться множеством способов. Другой причиной во время «живых» представлений является та, что может быть необходимо, изменить указатели URL, используемые для файлов контента, чтобы предусмотреть отказоустойчивое переключение от одного «живого» исходного сервера к другому.
[0298] В некоторых вариантах осуществления предпочтительно, что, если MPD обновлен, то обновления MPD выполняются таким образом, что обновленное MPD совместимо с предыдущим MPD в следующем смысле, что эталонный клиент и поэтому любой реализованный клиент, генерируют идентично функциональный список доступных сегментов из обновленного MPD в течение любого времени вплоть до времени достоверности предыдущего MPD, когда это будет сделано из предыдущего экземпляра MPD. Это требование гарантирует, что (a) клиенты могут немедленно начать использовать новый MPD без синхронизации со старым MPD, так как оно совместимо со старым MPD перед временем обновления; и (b) время обновления не должно быть синхронизировано со временем, в которое имеет место фактическое изменение MPD. Другими словами, обновления MPD могут быть объявлены заранее, и сервер может заменить старый экземпляр MPD, как только новая информация доступна, не имея необходимости поддерживать различные версии MPD.
[0299] Две возможности могут существовать для тактирования мультимедиа при обновлении MPD для набора представлений или всех представлений. Или (a) существующая шкала глобального времени продолжается через обновление MPD (упомянутое здесь как "непрерывное обновление MPD"), или (b), шкала текущего времени заканчивается, и новая шкала времени начинается с сегмента, следующего после изменения (упомянутое здесь как "прерывистое обновление MPD").
[0300] Разница между этими вариантами может быть очевидна, полагая, что дорожки Фрагмента Мультимедиа, и, следовательно, Сегмента, обычно не начинаются и не заканчиваются в одно и то же время из-за отличающейся степени детализации выборок по дорожкам. Во время нормального представления выборки одной дорожки фрагмента могут быть воспроизведены перед некоторыми выборками другой дорожки предыдущего фрагмента, то есть, имеется некоторый вид наложения между фрагментами, хотя может не быть наложения в пределах одной дорожки.
[0301] Разница между (a) и (b) заключается в том, может ли такое наложение быть разрешено через обновление MPD. Когда обновление MPD происходит из-за соединения полностью отдельного контента, такое наложение является обычно трудным для достижения, поскольку новый контент нуждается в новом кодировании, чтобы быть соединенным с предыдущим контентом. Поэтому предпочтительно обеспечить способность прерывистого обновления представления мультимедиа, посредством перезапуска шкалы времени для некоторых сегментов и возможно также определения нового набора представлений после обновления. Кроме того, если контент был независимо кодирован и сегментирован, то также избегают настраивать отметки времени для соответствия в пределах шкалы глобального времени предыдущей части контента.
[0302] Когда обновление происходит по менее важным причинам, таким как только добавление новых сегментов мультимедиа к списку описанных сегментов мультимедиа, или если местоположение URL изменено, то наложение и непрерывные обновления могут быть разрешены.
[0303] В случае прерывистого обновления MPD шкала времени последнего сегмента предыдущего представления заканчивается в самом последнем моменте времени окончания представления любой выборки в сегменте. Шкала времени следующего представления (или, более точно, первый момент времени представления первого сегмента мультимедиа новой части представления мультимедиа, также называемый новым периодом) обычно и предпочтительно начинается в тот же момент, что и конец представления последнего периода, так что плавное и непрерывное проигрывание обеспечивается.
[0304] Эти два случая иллюстрируются на Фиг. 11.
[0305] Предпочтительно и выгодно ограничить обновления MPD, чтобы сегментировать границы. Объяснения для ограничения таких изменений или обновлений границ сегментов следующие. Во-первых, изменения к двоичным метаданным для каждого представления, обычно Заголовка Кино, могут иметь место, по меньшей мере, по границам сегмента. Во-вторых, Описание Представления Мультимедиа может содержать указатели (URL) на сегменты. В некотором смысле MPD является структурой данных "зонтик", группирующей все файлы сегмента, ассоциированные с представлением мультимедиа. Чтобы поддерживать эти отношения ограничения, на каждый сегмент можно ссылаться посредством единственного MPD и когда MPD обновлен, оно предпочтительно обновляется только по границе сегмента.
[0306] Границы сегментов обычно не требуется выравнивать, однако для случая контента, соединенного из различных источников, и для прерывистых обновлений MPD, обычно имеет смысл выравнивать границы сегментов (в частности, что последний сегмент каждого представления может закончиться в одном и том же видео кадре и может не содержать аудио выборки с начальным временим представления позже, чем время представления этого кадра). Прерывистое обновление может затем начать новый набор представлений в общий момент времени, называемое периодом. Начальное время достоверности этого нового набора представлений обеспечивается, например, посредством начального времени периода. Относительное начальное время каждого представления сбрасывается в ноль, и начальное время этого периода помещает набор представлений в этот новый период в шкале глобального времени представления мультимедиа.
[0307] Для непрерывных обновлений MPD границы сегмента не должны быть выровнены. Каждым сегментом каждого альтернативного представления может управлять единственное Описание Представления Мультимедиа, и таким образом запросы обновления для новых экземпляров Описания Представления Мультимедиа, обычно запускаемые ожиданием, что никакие дополнительные сегменты мультимедиа не описаны в работающем MPD, могут иметь место в разные моменты времени в зависимости от потребляемого набора представлений, включающего набор представлений, которые, как ожидают, должны потребляться.
[0308] Чтобы поддерживать обновления в элементах MPD и атрибуты в более общем случае, любые элементы не только представлений или наборов представлений могут быть ассоциированы со временем достоверности. Так, если некоторые элементы MDP должны быть обновлены, например, когда количество представлений изменяется, или правила построения URL изменяются, то эти элементы каждый могут быть обновлены отдельно в заданные моменты времени посредством обеспечения множественных копий элемента с несвязными временами достоверности.
[0309] Достоверность предпочтительно ассоциирована с глобальным временем мультимедиа, таким образом, что описанный элемент, ассоциированный со временем достоверности, является действительным в период шкалы глобального времени представления мультимедиа.
[0310] Как описано выше, в одном варианте осуществления, времена достоверности только добавляются к полному набору представлений. Каждый полный набор затем формирует период. Время достоверности затем формирует начальное время периода. Другими словами, в конкретном случае использования элемента достоверности полный набор представлений может быть достоверным в течение периода в течение времени, указанном глобальным временем достоверности для набора представлений. Время достоверности набора представлений называется периодом. В начале нового периода истекает достоверность представления предыдущего набора, и новый набор представлений является достоверным. Следует снова отметить, что времена достоверности периодов являются предпочтительно несвязными.
[0311] Как отмечено выше, изменения к Описанию Представления Мультимедиа имеют место на границах сегмента, и таким образом для каждого представления изменение элемента фактически имеет место на границе следующего сегмента. Клиент может затем сформировать достоверное MPD, включающее в себя список сегментов в течение каждого момента времени в пределах времени представления мультимедиа.
[0312] Прерывистое соединение блоков может быть подходящим в случаях, когда блоки содержат данные мультимедиа из различных представлений, или из другого контента, например из сегмента контента и рекламы, или в других случаях. Может требоваться в системе потоковой передачи с запросом блоков, что изменения к метаданным представления имеют место только на границах блоков. Это может быть выгодным по причинам реализации, так как обновление параметров декодера мультимедиа в пределах блока может быть более сложным, чем обновление их только между блоками. В этом случае, может быть предпочтительно определено, что интервалы достоверности, как описано выше, могут быть интерпретированы как приблизительные, так что элемент считается достоверным от границы первого блока не ранее чем начало указанного интервала достоверности до границы первого блока не ранее, чем конец указанного интервала достоверности.
[0313] Примерный вариант осуществления вышеупомянутых описанных новых усовершенствований в системе потоковой передачи с запросом блоков, описан в ниже представленной секции Изменения в Представлениях Мультимедиа.
СИГНАЛИЗАЦИЯ ДЛИТЕЛЬНОСТИ СЕГМЕНТА
[0314] Прерывистые обновления эффективно делят представление на набор несвязных интервалов, названных периодом. Каждый период имеет свою собственную шкалу времени для тактирования выборок мультимедиа. Тактирование мультимедиа представления в пределах периода может быть предпочтительно указано посредством задания отдельного компактного списка длительностей сегмента в течение каждого периода или в течение каждого представления в периоде.
[0315] Атрибут, например, обозначаемый как начальное время периода, связанный с элементами в MPD, может задать время достоверности некоторых элементов в пределах времени представления мультимедиа. Этот атрибут может быть добавлен к любым элементам (атрибуты, которым можно назначить достоверность, могут быть изменены в элементы) MPD.
[0316] В течение прерывистых обновлений MPD сегменты всех представлений могут закончиться при прерывании. Это обычно подразумевает, по меньшей мере, что последний сегмент перед прерыванием имеет отличную длительность от предыдущих. Сигнализация длительности сегмента может включать в себя указание или что все сегменты имеют одну и ту же длительность или указание отдельной длительности для каждого сегмента. Может быть, желательно иметь компактное представление для списка длительностей сегмента, что является эффективным в случае, чтобы у многих из них была одна и та же длительность.
[0317] Длительности каждого сегмента в одном представлении или наборе представлений могут предпочтительно быть выполнены с единственной последовательностью, которая задает все длительности сегмента для единственного интервала от начала прерывистого обновления, то есть, начала периода, пока последний сегмент мультимедиа не будет описан в MPD. В одном варианте осуществления форматом этого элемента является текстовая строка, соответствующая произведению, которое содержит список записей длительности сегментов, когда каждая запись содержит атрибут длительности dur и дополнительный множитель mult атрибута, указывающего, что это представление содержит <mult> первых сегментов записи длительности <dur> первой записи, затем <mult> вторых сегментов записи длительности <dur> второй записи и так далее.
[0318] Каждая запись длительности задает длительность одного или более сегментов. Если значение <dur> сопровождается символом "*" и числом, то это число задает количество последовательных сегментов с этой длительностью в секундах. Если знак умножения "*" отсутствует, число сегментов равно одному. Если "*" присутствует без последующего числа, то все последующие сегменты имеют указанную длительность и в списке не может быть никаких других записей. Например, последовательность "30*" означает, что все сегменты имеют длительность 30 секунд. Последовательность "30*12 10,5" указывает 12 сегментов длительностью 30 секунд, с последующей одной длительностью 10,5 секунд.
[0319] Если длительности сегмента заданы отдельно для каждого альтернативного представления, то сумма длительностей сегмента в пределах каждого интервала может быть одной и той же для каждого представления. В случае видеодорожек интервал может закончиться на одном и том же кадре в каждом альтернативном представлении.
[0320] Специалисты в данной области техники после прочтения этого раскрытия могут найти подобные и эквивалентные способы выразить длительности сегмента компактным способом.
[0321] В другом варианте осуществления длительность сегмента сигнализируется как постоянная для всех сегментов в представлении, за исключением последнего, посредством атрибутом длительности сигнала <длительность>. Длительность последнего сегмента перед прерывистым обновлением может быть короче при условии, что начальная точка следующего прерывистого обновления или начало нового периода обеспечены, что затем подразумевает длительность последнего сегмента, достигающего начала следующего периода.
ИЗМЕНЕНИЯ И ОБНОВЛЕНИЯ К МЕТАДАННЫМ ПРЕДСТАВЛЕНИЯ
[0322] Указание изменений набора кодированных двоичных метаданных представления, таких как изменения заголовка кино "moov" могут быть достигнуты по-разному: (a) может быть одно поле moov для всего представления в отдельном файле, на который ссылаются в MPD, (b) может быть одно поле moov для каждого альтернативного представления в отдельном файле, на который ссылаются в каждом Альтернативном Представлении, (c), каждый сегмент может содержать поле moov и является, поэтому отдельным, (d) может быть поле moov для всего представления в одном 3GP файле вместе с MPD.
[0323] Следует отметить, что в случае (a) и (b) единственное 'moov' может быть предпочтительно объединено с понятием достоверности выше в том смысле, что на большее количество 'moov' полей можно сослаться в MPD, пока их достоверность является несвязной. Например, с определением границы периода достоверность 'moov' в старом периоде может истечь с началом нового периода.
[0324] В случае выбора (a) ссылке на единственное поле moov можно назначить элемент достоверности. Множественные заголовки представления могут быть разрешены, но только один может быть действительным одновременно. В другом варианте осуществления время достоверности всего набора представлений в некоторый период или весь этот период, как определено выше, может использоваться как время достоверности для метаданных этого представления, обычно предоставляемых как заголовок moov.
[0325] В случае выбора (b), ссылке на поле moov каждого представления можно назначить элемент достоверности. Множественные заголовки представления могут быть разрешены, но только один может быть достоверным одновременно. В другом варианте осуществления время достоверности всего представления или всего периода, как определено выше, может использоваться как время достоверности для метаданных этого представления, обычно предоставляемых как заголовок moov.
[0326] В случае опций (c), никакая сигнализация не может быть добавлена в MPD, но дополнительная сигнализация в потоке мультимедиа может быть добавлена, чтобы указать, изменится ли поле moov для какого-либо из наступающих сегментов. Это далее объясняется ниже в контексте "Сигнализации обновлений в пределах метаданных сегмента".
СИГНАЛИЗАЦИИ ОБНОВЛЕНИЙ В ПРЕДЕЛАХ МЕТАДАННЫХ СЕГМЕНТА
[0327] Чтобы избежать частых обновлений описания представления мультимедиа, чтобы получить знание относительно потенциальных обновлений, предпочтительно сигнализировать любые такие обновления вместе с сегментами мультимедиа. Может быть обеспечен дополнительный элемент или элементы внутри самих сегментов мультимедиа, которые могут указывать, что обновленные метаданные, такие как описание представления мультимедиа, доступны, и к которым должен быть получен доступ в пределах некоторого количества времени, чтобы успешно продолжить создание списка доступных сегментов. Кроме того, такие элементы могут обеспечить идентификатор файла, такой как URL, или информацию, которая может использоваться, чтобы построить идентификатор файла для обновленного файла метаданных. Обновленный файл метаданных может включать в себя метаданные, равные таковым, предоставленным в первоначальном файле метаданных для этого представления, модифицированные, чтобы указать интервалы достоверности вместе с дополнительными метаданными, также сопровождаемыми интервалами достоверности. Такая индикация может быть обеспечена в сегментах мультимедиа всех доступных представлений для представления мультимедиа. Клиент, получающий доступ к системе потоковой передачи с запросом блоков, при обнаружении такой индикации в пределах блока мультимедиа, может использовать протокол загрузки файлов или другое средство, чтобы извлечь обновленный файл метаданных. Клиент, таким образом, обеспечивается информацией об изменениях в описании представления мультимедиа и времени, в которое они произойдут или произошли. Выгодно, что каждый клиент запрашивает обновленное описание представления мультимедиа только однажды, когда такие изменения происходят, вместо того, чтобы "опрашивать" и принимать файл много раз для возможных обновлений или изменений.
[0328] Примеры изменений включают в себя дополнение или удаление представлений, изменения к одному или более представлениям, такие как изменение в скорости передачи в битах, разрешения, формата изображения, включенных дорожек или параметров кодека, и изменения правил построения URL, например, другой исходный сервер для рекламы. Некоторые изменения могут затронуть только сегмент инициализации, такой как элемент, Заголовок Кино ("moov"), ассоциированный с представлением, тогда как другие изменения могут затронуть Описание Представления Мультимедиа (MPD).
[0329] В случае контента «по требованию» эти изменения и их тактирование могут быть известны заранее и могут быть сообщены в Описании Представления Мультимедиа.
[0330] Для «живого» контента изменения могут быть не известны до точки, в которой они происходят. Одно решение состоит в том, чтобы разрешить динамически обновлять Описание Представления Мультимедиа, доступное в конкретном URL, и потребовать, чтобы клиенты регулярно запрашивали это MPD, чтобы обнаружить изменения. Это решение имеет неудобство в терминах масштабируемости (загрузка исходного сервера и эффективность кэша). В сценарии с большими количествами зрителей кэши могут принять много запросов MPD после того, как предыдущая версия истекла, от кэша и прежде, чем новая версия будет принята, и все они могут быть отправлены исходному серверу. Исходный сервер может быть обязан постоянно обрабатывать запросы от кэшей для каждой обновленной версии MPD. Кроме того, обновления могут не быть легко выровнены во времени с изменениями в представлении мультимедиа.
[0331] Так как одним из преимуществ потоковой передачи HTTP является способность использовать стандартную инфраструктуру сети и услуги для масштабируемости, предпочтительное решение может включать в себя только "статические" (то есть кэшируемые) файлы и не полагаться на клиентов, «опрашивающих» файлы, чтобы увидеть, изменились ли они.
[0332] Решения описаны и предложены, чтобы обеспечить обновление метаданных, включая описание представления мультимедиа и двоичные метаданные представления, такие как элементы "moov" в представлении адаптивного потокового мультимедиа HTTP.
[0333] Для случая «живого» контента точки, в которых могут измениться MPD или "moov", могут не быть известны, когда MPD строится. Поскольку частого "опроса" MPD, чтобы проверить на обновления, необходимо обычно избегать по причинам полосы частот и масштабируемости, обновления к MPD могут быть обозначены "в диапазоне" в самих файлах сегментов, то есть, каждый сегмент мультимедиа может иметь опцию, чтобы указать обновления. В зависимости от форматов (a)-(c) сегментов выше, различное обновление может быть сигнализировано.
[0334] Обычно, следующая индикация предпочтительно может быть обеспечена в сигнале в пределах сегмента: индикатор, что MPD может быть обновлено до запроса следующего сегмента в пределах этого представления или любого следующего сегмента, который имеет начальное время большее, чем начальное время текущего сегмента. Это обновление может быть объявлено, заранее указывая, что обновление должно только случиться в любом сегменте, более позднем, чем следующий. Это обновление MPD может также использоваться, чтобы обновить двоичные метаданные представления, такие как Заголовки Кино, в случае, если указатель сегмента мультимедиа изменен. Другой сигнал может указать, что с завершением этого сегмента нельзя запрашивать другие сегменты, которые «продвигают» время.
[0335] В случае, если сегменты отформатированы согласно формату (c) сегментов, то есть каждый сегмент мультимедиа может содержать самоинициализирующие метаданные, такие как заголовок кино, то еще один сигнал может быть добавлен, указывающий, что последующий сегмент содержит обновленный Заголовок Кино (moov). Это предпочтительно позволяет включить заголовок кино в сегмент, но Заголовок Кино должен быть только запрошен клиентом, если предыдущий сегмент указывает Обновление Заголовка Кино или в случае поиска или произвольного доступа при переключении представлений. В других случаях клиент может выдать запрос диапазона в байтах к сегменту, который исключает заголовок кино из загрузки, поэтому предпочтительно экономя полосу пропускания.
[0336] В еще одном варианте осуществления, если индикация Обновления MPD сигнализирована, то сигнал может также содержать указатель, такой как URL, для обновленного Описания Представления Мультимедиа. Обновленное MPD может описывать представление и до и после обновления, используя атрибуты достоверности, такие как новый и старый период, в случае прерывистых обновлений. Это может предпочтительно использоваться, чтобы разрешить просмотр сдвига во времени, как описано далее ниже, но также предпочтительно позволяет сигнализировать обновление MPD в любое время, прежде чем изменения, которые оно содержит, вступают в силу. Клиент может немедленно загрузить новое MPD и применить его к текущему представлению.
[0337] В конкретной реализации сигнализация любых изменений к описанию представления мультимедиа, заголовкам moov или концу представления может содержаться в поле информации потоковой передачи, которое отформатировано, следуя правилам формата сегмента, используя структуру поля формата файла мультимедиа на основе ISO. Это поле может обеспечить конкретный сигнал для любого из различных обновлений.
[0338] Поле информации потоковой передачи
[0339] Определение
[0340] Тип Поля: 'sinf'
Контейнер: Нет
Обязательность: Нет
Количество: Ноль или один.
[0341] Поле Информации Потоковой Передачи содержит информацию о текущем представлении, частью которого является файл.
[0342] Синтаксис
[0343] aligned(8) class StreaminglnformationBox
extends FullBox('sinf') {
unsigned int(32) streaming_information_flags;
[0344] / Следующие поля являются опциональными
string mpd_location
}
[0345] Семантика
[0346] streaming_information_flags содержит логическое ИЛИ ноля или более из следующего:
[0347] 0x00000001 Обновление Заголовка Кино следует
[0348] 0x00000002 Обновление Описания Представления
[0349] 0x00000004 Конец представления
[0350] mpd_location присутствует, если и только если флаги Обновления Описания Представления установлены и обеспечивает Унифицированный Указатель Ресурса для нового Описания Представления Мультимедиа.
ПРИМЕРНЫЙ СЛУЧАЙ ИСПОЛЬЗОВАНИЯ ОБНОВЛЕНИЙ MPD ДЛЯ «ЖИВЫХ» УСЛУГ
[0351] Предположим, что поставщик услуг хочет обеспечить футбольное событие «вживую» (в реальном времени), используя расширенную потоковую передачу с запросом блоков, описанную здесь. Возможно, миллионы пользователей могут хотеть получить доступ к представлению этого события. Живое событие спорадически прерывается разрывами, когда вызываются таймауты или другое затишье в действии, во время которого могут быть добавлены рекламные объявления. Как правило, нет никакого или имеется небольшое предварительное уведомление точного тактирования перерывов.
[0352] Поставщик услуг может, нуждается в обеспечении избыточной инфраструктуры (например, кодеры и серверы), чтобы разрешить плавное переключение в случае, если любой из компонентов терпит неудачу во время «живого» события.
[0353] Предположим, что пользователь, Анна, получает доступ к услуге в автобусе с помощью ее мобильного устройства, и услуга доступна немедленно. Рядом с нею сидит другой пользователь, Пол, который просматривает событие на своем ноутбуке. Забит гол, и оба празднуют это событие в одно и то же время. Пол говорит Анне, что первый гол в игре был еще более захватывающим, и Анна использует услугу так, чтобы она могла просмотреть событие 30 минут назад во времени. После просмотра гола, она возвращается к «живому» (в реальном времени) событию.
[0354] Чтобы обеспечить этот случай использования, поставщик услуг должен быть в состоянии обновить MPD, чтобы сигнализировать клиентам, что обновленное MPD доступно, и разрешить клиентам получить доступ к услуге потоковой передачи таким образом, что можно было представить данные близко к реальному времени.
[0355] Обновление MPD выполнимо асинхронным способом для доставки сегментов, как описано в настоящем описании в другом месте. Сервер может обеспечить гарантии приемнику, что MPD не обновлено в течение некоторого времени. Сервер может положиться на текущее MPD. Однако никакая явная сигнализация не является необходимой, когда MPD обновляется перед некоторым минимальным периодом обновления.
[0356] Полностью синхронное проигрывание с трудом достигается, поскольку клиент может оперировать с различными экземплярами обновления MPD, и поэтому клиенты могут иметь отклонение. Используя обновления MPD, сервер может передать изменения, и клиенты могут быть оповещены об изменениях даже во время представления. Внутриполосная сигнализация на основе сегмент-за-сегментом может использоваться, чтобы указать обновление MPD, таким образом, обновления могут быть ограничены границами сегментов, но это должно быть приемлемым в большинстве приложений.
[0357] Элемент MPD может быть добавлен, который обеспечивает время публикации во времени настенных часов MPD, а так же дополнительное поле обновления MPD, которое добавляется в начале сегментов, чтобы сигнализировать, что требуется обновление MPD. Обновления могут быть сделаны иерархически, как с обновлениями MPD.
[0358] "Время публикации" MPD обеспечивает уникальный идентификатор для MPD, и когда MPD было выпущено. Это также обеспечивает привязку для процедур обновления.
[0359] Поле обновления MPD может быть найдено в MPD после поля "styp", и определено Типом Поля = "mupe", не нуждаясь ни в каком контейнере, не будучи обязательным и имеющим количество ноль или один. Поле обновления MPD содержит информацию о представлении мультимедиа, частью которого является сегмент.
[0360] Примерный синтаксис следующий:
[0361] aligned(8) class MPDUpdateBox
[0362] extends FullBox('mupe') {
[0363] unsigned int(3) mpd_information_flags;
[0364] unsigned int(l) new_location_flag;
[0365] unsigned int(28) latest_mpd_update_time;
[0366] /// Следующее является опциональными полями
[0367] string mpd_location
[0368] }
[0369] Семантика различных объектов класса MPDUpdateBox может быть следующей:
[0370] mpd_information_flags: логическое ИЛИ ноля или более из следующего:
[0371] 0×00 Описание Представления Мультимедиа обновить теперь
[0372] 0×01 Описание Представления Мультимедиа обновить в будущем
[0373] 0×02 Конец представления
[0374] 0×03-0×07 зарезервировано
[0375] new_location_flag: если установлен в 1, то новое Описание Представления Мультимедиа доступно в новом местоположении, определенном посредством mpd_location.
[0376] latest_mpd_update_time: определяет время (в миллисекундах), когда обновление MPD необходимо относительно времени выпуска MPD самого последнего MPD. Клиент может выбрать обновить MPD любое время между теперь.
[0377] mpd_location: присутствует, если и только если new_location_flag установлен и если это так, mpd_location обеспечивает Унифицированный указатель ресурса для нового Описания Представления Мультимедиа.
[0378] Если полоса частот, используемая обновлениями, является проблемой, сервер может предложить обновления MPD для некоторых возможностей устройства таким образом, что только эти части обновляются.
ПРОСМОТР СМЕЩЕНИЯ ВО ВРЕМЕНИ И PVR СЕТИ
[0379] Когда просмотр смещения во времени поддерживается, может случиться, что в течение всего времени сеанса два или более MPD или Заголовков Кино действительны. В этом случае посредством обновления MPD, когда необходимо, но добавляя механизм достоверности или концепцию периода, достоверное MPD может существовать в течение всего окна времени. Это означает, что сервер может гарантировать, что о любом MPD и заголовке кино объявляют в течение всего любого промежутка времени, который находится в пределах действительного окна времени для рассмотрения смещения во времени. Это соответствует клиенту, чтобы гарантировать, что его доступное MPD и метаданные в течение его текущего времени представления действительны. Перемещение «живого» сеанса в сетевой сеанс PVR, используя только незначительные обновления MPD, также может быть поддержано.
СПЕЦИАЛЬНЫЕ СЕГМЕНТЫ МУЛЬТИМЕДИА
[0380] Проблемой, когда формат файла ISO/IEC 14496-12 используется в системе потоковой передачи с запросом блоков, является та, что, как описано выше, может быть предпочтительно, хранить данные мультимедиа для единственной версии представления во множественных файлах, размещенных в последовательных сегментах времени. Кроме этого, может быть предпочтительно, скомпоновать, чтобы каждый файл начинался с Точки Произвольного доступа. Дополнительно может быть предпочтительно, выбирать позиции точек поиска во время процесса кодирования видео и сегментировать представление во множественные файлы, каждый начинающийся с точки поиска, на основании выбора точки поиска, который был сделан во время процесса кодирования, причем каждая Точка Произвольного доступа может или не может быть помещена в начале файла, но в котором каждый файл начинается с Точки Произвольного доступа. В одном варианте осуществления со свойствами, описанными выше, метаданные представления, или Описание Представления Мультимедиа, могут содержать точную длительность каждого файла, где длительность взята, например, так, чтобы означать разность между временем начала видео мультимедиа файла и начальным временем мультимедиа видео следующего файла. На основании этой информации в метаданных представления клиент в состоянии построить отображение между шкалой глобального времени для представления мультимедиа и шкалой локального времени для мультимедиа в пределах каждого файла.
[0381] В другом варианте осуществления размер метаданных представления может быть предпочтительно уменьшен посредством определения вместо этого, что каждый файл или сегмент имеют одну и ту же длительность. Однако в этом случае, и когда файлы мультимедиа построены согласно способу, описанному выше, длительность каждого файла может не быть точно равной длительности, заданной в описании представления мультимедиа, так как Точка Произвольного доступа может, не существует в точке, которая является точно указанной длительностью от начала файла.
[0382] Следующий вариант осуществления изобретения, чтобы предусмотреть правильную работу системы потоковой передачи с запросом блоков, несмотря на упомянутое выше несоответствие, описан ниже. В этом способе может быть обеспечен элемент в пределах каждого файла, который задает отображение шкалы локального времени мультимедиа в пределах файла (посредством которого обозначается шкала времени, начинающаяся с нуля отметки времени, от которой отметки времени декодирования и композиции выборок мультимедиа в файле задаются согласно ISO/IEC 14496-12) на шкалу глобального времени представления. Эта информация отображения может содержать единственную отметку времени в глобальном времени представления, которое соответствует нулевой отметке времени в шкале локального времени файла. Информация отображения может альтернативно содержать значение смещения, которое задает разность между глобальным временем представления, соответствующим нулевой отметке времени в шкале локального времени файла, и глобальным временем представления, соответствующим началу файла согласно информации, обеспеченной в метаданных представления.
[0383] Примером таких полей может, например, быть поле ('tfdt') времени декодирования фрагмента дорожки или поле ('tfad') регулирования фрагмента дорожки вместе с полем ('tfma') регулирования мультимедиа фрагмента дорожки.
ПРИМЕРНЫЙ КЛИЕНТ, ВКЛЮЧАЮЩИЙ В СЕБЯ ГЕНЕРИРОВАНИЕ СПИСКА СЕГМЕНТОВ
[0384] Примерный клиент описан ниже. Он может использоваться как эталонный клиент для сервера, чтобы гарантировать надлежащее генерирование и обновления MPD.
[0385] Клиент потоковой передачи HTTP управляется информацией, обеспеченной в MPD. Предполагается, что клиент имеет доступ к MPD, которое он принял во время T, то есть, время, когда можно было в состоянии успешно принять MPD. Определение успешного приема может включать в себя клиента, получающего обновленное MPD, или клиента, верифицирующего, что MPD не было обновлено с предыдущего успешного приема.
[0386] Поведение примерного клиента приводится ниже. Для того чтобы предоставить услугу непрерывной потоковой передачи пользователю, клиент сначала анализирует MPD и создает список доступных сегментов для каждого представления в течение локального времени клиента в текущем времени системы, принимая во внимание процедуры генерирования списка сегментов, как детализировано ниже, возможно используя списки воспроизведения или используя правила построения URL. Затем клиент выбирает одно или множественные представления на основании информации в атрибутах представления и другой информации, например, доступной полосе частот и возможностей клиента. В зависимости от группирования представления могут быть представлены автономными или совместно с другими представлениями.
[0387] Для каждого представления клиент получает двоичные метаданные, такие как заголовок «moov» для этого представления, если присутствует, и сегменты мультимедиа выбранных представлений. Клиент получает доступ к мультимедийному контенту, запрашивая сегменты или диапазоны байтов сегментов, возможно используя список сегментов. Клиент может сначала буферизовать мультимедиа, прежде чем начать представление и, как только представление началось, клиент продолжает потреблять контент мультимедиа, непрерывно запрашивая сегменты или части сегментов, принимая во внимание процедуры обновления MPD.
[0388] Клиент может переключить представления, принимая во внимание обновленную информацию MPD и/или обновленную информацию из его среды, например, изменения доступной полосы частот. С любым запросом сегмента мультимедиа, содержащего точку произвольного доступа, клиент может переключиться на другое представление. При перемещении вперед, то есть, продвижении текущего времени системы (называемом "временим NOW", чтобы представить время относительно представления), клиент потребляет доступные сегменты. С каждым продвижением во времени NOW клиент, возможно, расширяет список доступных сегментов для каждого представления согласно процедурам, определенным здесь.
[0389] Если конец представления мультимедиа еще не достигнут и если текущее время воспроизведения находится в пределах порога, для которого клиент ожидает окончания мультимедиа для мультимедиа, описанного в MPD для любого потребления или необходимости потребления представления, то клиент может запрашивать обновление MPD с новым временем T приема времени выборки. После приема клиент затем принимает во внимание, возможно обновленное MPD и новое время T в генерировании доступных списков сегментов. Фиг. 29 иллюстрирует процедуру для услуг в реальном времени в разные моменты времени в клиенте.
ГЕНЕРИРОВАНИЕ СПИСКА ДОСТУПНЫХ СЕГМЕНТОВ
[0390] Предположим, что клиент потоковой передачи HTTP имеет доступ к MPD и может захотеть генерировать список доступных сегментов в течение времени NOW настенных часов. Клиент синхронизирован к эталону глобального времени с некоторой точностью, но предпочтительно никакая непосредственная синхронизация с сервером потоковой передачи HTTP не требуется.
[0391] Список доступных сегментов для каждого представления предпочтительно определен как пара списков начального времени сегмента и указателя сегмента, где начальное время сегмента может быть определено как являющееся относительным начала представления без потери общности. Начало представления может быть выровнено с началом периода или если эта концепция применяется. Иначе, начало представления может быть в начале представления мультимедиа.
[0392] Клиент использует правила построения URL и тактирование как, например, определено дополнительно здесь. Как только список описанных сегментов получен, этот список далее ограничивается доступными сегментами, которые могут быть поднабором сегментов полного представления мультимедиа. Конструкция управляется текущим значением часов во времени NOW клиента. Обычно сегменты только доступны в течение любого времени NOW в пределах набора времен доступности. В течение времен NOW вне этого окна, никакие сегменты не доступны. Кроме того, для услуг в реальном времени («живых»), предположим, что некоторое временное контрольное время предоставляет информацию о том, как далеко в будущее мультимедиа описано. Контрольное время определено на оси времени MPD-задокументированного мультимедиа; когда клиентское время воспроизведения достигает контрольного времени, оно предпочтительно запрашивает новое MPD.
[0393] Когда клиентское время воспроизведения достигает контрольного времени, оно предпочтительно запрашивает новое MPD.
[0394] Затем список сегментов дополнительно ограничивается посредством контрольного времени вместе с MPD-атрибутом TimeShiftBufferDepth таким образом, что только доступные сегменты мультимедиа являются теми, для которых сумма начального времени сегмента мультимедиа и начальное время представления попадает в интервал между NOW минус timeShiftBufferDepth минус длительность последнего описанного сегмента и меньшее значение или контрольное время или NOW.
МАСШТАБИРУЕМЫЕ БЛОКИ
[0395] Иногда доступная полоса частот уменьшается настолько низко, что становится маловероятным, что блок или блоки, в настоящее время принимаемые в приемнике, будут полностью принятыми вовремя, чтобы быть воспроизведенными, не делая паузу в представлении. Приемник может обнаружить такие ситуации заранее. Например, приемник может определить, что он принимает блоки, кодируя 5 единиц мультимедиа каждые 6 единиц времени, и имеет буфер на 4 единицы мультимедиа, так, чтобы приемник может ожидать, что будет остановка, или пауза, представления, приблизительно через 24 единицы времени. При достаточном уведомлении приемник может реагировать на такую ситуацию, например, оставить текущий поток блоков и начать запрашивать блок или блоки из другого представления контента, такого как тот, который использует меньшую полосу пропускания на каждую единицу времени проигрывания. Например, если приемник переключен на представление, где блоки, закодированные в течение по меньшей мере на 20% большего времени видео для блоков того же размера, приемник может быть в состоянии устранить необходимость останавливаться, пока ситуация с полосой пропускания не улучшится.
[0396] Однако, может быть расточительным иметь приемник, полностью отказывающийся от данных, уже принятых из оставленного представления. В варианте осуществления системы потоковой передачи с блоками, описанной здесь, данные в пределах каждого блока могут быть закодированы и скомпонованы таким образом, которым некоторые префиксы данных в пределах блока могут быть использованы, чтобы продолжить представление без оставления принятого блока. Например, известные методы масштабируемого кодирования видео могут быть использованы. Примеры таких способов кодирования видео включают в себя Масштабируемое кодирование Видео (SVC) H.264, или временную масштабируемость Усовершенствованного кодирования видео (AVC) H.264. Выгодно, что этот способ позволяет продолжать представление на основании части блока, которая была принята, даже когда прием блока или блоков может быть, отвергнут, например, из-за изменений в доступной полосе частот. Другое преимущество состоит в том, что единственный файл данных может использоваться как источник для множественных различных представлений контента. Это возможно, например, используя частичные HTTP запросы GET, чтобы выбрать поднабор блока, соответствующего необходимому представлению.
[0397] Одно усовершенствование, детализированное здесь, является расширенным сегментом, масштабируемой картой сегментов. Масштабируемая карта сегментов содержит местоположения различных уровней в сегменте таким образом, что клиент может получить доступ к частям сегментов соответственно и извлечь уровни. В другом варианте осуществления данные мультимедиа в сегменте упорядочены таким образом, что качество сегмента увеличивается во время загрузки данных постепенно с начала сегмента. В другом варианте осуществления постепенное повышение качества применяется для каждого блока или фрагмента, содержащегося в сегменте, таким образом, что может быть сделан запрос фрагмента, чтобы обратиться к масштабируемому подходу.
[0398] Фиг. 12 является чертежом, отображающим аспект масштабируемых блоков. На этом чертеже передатчик 1200 выводит метаданные 1202, масштабируемый уровень 1 (1204), масштабируемый уровень 2 (1206) и масштабируемый уровень 3 (1208), где последний является задержанным. Приемник 1210 может затем использовать метаданные 1202, масштабируемый уровень 1 (1204) и масштабируемый уровень 2 (1206), чтобы представить представление мультимедиа 1212.
НЕЗАВИСИМЫЕ УРОВНИ МАСШТАБИРУЕМОСТИ
[0399] Как объяснено выше, для системы потоковой передачи с запросом блоков нежелательна необходимость останавливаться, когда приемник не способен принять требуемые блоки конкретного представления данных мультимедиа вовремя для из проигрывания, поскольку это часто создает плохое пользовательское восприятие. Остановок можно избежать, уменьшить или смягчить посредством ограничения скорости передачи данных представлений, выбранных так, чтобы быть намного меньше доступной полосы частот, чтобы стало очень маловероятно, что любая заданная часть представления не будет принята вовремя, но эта стратегия имеет неудобство в том, что качество мультимедиа является обязательно намного ниже, чем могло быть в принципе поддержано доступной полосой частот. Более низкокачественное представление, чем возможно, также может быть интерпретировано как плохое пользовательское восприятие. Таким образом, проектировщик системы потоковой передачи с запросом блоков сталкивается с выбором в структуре клиентских процедур, программировании клиента или конфигурации аппаратного обеспечения, - или запрашивать версию контента, которая имеет намного более низкую скорость передачи данных, чем доступная полоса частот, при этом пользователь может страдать от плохого качества мультимедиа, или запрашивать версию контента, которая имеет скорость передачи данных, близкую к доступной полосе частот, когда пользователь может иметь высокую вероятность пауз во время представления, когда доступная полоса частот изменяется.
[0400] Чтобы обрабатывать такие ситуации, системы потоковой передачи блоков, описанные здесь, могут конфигурироваться, чтобы обращаться с множественными уровнями масштабируемости независимо, таким образом, что приемник может сделать многоуровневые запросы, и передатчик может отвечать на многоуровневые запросы.
[0401] В таких вариантах осуществления закодированные данные мультимедиа для каждого блока могут быть разделены на множественные несвязные части, называемые здесь как "уровни", таким образом, что комбинация уровней содержит все данные мультимедиа для блока и таким образом, что клиент, который принял некоторые поднаборы уровней, может выполнить декодирование и воспроизведение представления контента. В этом подходе упорядочение данных в потоке таково, что смежные диапазоны повышаются в качестве, и метаданные отражают это.
[0402] Примером метода, который может использоваться, чтобы генерировать уровни со свойством выше, является метод кодирования масштабируемого видео, например, как описано в стандартах ITU-T H.264/SVC. Другим примером метода, который может использоваться, чтобы генерировать уровни со свойством, упомянутым выше, является метод временных уровней масштабируемости, как предусмотрено в стандарте H.264/AVC ITU-T.
[0403] В этих вариантах осуществления метаданные могут быть обеспечены в MPD или в сегменте непосредственно, что допускает конструкцию запросов отдельных уровней любого заданного блока и/или комбинации уровней и/или заданного уровня множественных блоков и/или комбинацию уровней множественных блоков. Например, уровни, содержащие блок, могут быть сохранены в единственном файле, и могут быть обеспечены метаданные, определяющие диапазоны байтов в пределах файла, соответствующего отдельным уровням.
[0404] Протокол загрузки файлов, способный задавать диапазоны байтов, например HTTP 1.1, может использоваться, чтобы запросить отдельные уровни или множественные уровни. Кроме того, как будет ясно специалисту в области техники при рассмотрении этого раскрытия, способы, описанные выше, имеющие отношение к построению, запросу и загрузке блоков переменного размера и переменных комбинаций блоков, также могут быть применены в этом контексте.
КОМБИНАЦИИ
[0405] Ряд вариантов осуществления описаны ниже, которые могут предпочтительно использоваться клиентом потоковой передачи с запросом блоков, чтобы достигнуть улучшения пользовательского восприятия и/или уменьшения требований возможностей обслуживающей инфраструктуры по сравнению с существующими способами посредством использования данных мультимедиа, разделенных на уровни, как описано выше.
[0406] В первом варианте осуществления известные способы системы потоковой передачи с запросом блоков могут быть применены с модификацией, что различные версии контента в некоторых случаях заменяются различными комбинациями уровней. То есть, скажем, когда существующая система может обеспечить два отличных представления контента, расширенная система, описанная здесь, может обеспечить два уровня, где одно представление контента в существующей системе является аналогичным в скорости передачи в битах, качестве, и возможно, других метриках, первому уровню в расширенной системе, и второе представление контента в существующей системе является аналогичным в скорости передачи в битах, качестве и возможно, других метриках, комбинации этих двух уровней в расширенной системе. В результате емкость запоминающего устройства, требуемая в расширенной системе, уменьшается по сравнению с емкостью, требуемой в существующей системе. Кроме того, в то время как клиенты существующей системы могут выдать запросы блоков одного представления или другого представления, клиенты расширенной системы могут выдать запросы или первого или обоих уровней блока. В результате пользовательское восприятие в этих двух системах аналогично. Кроме того, улучшенное кэширование обеспечивается, когда даже для различного качества используются общие сегменты, которые затем кэшируются с более высокой вероятностью.
[0407] Во втором варианте осуществления клиент в расширенной системе потоковой передачи с запросом блоков, использующей описанный способ уровней, может поддерживать отдельный буфер данных для каждого из нескольких уровней кодирования мультимедиа. Как будет ясно специалистам в области обработки данных в пределах клиентских устройств, эти "отдельные" буферы могут быть реализованы посредством распределения физически или логически отдельных областей памяти для отдельных буферов или другими способами, в которых буферизованные данные хранятся в единственных или множественных областях памяти, и разделение данных из различных уровней достигается логически с использованием структур данных, которые содержат ссылки на местоположения хранения данных из отдельных уровней, и таким образом, используемый ниже термин "отдельные буферы", как должно быть понятно, включает в себя любой способ, которым могут быть отдельно идентифицированы данные различных уровней. Клиент выдает запросы отдельных уровней каждого блока на основании заполнения каждого буфера, например уровни, могут быть упорядочены в порядке приоритетов таким образом, что запрос данных из одного уровня может не быть выдан, если заполнение какого-нибудь буфера для более низкого уровня в порядке приоритетов ниже порога для этого более низкого уровня. В этом способе приоритет задается приему данных от более низких уровней в порядке приоритетов таким образом, что, если доступная полоса частот падает, ниже требуемой, также принять более высокие уровни в порядке приоритетов затем, только если более низкие уровни запрошены. Кроме того, пороги, ассоциированные с различными уровнями, могут быть различными, таким образом, что, например, более низкие уровни имеют более высокие пороги. В случае, когда доступная полоса частот изменяется таким образом, что данные для более высокого уровня не могут быть приняты перед временем проигрывания блока, то обязательно будут уже приняты данные для более низких уровней, и таким образом представление сможет продолжиться только с одними более низкими уровнями. Пороги для заполнения буфера могут быть определены в терминах байтов данных, длительности проигрывания данных, содержащихся в буфере, количестве блоков или любой другой подходящей мере.
[0408] В третьем варианте осуществления способы из первого и второго вариантов осуществления могут быть объединены таким образом, что обеспечены множественные представления мультимедиа, каждое содержащее поднабор уровней (как в первом варианте осуществления), и таким образом, что второй вариант осуществления применяется к подмножеству уровней в пределах представления.
[0409] В четвертом варианте осуществления способы первого, второго и/или третьего вариантов осуществления могут быть объединены с вариантом осуществления, в котором множественные независимые представления контента обеспечены таким образом, что, например, по меньшей мере, одно из независимых представлений содержит множественные уровни, к которым применены способы первого, второго и/или третьего вариантов осуществления.
УСОВЕРШЕНСТВОВАННЫЙ АДМИНИСТРАТОР БУФЕРА
[0410] В комбинации с монитором 126 буфера (см. Фиг. 2), усовершенствованный администратор буфера может использоваться, чтобы оптимизировать буфер стороны клиента. Системы потоковой передачи с запросом блоков хотят гарантировать, что проигрывание мультимедиа может начаться быстро и продолжиться «гладко», одновременно обеспечивая максимальное качество мультимедиа устройству назначения или пользователю. Это может потребовать, чтобы клиент запросил блоки, которые имеют самое высокое качество мультимедиа, но которые также могут быть начаты быстро и приняты во времени после этого, чтобы проигрываться, не вызывая паузы в представлении.
[0411] В вариантах осуществления, которые используют усовершенствованный администратор буфера, администратор определяет, какие блоки данных мультимедиа запросить, и когда сделать такие запросы. Усовершенствованный администратор буфера может быть, например, снабжен набором метаданных для контента, который должен быть представлен, эти метаданные включают в себя список представлений, доступных для контента, и метаданные для каждого представления. Метаданные для представления могут содержать информацию о скорости передачи данных представления и другие параметры, таких как видео, аудио или другие кодеки и параметры кодеков, разрешение видео, сложность декодирования, язык аудио и любые другие параметры, которые могут влиять на выбор представления в клиенте.
[0412] Метаданные для представления могут также содержать идентификаторы для блоков, в которые представление было сегментировано, эти идентификаторы предоставляют информацию, необходимую для клиента, чтобы запросить блок. Например, когда протоколом запроса является HTTP, идентификатором может быть URL HTTP, возможно вместе с дополнительной информацией, идентифицирующей диапазон в байтах или отрезок времени в пределах файла, идентифицированного этим URL, этот диапазон в байтах или отрезок времени идентифицируют конкретный блок в пределах файла, идентифицированного с помощью URL.
[0413] В конкретной реализации усовершенствованный администратор буфера определяет, когда приемник делает запрос новых блоков и может самостоятельно обрабатывать посылку запросов. В новом аспекте усовершенствованный администратор буфера делает запросы новых блоков согласно значению отношения баланса, которое балансирует между использованием слишком большого размера полосы частот и исчерпанием мультимедиа во время проигрывания потоковой передачи.
[0414] Информация, принятая монитором 126 буфера от буфера 125 блоков, может включать в себя индикации каждого события, когда данные мультимедиа приняты, сколько было принято, когда проигрывание данных мультимедиа началось или остановилось, и скорость проигрывание мультимедиа. На основании этой информации монитор 126 буфера может вычислить переменную, представляющую текущий размер буфера, Bcurrent. В этих примерах Bcurrent представляет объем мультимедиа, содержащегося в клиенте или другом буфере или буферах устройства, и может быть измерен в единицах времени так, чтобы Bcurrent представлял величину времени, которое может потребоваться для проигрывания всего мультимедиа, представленного блоками или частичными блоками, сохраненными в буфере или буферах, если никакие дополнительные блоки или частичные блоки не были приняты. Таким образом, Bcurrent представляет "длительность проигрывания" при нормальной скорости проигрывания данных мультимедиа, доступных в клиенте, но все еще проигрываемых.
[0415] Когда время проходит, значение Bcurrent уменьшается, поскольку мультимедиа проигрывается, и может увеличиться каждый раз, когда новые данные для блока принимаются. Следует отметить, что в целях этого объяснения предполагается, что блок принят, когда все данные этого блока доступны в блоке 124 запрашивания блоков, но другие меры могут быть использованы вместо этого, например, чтобы принять во внимание прием частичных блоков. На практике прием блока может иметь место в течение периода времени.
[0416] Фиг. 13 иллюстрирует изменение значения Bcurrent в течение времени, когда мультимедиа проигрывается и блоки принимаются. Как показано на Фиг. 13, значение Bcurrent равно нулю для моментов времени меньших, чем t0, указывая, что никакие данные не были приняты. В t0 первый блок принимают, и значение Bcurrent увеличивается, чтобы равняться длительности проигрывания принятого блока. В это время проигрывание еще не началось, и таким образом значение Bcurrent остается постоянным, до времени t1, при котором второй блок поступает и Bcurrent увеличивается на размер этого второго блока. В это время начинается проигрывание, и значение Bcurrent начинает уменьшаться линейно до времени t2, при котором поступает третий блок.
[0417] Продвижение Bcurrent продолжается таким "пилообразным" способом, увеличиваясь пошагово каждый раз, когда блок принимается (в моменты времени t2, t3, t4, t5 и t6) и плавно уменьшаясь, когда данные проигрываются между ними. Следует отметить, что в этом примере проигрывание осуществляется при нормальной скорости проигрывания для контента, и таким образом наклон кривой между приемом блоков точно равен -1, означая, что одна секунда данных мультимедиа проигрывается в течение каждой секунды реального времени, которое проходит. С основанным на кадрах мультимедиа, проигрываемого при заданном количестве кадров в секунду, например, 24 кадров в секунду, наклон -1 будет аппроксимирован функциями малых шагов, которые указывают проигрывание каждого отдельного кадра данных, например, шаги -1/24 секунды, когда каждый кадр проигрывается.
[0418] Фиг. 14 показывает другой пример изменения Bcurrent в течение времени. В этом примере первый блок приходит в t0, и проигрывание начинается немедленно. Прибытие блоков и проигрывание продолжаются до времени t3, при котором значение Bcurrent достигает нуля. Когда это случается, другие данные мультимедиа не доступны для проигрывания, вызывая паузу в представлении мультимедиа. В момент времени t4 принимают четвертый блок, и проигрывание может возобновиться. Этот пример, поэтому показывает случай, когда прием четвертого блока был позже, чем желательно, приводя к паузе в проигрывании и таким образом, плохому пользовательскому восприятию. Таким образом, цель усовершенствованного администратора буфера и других особенностей состоит в том, чтобы уменьшить вероятность этого события, одновременно поддерживая высокое качество мультимедиа.
[0419] Монитор 126 буфера может также вычислить другую метрику, Bratio(t), которая является отношением мультимедиа, принятого в заданном периоде времени, к длительности этого периода времени. Более конкретно, Bratio(t) равно Treceived / (Tnow-t), где Treceived объем мультимедиа (измеренный по его времени проигрывания), принятого в периоде времени от t, на некоторое время ранее, чем достигнуто текущее, Tnow.
[0420] Bratio(t) может использоваться, чтобы измерить частоту изменения Bcurrent. Bratio(t)=0 имеет место, когда никакие данные не были приняты с момента времени t; Bcurrent будет уменьшаться на (Tnow-t) с этого времени, предполагая, что мультимедиа проигрывается. Bratio(t)=1 имеет место, когда мультимедиа принято в том же объеме, в котором оно проигрывается, в течение времени (Tnow-t); Bcurrent будет иметь то же значение во время Tnow, как во время t. Bratio(t)>1 имеет место, когда больше данных было принято, чем необходимо, чтобы проигрываться в течение времени (Tnow-t); Bcurrent будет увеличиваться с момента времени t до времени Tnow.
[0421] Монитор 126 буфера далее вычисляет значение State (состояние), которое может принимать дискретное количество значений. Монитор 126 буфера также снабжен функцией NewState(Bcurrent, Bratio), которая, при заданном текущем значении Bcurrent и значениях Bratio для t<Tnow, обеспечивает новое значение State в качестве выходного. Всякий раз, когда Bcurrent и Bratio заставляют эту функцию возвращать значение, отличающееся от текущего значения State, новое значение присваивается для State и это новое значение State указывается селектору 123 блоков.
[0422] Функция NewState может быть оценена в отношении пространства всех возможных значений пары (Bcurrent, Bratio(Tnow-Tx)), где Tx может быть фиксированным (конфигурируемым) значением, или может быть получено из Bcurrent, например, посредством таблицы конфигурации, которая ставит в соответствие значения Bcurrent значениям Tx, или может зависеть от предыдущего значения State. Монитор 126 буфера снабжается одним или более разделами этого пространства, где каждое разделение содержит наборы несвязных областей, причем каждая область аннотирована значением State. Оценка функции NewState затем содержит операцию идентификации разделения и определение области, в которую попадает пара (Bcurrent, Bratio(Tnow-Tx)). Возвращаемое значение является затем аннотацией, ассоциированной с этой областью. В простом случае обеспечивается только одно разделение. В более сложном случае разделение может зависеть от пары (Bcurrent, Bratio(Tnow-Tx)) в предыдущий раз оценки функции NewState или от других факторов.
[0423] В конкретном варианте осуществления разделение, описанное выше, может быть основано на таблице конфигурации, содержащей многие пороговые значения для Bcurrent и многие пороговые значения для Bratio. В частности, пусть пороговые значения для Bcurrent равны Bthresh(0)=0, Bthresh(1), Bthresh (n1), Bthresh (n1+1)=∞, где n1 является количеством пороговых значений отличных от нуля для Bcurrent. Пусть пороговые значения для Bratio равны Br-thresh(0)=0, Br-thresh(1), Br-thresh (n2), Br-thresh (n2+1)=∞, где n2- количество пороговых значений для Bratio. Эти пороговые значения определяют разделение, содержащее (n1+1)×(n2+1) сетку ячеек, где i-я ячейка j-й строка соответствует области, в которой Br-thresh (i-1)<=Bcurrent<Bthresh (i) и Br-thresh (j-1)<=Bratio<Br-thresh (j). Каждая ячейка сетки, описанной выше, аннотируется значением State, таким как ассоциировано с конкретными значениями, сохраненными в памяти, и функция NewState затем возвращает значение State, ассоциированное с ячейкой, обозначенной значениями Bcurrent и Bratio (Tnow-Tx).
[0424] В другом варианте осуществления значение гистерезиса может быть ассоциировано с каждым пороговым значением. В этом расширенном способе оценка функции NewState может быть основана на временном разделении, построенном, используя набор временно модифицированных пороговых значений, следующим образом. Для каждого Bcurrent порогового значение, которое является меньшим, чем диапазон Bcurrent, соответствующий выбранной ячейке в отношении последней оценки NewState, пороговое значение уменьшается посредством вычитания значения гистерезиса, ассоциированного с этим порогом. Для каждого Bcurrent пороговое значение, которое больше, чем диапазон Bcurrent, соответствующий выбранной ячейке в отношении последней оценки NewState, это пороговое значение увеличивается посредством добавления значения гистерезиса, ассоциированного с этим порогом. Для каждого Bratio пороговое значение, которое является меньшим, чем диапазон Bratio, соответствующий выбранной ячейке в отношении последней оценки NewState, пороговое значение уменьшается посредством вычитания значения гистерезиса, ассоциированного с этим порогом. Для каждого Bratio пороговое значение, которое больше, чем диапазон Bratio, соответствующий выбранной ячейке в отношении последней оценки NewState, пороговое значение увеличивается посредством добавления значения гистерезиса, ассоциированного с этим порогом. Модифицированные пороговые значения используются, чтобы оценить значение NewState, и затем пороговые значения возвращаются к их первоначальным значениям.
[0425] Другие способы определить разделения пространства очевидны для специалистов в данной области техники после прочтения этого раскрытия. Например, разделение может быть определено при помощи неравенств, основанных на линейных комбинациях Bratio и Bcurrent, например, порогов линейных неравенств формы α1*Bratio+α2*Bcurrent≤α0, для действительных чисел α0, α1 и α2, чтобы определить полупространства в пределах полного пространства, и определяющее каждый несвязный набор как пересечение многих таких полу-пространств.
[0426] Вышеупомянутое описание является иллюстрацией основного процесса. Как будет ясно специалистам в программировании в реальном времени после прочтения этого раскрытия, возможны эффективные реализации. Например, каждый раз, когда новая информация выдается на монитор 126 буфера, можно вычислить будущее время, при котором NewState перейдет к новому значению, если, например, никакие дальнейшие данные для блоков не будут приняты. Таймер затем устанавливается в течение этого времени, и в отсутствии дополнительных вводов истечение этого таймера вызовет посылку нового значения State на селектор 123 блоков. В результате, вычисления должны быть выполнены, только когда новая информация выдается в монитор 126 буфера или когда таймер истекает, а не непрерывно.
[0427] Подходящие значения State могут быть "Низкое", "Стабильное" и "Полное". Пример подходящего набора пороговых значений и получающейся сетки ячеек показан на Фиг. 15.
[0428] На Фиг. 15, пороги Bcurrent показаны на горизонтальной оси в миллисекундах, со значениями гистерезиса, показанными ниже как "+/-значение". Пороги Bratio показаны на вертикальной оси в промилях (то есть, умножены на 1000) со значениями гистерезиса, показанными ниже как "+/-значение". Значения State аннотируются в ячейках сетки как "L", "S" и "F" для "Низкое", "Стабильное" и "Полное" соответственно.
[0429] Селектор 123 блоков принимает уведомления от блока 124 запрашивания блоков всякий раз, когда есть возможность запросить новый блок. Как описано выше, селектор 123 блоков обеспечивается информацией относительно множества доступных блоков и метаданными для этих блоков, включая, например, информацию о скорости передачи данных мультимедиа каждого блока.
[0430] Информация о скорости передачи данных мультимедиа блока может содержать фактическую скорость передачи данных мультимедиа конкретного блока (то есть, размер блока в байтах, разделенный на время проигрывания в секундах), среднюю скорость передачи данных мультимедиа представления, которому блок принадлежит, или меру доступной требуемой полосы частот, на длительной основе, чтобы проигрывать представление, которому принадлежит блок, без пауз, или комбинации вышеупомянутого.
[0431] Селектор 123 блоков выбирает блоки на основании значения State, указанного последним монитором 126 буфера. Когда это значение State является "Стабильное", селектор 123 блоков выбирает блок из того же представления, как предыдущий выбранный блок. Выбранный блок является первым блоком (в порядке проигрывания), содержащим данные мультимедиа в течение некоторого временного периода в представлении, для которого не были ранее запрошены никакие данные мультимедиа.
[0432] Когда значение State равно "Низкое", селектор 123 блоков выбирает блок из представления с более низкой скоростью передачи данных мультимедиа, чем таковая ранее выбранного блока. Многие факторы могут влиять на точный выбор представления в этом случае. Например, селектор 123 блоков может быть обеспечен индикацией совокупной скорости передачи поступающих данных и может выбрать представление со скоростью передачи данных мультимедиа, которая является меньше, чем это значение.
[0433] Когда значение State равно "Полное", селектор 123 блоков выбирает блок из представления с более высокой скоростью передачи данных мультимедиа, чем таковая ранее выбранного блока. Многие факторы могут влиять на точный выбор представления в этом случае. Например, селектор 123 блоков может быть обеспечен индикацией совокупной скорости передачи поступающих данных, и может выбрать представление со скоростью передачи данных мультимедиа, которая не является большей, чем это значение.
[0434] Многие дополнительные факторы могут далее влиять на работу селектора 123 блоков. В частности, частота, с которой скорость передачи данных мультимедиа выбранного блока увеличивается, может быть ограничена, даже если монитор 126 буфера продолжает указывать состояние "Полное". Кроме того, возможно, что селектор 123 блоков принимает индикацию состояния "Полное", но нет никаких блоков с более высокой доступной скоростью передачи данных мультимедиа (например, так как последний выбранный блок уже имел самую высокую доступную скорость передачи данных мультимедиа). В этом случае селектор 123 блоков может задержать выбор следующего блока на время, выбранное таким образом, что полное количество данных мультимедиа, буферизованных в буфере 125 блоков, ограничено сверху.
[0435] Дополнительные факторы могут влиять на набор блоков, которые рассматриваются во время процесса выбора. Например, доступные блоки могут быть ограничены теми из представлений, разрешение (разрешающая способность) кодирования которых попадает в пределы конкретного диапазона, поданного на селектор 123 блоков.
[0436] Селектор 123 блоков может также принять входные сигналы из других компонентов, которые контролируют другие аспекты системы, такие как доступность вычислительных ресурсов, для декодирования мультимедиа. Если такие ресурсы становятся недостаточными, селектор 123 блоков может выбрать блоки, декодирование которых указано имеющим более низкую вычислительную сложность в пределах метаданных (например, представления с более низким разрешением или скоростью передачи кадров имеют обычно более низкую сложность декодирования).
[0437] Вышеописанный вариант осуществления дает существенное преимущество в том, что использование значения Bratio в оценке функции NewState в мониторе 126 буфера допускает более быстрое увеличение качества в начале представления, по сравнению со способом, который рассматривает только Bcurrent. Без рассмотрения Bratio большое количество буферизованных данных может быть накоплено прежде, чем система будет в состоянии выбрать блоки с более высокой скоростью передачи данных мультимедиа и, следовательно, более высоким качеством. Однако, когда значение Bratio является большим, это указывает, что доступная полоса частот намного выше, чем скорость передачи данных мультимедиа ранее принятых блоков, и что даже с относительно небольшими буферизованными данными (то есть, низким значением Bcurrent) остается безопасным запросить блоки с более высокой скоростью передачи данных мультимедиа, и следовательно, более высокого качества. Равным образом, если значение Bratio является низким (<1, например), это указывает, что доступная полоса частот снизилась ниже скорости передачи данных мультимедиа ранее запрошенных блоков и, таким образом, даже если Bcurrent является высоким, система переключится на более низкую скорость передачи данных мультимедиа и следовательно, более низкое качество, например, чтобы избежать достижения точки, когда Bcurrent=0 и проигрывание мультимедиа остановится. Это улучшенное поведение может быть особенно важным в средах, когда сетевые условия и, таким образом, скорости доставки могут измениться быстро и динамически, например, пользователей, использующих потоковую передачу на мобильные устройства.
[0438] Другое преимущество получают при помощи данных конфигурации, чтобы задать разделение пространства значений (Bcurren, Bratio). Такие данные конфигурации могут быть выданы на монитор 126 буфера в качестве части метаданных представления или посредством другого динамического средства. Так как при практическом развертывании поведение пользовательских сетевых соединений может быть очень переменным между пользователями и в течение времени для единственного пользователя, может быть трудно, предсказать разделения, которые будут работать хорошо для всех пользователей. Возможность предоставить такую информацию о конфигурации пользователям динамически обеспечивает хорошие параметры настройки конфигурации, которые должны быть развернуты в течение времени согласно накопленному восприятию (опыту).
ПЕРЕМЕННОЕ ИЗМЕНЕНИЕ РАЗМЕРОВ ЗАПРОСА
[0439] Высокая частота запросов может требоваться, если каждый запрос единственного блока, и если каждый блок кодирует для короткого сегмента мультимедиа. Если блоки мультимедиа коротки, проигрывание видео перемещается от блока к блоку быстро, что обеспечивает более частые возможности приемника, чтобы отрегулировать или изменить свою выбранную скорость передачи данных, изменяя представление, улучшая вероятность, что проигрывание может продолжиться без остановки. Однако, обратная сторона высокой частоты запросов - та, что они не могут быть жизнеспособными в некоторых сетях, в которых доступная полоса частот ограничена в сети клиент - сервер, например, в беспроводных глобальных сетях (WAN), таких как 3G и 4G беспроводных WAN, где емкость канала связи от клиента к сети ограничена или может стать ограниченной в течение коротких или длительных периодов времени из-за изменений в радио-условиях.
[0440] Высокая частота запросов также подразумевает высокую нагрузку на обслуживающую инфраструктуру, которая вносит ассоциированные затраты в терминах требований емкости. Таким образом, было бы желательно иметь некоторые из выгод высокой частоты запросов безо всех таких неудобств.
[0441] В некоторых вариантах осуществления системы потоковой передачи блоков гибкость высокой частоты запросов объединяется с менее частыми запросами. В этом варианте осуществления блоки могут быть построены, как описано выше, и соединены в сегменты, содержащие множественные блоки, также как описано выше. В начале представления процессы, описанные выше, когда каждый запрос ссылается на единственный блок или множественные параллельные запросы, сделаны так, чтобы запрашивать, чтобы части блока были применены так, чтобы гарантировать быстрое время переключения канала и поэтому - хорошее пользовательское восприятие в начале представления. Затем, когда некоторое условие, которое описано ниже, соблюдается, клиент может выдать запросы, которые охватывают множественные блоки в единственном запросе. Это возможно, так как блоки были агрегированы в большие файлы или сегменты и могут быть запрошены, используя временные диапазоны или байтов. Последовательные диапазоны байтов или времени могут быть агрегированы в единственный больший диапазон байтов или времени, приводя к единственному запросу множественных блоков, и даже не непрерывные блоки могут быть запрошены в одном запросе.
[0442] Одна базовая конфигурация, которая может быть выведена посредством решения, запросить ли единственный блок (или частичный блок) или запросить множественные последовательные блоки, заключается в том, чтобы иметь основу конфигурации для решения относительно того, будут ли запрошенные блоки, вероятно, проиграны или нет. Например, если вероятно, что вскоре будет необходимо измениться на другое представление, то лучше для клиента сделать запросы одиночных блоков, то есть малое количество данных мультимедиа. Одна причина для этого заключается в том, что если запрос множественных блоков сделан, когда переключение к другому представлению может быть неизбежным, то это переключение может быть сделано прежде, чем последние несколько блоков запроса будут проиграны. Таким образом, загрузка этих последних нескольких блоков может задержать доставку данных мультимедиа представления, к которому осуществлено переключение, что может вызвать остановку проигрывания мультимедиа.
[0443] Однако, запросы одиночных блоков действительно приводят к более высокой частоте запросов. С другой стороны, если маловероятно, что будет необходимость измениться на другое представление вскоре, то может быть предпочтительно сделать запрос множественных блоков, поскольку все эти блоки, вероятно, будут проигрываются, и это приводит к более низкой частоте запросов, что может существенно снизить служебные расходы на запросы, особенно если является типичным, что не имеется неизбежного изменения в представлении.
[0444] В обычных системах агрегации блоков величина запрошенных в каждом запросе данных динамически не регулируется, то есть, обычно каждый запрос предназначен для всего файла или каждый запрос предназначен для приблизительно одной и той же величины файла представления (иногда измеряется во времени, иногда в байтах). Таким образом, если все запросы являются малыми, то служебные расходы на запрос высоки, тогда как если все запросы большие, то это увеличивает шансы событий остановки мультимедиа, и/или обеспечения более низкого качества проигрывания мультимедиа, если выбраны представления с более низким качеством, чтобы избежать необходимости быстро изменять представления, когда условия сети изменяются.
[0445] Примером условия, которое, когда удовлетворено, может вызвать последующие запросы для ссылки на множественные блоки, является порог в отношении размере буфера, Bcurrent. Если Bcurrent ниже порога, то каждый выданный запрос ссылается на единственный блок. Если Bcurrent больше или равен порогу, то каждый выданный запрос ссылается на множественные блоки. Если запрос выдан, который ссылается на множественные блоки, то количество блоков, запрошенных в каждом единственном запросе, может быть определено одним из нескольких возможных способов. Например, это количество может быть постоянным, например, равным двум. Альтернативно, количество блоков, которые запрошены в единственном запросе, может зависеть от состояния буфера и в особенности от Bcurrent. Например, множество порогов может быть установлено с количеством блоков, которые запрашиваются в единственном запросе, получаемом из наиболее высокого из множественных порогов, который меньше чем Bcurrent.
[0446] Другим примером условия, которое, когда удовлетворено, может вызвать запросы для ссылки множественные блоки, является значение переменной State, описанной выше. Например, когда State является "Стабильное" или "Полное", то запрос может быть выдан для множественных блоков, но когда State является "Низкое", то все запросы могут быть на один блок.
[0447] Другой вариант осуществления показан на Фиг. 16. В этом варианте осуществления, когда должен быть выдан следующий запрос (определенный на этапе 1300), текущее значение State и Bcurrent используются, чтобы определить размер следующего запроса. Если текущее значение State равно "Низкое", или текущее значение State равно "Полное", и текущее представление не является наиболее высоко доступным (определенное на этапе 1310, ответ - "Да"), то следующий запрос выбирается коротким, например, только для следующего блока (определенный блок и запрос, сделанный на этапе 1320). Объяснением этого является то, что они являются условиями, когда вероятно, что совсем скоро будет изменение представлений. Если текущее значение State равно "Стабильное", или текущее значение State равно "Полное", и текущее представление является наиболее высоко доступным (определенное на этапе 1310, ответ - "Нет"), то длительность последующих блоков, запрошенных в следующем запросе, выбирается так, чтобы быть пропорциональной α-доли Bcurrent для некоторых фиксированных α <1 (блоки, определенные на этапе 1330, запрос, сделанный на этапе 1340), например, для α=0,4, если Bcurrent=5 секунд, то следующий запрос может быть в течение приблизительно 2 секунд блоков, тогда как, если Bcurrent=10 секунд, то следующий запрос может быть в течение приблизительно 4 секунд блоков. Одним объяснением этого является то, что в этих условиях может быть маловероятно, что переключение к новому представлению будет сделано для величины времени, которая пропорциональна Bcurrent.
ГИБКАЯ КОНВЕЙЕРНАЯ ОБРАБОТКА
[0448] Системы потоковой передачи блоков могут использовать протокол запросов файла, который имеет конкретный нижележащий транспортный протокол, например TCP/IP. В начале соединения TCP/IP или другого транспортного протокола, может потребоваться некоторое большое количество времени, чтобы достигнуть использования полной доступной полосы частот. Это может привести к "штрафу за запуск соединения" каждый раз, когда начато новое соединение. Например, в случае TCP/IP штраф за запуск соединения происходит и из-за времени, потраченного для начального квитирования установления связи TCP, чтобы установить соединение, и из-за времени, потраченного для протокола управления перегрузки, чтобы достигнуть полного использования доступной полосы частот.
[0449] В этом случае может быть желательно, выдать множественные запросы, используя единственное соединение, чтобы уменьшить частоту, с которой накладывается штраф за запуск соединения. Однако, некоторые протоколы транспортировки файлов, например HTTP, не обеспечивают механизм, чтобы отменить запрос, кроме закрытия соединения транспортного уровня в целом, и таким образом подвергаясь штрафу за запуск соединения, когда новое соединение устанавливается вместо старого. Выданный запрос может быть необходимо, отменить, если определено, что доступная полоса частот изменилась, и другая скорость передачи данных мультимедиа требуется вместо нее, то есть, имеется решение переключиться на другое представление. Другая причина отмены выданного запроса может быть та, что если пользователь запросил, чтобы представление мультимедиа было закончено и новое представление начато (возможно, этого же элемента контента в другой точке в представлении или возможно нового элемента контента).
[0450] Как известно, штрафа за запуск соединения можно избежать, поддерживая открытое соединение и повторно используя то же соединение для последующих запросов и, как также известно, соединение может быть сохранено полностью используемым, если множественные запросы выданы в одно и то же время на одном и том же соединении (способ, известный как "конвейерная обработка" в контексте HTTP). Однако, неудобство выдачи множественных запросов в одно и то же время, или в более общем случае, таким образом, что множественные запросы выдаются перед тем, как предыдущие запросы завершены, по соединению, может быть тем, что соединение затем задействуется, чтобы нести ответ на эти запросы и так, что если изменения, к которым должны быть выданы запросы, становятся желательными, то соединение может быть закрыто, если становится необходимым отменить запросы, уже выданные, которые больше не желательны.
[0451] Вероятность, что выданный запрос должен быть отменен, может частично зависеть от длительности временного интервала между выдачей запроса и временем проигрывания запрошенного блока в том смысле, что когда этот временной интервал большой, вероятность, что выданный запрос должен быть отменен, также высока (так как вероятно, что доступная полоса частот изменяется во время интервала).
[0452] Как известно, некоторые протоколы загрузки файлов имеют свойство, что единственное лежащее в основе соединение транспортного уровня может предпочтительно использоваться для множественных запросов загрузки. Например, HTTP имеет это свойство, так как повторное использование единственного соединения для множественных запросов избегает "штрафа за запуск соединения", описанного выше для запросов, отличных от первого. Однако, неудобство этого подхода в том, что соединение задействуется для транспортировки запрошенных данных в каждом выданном запросе, и поэтому, если запрос или запросы должны быть отменены, то или соединение может быть закрыто, подвергаясь штрафу за запуск соединения, когда заменяющее соединение устанавливается, или клиент может ожидать приема данных, которые больше не необходимы, подвергаясь задержке при приеме последующих данных.
[0453] Ниже описан вариант осуществления, который сохраняет преимущества повторного использования соединения, не подвергаясь этому неудобству, и который также дополнительно улучшает частоту, с которой могут быть снова использованы соединения.
[0454] Варианты осуществления систем потоковой передачи блоков, описанных здесь, конфигурируются, чтобы повторно использовать соединение для множественных запросов, не имея необходимости передавать соединение при начале к конкретному набору запросов. По существу, новый запрос выдается на существующем соединении, когда уже выданные запросы на этом соединении еще не завершены, но близки к завершению. Одна причина для не ожидания завершения существующих запросов та, что, если предыдущие запросы завершены, то скорость соединения может ухудшиться, то есть, лежащий в основе сеанс TCP может войти в состояние ожидания, или переменная TCP cwnd мог быть значительно уменьшена, таким образом значительно уменьшая начальную скорость загрузки нового запроса, выданного на этом соединении. Одна причина для ожидания до состояния, близкому к завершению, прежде чем выдать дополнительный запрос, является та, что если новый запрос выдан задолго перед завершением предыдущих запросов, то новый выданный запрос может не даже начаться в течение некоторого существенного промежутка времени, и может случиться, что во время этого промежутка времени, прежде нового выданного запроса, принятие решения сделать новый запрос больше не является действительным, например, из-за решения переключить представления. Таким образом, вариант осуществления клиентов, которые реализуют этот способ, заключается в том, чтобы выдавать новый запрос по соединению как можно позднее без замедления возможностей загрузки соединения.
[0455] Способ содержит контроль количества байтов, принятых по соединению в ответ на последний запрос, выданный по этому соединению, и применение теста к этому количеству. Это может быть сделано при наличии приемника (или передатчика, если применимо), сконфигурированного, чтобы контролировать и выполнять тест.
[0456] Если тест проходит, то другой запрос может быть выдан по этому соединению. Одним примером подходящего теста является - больше ли количество принятых байтов, чем фиксированная доля размера запрошенных данных. Например, эта доля может составить 80%. Другой пример подходящего теста основан на следующем вычислении, как проиллюстрировано на Фиг. 17. В этом вычислении, пусть R будет оценкой скорости передачи данных соединения, T будет оценкой времени прохождения сигнала туда и обратно ("RTT") и Х будет числовым коэффициентом, который, например, может быть постоянно установлен равным значению между 0.5 и 2, когда оценки R и T обновляются на регулярной основе (обновлено на этапе 1410). Пусть S будет размером данных, запрошенных в последнем запросе, B будет количеством байтов запрошенных принятых данных (вычислено на этапе 1420).
[0457] В подходящем тесте необходимо, чтобы приемник (или передатчик, если применимо) выполнял программу, чтобы оценить неравенство (S-B)<X*R*T (проверяется на этапе 1430), и если "Да", то предпринимать действие. Например, тест мог быть сделан так, чтобы видеть, есть ли другой запрос, готовый к выдаче по соединению (проверяется на этапе 1440), и если "Да", то выдавать этот запрос к соединению (этап 1450), и если "Нет", то процесс возвращается на этап 1410, чтобы продолжить обновление и тестирование. Если результат теста на этапе 1430- "Нет", то процесс возвращается на этап 1410, чтобы продолжить обновление и проверку.
[0458] Тест неравенства на этапе 1430 (выполняемый соответственно запрограммированными элементами, например) заставляет каждый последующий запрос выдавать, когда количество остающихся данных, которые должны быть приняты, равно Х раз от количества данных, которые могут быть приняты при текущей оцененной скорости передачи приема в пределах одного RTT. Многие способы, чтобы оценить скорость передачи данных R на этапе 1410, известны в технике. Например, скорость передачи данных может быть оценена как Dt/t, где Dt - количество битов, принятых в предшествующие t секунд, и где t может быть, например, 1 сек или 0,5 сек или некоторым другим интервалом. Другой способ - экспоненциальное взвешенное среднее, или фильтр с бесконечной импульсной характеристикой (IIR) первого порядка поступающей скорости передачи данных. Многие способы для оценки RTT, T, на этапе 1410 известны в технике.
[0459] Тест на этапе 1430 может быть применен к совокупности всех активных соединений на интерфейсе, как объяснено более подробно ниже.
[0460] Способ далее содержит построение списка запросов-кандидатов, ассоциирование каждого запроса-кандидата с набором подходящих серверов, к которым запрос может быть сделан, и упорядочение списка запросов-кандидатов в порядке приоритета. Некоторые записи в списке запросов-кандидатов могут иметь один и тот же приоритет. Серверы в списке подходящих серверов, ассоциированных с каждым запросом-кандидатом, идентифицируются посредством имен хостов. Каждое имя хоста соответствует набору адресов интернет-протокола, которые могут быть получены из системы доменных имен, как известно. Поэтому каждый возможный запрос в списке запросов-кандидатов ассоциирован с рядом адресов интернет-протокола, в частности, объединением из наборов адресов интернет-протокола, ассоциированных с именами хостов, ассоциированных с серверами, ассоциированными с запросом-кандидатом. Всякий раз, когда тест, описанный на этапе 1430, удовлетворяется для соединения, и никакой новый запрос еще не был выдан по этому соединению, запрос с самым высоким приоритетом в списках запросов-кандидатов, с которыми ассоциирован адрес интернет-протокола адресата соединения, выбирается, и этот запрос выдается на соединение. Запрос также удаляется из списка запросов-кандидатов.
[0461] Запросы-кандидаты могут быть удалены (отменены) из списка запросов-кандидатов, новые запросы могут быть добавлены к списку кандидатов с приоритетом, который выше, чем уже существующие запросы в списке кандидатов, и существующие запросы в списке кандидатов могут изменить свой приоритет. Динамическая природа того, какие запросы находятся в списке запросов-кандидатов, и динамическая природа их приоритета в списке кандидатов может изменить то, какие запросы могут быть, затем выданы в зависимости от того, когда удовлетворен тест описанного на этапе 1430 типа.
[0462] Например, может быть, возможно, что, если ответом на тест, описанный на этапе 1430, является "Да" в некоторое время t, то следующий выданный запрос будет запросом A, тогда как если ответ на тест, описанный на этапе 1430, не "Да" до некоторого времени t'>t, то следующий выданный запрос вместо этого может быть запросом B, так как или запрос A был удален из списка запросов-кандидатов между временем t и t', или так как запрос B был добавлен к списку запросов-кандидатов с более высоким приоритетом, чем запрос между временем t и t', или так как запрос B был в списке кандидатов во время t, но с более низким приоритетом, чем запрос A, и между временем t и t' приоритет запроса B был сделан выше, чем таковой запроса A.
[0463] Фиг. 18 иллюстрирует пример списка запросов в списке запросов-кандидатов. В этом примере имеются три соединения, и в списке кандидатов имеются шесть запросов, маркированных A, B, C, D, E и F. Каждый из запросов в списке кандидатов может быть выдан на поднабор соединений, как указано, например, запрос A может быть выдан на соединение 1, тогда как запрос F может быть выдан на соединение 2 или соединение 3. Приоритет каждого запроса также помечен на Фиг. 18, и значение более низкого приоритета указывает, что запрос является более высокоприоритетным. Таким образом, запросы A и B с приоритетом 0 являются самыми высокоприоритетными запросами, тогда как запрос F со значением приоритета 3 является самым низкоприоритетным среди запросов в списке кандидатов.
[0464] Если в данный момент t соединение 1 проходит тест, описанный на этапе 1430, то или запрос A или запрос B выдается на соединение 1. Если вместо этого соединение 3 проходит тест, описанный на этапе 1430 в это время t, то запрос D выдается на соединение 3, так как запрос D является запросом с самым высоким приоритетом, который может быть выдан на соединение 3.
[0465] Предположим, что для всех соединений ответом на тест, описанный на этапе 1430 со времени t до некоторого более позднего времени t', является "Нет", и между временем t и t' запрос А изменяет свой приоритет от 0 на 5, запрос B удаляется из списка кандидатов, и новый запрос G с приоритетом 0 добавляется к списку кандидатов. Затем во время t' новый список кандидатов может быть, как показано на Фиг. 19.
[0466] Если во время t' соединение 1 проходит тест, описанный на этапе 1430, то запрос C с приоритетом 4 выдается на соединение 1, так как он является самым высокоприоритетным запросом в списке кандидатов, который может быть выдан на соединение 1 в данный момент.
[0467] Предположим в этой той же самой ситуации, что вместо этого запрос A был бы выдан на соединение 1 во время t (который был одним из двух самых высокоприоритетных выборов для соединения 1 во время t, как показано на Фиг. 18). Так как ответом на тест, описанный на этапе 1430, со времени t до некоторого более позднего времени t' является "Нет" для всех соединений, соединение 1 все еще доставляет данные до, по меньшей мере, времени t' для запросов, выданных до времени t, и таким образом запрос A не может начаться до по меньшей мере времени t'. Выдача запроса C во время t' является лучшим решением, чем выдача запроса во время t, которое могло быть, так как запрос C начинается в то же время после t', когда запрос A мог бы начаться, и так как к этому времени запрос C является более высокоприоритетным, чем запрос A.
[0468] В качестве другой альтернативы, если тест типа, описанного на этапе 1430, применяется к совокупности активных соединений, может быть выбрано соединение, которое имеет адресата, адрес интернет-протокола которого ассоциирован с первым запросом в списке запросов-кандидатов или другим запросом с тем же приоритетом, как у упомянутого первого запроса.
[0469] Многие способы возможны для построения списка запросов-кандидатов. Например, список кандидатов может содержать n запросов, представляющих запросы следующих n частей данных текущего представления упомянутого представления в порядке временной последовательности, когда запрос самой ранней части данных имеет самый высокий приоритет, и запрос последней части данных имеет самый низкий приоритет. В некоторых случаях n может быть единицей. Значение n может зависеть от размера буфера Bcurrent, или переменной State или другой меры состояния занятости буфера клиента. Например, ряд пороговых значений могут быть установлены для Bcurrent, и значение, ассоциированное с каждым порогом, и затем значение n берут так, чтобы было значением, ассоциированным с самым высоким порогом, которое меньше, чем Bcurrent.
[0470] Вариант осуществления, описанный выше, гарантирует гибкое распределение запросов на соединения, гарантируя, что предпочтение дается многократному использованию существующего соединения, даже если самый высокоприоритетный запрос не является подходящим для этого соединения (так как IP адрес адресата этого соединения не является адресом, который назначен любому из имен хоста, ассоциированных с запросом). Зависимость n от Bcurrent или State или другая мера занятия буфера клиента гарантирует, что такие запросы "вне приоритетного порядка" не выдаются, когда клиенту срочно требуется выдача и завершение запроса, ассоциированного со следующей частью данных, которые должны быть проиграны во временной последовательности
[0471] Эти способы могут быть предпочтительно объединены со скоординированными HTTP и FEC.
ВЫБОР СООТВЕТСТВУЮЩЕГО СЕРВЕРА
[0472] Как известно, файлы, которые должны быть загружены, используя протокол загрузки файлов, обычно идентифицируются идентификатором, содержащим имя хоста и имя файла. Например, дело обстоит так для протокола HTTP, когда идентификатором является Унифицированный идентификатор ресурса (URI). Имя хоста может соответствовать множественным хостам, идентифицированным адресами интернет-протокола. Например, общепринятой методикой является распределение нагрузки запросов от множественных клиентов по множественным физическим машинам. В частности, этот подход обычно принят Сетями доставки контента (CDN). В этом случае запрос, выданный на соединение с любым из физических хостов, как ожидают, будет успешным. Многие способы известны, которым клиент может выбирать среди адресов интернет-протокола, ассоциированных с именем хоста. Например, эти адреса обычно предоставляются клиенту через Систему Доменных Имен и обеспечиваются в порядке приоритетов. Клиент может затем выбрать самый высокоприоритетный (первый) адрес интернет-протокола. Однако обычно не существует координации между клиентами относительно того, как этот выбор делается, так что в итоге различные клиенты могут запросить один и тот же файл от различных серверов. Это может привести к тому, что один и тот же файл будет сохранен в кэше соседних множественных серверов, что снижает эффективность инфраструктуры кэша.
[0473] Это может быть обработано системой, которая предпочтительно увеличивает вероятность, что два клиента, запрашивающие один и тот же блок, запросят этот блок от одного и того же сервера. Новый способ, описанный здесь, содержит выбор среди доступных адресов интернет-протокола способом, заданным идентификатором файла, который должен быть запрошен, и таким образом, что различные клиенты, которым предоставлены одни и те же или аналогичные выборы адресов интернет-протокола и идентификаторов файла, сделают один и тот же выбор.
[0474] Первый вариант осуществления способа описан со ссылками на Фиг. 20. Клиент сначала получает набор адресов интернет-протокола IP1, IP2, IPn, как показано на этапе 1710. Если есть файл, для которого должны быть выданы запросы, как решено на этапе 1720, то клиент определяет, на какой адрес интернет-протокола выдать запросы файла, как определяется на этапах 1730-1770. Имея набор адресов интернет-протокола и идентификатор для файла, который должен быть, запрошен, способ содержит упорядочение адресов интернет-протокола способом, определенным идентификатором файла. Например, для каждого адреса интернет-протокола строится строка байтов, содержащая конкатенацию адреса интернет-протокола и идентификатора файла, как показано на этапе 1730. Хэш-функция применяется к этой строке байтов, как показано на этапе 1740, и получающиеся хэш-значения компонуются согласно фиксированному порядку, как показано на этапе 1750, например, увеличивая порядок номеров, указывающих упорядочение в отношении адресов интернет-протокола. Одна и та же хэш-функция может использоваться всеми клиентами, таким образом, гарантируя, что к одному и тому же результату приводит хэш-функция при заданных входных данных, введенных всеми клиентами. Хэш-функция может статически конфигурироваться во всех клиентах в наборе клиентов, или все клиенты в наборе клиентов могут получить частичное или полное описание хэш-функции, когда клиенты получают список адресов интернет-протокола, или все клиенты в наборе клиента могут получить частичное или полное описание хэш-функции, когда клиенты получают идентификатор файла, или хэш-функция может быть определена другим средством. Адрес интернет-протокола, который является первым в этом порядке, выбирается, и этот адрес затем используется, чтобы установить соединение, и выдаются запросы на все или части файла, как показано на этапах 1760 и 1770.
[0475] Способ, описанный выше, может быть применен, когда новое соединение установлено, чтобы запросить файл. Он также может быть применен, когда многие установленные соединения доступны, и одно из них может быть выбрано, чтобы выдать новый запрос.
[0476] Кроме того, когда установленное соединение доступно, и запрос может быть выбран из набора запросов-кандидатов с равным приоритетом, упорядочение в отношении запросов-кандидатов вызывается, например, тем же способом значений хэш-функции, описанных выше, и выбирается запрос-кандидат, оказывающийся первым в этом порядке. Способы могут быть объединены, чтобы выбрать и соединение и запрос-кандидат из набора соединений и запросов равного приоритета, снова вычисляя хэш-функцию для каждой комбинации соединения и запроса, упорядочивая эти значения хэш-функции согласно фиксированному упорядочению и выбирая комбинацию, которая имеет место первой в порядке, вызванным в отношении набора комбинаций запросов и соединений.
[0477] Этот способ является выгодным по следующей причине: типичный подход, применяемый инфраструктурой, обслуживающей блоки, такой как тот, что показан на Фиг. 1 (BSI 101) или Фиг. 2 (BSI 101), и в особенности подход, обычно применяемый посредством CDN, заключается в обеспечении множественных кэширующих прокси-серверов, которые принимают запросы клиента. Кэширующий прокси-сервер может быть не обеспечен файлом, запрошенным в заданном запросе, и в этом случае такие серверы обычно направляют запрос к другому серверу, принимают ответ от этого сервера, обычно включающий в себя запрошенный файл, и направляют ответ клиенту. Кэширующий прокси-сервер может также хранить (кэшировать) запрошенный файл так, чтобы он немедленно мог ответ на последующие запросы о файле. Этот общий подход, описанный выше, имеет то свойство, что набор файлов, хранящихся на заданном кэширующем прокси-сервере, в значительной степени определен набором запросов, которые принял кэширующий прокси-сервер.
[0478] Способ, описанный выше, имеет следующее преимущество. Если всем клиентам в наборе клиентов предоставят один и тот же список адресов интернет-протокола, то эти клиенты будут использовать один и тот же адрес интернет-протокола для всех запросов, выданных для одного и того же файла. Если будет два различных списка адресов интернет-протокола, и каждому клиенту предоставляют один из этих двух списков, то клиенты будут использовать самое большее два различных адреса интернет-протокола для всех запросов, выданных для одного и того же файла. Обычно, если списки адресов интернет-протокола, предоставленных клиентам, аналогичны, то клиенты будут использовать малый набор обеспеченных адресов интернет-протокола для всех запросов, выданных для одного и того же файла. Так как имеется тенденция ближайшим клиентам предоставлять аналогичные списки адресов интернет-протокола, вероятно, что ближайшие клиенты будут запрашивать файлы только от малой части кэширующих прокси-серверов, доступных для этих клиентов. Таким образом, будет только малая доля кэширующих прокси-серверов, которые кэшируют файл, что предпочтительно минимизирует объем кэширования ресурсов, используемых для кэширования файла.
[0479] Предпочтительно хэш-функция имеет свойство, что очень малая доля различных вводов отображается на (преобразуется в) один и тот же результат, и что различные входные данные отображаются на по существу случайные выходные данное, чтобы гарантировать, что для заданного набора адресов интернет-протокола доля файлов, для которых заданный один из адресов интернет-протокола является первым в отсортированном списке, полученном на этапе 1750, является приблизительно одной и той же для всех адресов интернет-протокола в списке. С другой стороны, важно, что хэш-функция детерминирована, в том смысле, что для заданного входа выходной результат хэш-функции является одним и тем же для всех клиентов.
[0480] Другое преимущество способа, описанного выше, является следующим. Предположим, что всем клиентам в наборе клиентов предоставлен один и тот же список адресов интернет-протокола. Из-за свойств хэш-функции, описанной выше, вероятно, что запросы различных файлов от этих клиентов будут равномерно распределены по набору адресов интернет-протокола, что в свою очередь означает, что запросы будут распределены равномерно по кэширующим прокси-серверам. Таким образом, ресурсы кэширования, используемые для того, чтобы хранить эти файлы, распределены равномерно по кэширующим прокси-серверам, и запросы файлов распределены равномерно по кэширующим прокси-серверам. Таким образом, способ обеспечивает и балансирование хранения, и балансирование нагрузки с помощью инфраструктуры кэширования.
[0481] Многие изменения к подходу, описанному выше, известны специалистам, и во многих случаях эти изменения сохраняют свойство, что набор файлов, хранящихся на заданном прокси, определен, по меньшей мере, частично, набором запросов, которые принял кэширующий прокси-сервер. В общем случае, в котором заданное имя хоста разрешается для множественных физических кэширующих прокси-серверов, будет общим, что все эти серверы, в конечном счете, сохранят копию любого заданного файла, который часто запрашивают. Такое дублирование может быть нежелательным, так как ресурсы хранения на кэширующих прокси-серверах ограничены, и в результате файлы могут быть при случае удалены (очищены) из кэша. Новый способ, описанный здесь, гарантирует, что эти запросы заданного файла направлены на кэширующие прокси-серверы таким образом, что это дублирование уменьшается, таким образом, уменьшая необходимость удалить файлы из кэша, и таким образом увеличивая вероятность, что любой заданный файл присутствует в (то есть, не был очищен) в прокси-кэше.
[0482] Когда файл присутствует в прокси-кэше, ответ, посланный клиенту, является более быстрым, что имеет преимущество в уменьшении вероятности, что запрошенный файл прибывает поздно, что может привести к паузе в проигрывании мультимедиа, и поэтому - плохому пользовательскому восприятию (опыту). Дополнительно, когда файл не присутствует в прокси-кэше, запрос может быть послан в другой сервер, вызывая дополнительную нагрузку и на обслуживающую инфраструктуру и на сетевые соединения между серверами. Во многих случаях сервер, в который посылают запрос, может быть в удаленном местоположении, и передача файла от этого сервера назад к кэширующему прокси-серверу может подвергнуться затратам на передачу. Поэтому новый способ, описанный здесь, приводит к уменьшению этих затрат на передачу.
ВЕРОЯТНОСТНЫЕ ЗАПРОСЫ ЦЕЛЫХ ФАЙЛОВ
[0483] Конкретная проблема в случае, когда протокол HTTP используется с запросами диапазона, заключается в поведении серверов кэша, которые обычно используются, чтобы обеспечить масштабируемость в обслуживающей инфраструктуре. В то время как для серверов кэша HTTP может быть характерно, поддерживать заголовок диапазона HTTP, точное поведение различных серверов кэша HTTP изменяется посредством реализации. Большинство реализаций сервера кэша обслуживает запросы диапазона из кэша в случае, когда файл доступен в кэше. Общая реализация серверов кэша HTTP всегда направляет нисходящие (в нисходящем направлении) запросы HTTP, содержащие заголовок диапазона, на расположенный выше по тракту передачи узел, если сервер кэша не имеет копии файла (сервер кэша или исходный сервер). В некоторых реализациях ответом в восходящем направлении на запрос диапазона является весь файл, и этот весь файл кэшируется, и ответ на нисходящий запрос диапазона извлекается из этого файла и посылается. Однако, по меньшей мере, в одной реализации, восходящим ответом на запрос диапазона являются только байты данных в самом запросе диапазона, и эти байты данных не кэшируются, а вместо этого только посылаются в качестве ответа на нисходящий запрос диапазона. В результате использование заголовков диапазона клиентами может иметь то последствие, что сам файл никогда не вносится в кэши, и желательные свойства масштабируемости сети будут потеряны.
[0484] Выше была описана работа кэширующих прокси-серверов, а также был описан способ запрашивания блоков из файла, который является агрегациями множественных блоков. Например, это может быть достигнуто посредством использования заголовка запроса диапазона HTTP. Такие запросы ниже названы "частичными запросами". Следующий вариант осуществления описан ниже, который имеет преимущество в случае, когда инфраструктура 101 обслуживания блоков не оказывает полную поддержку для заголовка диапазона HTTP. Обычно, серверы в инфраструктуре обслуживания блоков, например, Сети доставки контента, поддерживает частичные запросы, но могут не сохранять ответ на частичные запросы в локальном запоминающем устройстве (кэше). Такой сервер может выполнить частичный запрос, направляя запрос другому серверу, если только весь файл не хранится в локальном запоминающем устройстве, в этом случае ответ можно послать без направления запроса другому серверу.
[0485] Система потоковой передачи с запросом блоков, которая осуществляет использование нового расширения агрегации блоков, описанной выше, может выполняться плохо, если инфраструктура обслуживания блоков проявляет это поведение, так как все запросы, будучи частичными запросами, будут отправлены другому серверу, и никакие запросы не будут обслужены кэширующими прокси-серверами, отвергая задачу обеспечения кэширующих прокси-серверов в первом месте. Во время обработки потоковой передачи запроса блоков, как описано выше, клиент может в некоторый момент запросить блок, который находится в начале файла.
[0486] Согласно новому способу, описанному здесь, всякий раз, когда некоторое условие соблюдено, такие запросы могут быть преобразованы из запросов первого блока в файле к запросу всего файла. Когда запрос целого файла принят кэширующим прокси-сервером, прокси-сервер обычно сохраняет ответ. Поэтому использование этих запросов заставляет заносить файл в кэш локальных кэширующих прокси-серверов таким образом, что последующие запросы, или запросы полного файла или частичные запросы, могут быть обслужены непосредственно кэширующим прокси-сервером. Условие может быть таким, что среди набора запросов, ассоциированных с заданным файлом, например, набор запросов, генерируемых набором клиентов, просматривающих интересующий элемент контента, условие будет соблюдено для, по меньшей мере, обеспеченной доли этих запросов.
[0487] Примером подходящего условия является то, что случайным образом выбранное количество выше обеспеченного порога. Этот порог может быть установлен таким образом, что преобразование запроса единственного блока в запрос целого файла происходит в среднем для обеспеченной доли запросов, например, один раз из десяти (когда случайное число может быть выбрано из интервала [0,1], и порог может быть равен 0,9). Другим примером подходящего условия является то, что хэш-функция, вычисленная по небольшому количеству информации, ассоциированной с блоком, и некоторой информации, ассоциированной с клиентом, принимает одно из обеспеченного набора значений. Этот способ имеет преимущество в том, что для файла, который часто запрашивают, этот файл будет внесен в кэш локального прокси-сервера, однако, работа системы потоковой передачи с запросом блоков не изменяется значительно от стандартной работы, в которой каждый запрос делается для единственного блока. Во многих случаях, когда происходит преобразование запроса из запроса единственного блока в запрос целого файла, клиентские процедуры могут в ином случае продолжать запрашивать другие блоки в пределах файла. Если дело обстоит так, то такие запросы могут быть подавлены, так как интересующие блоки будут приняты в любом случае в результате запроса целого файла.
КОНСТРУКЦИЯ URL И ГЕНЕРИРОВАНИЕ СПИСКА СЕГМЕНТОВ И ПОИСК
[0488] Генерирование списка сегментов имеет дело с проблемой того, как клиент может сгенерировать список сегментов из MPD в конкретное локальное клиентское время NOW для конкретного представления, которое начинается в некоторое начальное время (starttime) или относительно начала представления мультимедиа для случаев по требованию или выраженных во времени «настенных часов». Список сегментов может содержать указатель, например URL, на необязательные начальные метаданные представления, а также список сегментов мультимедиа. Каждому сегменту мультимедиа может быть назначено начальное время, длительность и указатель. Начальное время обычно выражает приближение времени мультимедиа содержащегося в сегменте мультимедиа, но не обязательно точное время выборки. Начальное время используется клиентом потоковой передачи HTTP, чтобы выдать запрос загрузки в подходящее время. Генерирование списка сегментов, включая начальное время каждого, может быть сделано разными способами. URL могут быть обеспечены как список проигрывания, или правило построения URL может предпочтительно использоваться для компактного представления списка сегментов.
[0489] Список сегментов, основанный на построении URL, может, например, быть выполнен, если MPD сигнализирует это конкретным атрибутом или элементом, таким как FileDynamicInfo или эквивалентным сигналом. Общий способ создать список сегментов из конструкции URL предложен ниже в секции "Обзор конструкции URL”. Основанная на списке воспроизведения конструкция может, например, быть сигнализирована различным сигналом. Поиск в списке сегментов и получение точного времени мультимедиа также предпочтительно реализуется в этом контексте.
КРАТКИЙ ОБЗОР КОНСТРУКТОРА URL
[0490] Как выше описано, в одном варианте осуществления настоящего изобретения может быть обеспечен файл метаданных, содержащий правила построения URL, которые позволяют клиентским устройствам конструировать идентификаторы файлов для блоков представления. Ниже описывается дополнительное новое расширение к системе потоковой передачи с запросом блоков, которое предусматривает изменения в файле метаданных, включая изменения в правилах построения URL, изменения в объеме доступного кодирования, изменения в метаданных, ассоциированных с доступным кодирования, таких как скорость передачи в битах, формат изображения, разрешение, аудио или видео кодек или параметры кодека или другие параметры.
[0491] В этом новом расширении могут быть обеспечены дополнительные данные, ассоциированные с каждым элементом файла метаданных, указывая временной интервал в пределах полного представления. В пределах этого временного интервала элемент можно считать достоверным, и иначе временной интервал, элемент может быть проигнорирован. Кроме того, синтаксис метаданных может быть расширен таким образом, что элементы, которым ранее разрешено было появляться только однажды или самое большее однажды, могут появляться многократно. Дополнительное ограничение может быть применено в этом случае, которое обеспечивает то, что для таких элементов заданные временные интервалы должны быть несвязными. В любой заданный момент времени рассмотрение только элементов, временной интервал которых содержит заданные моменты времени, приводит к файлу метаданных, который совместим с первоначальным синтаксисом метаданных. Такие временные интервалы названы интервалами достоверности. Этот способ, поэтому предусматривает сигнализацию в пределах изменений единственного файла метаданных вида, описанного выше. Выгодно, такой способ может использоваться, чтобы обеспечить представление мультимедиа, которое поддерживает изменения вида, описанного в заданных точках в пределах представления.
КОНСТРУКТОР URL
[0492] Как описано здесь, общей особенностью систем потоковой передачи с запросом блоков является необходимость предоставить клиенту "метаданные", которые идентифицируют доступные кодирования мультимедиа и предоставляют информацию, необходимую клиенту, чтобы запросить блоки из этих кодирований. Например, в случае HTTP эта информация может содержать URL для файлов, содержащих блоки мультимедиа. Файл списка воспроизведения может быть обеспечен, который перечисляет URL для блоков для заданного кодирования. Множественные файлы списка воспроизведения обеспечены, один для каждого кодирования, вместе с главным списком воспроизведения из списков воспроизведения, которые перечисляет списки воспроизведения, соответствующие различным кодированиям. Неудобство этой системы заключается в том, что метаданные могут стать весьма большими и поэтому требуют времени, чтобы быть запрошенными, когда клиент начинает поток. Другое неудобство этой системы очевидно в случае «живого» контента, когда файлы, соответствующие блокам данных мультимедиа, генерируются "на лету" из потока мультимедиа, который захвачен в режиме реального времени («вживую»), например, спортивное событие или программа новостей в режиме реального времени. В этом случае файлы списка воспроизведения могут быть обновлены каждый раз, когда новый блок доступен (например, каждые несколько секунд). Клиентские устройства могут повторяющимся образом извлекать файл списка воспроизведения, чтобы определить, доступны ли новые блоки, и получать их URL. Это может внести значительную нагрузку в обслуживающую инфраструктуру, и в частности означает, что файлы метаданных не могут быть кэшированы дольше, чем интервал обновления, который равен размеру блока, который обычно имеет порядок нескольких секунд.
[0493] Один важный аспект системы потоковой передачи с запросом блоков заключается в способе, используемом, чтобы сообщить клиентам идентификаторы файла, например URL, которые должны использоваться, вместе с протоколом загрузки файлов, чтобы запрашивать блоки. Например, способ, в котором для каждого представления в представлении обеспечен файл списка воспроизведения, который перечисляет URL файлов, содержащих блоки данных мультимедиа. Неудобство этого способа заключается в том, что, по меньшей мере, часть файла самого списка воспроизведения должна быть загружена прежде, чем проигрывание может начаться, увеличивая время переключения канала, и поэтому вызывая плохое пользовательское восприятие. Для длинного представления мультимедиа с несколькими или многими представлениями список URL файлов может быть большим, и, следовательно, файл списка воспроизведения может быть большим, дополнительно увеличивая время переключения канала.
[0494] Другое неудобство этого способа происходит в случае «живого» контента. В этом случае полный список URL не сделан доступным заранее, и файл списка воспроизведения периодически обновляется, когда новые блоки становятся доступными, и клиенты периодически запрашивают файл списка воспроизведения, чтобы принять обновленную версию. Поскольку этот файл часто обновляется, он не может долгое время храниться в кэширующих прокси-серверах. Это означает, что очень многие запросы этого файла будут отправлены другим серверам и в конечном счете серверу, который генерирует этот файл. В случае популярного представления мультимедиа это может привести к высокой нагрузке на этом сервере и сети, что может в свою очередь привести к медленному времени ответа и поэтому высокому времени переключения канала и плохому пользовательскому восприятию. В худшем случае сервер становится перегруженным, и это приводит к тому, что некоторые пользователи не смогут просмотреть представление.
[0495] Желательно в структуре системы потоковой передачи с запросом блоков избежать установление ограничения в отношении формы идентификаторов файла, которые могут быть использованы. Это потому, что многие рассмотрения могут мотивировать использование идентификаторов конкретной формы. Например, в случае, когда инфраструктурой обслуживания блоков является сеть доставки контента, могут быть соглашения обозначения или сохранения файлов, относящиеся к желанию распределить хранение или обслуживание нагрузки по сети, или другие требования, которые приводят к конкретным формам идентификатора файла, которые не могут быть предсказаны во время конструирования системы.
[0496] Другой вариант осуществления описан ниже, который смягчает вышеупомянутые неудобства, в то же время, сохраняя гибкость, чтобы выбрать подходящие соглашения об идентификационной информации файла. В этом способе метаданные могут быть обеспечены для каждого представления из представления мультимедиа, содержащего правило построения идентификатора файла. Правило построения идентификатора файла может, например, содержать текстовую строку. Чтобы определить идентификатор файла для заданного блока представления, способ интерпретации правила построения идентификатора файла может быть обеспечен, причем этот способ содержит определение входных параметров и оценку правила построения идентификационной информации файла, вместе с входными параметрами. Входные параметры могут, например, включать в себя индекс файла, который должен быть идентифицирован, когда первый файл имеет индекс ноль, второй имеет индекс один, третий имеет индекс два, и так далее. Например, в случае, когда каждый файл охватывает одну и ту же длительность времени (или приблизительно одну и ту же длительность времени), то индекс файла, ассоциированного с любым заданным временем в пределах представления, может легко быть определен. Альтернативно, время в пределах представления, охваченное каждым файлом, может быть обеспечено в представления или метаданных версии.
[0497] В одном варианте осуществления правило построения идентификатора файла может содержать текстовую строку, которая может содержать некоторые специальные идентификаторы, соответствующие входным параметрам. Способ оценки правила построения идентификатора файла содержит определение позиции специальных идентификаторов в текстовой строке и замену каждого такого специального идентификатора строковым представлением значения соответствующего входного параметра.
[0498] В другом варианте осуществления правило построения идентификатора файла может содержать текстовую строку, соответствующую языку выражения. Язык выражения содержит определение синтаксиса, которому выражения на языке могут соответствовать, и набор правил для того, чтобы оценить строку, соответствующую синтаксису.
[0499] Конкретный пример описан ниже со ссылками на Фиг. 21 и т.д. Пример определения синтаксиса для подходящего языка выражения, определенного в расширенной форме Бэкуса - Наура, БНФ, является таким, как показано на Фиг. 21. Пример правил для оценки строки, соответствующей продукции <expression> (<выражение>) на Фиг. 21, содержит рекурсивное преобразование строки, совместимой с продукцией <expression> (<expression>), в строку, совместимую с продукцией <lateral> (<буквальное>) следующим образом:
[0500] <expression>, совместимое с продукцией <lateral> не изменяется.
[0501] <expression>, совместимое с продукцией <variable> (<переменная>), заменяется значением переменной, идентифицированной строкой <token> (<маркер>) продукции <variable>.
[0502] <expression>, совместимое с продукцией <function> (<функция>), оценивается посредством оценки каждого из его аргументов согласно этим правилам и применяя преобразование к этим аргументам, в зависимости от элемента <token> продукции <функция>, как описано ниже.
[0503] <expression>, совместимое с последней альтернативой продукции <expression>, оценивается посредством оценки двух элементов <expression> и применяя операцию к этим аргументам, в зависимости от элемента <operator> (<оператор>) последней альтернативы продукции <expression>, как описано ниже.
[0504] В способе, описанном выше, принимается, что оценка имеет место в контексте, в котором может быть определено множество переменных. Переменная является парой (имя, значение), где "имя" является строкой, совместимой с продукцией <token>, и "значение" является строкой, совместимой с продукцией <lateral>. Некоторые переменные могут быть определены вне процесса оценки прежде, чем оценка начнется. Другие переменные могут быть определены в самом процесса оценки. Все переменные являются "глобальными" в том смысле, что только одна переменная существует с каждым возможным "именем".
[0505] Примером функции является функция printf («печатать»). Эта функция принимает один или более аргументов. Первый аргумент, может быть, совместим с продукцией <string> (в дальнейшем "строка"). Функция printf оценивается к преобразованной версии ее первого аргумента. Примененное преобразование является таким же, как функция "printf” стандартной библиотеки (языка) C, с дополнительными аргументами, включенными в продукцию <function>, передавая дополнительные аргументы, ожидаемые функцией printf стандартной библиотекой C.
[0506] Другим примером функции является функция "хэш-функция". Эта функция принимает два аргумента, первым из которых может быть строка, и вторым из которых может быть совместимый с продукцией <number> (в дальнейшем "число"). Функция "хэш-функция" применяет алгоритм хэш-функции к первому аргументу и возвращает результат, который является неотрицательным целым числом, меньшим, чем второй аргумент. Пример подходящей хэш-функции дан в функции C, показанной на Фиг. 22, чьими аргументами являются строка ввода (исключая заключающие кавычки) и числовое входное значение. Другие примеры хэш-функций известны специалистам.
[0507] Другим примером функции является функция "Subst", которая принимает один, два или три строковых аргумента. В случае, когда передается один аргумент, результатом функции "Subst" является первый аргумент. В случае, когда передаются два аргумента, то результат функции "Subst" вычисляют, стирая любые появления второго аргумента (исключая заключающие кавычки) в первом аргументе и возвращая первый аргумент, измененный таким образом. В случае, когда передаются три аргумента, то результат функции "Subst" вычисляют, заменяя любые появления второго аргумента (исключая заключающие кавычки) в первом аргументе третьим аргументом (исключая заключающие кавычки) и возвращая первый аргумент, измененный таким образом.
[0508] Некоторыми примерами операторов являются суммирование, вычитание, деление, умножение и операторы взятия по модулю, идентифицированные продукциями <operator> '+', '-', '/', '*', '%' соответственно. Эти операторы требуют, чтобы продукции <expression> любой стороны продукции <operator> оценивались числами. Оценка оператора содержит применение соответствующей арифметической операции (суммирование, вычитание, деление, умножение и взятие по модулю, соответственно) к этим двум числам обычным образом и возврат результата в форме, совместимой с продукцией <number>.
[0509] Другой пример оператора - оператор присваивания, идентифицированный продукцией <operator> '='. Этот оператор требует, чтобы левый аргумент оценивался как строка, содержание которой совместимо с продукцией <token>. Содержание строки определяется так, чтобы быть символьной строкой внутри заключающих кавычек. Оператор равенства вынуждает переменной, именем которой является <token>, равное содержанию левого аргумента, назначить значение, равное результату оценки правого аргумента. Это значение также является результатом оценки выражения оператора.
[0510] Другим примером оператора является оператор последовательности, идентифицированный продукцией <operator> ';'. Результат оценки этого оператора является правый аргумент. Следует отметить, что как и со всеми операторами, оба аргумента оцениваются, и левый аргумент оценивается первым.
[0511] В одном варианте осуществления этого изобретения идентификатор файла может быть получен посредством оценки правила построения идентификатора файла согласно вышеупомянутому правилу с конкретным набором входных переменных, которые идентифицируют необходимый файл. Примером входной переменной является переменная с именем "индекс" и значением, равным числовому индексу файла в представлении. Другим примером входной переменой является переменная с именем "скорость передачи в битах" и значением, равным средней скорости передачи в битах требуемой версии представления.
[0512] Фиг. 23 иллюстрирует некоторые примеры правил построения идентификатора файла, когда входными переменными являются "id", задающая идентификатор для представления желательного представления, и "seq", задающая последовательный номер для файла.
[0513] Как будет ясно специалистам после прочтения этого раскрытия, возможны многочисленные изменения способа, описанного выше. Например, не все функции и операторы, описанные выше, могут быть обеспечены, или могут быть предоставлены дополнительные функции или операторы.
ПРАВИЛА ПОСТРОЕНИЯ URL И ТАКТИРОВАНИЕ
[0514] Эта секция обеспечивает основные правила построения URI, чтобы назначить файл или сегмент URI, а также начальное время, для каждого сегмента в пределах представления и представления мультимедиа.
[0515] Для этого параграфа принята доступность описания представления мультимедиа в клиенте.
[0516] Предположим, что клиент потоковой передачи HTTP проигрывает мультимедиа, которое загружено в представлении мультимедиа. Фактическое время представления клиента HTTP может быть определено как время представления относительно начала представления. При инициализации может быть принято время представления t=0.
[0517] В любой точке t клиент HTTP может загрузить любые данные с временем проигрывания tP (также относительно начала представления) самое большее MaximumClientPreBufferTime перед фактическим временем представления t и любыми данными, которые требуются из-за пользовательского взаимодействия, например, поиска, перехода вперед и т.д. В некоторых вариантах осуществления MaximumClientPreBufferTime может даже не быть задано в том смысле, что клиент может загрузить данные перед текущим временем проигрывания tP без ограничений.
[0518] Клиент HTTP может избежать загрузки ненужных данных, например, любые сегменты из представлений, которые, как ожидается, не будут проигрываться, могут обычно не загружаться.
[0519] Основной процесс в предоставлении текущих услуг может быть загрузкой данных посредством генерирования соответствующих запросов загрузить все файлы/сегменты или поднабор файлов/сегментов, например, посредством использования запросов GET HTTP или частичных запросов GET HTTP. Это описание направлено на то, как получить доступ к данным для конкретного времени проигрывания tP, но обычно клиент может загрузить данные в течение большего диапазона времени проигрывания, чтобы избежать неэффективных запросов. Клиент HTTP может минимизировать количество/частоту запросов HTTP в предоставлении текущей услуги.
[0520] Для того, чтобы получить доступ к данным мультимедиа во время проигрывания tP или, по меньшей мере, близко к времени проигрывания tP в конкретном представлении, клиент определяет URL для файла, который содержит это время проигрывания и, кроме этого, определяет диапазон в байтах в файле, чтобы получить доступ к этому времени проигрывания.
[0521] Описание Представления Мультимедиа может назначить id представления, r, каждому представлению, например посредством использования атрибута RepresentationID. Другими словами, контент MPD, когда записан системой потребления или когда считан клиентом, будет интерпретироваться таким образом, что есть назначение. Чтобы загрузить данные для конкретного времени проигрывания tP для конкретного представления с id r, клиент может построить соответствующие URI для файла.
[0522] Описание Представления Мультимедиа может назначить каждому файлу или сегменту каждого представления r следующие атрибуты:
[0523] (a) порядковый номер i файла в пределах представления r, с i=1, 2, Nr, (b) относительное начальное время файла с id представления r и индексом i файла относительно времени представления, определенные как ts (r, i), (c) URI файла для файла/сегмента с id представления r и индексом файла i, указанные как FileURI (r, i).
[0524] В одном варианте осуществления начальное время файла и URI файлов могут быть обеспечены явно для представления. В другом варианте осуществления список URI файлов может быть обеспечен явно, когда каждому URI файла неотъемлемо назначают индекс i согласно позиции в списке, и начальное время сегмента получают как сумму всех длительностей сегмента для сегментов от 1 до i-1. Длительность каждого сегмента может быть обеспечена согласно любому из правил, описанных выше. Например, любой специалист в элементарной математике может использовать другие способы, чтобы получить методологию, чтобы легко получить начальное время из единственного элемента или атрибута и позицию/индекс URI файла в представлении.
[0525] Если правило построения динамического URI обеспечено в MPD, то начальное время каждого файла и URI каждого файла может быть построено динамически посредством использования правила построения, индекса запрошенного файла, и возможно некоторых дополнительных параметров, обеспеченных в описании представления мультимедиа. Информация может, например, быть обеспечена в атрибутах MPD и элементах, таких как FileURIPattern и FilelnfoDynamic. FileURIPattern предоставляет информацию о том, как построить URI на основании порядкового номера индекса файла i и ID представления r. FileURIFormat построен как:
[0526] FileURIFormat=sprintf ("%s%s%s%s%s. %s", BaseURI, BaseFileName,
[0527] RepresentationlDFormat, SeparatorFormat,
[0528] FileSequencelDFormat, FileExtension);
[0529] и FileURI (r, i) построен как
[0530] FileURI (r, i)=sprintf (FileURIFormat, r, i);
[0531] Относительное начальное время ts (r, i) для каждого файла/сегмента может быть получено посредством некоторого атрибута, содержащегося в MPD, описывающего длительности сегментов в этом представлении, например, атрибут FilelnfoDynamic. MPD может также содержать последовательность атрибутов FilelnfoDynamic, которая является глобальной для всех представлений в представлении мультимедиа или, по меньшей мере, для всех представлений в периоде таким же образом, как определено выше. Если данные мультимедиа для конкретного времени проигрывания tP в представлении r запрошены, соответствующий индекс i (r, tP) может быть получен как i(r, tp) таким образом, что это время проигрывания этого индекса находится в интервале начального времени ts (r, i (r, tP)) и ts (r, i (r, tP)+1). Доступ к сегменту может быть далее ограничен случаями выше, например, сегмент не доступен.
[0532] Получение доступа к точному времени проигрывания tP, как только индекс и URI соответствующего сегмента получены, зависит от фактического формата сегмента. В этом примере предположим, что сегменты мультимедиа имеют шкалу локального времени, которая начинается в 0 без потери общности. Чтобы получить доступ и представить данные во время проигрывания tP, клиент может загрузить данные, соответствующие локальному времени, из файла/сегмента, к которому можно получить доступ через URI FileURI (r, i) с i=i(r, tp).
[0533] Обычно клиенты могут загрузить весь файл и могут затем получить доступ к времени проигрывания tP. Однако не обязательно вся информация файла 3GP должна быть загружена, так как 3GP файл обеспечивает структуры, чтобы отобразить локальное тактирование в диапазоны в байтах. Поэтому, только конкретные диапазоны байтов, чтобы получить доступ к времени проигрывания tP, могут быть достаточными, чтобы проигрывать мультимедиа, пока достаточная информация произвольного доступа доступна. Также достаточная информация относительно структуры и отображения диапазона в байтах и локального тактирования сегмента мультимедиа может быть обеспечена в начальной части сегмента, например, используя индекс сегментов. При наличии доступа к начальным, например, 1200 байтам сегмента, клиент может иметь достаточную информацию, что непосредственно обратиться к диапазону в байтах, необходимому, чтобы tP времени проигрывания.
[0534] В другом примере предполагают, что индекс сегментов, возможно заданный как поле "tidx", как указано ниже, может использоваться, чтобы идентифицировать смещения в байтах необходимого фрагмента или фрагментов. Частичные запросы GET могут быть сформированы для необходимого фрагмента или фрагментов. Существуют другие альтернативы, например клиент, может выдать стандартный запрос файла и отменить его, когда первое поле "tidx" было принято.
ПОИСК
[0535] Клиент может пытаться искать конкретное время представления tp в представлении. На основании MPD клиент имеет доступ к начальному времени сегмента мультимедиа, и URL сегмента мультимедиа каждого сегмента в представлении. Клиент может получить индекс segment_index сегмента этого сегмента, наиболее вероятно содержащий выборки мультимедиа в течение времени представления tp, когда максимальный индекс i сегмента, для которого начальное время tS (r, i) меньше или равно времени представления tp, то есть segment_index=max {i | tS(r, i)<=tp}. URL сегмента получают как FileURI (r, i).
[0536] Следует отметить, что тактирование информации в MPD может быть приблизительным из-за проблем, относящихся к размещению Точек Произвольного доступа, выравниванию дорожек мультимедиа и дрейф f тактирования мультимедиа. В результате сегмент, идентифицированный в соответствии с процедурой выше, может начаться во время немного позже tp, и данные мультимедиа для времени представления tp могут быть в предыдущем сегменте мультимедиа. В случае поиска или время поиска может быть обновлено, чтобы равняться времени первой выборки извлеченного файла, или предыдущий файл может быть извлечен вместо этого. Однако следует отметить, что во время непрерывного проигрывания, включая случаи, когда имеется переключение между альтернативными представлениями/версиями, данные мультимедиа в течение времени между tp и началом извлеченного сегмента являются, тем не менее, доступными.
[0537] Для точного поиска времени представления tp, клиент потоковой передачи HTTP должен получить доступ к случайной точке доступа (RAP). Чтобы определить точку произвольного доступа в сегменте мультимедиа в случае адаптивной потоковой передачи HTTP 3GPP, клиент может, например, использовать информацию в поле 'tidx' или 'sidx', если они присутствуют, чтобы определить местонахождение точек произвольного доступа и соответствующее время представления в представлении мультимедиа. В случаях, когда сегмент является фрагментом кино 3GPP, для клиента также возможно использовать информацию в пределах полей 'moof' и 'mdat', например, чтобы определить местонахождение RAP и получить необходимое время представления из информации во фрагменте кино и начальное время сегмента, полученное из MPD. Если RAP со временем представления перед требуемым временем представления tp не доступна, клиент может или получить доступ к предыдущему сегменту или может использовать только первую точку произвольного доступа как результат поиска. Когда сегменты мультимедиа начинаются с RAP, эти процедуры просты.
[0538] Также следует отметить, что не обязательно вся информация сегмента мультимедиа должна быть загружена, чтобы получить доступ ко времени представления tp. Клиент может, например, первоначально запросить поле 'tidx' или 'sidx' из начала сегмента мультимедиа, используя запросы диапазона в байтах. Посредством использования полей 'tidx' или 'sidx', тактирование сегмента может быть отображено в диапазоны байтов сегмента. Непрерывно используя частичные запросы HTTP, только к релевантным частям сегмента мультимедиа необходимо получить доступ, для улучшенного пользовательского восприятия и низких задержек запуска.
ГЕНЕРИРОВАНИЕ СПИСКА СЕГМЕНТОВ
[0539] Как описано здесь, должно быть, очевидно, как реализовать клиент прямой потоковой передачи HTTP, который использует информацию, обеспеченную MPD, чтобы создать список сегментов для представления, которое имеет сообщенную приблизительную длительность dur сегмента. В некоторых вариантах осуществления клиент может назначить сегменты мультимедиа в пределах последовательных индексов i=1, 2, 3, представления, то есть, первому сегменту мультимедиа назначен индекс i=1, второму сегменту мультимедиа назначают индекс i=2, и так далее. Затем, списку сегментов мультимедиа с индексами i сегмента назначают startTime[i] и генерируют URL[i], например, следующим образом. Сначала, индекс i устанавливают в 1. Начальное время первого сегмента мультимедиа получают как 0, startTime [1]=0. URL сегмента i мультимедиа, URL[i], получают как FileURI(r, i). Процесс продолжяют для всех описанных сегментов мультимедиа с индексом i и startTime[i] сегмента i мультимедиа получают как (i-1) *dur и URL[i], получают как FileURI(r, i).
ПАРАЛЛЕЛЬНЫЕ ЗАПРОСЫ HTTP/TCP
[0540] Проблемой в системе потоковой передачи с запросом блоков является желание всегда запросить блоки высшего качества, которые могут быть полностью приняты вовремя для проигрывания. Однако скорость прибытия данных не может быть известна заранее и, таким образом, может случиться, что запрошенный блок не прибывает вовремя, чтобы быть проигранным. Это приводит к необходимости сделать паузу в проигрывании мультимедиа, что приводит к плохому пользовательскому восприятию. Эта проблема может быть смягчена алгоритмами клиента, которые проявляют консервативный подход к выбору блоков для запроса, посредством запрашивания блоков более низкого качества (и также меньшего размера), которые, более вероятно, будут приняты вовремя, даже если скорость прибытия данных упадет во время приема блока. Однако этот консервативный подход имеет неудобство в возможной доставке проигрывания более низкого качества пользователю или устройству назначения, что является также плохим пользовательским восприятием. Проблема может быть усугублена, когда множественное число соединений HTTP используются в одно и то же время, чтобы загрузить различные блоки, как описано ниже, так как доступные ресурсы сети совместно используются по соединениям и таким образом одновременно используются для блоков с различными временами проигрывания.
[0541] Может быть предпочтительно для клиента выдать запросы множественных блоков одновременно, где в этом контексте "одновременно" означает, что ответы на запросы происходят в накладывающихся временных интервалах, и это не обязательно является случаем, что запросы делаются точно или даже приблизительно одно и то же время. В случае протокола HTTP этот подход может улучшить использование доступной полосы частот из-за поведения протокола TCP (как хорошо известно). Это может быть особенно важно, чтобы улучшить время переключения контента, как когда новый контент сначала запрошен, соответствующие соединения HTTP/TCP, по которым запрошены данные для блоков, могут быть медленными, чтобы начинаться, и таким образом, использование нескольких соединений HTTP/TCP в этой точке может значительно ускорить срок доставки данных первых блоков. Однако запрашивание различных блоков или фрагментов по различным соединениям HTTP/TCP может также привести к ухудшенной производительности, поскольку запросы блоков, которые должны быть проиграны сначала, конкурируют с запросами последующих блоков, конкурирующие загрузки HTTP/TCP изменяются значительно по их скорости доставки, и таким образом время завершения запроса может быть сильно изменяющимся, и обычно невозможно управлять, какие загрузки HTTP/TCP будут полностью быстрыми и какие будут более медленными, и таким образом вероятно, что по меньшей мере часть времени загрузки HTTP/TCP первых нескольких блоков будет последним для завершения, таким образом приводя к большому и переменному времени переключения каналов.
[0542] Предположим, что каждый блок или фрагмент сегмента загружены по отдельному соединению HTTP/TCP, и что количество параллельных соединений равно n, и длительность проигрывания каждого блока t секунд, и что текущая скорость передачи контента, ассоциированного с сегментом, равна S. Когда клиент сначала начинает потоковую передачу контента, запросы могут быть выданы для первых n блоков, представляя n*t секунд данных мультимедиа.
[0543] Как известно специалистам, есть большая вариация в скорости передачи данных TCP-соединений. Однако чтобы упростить это описание, предположим в идеале, что все соединения осуществляются параллельно таким образом, что первый блок будет полностью принят в приблизительно одно и то же время как и другие запрошенные n-1 блоков. Чтобы еще упростить описание, предположим, что совокупная полоса частот, используемая n соединениями загрузки, фиксирована равным значению B для всей длительности загрузки, и что текущая скорость потоковой передачи S является постоянной по всему представлению. Предположим далее, что структура данных мультимедиа такова, что проигрывание блока может быть сделано, когда весь блок доступен в клиенте, то есть, проигрывание блока может начаться только после того, как весь блок принят, например, из-за структуры лежащего в основе кодирования видео, или, так как используется шифрование, чтобы зашифровать каждый фрагмент или блок отдельно, и таким образом должны быть приняты весь фрагмент или блок прежде, чем он может быть расшифрован. Таким образом, чтобы упростить описание ниже, мы предполагаем, что весь блок должен быть принят прежде, чем любой блок может быть проигран. Тогда время, требуемое перед тем, как приходит первый блок и может быть проигран равно приблизительно n*t*S/B.
[0544] Так как желательно минимизировать время переключения контента, поэтому желательно минимизировать n*t*S/B. Значение t может быть определено факторами, такими как лежащая в основе структура кодирования видео и как способы потребления используются, и таким образом t может быть разумно малым, но очень малые значения t приводят к чрезмерно сложной карте сегментов и возможно могут быть несовместимыми с эффективным кодированием и декодированием видео, если используется. Значение n может также влиять на значение B, то есть, B может быть большим для большего количества n соединений, и таким образом уменьшение количества соединений, n, имеет отрицательный побочный эффект потенциального уменьшения количества доступной полосы частот, которая используется, B, и поэтому может не эффективно в достижении цели уменьшения времени переключения контента. Значение S зависит от того, какое представление выбрано для загрузки и проигрывания, и в идеале S должен быть так близко к B насколько возможно, чтобы максимизировать качество проигрывания мультимедиа для заданных условий сети. Таким образом, чтобы упростить это описание, предположим, что S приблизительно равно B. Тогда время переключения канала пропорционально n*t. Таким образом, использование большего количества соединений, чтобы загрузить различные фрагменты, может ухудшить время переключения канала, если совокупная полоса частот, используемая соединениями, является суб-линейно пропорциональной количеству соединений, которое обычно имеет место.
[0545] В качестве примера, предположим t=1 секунда, и с n=1 значение B=500 Кб/сек, и с n=2 значение B=700 Кб/сек, и с n=3 значение B=800 Кб/сек. Предположим, что выбрано представление с S=700 Кб/сек. Тогда, с n=1 время загрузки для первого блока равно 1 *700/500=1,4 секунды, с n=2 время загрузки для первого блока равно 2*700/700=2 секунды, и с n=3 время загрузки для первого блока равно 3*700/800=2,625 секунды. Кроме того, поскольку количество соединений увеличивается, изменчивость в отдельных скоростях загрузки соединений, вероятно, увеличится (хотя даже с одним соединением, вероятно, будет некоторая существенная изменчивость). Таким образом, в этом примере, время переключения канала и изменчивость во времени переключения канала увеличивается, когда количество соединений увеличивается. Интуитивно, блоки, которые доставляются, имеют различные приоритеты, то есть, первый блок имеет самый ранний крайний срок доставки, второй блок имеет второй самый ранний крайний срок, и т.д., тогда как соединения загрузки, по которым доставляют блоки, конкурируют за ресурсы сети во время доставки, и таким образом блоки с самыми ранними крайними сроками становятся более задержанными, поскольку больше конкурирующих блоков запрашиваются. С другой стороны, даже в этом случае, в конечном счете использование более чем одного соединения загрузки позволяет поддержку надежно более высокой текущей скорости передачи, например, с тремя соединениями, скорость потоковой передачи до 800 Кб/сек может быть поддержана в этом примере, тогда как только поток 500 Кб/сек может быть поддержан с одним соединением.
[0546] Практически, как отмечено выше, скорость передачи данных соединения может быть очень переменной и в пределах одного и того же соединения в течение времени и между соединениями, и, в результате n запрошенных блоков обычно не завершаются в одно и то же время, и фактически это обычно может иметь место, что один блок может быть завершен за половину времени другого блока. Это влияет на результаты в непредсказуемом поведении, так как в некоторых случаях первый блок может быть завершен намного скорее, чем другие блоки, и в других случаях первый блок может быть завершен намного позже, чем другие блоки, и в результате начало проигрывания может в некоторых случаях произойти относительно быстро, и в других случаях может быть медленным для начала. Это непредсказуемое поведение может быть расстраивающим для пользователя и может, поэтому считаться плохим пользовательским восприятием.
[0547] Поэтому необходимы способы, в которых множественные соединения TCP могут быть использованы, чтобы улучшить время переключения канала и изменчивость во времени переключения канала, в то же время, поддерживая возможную скорость потоковой передачи хорошего качества. Также необходимы способы, чтобы разрешить совместное использование доступной полосы частот, назначенной каждому блоку, которая должна быть настроена, когда приближается время проигрывания блока, так чтобы в случае необходимости большая доля доступной полосы частот может быть назначена блоку с самым близким временем проигрывания.
СОВМЕСТНОЕ ЗАПРАШИВАНИЕ HTTP/TCP
[0548] Ниже описаны способы для того, чтобы использовать параллельные запросы HTTP/TCP совместным способом. Приемник может использовать множественные параллельные совместные запросы HTTP/TCP, например, используя множество запросов диапазона в байтах HTTP, в котором каждый такой запрос выдан для части фрагмента в исходном сегменте или всех из фрагмента исходного сегмента, или части или исправленного фрагмента исправленного сегмента, или для всех из исправленного фрагмента исправленного сегмента.
[0549] Преимущества совместных запросов HTTP/TCP вместе с использованием FEC-исправленных данных могут быть особенно важными, чтобы обеспечить согласованное быстрое время переключения канала. Например, во время переключения канала, вероятно, что соединения TCP были или только что начаты или были в состоянии ожидания в течение некоторого промежутка времени, в этом случае окно перегрузки, cwnd, находится в его минимальном значении для соединений, и таким образом скорость доставки этих TCP-соединений займет несколько раз передач туда и обратно (RTT), чтобы повыситься, и будет высокая изменчивость в скоростях доставки по различным соединениям TCP в течение этого времени повышения.
[0550] Краткий обзор способа без - FEC описан ниже, который является способом совместного запроса HTTP/TCP, в котором только данные мультимедиа исходных блоков запрашиваются, используя множественные одновременные соединения HTTP/TCP, то есть, никаких FEC-исправленных данных не запрашивают. В способе без - FEC части одного и того же фрагмента запрашивают по различным соединениям, например, используя запросы диапазонов в байтах HTTP для частей фрагмента, и таким образом, например, каждый запрос диапазона в байтах HTTP предназначен для части диапазона в байтах, обозначенного в карте сегментов для этого фрагмента. Может иметь место случай, что отдельный запрос HTTP/TCP повышает свою скорость доставки, чтобы полностью использовать доступную полосу частот посредством нескольких RTT (времен передачи туда и обратно), и таким образом имеется относительно длительный период времени, когда скорость доставки меньше, чем доступная полоса частот, и таким образом, если единственное соединение HTTP/TCP используется, чтобы загрузить, например, первый фрагмент контента, который должен быть проигран, время переключения канала может быть большим. Используя способ без - FEC, загрузка различных частей одного и того же фрагмента по различным соединениям HTTP/TCP может значительно уменьшить время переключения канала.
[0551] Краткий обзор способа FEC описан ниже, который является способом совместного запроса HTTP/TCP, в котором данные мультимедиа исходного сегмента и данные, исправленные посредством FEC, генерируемые из данных мультимедиа, запрашиваются, используя множественные одновременные соединения HTTP/TCP. В способе FEC части одного и того же фрагмента и FEC-исправленных данных, генерируемых из этого фрагмента, запрашивают по различным соединениям, используя запросы диапазона в байтах HTTP для частей фрагмента, и таким образом, например, каждый запрос диапазона в байтах HTTP предназначен для части диапазона в байтах, указанного в карте сегментов для этого фрагмента. Может иметь место случай, что отдельный запрос HTTP/TCP повышает свою скорость доставки, чтобы полностью использовать доступную полосу частот посредством нескольких RTT (времен передачи туда и обратно), и таким образом имеется относительно длительный период времени, когда скорость доставки меньше, чем доступная полоса частот, и таким образом, если единственное соединение HTTP/TCP используется, чтобы загрузить, например, первый фрагмент контента, который должен быть проигран, время переключения канала может быть большим. Использование FEC-способа имеет те же самые преимущества как способ без - FEC, и имеет дополнительное преимущество, что не все запрошенные данные должны прибыть прежде, чем фрагмент может быть восстановлен, таким образом дополнительно уменьшая время переключения канала и изменчивость во времени переключения канала. Делая запросы по различным соединениям TCP, и перезапрашивая посредством также запрашивания FEC-исправленных данных, по меньшей мере, одному из соединений, величина времени, которая требуется, чтобы доставить достаточное количество данных, чтобы, например, восстановить первый запрошенный фрагмент, который позволяет начать воспроизведение мультимедиа, может быть значительно уменьшено и сделано быть намного более согласованными, чем, если бы совместные соединения TCP и FEC-исправленные данные не использовались.
[0552] Фиг. 24 (a)-(e) показывают пример флуктуаций скорости доставки 5 TCP-соединений, запущенных по одной и той же линии связи к одному и тому же клиенту от одного и того же web-сервера HTTP эмулированной сети эволюционированной оптимизированной передача данных (EVDO). На Фиг. 24 (a)-(e) ось X показывает время в секундах, и ось Y показывает скорость передачи, с которой биты, принимаются в клиенте по каждому из 5 TCP-соединений, измеренных по интервалам 1 секунда, для каждого соединения. В этой конкретной эмуляции было 12 TCP-соединений, всего запущенных по этой линии связи, и таким образом сеть была относительно загружена в течение показанного времени, что может быть типичным, когда больше чем один клиент осуществляет потоковую передачу в пределах одной и той же ячейки мобильной сети. Следует отметить, что, хотя скорости доставки несколько коррелированны во времени, есть большая разница в скоростях доставки этих 5 соединений во многих точках во времени.
[0553] Фиг. 25 показывает возможную структуру запроса для фрагмента, который составляет 250000 битов по размеру (приблизительно 31,25 килобайта), когда есть 4 запроса диапазона в байтах HTTP, сделанных параллельно для различных частей фрагмента, то есть, первое соединение HTTP запрашивает первые 50000 битов, второе соединение HTTP запрашивает следующие 50000 битов, третье соединение HTTP запрашивает следующие 50000 битов, и четвертое соединение HTTP запрашивает следующие 50000 битов. Если FEC не используется, то есть, способ без - FEC, то имеются только эти 4 запроса для фрагмента в этом примере. Если FEC используется, то есть, способ FEC, то в этом примере есть одно дополнительное соединение HTTP, которое запрашивает дополнительные 50000 битов FEC-исправленных данных исправленного сегмента, генерируемого из этого фрагмента.
[0554] Фиг. 26 является увеличенным изображением первых двух секунд 5 TCP-соединений, показанных на Фиг. Фиг. 24 (a)-(e), где на Фиг. 26 ось X показывает время с промежутками в 100 миллисекунд, и ось Y показывает скорость, с которой биты, принимаются в клиенте по каждому из 5 TCP-соединений, измеренных по интервалам 100 миллисекунд. Одна линия показывает совокупное количество битов, которое было принято в клиенте для этого фрагмента из первых 4 соединений HTTP (исключая соединение HTTP, по которому запрошены данные FEC), то есть, которые прибывают, не используя способ без - FEC. Другая линия показывает совокупное количество битов, которое было принято в клиенте для фрагмента от всех 5 из соединений HTTP (включая соединение HTTP, по которому запрошены FEC-данные), то есть, которые прибывают, используя способ FEC. Для способа FEC предполагается, что фрагмент может быть FEC декодированным из приема любых 200000 битов из 250000 запрошенных битов, которые могут быть реализованы, если используется, например, код FEC Рида-Соломона, и который может по существу реализоваться, если например код RaptorQ, описанный в Luby IV, используется. Для способа FEC в этом примере достаточно данных принято, чтобы восстановить фрагмент, используя FEC-декодирование после 1 секунды, обеспечивая время переключения канала в 1 секунду (предполагая, что данные для последующих фрагментов могут быть запрошены и приняты прежде, чем первый фрагмент полностью проигран). Для способа без - FEC в этом примере должны быть приняты все данные для этих 4 запросов прежде, чем фрагмент может быть восстановлен, что имеет место после 1,7 секунды, приводя к времени переключения канала равному 1,7 секунды. Таким образом, в примере, показанном на Фиг. 26, способ без - FEC на 70% хуже в терминах времени переключения канала, чем способ FEC. Одна из причин для преимущества, показанного способом FEC в этом примере, заключается в том, что для способа FEC прием любых 80% запрошенных данных позволяет восстановить фрагмент, тогда как для способа без - FEC прием 100% запрошенных данных требуется. Таким образом, способ без - FEC должен ждать самого медленного соединения TCP, чтобы закончить доставку, и из-за естественных изменений в скорости доставки TCP имеется вероятность большой дисперсии в скорости доставки самого медленного соединения TCP по сравнению со средним соединением TCP. Со способом FEC в этом примере одно медленное соединение TCP не определяет, когда фрагмент является восстанавливаемым. Вместо этого, для способа FEC доставка достаточно многих данных является намного большей функцией средней скорости доставки TCP, чем скорость доставки TCP в худшей случае.
[0555] Есть много изменений способа без - FEC и способа FEC, описанных выше. Например, совместный запрос HTTP/TCP может использоваться только для первых нескольких фрагментов после того, как произошло переключение канала, и после этого используется только единственный запрос HTTP/TCP, чтобы загрузить дальнейшие фрагменты, множественные фрагменты, или все сегменты. В качестве другого примера, количество совместных используемых соединений HTTP/TCP может быть функцией как срочности фрагментов, которые запрошены, то есть, насколько неизбежно время проигрывания этих фрагментов, и текущих условий в сети.
[0556] В некоторых вариациях множество соединений HTTP может использоваться, чтобы запросить исправленные данные из исправленных сегментов. В других вариациях различные количества данных могут быть запрошены на различных соединениях HTTP, например, в зависимости от текущего размера буфера мультимедиа и скорости приема данных в клиенте. В другой вариации исходные представления не являются независимыми друг от друга, но вместо этого представляют многоуровневое кодирование мультимедиа, когда, например, расширенное исходное представление может зависеть от базового исходного представления. В этом случае, может быть исправленное представление, соответствующее базовому исходному представлению, и другое исправленное представление, соответствующее комбинации базового и расширенного исходного представлений.
[0557] Дополнительные общие элементы добавляют к преимуществам одно, которое можно реализовать способами, раскрытыми выше. Например, количество используемых соединений HTTP может измениться в зависимости от текущего объема мультимедиа в буфере мультимедиа, и/или скорости приема в буфер мультимедиа. Совместные запросы HTTP, использующие FEC, то есть, способ FEC, описанный выше и варианты этого способа, могут быть использованы активно, когда буфер мультимедиа является относительно пустым, например, больше совместных запросов HTTP сделано параллельно для различных частей первого фрагмента, запрашивающих весь исходный фрагмент и относительно большую долю исправленных данных из соответствующего исправленного фрагмента, и затем переходя к уменьшенному количеству одновременных запросов HTTP, запрашивая большие части данных мультимедиа в каждом запросе, и запрашивая меньшую долю исправленных данных, например, переходя к 1, 2 или 3 одновременным запросам HTTP, переходя к созданию запросов полных фрагментов или множественных последовательных фрагментов для каждого запроса, и переходя к тому, чтобы не запрашивать исправленные данные, когда буфер мультимедиа растет.
[0558] В качестве другого примера, количество FEC-исправленных данных может изменяться как функция размера буфера мультимедиа, то есть, когда буфер мультимедиа является малым, то больше FEC-исправленных данных может быть запрошено, и когда буфер мультимедиа растет, то количество запрошенных FEC-исправленных данных может уменьшаться, и в некоторый момент, когда буфер мультимедиа является достаточно большим, то никаких FEC-исправленных данных можно не запрашивать, а только данные из исходных сегментов исходных представлений. Выгоды таких расширенных способов заключаются в том, что они могут разрешить более быстрое и более согласованное время переключения канала, и большую устойчивость против потенциальных задержек или остановок мультимедиа, в то же время минимизируя величину дополнительной полосы частот, использованной помимо величины, которая потреблялась бы посредством только доставки мультимедиа в исходных сегментах, посредством уменьшения как трафика сообщений запросов, так и FEC-исправленных данных, в то же время, обеспечивая поддержку самых высоких скоростей передачи мультимедиа, возможных для заданных условий сети.
ДОПОЛНИТЕЛЬНЫЕ РАСШИРЕНИЯ ПРИ ИСПОЛЬЗОВАНИИ ОДНОВРЕМЕННЫХ СОЕДИНЕНИЙ HTTP
[0559] Запрос HTTP/TCP может быть отменен, если подходящее условие соблюдено, и другой запрос HTTP/TCP может быть сделан, чтобы загрузить данные, которые могут заменить данные, запрошенные в отмененном запросе, причем второй запрос HTTP/TCP может запрашивать точно те же самые данные как в первоначальном запросе, например, исходные данные; или перекрывающиеся данные, например, некоторые из одних и тех же исходных данных и исправленных данных, которые не были запрошены в первом запросе; или полностью несвязные данные, например, исправленные данные, которые не были запрошены в первом запросе. Пример подходящего условия заключается в том, что запрос терпит неудачу из-за отсутствия ответа от серверной инфраструктуры блоков (BSI) в пределах обеспеченного времени или отказа в установлении транспортного соединения с BSI или приема явного сообщения отказа от сервера или другого условия отказа.
[0560] Другой пример подходящего условия заключается в том, что прием данных происходит необычно медленно, согласно сравнению меры скорости соединения (скорости прибытия данных в ответ на рассматриваемый запрос) с ожидаемой скоростью соединения или с оценкой скорости соединения, требуемой, чтобы принять ответ перед временем проигрывания данных мультимедиа, содержащихся в нем, или другой временной зависимостью от этого времени.
[0561] Этот подход имеет преимущество в случае, когда BSI иногда показывает отказы или плохую производительность. В этом случае подход, описанный выше, увеличивает вероятность, что клиент может продолжить надежное проигрывание данных мультимедиа, несмотря на отказы или плохую производительность в BSI. Следует отметить, что в некоторых случаях может быть выгодно, создать BSI таким образом, что она действительно проявляет такие отказы или плохую производительность иногда, например, такая структура может иметь более низкую стоимость, чем альтернативная структура, которая не проявляет такие отказы или плохую производительность, или, которая показывает их менее часто. В этом случае способ, описанный здесь, имеет преимущество в том, что он разрешает использование такой структуры более низкой стоимости для BSI без последующего ухудшения в пользовательском восприятии.
[0562] В другом варианте осуществления количество запросов, выданных для данных, соответствующих заданному блоку, может зависеть от того, соблюдено ли подходящее условие относительно этого блока. Если условие не соблюдено, то клиент может быть ограничен от создания дополнительных запросов этого блока, если успешное завершение всех в настоящее время незавершенных запросов данных для этого блока может разрешить восстановление блока с высокой вероятностью. Если условие соблюдено, то большее количество запросов блока может быть выдано, то есть, ограничение выше не применяется. Пример подходящего условия заключается в том, что время до запланированного времени проигрывания блока или другое время, зависимое от этого времени, падает ниже обеспеченного порога. Этот способ имеет преимущество, так как дополнительные запросы данных для блока выдаются, когда прием блока становится более срочным, так как время проигрывания данных мультимедиа, содержащих блок, близко. В случае общих транспортных протоколов, таких как HTTP/TCP, эти дополнительные запросы имеют эффект увеличения совместного использования доступной полосы частот, выделенной данным, которые дают вклад в прием рассматриваемого блока. Это уменьшает время, требуемое для приема достаточных данных, чтобы восстановить блок для завершения, и поэтому уменьшает вероятность, что блок не может быть восстановлен до запланированного времени проигрывания данных мультимедиа, содержащих блок. Как описано выше, если блок не может быть восстановлен до запланированного времени проигрывания данных мультимедиа, содержащих блок, то проигрывание может сделать паузу, приводя к плохому пользовательскому восприятию, и поэтому способ, описанный здесь, выгодно уменьшает вероятность этого плохого пользовательского восприятия.
[0563] Должно быть понятно, что по всему настоящему описанию ссылка на запланированное время проигрывания блока относится ко времени, в которое закодированные данные мультимедиа, содержащие блок, могут быть первыми доступны в клиенте, чтобы достигнуть проигрывание представления без приостановки. Как ясно специалистам в области систем представления мультимедиа, это время находится практически перед фактическим временем появления мультимедиа, содержащего блок, в физических преобразователях, используемых для проигрывания (экран, спикер и т.д.), так как может быть необходимо, применить несколько функций преобразования к данным мультимедиа, содержащим блок, чтобы вызвать фактическое проигрывание этого блока и эти функции могут потребовать некоторого времени для завершения. Например, данные мультимедиа обычно транспортируются в сжатой форме, и преобразование декомпрессии может быть применено.
СПОСОБЫ ГЕНЕРИРОВАНИЯ СТРУКТУР ФАЙЛОВ, ПОДДЕРЖИВАЮЩИХ СОВМЕСТНЫЕ СПОСОБЫ HTTP/FEC
[0564] Вариант осуществления, чтобы генерировать структуру файлов, которая может использоваться предпочтительно клиентом, использующим способы совместного HTTP/FEC, описан ниже. В этом варианте осуществления для каждого исходного сегмента имеется соответствующий исправленный сегмент, генерируемый следующим образом. Параметр R указывает в среднем, сколько FEC-исправленных данных генерируется для исходных данных в исходных сегментах. Например, R=0,33 указывает что, если исходный сегмент содержит 1000 килобайт данных, то соответствующий исправленный сегмент содержит приблизительно 330 килобайт исправленных данных. Параметр S указывает размер символа в байтах, используемых для кодирования и декодирования с FEC. Например, S=64 указывает, что исходные данные и исправленные данные содержат символы размером 64 байта каждый в целях кодирования и декодирования FEC.
[0565] Исправленный сегмент может генерироваться для исходного сегмента следующим образом. Каждый фрагмент исходного сегмента рассматривают как исходный блок для целей кодирования FEC, и таким образом каждый фрагмент рассматривают как последовательность исходных символов исходного блока, из которого генерируются исправленные символы. Количество исправленных символов, всего генерируемых для первых i фрагментов, вычисляют как TNRS (i)= ceiling(R*B (i)/S), в котором ceiling(x) является функцией, которая выдает наименьшее целое число со значением, которое является, по меньшей мере, x. Таким образом, количество исправленных символов, сгенерированных для фрагмента i равно NRS (i)=TNRS (i)-TNRS (i-1).
[0566] Исправленный сегмент содержит конкатенацию исправленных символов для фрагментов, при этом порядок исправленных символов в исправленном сегменте находится в порядке фрагментов, из которых они генерируются, и в пределах фрагмента исправленные символы находятся в порядке их идентификатора символа кодирования (ESI). Структура исправленного сегмента, соответствующая структуре исходного сегмента, показана на Фиг. 27, включая генератор 2700 исправленного сегмента.
[0567] Следует отметить, что, определяя количество исправленных символов для фрагмента, как описано выше, общее количество исправленных символов для всех предыдущих фрагментов, и таким образом индекс байта в исправленном сегменте, зависят только от R, S, B(i-1) и B (i), и не зависят ни от одной предыдущей или последующей структуры фрагментов в исходном сегменте. Это выгодно, так как это позволяет клиенту быстро вычислять позицию начала исправленного блока в пределах исправленного сегмента, и также быстро вычислять количество исправленных символов в пределах этого блока исправления, используя только локальную информацию о структуре соответствующего фрагмента исходного сегмента, из которого генерируется исправленный блок. Таким образом, если клиент решает начать загрузку и проигрывание фрагмента с середины исходного сегмента, он может также быстро сгенерировать и получить доступ к соответствующему исправленному блоку изнутри соответствующего исправленного сегмента.
[0568] Количество исходных символов в исходном блоке, соответствующих фрагменту i, вычисляют как NSS(i)=ceiling((B(i)-B(i-1))/S). Последний исходный символ заполняется нулевыми байтами в целях кодирования и декодирования с FEC, если B(i)-B(i-1) не кратно S, то есть, последний исходный символ заполняется нулевыми байтами так, чтобы это были S байтов по размеру в целях кодирования и декодирования с FEC, но эти нулевые заполняющие байты не сохранены в качестве части исходного сегмента. В этом варианте осуществления ESI для исходного символа равны 0, 1, NSS(i)-1 и ESI для исправленных символов равны NSS(i), NSS(i)+NRS(i)-1.
[0569] URL для исправленного сегмента в этом варианте осуществления может генерироваться из URL для соответствующего исходного сегмента, просто добавляя, например суффикс ".repair" к URL исходного сегмента.
[0570] Информация индексации исправления и информация FEC для исправленного сегмента неявно определена информацией индексации для соответствующего исходного сегмента, и из значений R и S, как описано здесь. Смещения во времени и структура фрагмента, содержащая исправленный сегмент, определены смещением во времени и структурой соответствующего исходного сегмента. Смещение в байтах до конца исправленных символов в исправленном сегменте, соответствующем фрагменту i, может быть вычислено как RB(i)=S*ceiling(R*B (i)/S). Количество байтов в исправленном сегменте, соответствующем фрагменту i, тогда равно RB(i)-RB(i-1), и таким образом количество исправленных символов, соответствующих фрагменту i, вычисляют как NRS(i)=RB(i)-RB(i-1))/S. Количество исходных символов, соответствующих фрагменту i, может быть вычислено как NSS (i)=ceiling((B (i)-B(i-1))/S). Таким образом, в этом варианте осуществления информация индексации исправления для исправленного блока в исправленном сегменте и соответствующая информация FEC может быть неявно получена из R, S и информации индексации для соответствующего фрагмента соответствующего исходного сегмента.
[0571] В качестве примера, рассмотрим пример, показанный на Фиг. 28, показывающий фрагмент 2, который начинается при смещении в байтах B(l)=6410, и заканчивается при смещении в байтах B(2)=6770. В этом примере размер символа равен S=64 байта, и пунктирные вертикальные линии показывают смещения в байтах в исходном сегменте, которые соответствуют множеству S. Полный размер исправленного сегмента как доли размера исходного сегмента установлен в R=0,5 в этом примере. Количество исходных символов в исходном блоке для фрагмента 2 вычисляют как NSS(2)=ceiling((6770-6410)/64)=ceiling(5,625)=6, и эти 6 исходных символов имеют ESI 0, 5, соответственно, при этом первый исходный символ составляет первые 64 байта фрагмента 2, который начинается в индексе 6410 байтов в исходном сегменте, второй исходный символ составляет следующие 64 байта фрагмента 2, который начинается в индексе 6474 байтов в исходном сегменте, и т.д. Конечное смещение в байтах исправленного блока, соответствующего фрагменту 2, вычисляется как RB(2)=64*ceiling (0,5*6770/64)=64*ceiling (52,89)=64*53=3392, и начальное смещение в байтах исправленного блока, соответствующего фрагменту 2, вычисляется как RB(1)=64*ceiling (0,5*6410/64)=64*ceiling (50,07)=64*51=3264, и таким образом в этом примере имеются два исправленных символа в исправленном блоке, соответствующем фрагменту 2 с ESI 6 и 7, соответственно, начинающиеся при смещении в байтах 3264 в исправленном сегменте, и заканчивающиеся при смещении в байтах 3392.
[0572] Следует отметить, что в примере, показанном на Фиг. 28, даже при том, что R=0,5 и есть 6 исходных символов, соответствующих фрагменту 2, количество исправленных символов не равно 3, как можно было бы ожидать, если просто использовать количество исходных символов, чтобы вычислить количество исправленных символов, но вместо этого определено, чтобы быть равным 2 согласно способам, описанным здесь. В противоположность простому использованию количества исходных символов фрагмента, чтобы определить количество исправленных символов, варианты осуществления, описанные выше, позволяют вычислить расположение блока исправления в пределах исправленного сегмента исключительно из индексной информации, ассоциированной с соответствующим исходным блоком соответствующего исходного сегмента. Кроме того, когда количество K исходных символов в исходном блоке растет, количество исправленных символов, KR, соответствующего исправленного блока близко аппроксимируется посредством K*R, поскольку обычно, KR, является самое большее ceil(K*R), и KR является, по меньшей мере, floor((K-1)*R), где floor(x) является наибольшим целым числом, которое равно самое большее x.
[0573] Есть много изменений вышеупомянутых вариантов осуществления для того, чтобы генерировать структуру файлов, которая может выгодно использоваться клиентом, использующим способы совместных HTTP/FEC, как понятно специалисту в данной области техники. В качестве примера альтернативного варианта осуществления, первоначальный сегмент для представления может быть разделен в N>1 параллельных сегментов, при этом для i=1, N, заданная доля Fi первоначального сегмента содержится в i-м параллельном сегменте, и когда сумма Fi для i=1, N равна 1. В этом варианте осуществления может быть одна главная карта сегментов, которая используется, чтобы получить карты сегментов для всех параллельных сегментов, аналогично тому, как карта исправленного сегмента получается из исходной карты сегментов в варианте осуществления, описанном выше. Например, главная карта сегментов может указывать структуру фрагмента, если все исходные данные мультимедиа не были разделены в параллельные сегменты, но вместо этого содержались в одном первоначальном сегменте, и затем карта сегментов для i-го параллельного сегмента может быть получена из главной карты сегмента, вычисляя, что, если количество данных мультимедиа в первом префиксе фрагментов первоначального сегмента равно L байтов, то общее количество байтов этого префикса в совокупности среди первого i параллельного сегмента равно ceil(L*Gi), где Gi- сумма по j=1, i для Fj. В качестве другого примера альтернативного варианта осуществления, сегменты могут состоять из комбинации первоначальных исходных данных мультимедиа для каждого фрагмента, после которого следуют немедленно исправленные данные для этого фрагмента, приводя к сегменту, который содержит смесь исходных данных мультимедиа и исправленных данных, сгенерированных с использованием кода FEC из этих исходных данных мультимедиа. В качестве другого примера альтернативного варианта осуществления, сегмент, который содержит смесь исходных данных мультимедиа и исправленных данных, может быть разделен во множественные параллельные сегменты, содержащие смесь исходных данных мультимедиа и исправленных данных.
[0574] Другие варианты осуществления могут быть очевидны для специалиста в данной области техники после прочтения этого раскрытия. В других вариантах осуществления могут быть предпочтительно сделаны комбинации или подкомбинации вышеупомянутого раскрытого изобретения. Примерные компоновки компонентов показаны в целях иллюстрации, и должно быть понятно, что комбинации, дополнения, перестановки, и т.п. рассматриваются в альтернативных вариантах осуществления настоящего изобретения. Таким образом, в то время как изобретение было описано относительно примерных вариантов осуществления, специалист в данной области техники распознает, что возможны многочисленные модификации.
[0575] Например, процессы, описанные здесь, могут быть реализованы, используя компоненты аппаратного обеспечения, компоненты программного обеспечения, и/или любую их комбинацию. В некоторых случаях, компоненты программного обеспечения могут быть обеспечены на материальном, не временном носителе для выполнения на аппаратном обеспечении, которое обеспечено этим носителем или является отдельным от носителя. Описание и чертежи должны, соответственно, быть расценены в иллюстративном, а не ограничительном смысле. Однако, должно быть, очевидно, что различные модификации и изменения могут быть сделаны к ним, не отступая от более широкого объема и области изобретения, как сформулировано в формуле изобретения, и что это изобретение предназначено, чтобы охватить все модификации и эквиваленты в рамках нижеследующей формулы изобретения.

Claims (8)

1. Способ обеспечения блоков данных мультимедиа, содержащий этапы, на которых:
получают данные мультимедиа, соответствующие представлению; сохраняют упомянутые данные мультимедиа, соответствующие упомянутому представлению, в качестве множества сегментов, при этом один или более из упомянутого множества сегментов включает в себя множество блоков;
сохраняют данные соответствий, ассоциированные с по меньшей мере одним сегментом, при этом сохраненные данные соответствий включают в себя соответствие между по меньшей мере одним указателем времени и по меньшей мере одной позицией по меньшей мере одного блока в упомянутом по меньшей мере одном сегменте;
передают сегмент и индекс сегмента клиенту, при этом индекс сегмента включает в себя данные соответствий, ассоциированные с этим сегментом, и при этом индекс сегмента позволяет клиенту задавать позицию одного или более блоков в упомянутом сегменте для включения в один или более запросов;
принимают запрос на блок от клиента, при этом запрос включает в себя заданную позицию упомянутого блока в упомянутом сегменте; и передают блок клиенту в ответ на запрос на блок.
2. Способ по п. 1, в котором сохраненные данные соответствий сохраняют в качестве части файла, который также содержит метаданные, соответствующие упомянутым данным мультимедиа.
3. Способ по п.1,в котором сохраненные данные соответствий являются картой, отформатированной как метаданные XML, при этом указатель времени является временным диапазоном по отношению к началу представления или по отношению к началу блока.
4. Способ по п.1, в котором множество блоков и сохраненных данных соответствий генерируют системой потребления мультимедиа и сохраняют на сервере общего назначения, который отвечает, по меньшей мере, на запросы файлов.
5. Способ по п.4,в котором запросами файлов являются НТТР-запросы.
6. Способ по п. 1, в котором упомянутое множество блоков имеют переменную длительность, и сохраненные данные соответствий позволяют клиентским устройствам определять временной диапазон и соответствия местоположений данных, которые могут меняться в зависимости от переменных длительностей блоков мультимедиа.
7. Способ по п.1, в котором сегмент из множества сегментов включает в себя группу картинок (GoP), и при этом группу картинок разделяют на больше чем один блок.
8. Способ определения запросов, которые нужно сделать из сервера мультимедиа, выполняемый в клиентском устройстве, которое способно представлять представление мультимедиа в течение периода времени представления, причем способ содержит этапы, на которых:
получают в клиентском устройстве список сегментов представления мультимедиа, при этом клиентское устройство сконфигурировано, чтобы передавать запрос на сегмент, при этом сегмент включает в себя множество блоков;
определяют в клиентском устройстве желательный период времени представления мультимедиа, при этом желательный период времени меньше, чем весь период времени представления;
получают в клиентском устройстве сохраненные данные соответствий, которые включают в себя соответствие между по меньшей мере одним указателем времени и по меньшей мере одной позицией блока в сегменте представления мультимедиа;
определяют в клиентском устройстве и из сохраненных данных соответствий по меньшей мере один блок в упомянутом сегменте для запроса из сервера мультимедиа;
передают запрос на упомянутый по меньшей мере один блок; и представляют представление мультимедиа.
RU2012116086/08A 2009-09-22 2010-09-22 Расширенная система потоковой передачи с запросом блоков, использующая сигнализацию или создание блоков RU2553101C2 (ru)

Applications Claiming Priority (15)

Application Number Priority Date Filing Date Title
US24476709P 2009-09-22 2009-09-22
US61/244,767 2009-09-22
US25771909P 2009-11-03 2009-11-03
US61/257,719 2009-11-03
US25808809P 2009-11-04 2009-11-04
US61/258,088 2009-11-04
US28577909P 2009-12-11 2009-12-11
US61/285,779 2009-12-11
US29672510P 2010-01-20 2010-01-20
US61/296,725 2010-01-20
US37239910P 2010-08-10 2010-08-10
US61/372,399 2010-08-10
US12/887,476 2010-09-21
US12/887,476 US9432433B2 (en) 2006-06-09 2010-09-21 Enhanced block-request streaming system using signaling or block creation
PCT/US2010/049842 WO2011038013A2 (en) 2009-09-22 2010-09-22 Enhanced block-request streaming system using signaling or block creation

Publications (2)

Publication Number Publication Date
RU2012116086A RU2012116086A (ru) 2013-10-27
RU2553101C2 true RU2553101C2 (ru) 2015-06-10

Family

ID=43382476

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2012116086/08A RU2553101C2 (ru) 2009-09-22 2010-09-22 Расширенная система потоковой передачи с запросом блоков, использующая сигнализацию или создание блоков

Country Status (17)

Country Link
US (3) US9432433B2 (ru)
EP (1) EP2481197B1 (ru)
JP (7) JP5666598B2 (ru)
KR (4) KR101395193B1 (ru)
CN (1) CN102577411B (ru)
BR (1) BR112012006374B1 (ru)
CA (4) CA2854017C (ru)
DK (1) DK2481197T3 (ru)
ES (1) ES2734257T3 (ru)
HU (1) HUE044122T2 (ru)
MY (1) MY163822A (ru)
PL (1) PL2481197T3 (ru)
PT (1) PT2481197T (ru)
RU (1) RU2553101C2 (ru)
SI (1) SI2481197T1 (ru)
WO (1) WO2011038013A2 (ru)
ZA (1) ZA201202935B (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2640628C2 (ru) * 2015-08-13 2018-01-10 Сяоми Инк. Способ и устройство для представления мультимедийной информации
RU2656689C2 (ru) * 2016-11-08 2018-06-06 Федеральное государственное казенное военное образовательное учреждение высшего образования "Краснодарское высшее военное училище имени генерала армии С.М. Штеменко" Министерство обороны Российской Федерации Способ мультипоточного шифрования информации и устройство для его осуществления

Families Citing this family (212)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
JP4546246B2 (ja) 2002-10-05 2010-09-15 デジタル ファウンテン， インコーポレイテッド 連鎖的暗号化反応の系統的記号化および復号化
CN1954501B (zh) 2003-10-06 2010-06-16 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法
EP1743431A4 (en) 2004-05-07 2007-05-02 Digital Fountain Inc SYSTEM FOR DOWNLOADING AND RECORDING AND CONTINUOUS READING OF FILES
CN101686107B (zh) 2006-02-13 2014-08-13 数字方敦股份有限公司 使用可变fec开销和保护周期的流送和缓冲
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US7971129B2 (en) 2006-05-10 2011-06-28 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US20100211690A1 (en) * 2009-02-13 2010-08-19 Digital Fountain, Inc. Block partitioning for a data stream
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US8335873B2 (en) 2006-09-14 2012-12-18 Opentv, Inc. Method and systems for data transmission
US11303684B2 (en) 2006-09-14 2022-04-12 Opentv, Inc. Methods and systems for data transmission
US9237101B2 (en) 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
US9214004B2 (en) 2008-12-18 2015-12-15 Vmware, Inc. Watermarking and scalability techniques for a virtual desktop planning tool
US8788079B2 (en) 2010-11-09 2014-07-22 Vmware, Inc. Monitoring audio fidelity and audio-video synchronization
US9674562B1 (en) 2008-12-18 2017-06-06 Vmware, Inc. Quality evaluation of multimedia delivery in cloud environments
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
WO2010117129A2 (en) 2009-04-07 2010-10-14 Lg Electronics Inc. Broadcast transmitter, broadcast receiver and 3d video data processing method thereof
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
KR101786051B1 (ko) * 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치
KR101777347B1 (ko) 2009-11-13 2017-09-11 삼성전자주식회사 부분화에 기초한 적응적인 스트리밍 방법 및 장치
KR101750049B1 (ko) 2009-11-13 2017-06-22 삼성전자주식회사 적응적인 스트리밍 방법 및 장치
KR101750048B1 (ko) * 2009-11-13 2017-07-03 삼성전자주식회사 변속 재생 서비스 제공 방법 및 장치
CA2782825C (en) 2009-12-04 2016-04-26 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
KR101737084B1 (ko) 2009-12-07 2017-05-17 삼성전자주식회사 메인 콘텐트에 다른 콘텐트를 삽입하여 스트리밍하는 방법 및 장치
EP2526671B1 (en) * 2010-01-18 2016-11-16 Telefonaktiebolaget LM Ericsson (publ) Methods and arrangements for http media stream distribution
KR101777348B1 (ko) * 2010-02-23 2017-09-11 삼성전자주식회사 데이터 전송 방법 및 장치와 데이터 수신 방법 및 장치
US8667164B2 (en) 2010-04-26 2014-03-04 Samsung Electronics Co., Ltd. Method and apparatus for playing live content
KR101652255B1 (ko) * 2010-04-26 2016-09-09 삼성전자주식회사 라이브 컨텐츠의 효과적인 재생방법
US9253548B2 (en) 2010-05-27 2016-02-02 Adobe Systems Incorporated Optimizing caches for media streaming
US9497290B2 (en) * 2010-06-14 2016-11-15 Blackberry Limited Media presentation description delta file for HTTP streaming
KR101702562B1 (ko) * 2010-06-18 2017-02-03 삼성전자 주식회사 멀티미디어 스트림 파일의 저장 파일 포맷, 저장 방법 및 이를 이용한 클라이언트 장치
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
KR20120034550A (ko) 2010-07-20 2012-04-12 한국전자통신연구원 스트리밍 컨텐츠 제공 장치 및 방법
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
CN102130936B (zh) 2010-08-17 2013-10-09 华为技术有限公司 一种在动态http流传输方案中支持时移回看的方法和装置
US9467493B2 (en) 2010-09-06 2016-10-11 Electronics And Telecommunication Research Institute Apparatus and method for providing streaming content
CN103222276B (zh) * 2010-09-20 2017-04-19 数码士有限公司 将在http流式传输中发生表达切换时实现的处理方法
US9369512B2 (en) * 2010-10-06 2016-06-14 Electronics And Telecommunications Research Institute Apparatus and method for providing streaming content
JP5640649B2 (ja) * 2010-10-27 2014-12-17 ソニー株式会社 データ通信方法及び情報処理装置
US8468262B2 (en) * 2010-11-01 2013-06-18 Research In Motion Limited Method and apparatus for updating http content descriptions
KR101613941B1 (ko) * 2010-11-02 2016-04-20 엘지전자 주식회사 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
US9336117B2 (en) 2010-11-09 2016-05-10 Vmware, Inc. Remote display performance measurement triggered by application display upgrade
EP2638682A4 (en) * 2010-11-12 2014-07-23 Realnetworks Inc TRAFFIC MANAGEMENT IN ADAPTIVE STREAMING PROTOCOLS
US9247312B2 (en) 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US9661104B2 (en) * 2011-02-07 2017-05-23 Blackberry Limited Method and apparatus for receiving presentation metadata
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US11025962B2 (en) 2011-02-28 2021-06-01 Adobe Inc. System and method for low-latency content streaming
WO2012125006A2 (ko) * 2011-03-16 2012-09-20 한국전자통신연구원 레프리젠테이션을 사용하는 스트리밍 콘텐츠 제공 장치 및 방법
KR101803970B1 (ko) * 2011-03-16 2017-12-28 삼성전자주식회사 컨텐트를 구성하는 장치 및 방법
US8510555B2 (en) * 2011-04-27 2013-08-13 Morega Systems Inc Streaming video server with virtual file system and methods for use therewith
US8813116B2 (en) * 2011-04-27 2014-08-19 Morega Systems Inc. Adaptive video server with virtual file system and methods for use therewith
WO2011144117A2 (zh) * 2011-05-27 2011-11-24 华为技术有限公司 媒体发送方法、媒体接收方法和客户端及系统
KR20120138604A (ko) * 2011-06-14 2012-12-26 삼성전자주식회사 멀티미디어 시스템에서 복합 미디어 컨텐츠를 송수신하는 방법 및 장치
US8745122B2 (en) * 2011-06-14 2014-06-03 At&T Intellectual Property I, L.P. System and method for providing an adjunct device in a content delivery network
CN102843335B (zh) * 2011-06-20 2015-09-09 华为技术有限公司 流媒体内容的处理方法和设备
KR101222432B1 (ko) * 2011-07-06 2013-01-15 주식회사에어플러그 고정 호스트 주소에 기반하여 복수의 이종망(異種網)들을 선택적으로 사용하여 데이터 송수신할 수 있게 하는 장치와 이를 위한 방법
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
JP2013021574A (ja) * 2011-07-12 2013-01-31 Sharp Corp 生成装置、配信サーバ、生成方法、再生装置、再生方法、再生システム、生成プログラム、再生プログラム、記録媒体およびデータ構造
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
JP2014531142A (ja) 2011-08-16 2014-11-20 デスティニーソフトウェアプロダクションズ インク スクリプトをベースとするビデオ・レンダリング
US8977778B2 (en) * 2011-08-29 2015-03-10 Latakoo, Inc. Compressing, transcoding, sending, and retrieving video and audio files in a server-based system and related systems and methods
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US8806188B2 (en) * 2011-08-31 2014-08-12 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming using automatically generated top level index files
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8676952B2 (en) * 2011-09-13 2014-03-18 Ericsson Television Inc. User adaptive HTTP stream manager and method for using same
US9445136B2 (en) * 2011-09-21 2016-09-13 Qualcomm Incorporated Signaling characteristics of segments for network streaming of media data
EP2759115A4 (en) * 2011-09-23 2015-05-20 Ericsson Telefon Ab L M USE OF MEMORY IN A TELECOMMUNICATIONS NETWORK
KR101678540B1 (ko) * 2011-09-30 2016-11-22 후아웨이 테크놀러지 컴퍼니 리미티드 스트리밍 미디어 전송 방법 및 장치
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
AU2011232766B2 (en) * 2011-10-07 2014-03-20 Accenture Global Services Limited Synchronising digital media content
KR20130040132A (ko) * 2011-10-13 2013-04-23 한국전자통신연구원 이종 ip 네트워크를 통한 미디어 코덱에 독립적인 미디어 데이터 전송 방법
GB2499539B (en) * 2011-10-27 2017-05-03 Lg Electronics Inc Method for transreceiving media content and device for transreceiving using same
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
EP2786262A4 (en) * 2011-12-01 2014-12-03 Huawei Tech Co Ltd SYSTEMS AND METHODS FOR CONNECTING CONNECTIONS FOR TRANSMITTING VIDEO STREAMS ON CONTENT PROVIDING NETWORKS
KR101719998B1 (ko) * 2011-12-12 2017-03-27 엘지전자 주식회사 미디어 컨텐트를 수신하는 장치 및 방법
WO2013090280A2 (en) * 2011-12-15 2013-06-20 Dolby Laboratories Licensing Corporation Bandwidth adaptation for dynamic adaptive transferring of multimedia
US20130159382A1 (en) * 2011-12-15 2013-06-20 Microsoft Corporation Generically presenting virtualized data
US9319321B2 (en) 2011-12-16 2016-04-19 Netflix, Inc. Web server constraint support
US10218756B2 (en) 2012-01-06 2019-02-26 Comcast Cable Communications, Llc Streamlined delivery of video content
US9930379B2 (en) 2012-01-31 2018-03-27 Comcast Cable Communications, Llc System and method for data stream fragmentation
US9503490B2 (en) * 2012-02-27 2016-11-22 Qualcomm Incorporated Dash client and receiver with buffer water-level decision-making
US20140082661A1 (en) * 2012-03-06 2014-03-20 Google Inc. Low latency video storyboard delivery with selectable resolution levels
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US20150172889A1 (en) * 2012-06-04 2015-06-18 The University Of Tokyo Wireless network apparatus
US9571827B2 (en) * 2012-06-08 2017-02-14 Apple Inc. Techniques for adaptive video streaming
CN103516731B (zh) * 2012-06-15 2017-04-19 华为技术有限公司 一种缓存服务器的服务方法、缓存服务器及系统
US10616297B2 (en) * 2012-07-09 2020-04-07 Futurewei Technologies, Inc. Content-specific identification and timing behavior in dynamic adaptive streaming over hypertext transfer protocol
WO2014015110A1 (en) 2012-07-18 2014-01-23 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear tv experience using streaming content distribution
US9804668B2 (en) 2012-07-18 2017-10-31 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear TV experience using streaming content distribution
US9628542B2 (en) * 2012-08-24 2017-04-18 Akamai Technologies, Inc. Hybrid HTTP and UDP content delivery
TWI516104B (zh) 2012-09-04 2016-01-01 緯創資通股份有限公司 網路影片播放的方法及其電子裝置
US20140074961A1 (en) * 2012-09-12 2014-03-13 Futurewei Technologies, Inc. Efficiently Delivering Time-Shifted Media Content via Content Delivery Networks (CDNs)
CN103702237A (zh) * 2012-09-28 2014-04-02 北京大学 Http流媒体的速率自适方法及装置
US8639781B1 (en) * 2012-10-19 2014-01-28 Dropbox, Inc. Systems and methods for downloading files
KR20150082320A (ko) * 2012-10-19 2015-07-15 인터디지탈 패튼 홀딩스, 인크 Ｈｔｔｐ 스트리밍을 위한 멀티-가설 레이트 적응
US9866886B2 (en) * 2012-10-23 2018-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for distributing a media content service
WO2014067070A1 (zh) * 2012-10-30 2014-05-08 华为技术有限公司 数据传输方法、切换方法、数据传输装置、切换装置、用户设备、无线接入节点、数据传输系统、切换系统
US9015470B2 (en) * 2012-11-08 2015-04-21 Morega Systems, Inc Adaptive video server with fast initialization and methods for use therewith
WO2014083739A1 (ja) * 2012-11-28 2014-06-05 パナソニック株式会社 受信端末および受信方法
US8918821B2 (en) * 2012-12-11 2014-12-23 Morega Systems, Inc. Client device with video playlist translation via client-side proxy and methods for use therewith
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
WO2014112416A1 (ja) * 2013-01-15 2014-07-24 シャープ株式会社 映像供給装置、映像取得装置、およびプログラム
EP2932397B1 (en) * 2013-01-18 2017-08-09 Huawei Technologies Co., Ltd. Method and apparatus for performing adaptive streaming on media contents
US9432426B2 (en) * 2013-02-04 2016-08-30 Qualcomm Incorporated Determining available media data for network streaming
KR101716071B1 (ko) 2013-02-27 2017-03-13 애플 인크. 적응적 스트리밍 기법
US9734194B1 (en) * 2013-03-14 2017-08-15 Google Inc. Encoding time interval information
US8826346B1 (en) * 2013-03-15 2014-09-02 General Instrument Corporation Methods of implementing trickplay
EP3448032B1 (en) * 2013-03-25 2022-10-19 Imax Corporation Enhancing motion pictures with accurate motion information
US20140297882A1 (en) * 2013-04-01 2014-10-02 Microsoft Corporation Dynamic track switching in media streaming
US9603039B2 (en) 2013-04-03 2017-03-21 Qualcomm Incorporated Opportunistic media patching for a communication session
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
US10284612B2 (en) * 2013-04-19 2019-05-07 Futurewei Technologies, Inc. Media quality information signaling in dynamic adaptive video streaming over hypertext transfer protocol
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
WO2014201177A1 (en) * 2013-06-11 2014-12-18 Seven Networks, Inc. Offloading application traffic to a shared communication channel for signal optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
DE102013211571B4 (de) * 2013-06-19 2016-02-11 Opticom Dipl.-Ing. Michael Keyhl Gmbh Konzept zur bestimmung der qualität eines mediadatenstroms mit variierender qualität-zu-bitrate
EP2819379A1 (en) * 2013-06-28 2014-12-31 Thomson Licensing Method for adapting the downloading behavior of a client terminal configured to receive multimedia content, and corresponding terminal
EP3020208B1 (en) * 2013-07-12 2022-03-09 Canon Kabushiki Kaisha Adaptive data streaming with push messages control
CN105359536B (zh) * 2013-07-17 2020-07-24 索尼公司 内容供给装置及方法、终端装置、以及内容供给系统
US9955203B2 (en) * 2013-09-24 2018-04-24 Ericsson Ab Recording device and method for efficient network personal video recorder manipulation through adaptive bit rate streaming
US9270721B2 (en) * 2013-10-08 2016-02-23 Qualcomm Incorporated Switching between adaptation sets during media streaming
WO2015068518A1 (ja) * 2013-11-05 2015-05-14 株式会社リコー 通信装置、通信システム、通信方法および通信プログラム
CN105683917B (zh) * 2013-11-05 2019-05-21 株式会社理光 通信装置、通信系统、通信方法和通信程序
JP2015103105A (ja) 2013-11-26 2015-06-04 株式会社リコー 通信装置、通信システム、及び通信プログラム
EP3092772B1 (en) 2014-01-07 2019-07-31 Nokia Technologies Oy Media encapsulating and decapsulating
US10397664B2 (en) * 2014-01-10 2019-08-27 Sony Corporation Method for operating a mobile device
US20150201253A1 (en) * 2014-01-10 2015-07-16 Samsung Electronics Co., Ltd. Methods and apparatus for universal presentation timeline alignment
JP2015136059A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP2015136060A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
US9900362B2 (en) 2014-02-11 2018-02-20 Kiswe Mobile Inc. Methods and apparatus for reducing latency shift in switching between distinct content streams
US9342229B2 (en) 2014-03-28 2016-05-17 Acast AB Method for associating media files with additional content
WO2015152569A1 (ko) * 2014-04-01 2015-10-08 (주)유비쿼스 Ｇ．ｈｎ 기술이 적용된 액세스 네트워크의 동기화 통신 방법과 이를 이용하는 액세스 네트워크 집선장비, 액세스 네트워크 단말, 및 액세스 네트워크 시스템
EP3128709B1 (en) 2014-04-01 2021-09-08 Ubiquoss Inc. Method for controlling line in access network having g.hn technology applied thereto, and access network line concentration instrument, access network terminal and access network system using same
US9448789B2 (en) * 2014-04-04 2016-09-20 Avid Technology, Inc. Method of consolidating, synchronizing, and streaming production content for distributed editing of media compositions
CN103957471B (zh) * 2014-05-05 2017-07-14 华为技术有限公司 网络视频播放的方法和装置
KR101538114B1 (ko) * 2014-05-23 2015-07-23 가천대학교 산학협력단 모바일 스마트 기기 내에서 다중 코덱 기반으로 끊김 없이 동영상을 재생할 수 있도록 하는 동영상 처리 장치 및 방법
US20150350369A1 (en) * 2014-05-30 2015-12-03 Qualcomm Incorporated Method For Reducing Pre-Fetching Of Multimedia Streaming Data With Minimal Impact On Playback User Experience
US10306021B1 (en) * 2014-08-21 2019-05-28 Amazon Technologies, Inc. Streaming content to multiple clients
CA2962040C (en) * 2014-09-22 2020-07-21 Arris Enterprises Llc Video quality of experience based on video quality estimation
WO2016048200A1 (en) * 2014-09-23 2016-03-31 Telefonaktiebolaget L M Ericsson (Publ) Video tune-in
US10484725B2 (en) * 2014-09-26 2019-11-19 Sony Corporation Information processing apparatus and information processing method for reproducing media based on edit file
JP2016072858A (ja) * 2014-09-30 2016-05-09 エヌ・ティ・ティ・コミュニケーションズ株式会社 メディアデータ生成方法、メディアデータ再生方法、メディアデータ生成装置、メディアデータ再生装置、コンピュータ読み取り可能な記録媒体、及びプログラム
CN104469392B (zh) * 2014-12-19 2018-04-20 北京奇艺世纪科技有限公司 一种视频文件存储方法及装置
US9860294B2 (en) * 2014-12-24 2018-01-02 Intel Corporation Media content streaming
CN113259731B (zh) 2015-01-06 2023-07-04 帝威视有限公司 用于编码内容和在设备之间共享内容的系统和方法
US20160308927A1 (en) * 2015-04-20 2016-10-20 Qualcomm Incorporated Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
US10929353B2 (en) 2015-04-29 2021-02-23 Box, Inc. File tree streaming in a virtual file system for cloud-based shared content
US9615258B2 (en) 2015-05-21 2017-04-04 Nokia Solutions And Networks Oy Method and apparatus for securing timing packets over untrusted packet transport network
GB2537459B (en) * 2015-06-03 2017-06-21 Bridgeworks Ltd Transmitting data
GB2538997A (en) 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
CN106294193B (zh) * 2015-06-03 2019-10-15 杭州海康威视系统技术有限公司 存储设备及基于该存储设备的分块存储方法
GB2539461B (en) * 2015-06-16 2020-01-08 Canon Kk Image data encapsulation
WO2017004196A1 (en) * 2015-06-29 2017-01-05 Vid Scale, Inc. Dash caching proxy application
US10021187B2 (en) * 2015-06-29 2018-07-10 Microsoft Technology Licensing, Llc Presenting content using decoupled presentation resources
JP6258897B2 (ja) * 2015-07-01 2018-01-10 シャープ株式会社 コンテンツ取得装置、コンテンツ取得方法、メタデータ配信装置、メタデータ配信方法
US10693936B2 (en) * 2015-08-25 2020-06-23 Qualcomm Incorporated Transporting coded audio data
JP6551107B2 (ja) * 2015-09-24 2019-07-31 ブラザー工業株式会社 サーバ装置、サーバプログラム、端末プログラム、動画送信方法、動画表示方法、通信システム
JP6099715B2 (ja) * 2015-09-30 2017-03-22 エヌ・ティ・ティ・コミュニケーションズ株式会社 ストリーミングメディア再生装置、ストリーミングメディア再生方法、及びプログラム
JP2016040919A (ja) * 2015-10-09 2016-03-24 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
US9942582B2 (en) * 2015-12-01 2018-04-10 Hulu, LLC Dynamic seeking in video delivery systems
US9930427B2 (en) * 2015-12-21 2018-03-27 Comcast Cable Communications Management, Llc Providing advanced playback and control functionality to video client
US10261964B2 (en) * 2016-01-04 2019-04-16 Gracenote, Inc. Generating and distributing playlists with music and stories having related moods
US10129358B2 (en) * 2016-01-15 2018-11-13 Verizon Digital Media Services Inc. Partitioned serialized caching and delivery of large files
US10631069B2 (en) 2016-02-16 2020-04-21 Nokia Technologies Oy Media encapsulating and decapsulating
US10567461B2 (en) * 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
US10187178B2 (en) * 2016-10-11 2019-01-22 Microsoft Technology Licensing, Llc Dynamically partitioning media streams
US10785116B1 (en) * 2017-01-12 2020-09-22 Electronic Arts Inc. Computer architecture for asset management and delivery
CN108668179B (zh) * 2017-03-27 2021-05-14 华为技术有限公司 媒体索引文件的传输方法及相关设备
EP3410728A1 (en) 2017-05-30 2018-12-05 Vestel Elektronik Sanayi ve Ticaret A.S. Methods and apparatus for streaming data
US10284888B2 (en) * 2017-06-03 2019-05-07 Apple Inc. Multiple live HLS streams
JP7027706B2 (ja) * 2017-06-15 2022-03-02 ソニーグループ株式会社 送信装置、受信装置、送信方法、受信方法及び記録媒体
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
US11470131B2 (en) 2017-07-07 2022-10-11 Box, Inc. User device processing of information from a network-accessible collaboration system
CN109525624B (zh) * 2017-09-20 2022-01-04 腾讯科技（深圳）有限公司 一种容器登录方法、装置及存储介质
US11025691B1 (en) * 2017-11-22 2021-06-01 Amazon Technologies, Inc. Consuming fragments of time-associated data streams
US10878028B1 (en) 2017-11-22 2020-12-29 Amazon Technologies, Inc. Replicating and indexing fragments of time-associated data streams
US10944804B1 (en) 2017-11-22 2021-03-09 Amazon Technologies, Inc. Fragmentation of time-associated data streams
WO2019195848A1 (en) * 2018-04-06 2019-10-10 Deluxe One Llc Dynamic watermarking of digital media content at point of transmission
US10904642B2 (en) * 2018-06-21 2021-01-26 Mediatek Singapore Pte. Ltd. Methods and apparatus for updating media presentation data
US10715882B2 (en) * 2018-06-29 2020-07-14 Intel Corporation Timing synchronization between a content source and a display panel
CN110971339B (zh) 2018-09-28 2021-04-27 维沃移动通信有限公司 一种信息传输方法及终端
CN109861790B (zh) * 2019-01-16 2022-04-19 顺丰科技有限公司 数据传输方法和装置
CN111510770B (zh) * 2019-01-30 2021-08-24 上海哔哩哔哩科技有限公司 切换清晰度的方法、装置、计算机设备及可读存储介质
US20200296316A1 (en) 2019-03-11 2020-09-17 Quibi Holdings, LLC Media content presentation
US20200296462A1 (en) 2019-03-11 2020-09-17 Wci One, Llc Media content presentation
US11223667B2 (en) 2019-04-30 2022-01-11 Phantom Auto Inc. Low latency wireless communication system for teleoperated vehicle environments
US11323730B2 (en) 2019-09-05 2022-05-03 Apple Inc. Temporally-overlapped video encoding, video decoding and video rendering techniques therefor
US11734131B2 (en) * 2020-04-09 2023-08-22 Micron Technology, Inc. Memory device having redundant media management capabilities
US11663119B2 (en) 2020-05-29 2023-05-30 International Business Machines Corporation Select decompression headers and symbol start indicators used in writing decompressed data
US11588876B2 (en) * 2020-06-16 2023-02-21 T-Mobile Usa, Inc. Device-side playback restrictions on high throughput networks
US11973817B2 (en) * 2020-06-23 2024-04-30 Tencent America LLC Bandwidth cap signaling using combo-index segment track in media streaming
CN112565337B (zh) * 2020-11-06 2022-09-30 北京奇艺世纪科技有限公司 请求传输方法、服务端、客户端、系统及电子设备
CN112711215B (zh) * 2021-02-04 2022-01-25 杭州并坚科技有限公司 总线终端控制器、总线通信供电系统及其通信供电方法
CN112911650A (zh) * 2021-03-28 2021-06-04 高小翎 移动高清视频智能双向探测带宽控制系统
GB2620583A (en) * 2022-07-11 2024-01-17 Canon Kk Method, device, and computer program for optimizing dynamic encapsulation and parsing of content data
US11799700B1 (en) * 2022-08-31 2023-10-24 Qualcomm Incorporated Decoding multi-level coded (MLC) systems
CN117806709B (zh) * 2024-02-29 2024-06-07 山东云海国创云计算装备产业创新中心有限公司 系统级芯片的性能优化方法、装置、设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6332163B1 (en) * 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
RU2290768C1 (ru) * 2006-01-30 2006-12-27 Общество с ограниченной ответственностью "Трафиклэнд" Система медиавещания в инфраструктуре оператора мобильной связи
RU2297663C2 (ru) * 2001-11-29 2007-04-20 Нокиа Корпорейшн Система и способ идентификации и доступа к услугам сети

Family Cites Families (659)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3909721A (en) 1972-01-31 1975-09-30 Signatron Signal processing system
JPS5231218B2 (ru) 1973-08-14 1977-08-13
US4365338A (en) 1980-06-27 1982-12-21 Harris Corporation Technique for high rate digital transmission over a dynamic dispersive channel
US4965825A (en) 1981-11-03 1990-10-23 The Personalized Mass Media Corporation Signal processing apparatus and methods
US4589112A (en) 1984-01-26 1986-05-13 International Business Machines Corporation System for multiple error detection with single and double bit error correction
US4901319A (en) * 1988-03-18 1990-02-13 General Electric Company Transmission system with adaptive interleaving
GB8815978D0 (en) 1988-07-05 1988-08-10 British Telecomm Method & apparatus for encoding decoding & transmitting data in compressed form
US5136592A (en) 1989-06-28 1992-08-04 Digital Equipment Corporation Error detection and correction system for long burst errors
US5701582A (en) 1989-08-23 1997-12-23 Delta Beta Pty. Ltd. Method and apparatus for efficient transmissions of programs
US7594250B2 (en) 1992-04-02 2009-09-22 Debey Henry C Method and system of program transmission optimization using a redundant transmission sequence
US5421031A (en) 1989-08-23 1995-05-30 Delta Beta Pty. Ltd. Program transmission optimisation
US5329369A (en) 1990-06-01 1994-07-12 Thomson Consumer Electronics, Inc. Asymmetric picture compression
US5455823A (en) 1990-11-06 1995-10-03 Radio Satellite Corporation Integrated communications terminal
US5164963A (en) 1990-11-07 1992-11-17 At&T Bell Laboratories Coding for digital transmission
US5465318A (en) 1991-03-28 1995-11-07 Kurzweil Applied Intelligence, Inc. Method for generating a speech recognition model for a non-vocabulary utterance
US5379297A (en) * 1992-04-09 1995-01-03 Network Equipment Technologies, Inc. Concurrent multi-channel segmentation and reassembly processors for asynchronous transfer mode
EP0543070A1 (en) 1991-11-21 1993-05-26 International Business Machines Corporation Coding system and method using quaternary codes
US6850252B1 (en) 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
US5371532A (en) 1992-05-15 1994-12-06 Bell Communications Research, Inc. Communications architecture and method for distributing information services
US5425050A (en) 1992-10-23 1995-06-13 Massachusetts Institute Of Technology Television transmission system using spread spectrum and orthogonal frequency-division multiplex
US5372532A (en) 1993-01-26 1994-12-13 Robertson, Jr.; George W. Swivel head cap connector
EP0613249A1 (en) 1993-02-12 1994-08-31 Altera Corporation Custom look-up table with reduced number of architecture bits
DE4316297C1 (de) 1993-05-14 1994-04-07 Fraunhofer Ges Forschung Frequenzanalyseverfahren
AU665716B2 (en) 1993-07-05 1996-01-11 Mitsubishi Denki Kabushiki Kaisha A transmitter for encoding error correction codes and a receiver for decoding error correction codes on a transmission frame
US5590405A (en) 1993-10-29 1996-12-31 Lucent Technologies Inc. Communication technique employing variable information transmission
JP2576776B2 (ja) * 1993-11-10 1997-01-29 日本電気株式会社 パケット伝送方法・パケット伝送装置
US5517508A (en) 1994-01-26 1996-05-14 Sony Corporation Method and apparatus for detection and error correction of packetized digital data
CA2140850C (en) 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US5566208A (en) 1994-03-17 1996-10-15 Philips Electronics North America Corp. Encoder buffer having an effective size which varies automatically with the channel bit-rate
US5432787A (en) 1994-03-24 1995-07-11 Loral Aerospace Corporation Packet data transmission system with adaptive data recovery method
US5757415A (en) 1994-05-26 1998-05-26 Sony Corporation On-demand data transmission by dividing input data into blocks and each block into sub-blocks such that the sub-blocks are re-arranged for storage to data storage means
US5802394A (en) 1994-06-06 1998-09-01 Starlight Networks, Inc. Method for accessing one or more streams in a video storage system using multiple queues and maintaining continuity thereof
US5739864A (en) 1994-08-24 1998-04-14 Macrovision Corporation Apparatus for inserting blanked formatted fingerprint data (source ID, time/date) in to a video signal
US5568614A (en) 1994-07-29 1996-10-22 International Business Machines Corporation Data streaming between peer subsystems of a computer system
US5668948A (en) 1994-09-08 1997-09-16 International Business Machines Corporation Media streamer with control node enabling same isochronous streams to appear simultaneously at output ports or different streams to appear simultaneously at output ports
US5926205A (en) 1994-10-19 1999-07-20 Imedia Corporation Method and apparatus for encoding and formatting data representing a video program to provide multiple overlapping presentations of the video program
US5659614A (en) 1994-11-28 1997-08-19 Bailey, Iii; John E. Method and system for creating and storing a backup copy of file data stored on a computer
US5617541A (en) * 1994-12-21 1997-04-01 International Computer Science Institute System for packetizing data encoded corresponding to priority levels where reconstructed data corresponds to fractionalized priority level and received fractionalized packets
JP3614907B2 (ja) 1994-12-28 2005-01-26 株式会社東芝 データ再送制御方法及びデータ再送制御システム
JP3651699B2 (ja) 1995-04-09 2005-05-25 ソニー株式会社 復号化装置及び符号化復号化装置
US6079042A (en) 1995-04-27 2000-06-20 The Trustees Of The Stevens Institute Of Technology High integrity transport for time critical multimedia networking applications
US5835165A (en) 1995-06-07 1998-11-10 Lsi Logic Corporation Reduction of false locking code words in concatenated decoders
US5805825A (en) 1995-07-26 1998-09-08 Intel Corporation Method for semi-reliable, unidirectional broadcast information services
JP3167638B2 (ja) 1995-08-04 2001-05-21 三洋電機株式会社 ディジタル変調方法と復調方法及びディジタル変調回路と復調回路
US6079041A (en) 1995-08-04 2000-06-20 Sanyo Electric Co., Ltd. Digital modulation circuit and digital demodulation circuit
US5754563A (en) 1995-09-11 1998-05-19 Ecc Technologies, Inc. Byte-parallel system for implementing reed-solomon error-correcting codes
KR0170298B1 (ko) 1995-10-10 1999-04-15 김광호 디지탈 비디오 테이프의 기록 방법
US5751336A (en) 1995-10-12 1998-05-12 International Business Machines Corporation Permutation based pyramid block transmission scheme for broadcasting in video-on-demand storage systems
US6085221A (en) 1996-01-08 2000-07-04 International Business Machines Corporation File server for multimedia file distribution
JP3305183B2 (ja) 1996-01-12 2002-07-22 株式会社東芝 ディジタル放送受信端末装置
US6012159A (en) * 1996-01-17 2000-01-04 Kencast, Inc. Method and system for error-free data transfer
US5852565A (en) 1996-01-30 1998-12-22 Demografx Temporal and resolution layering in advanced television
US5936659A (en) 1996-01-31 1999-08-10 Telcordia Technologies, Inc. Method for video delivery using pyramid broadcasting
US5903775A (en) 1996-06-06 1999-05-11 International Business Machines Corporation Method for the sequential transmission of compressed video information at varying data rates
US5745504A (en) 1996-06-25 1998-04-28 Telefonaktiebolaget Lm Ericsson Bit error resilient variable length code
US5940863A (en) 1996-07-26 1999-08-17 Zenith Electronics Corporation Apparatus for de-rotating and de-interleaving data including plural memory devices and plural modulo memory address generators
US5936949A (en) 1996-09-05 1999-08-10 Netro Corporation Wireless ATM metropolitan area network
KR100261706B1 (ko) 1996-12-17 2000-07-15 가나이 쓰도무 디지탈방송신호의 수신장치와 수신 및 기록재생장치
US6141053A (en) 1997-01-03 2000-10-31 Saukkonen; Jukka I. Method of optimizing bandwidth for transmitting compressed video data streams
US6044485A (en) * 1997-01-03 2000-03-28 Ericsson Inc. Transmitter method and transmission system using adaptive coding based on channel characteristics
US6011590A (en) * 1997-01-03 2000-01-04 Ncr Corporation Method of transmitting compressed information to minimize buffer space
US5983383A (en) 1997-01-17 1999-11-09 Qualcom Incorporated Method and apparatus for transmitting and receiving concatenated code data
US5946357A (en) 1997-01-17 1999-08-31 Telefonaktiebolaget L M Ericsson Apparatus, and associated method, for transmitting and receiving a multi-stage, encoded and interleaved digital communication signal
EP0854650A3 (en) 1997-01-17 2001-05-02 NOKIA TECHNOLOGY GmbH Method for addressing a service in digital video broadcasting
US6014706A (en) * 1997-01-30 2000-01-11 Microsoft Corporation Methods and apparatus for implementing control functions in a streamed video display system
WO1998039927A1 (en) 1997-03-07 1998-09-11 Sanyo Electric Co., Ltd. Digital broadcast receiver and display
US6115420A (en) 1997-03-14 2000-09-05 Microsoft Corporation Digital video signal encoder and encoding method
DE19716011A1 (de) 1997-04-17 1998-10-22 Abb Research Ltd Verfahren und Vorrichtung zur Informationsübertragung über Stromversorgungsleitungen
US6226259B1 (en) 1997-04-29 2001-05-01 Canon Kabushiki Kaisha Device and method for transmitting information device and method for processing information
US5970098A (en) 1997-05-02 1999-10-19 Globespan Technologies, Inc. Multilevel encoder
US5844636A (en) 1997-05-13 1998-12-01 Hughes Electronics Corporation Method and apparatus for receiving and recording digital packet data
WO1998053454A1 (fr) 1997-05-19 1998-11-26 Sanyo Electric Co., Ltd. Modulation et demodulation numeriques
JPH1141211A (ja) 1997-05-19 1999-02-12 Sanyo Electric Co Ltd ディジタル変調回路と変調方法、ディジタル復調回路と復調方法
JP4110593B2 (ja) 1997-05-19 2008-07-02 ソニー株式会社 信号記録方法及び信号記録装置
US6128649A (en) 1997-06-02 2000-10-03 Nortel Networks Limited Dynamic selection of media streams for display
US6081907A (en) 1997-06-09 2000-06-27 Microsoft Corporation Data delivery system and method for delivering data and redundant information over a unidirectional network
US5917852A (en) 1997-06-11 1999-06-29 L-3 Communications Corporation Data scrambling system and method and communications system incorporating same
KR100240869B1 (ko) 1997-06-25 2000-01-15 윤종용 이중 다이버서티 시스템을 위한 데이터 전송 방법
US5933056A (en) 1997-07-15 1999-08-03 Exar Corporation Single pole current mode common-mode feedback circuit
US6175944B1 (en) * 1997-07-15 2001-01-16 Lucent Technologies Inc. Methods and apparatus for packetizing data for transmission through an erasure broadcast channel
US6047069A (en) 1997-07-17 2000-04-04 Hewlett-Packard Company Method and apparatus for preserving error correction capabilities during data encryption/decryption
US6904110B2 (en) 1997-07-31 2005-06-07 Francois Trans Channel equalization system and method
US6178536B1 (en) * 1997-08-14 2001-01-23 International Business Machines Corporation Coding scheme for file backup and systems based thereon
FR2767940A1 (fr) 1997-08-29 1999-02-26 Canon Kk Procedes et dispositifs de codage et de decodage et appareils les mettant en oeuvre
EP0903955A1 (en) 1997-09-04 1999-03-24 STMicroelectronics S.r.l. Modular architecture PET decoder for ATM networks
US6088330A (en) 1997-09-09 2000-07-11 Bruck; Joshua Reliable array of distributed computing nodes
US6134596A (en) 1997-09-18 2000-10-17 Microsoft Corporation Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates
US6272658B1 (en) 1997-10-27 2001-08-07 Kencast, Inc. Method and system for reliable broadcasting of data files and streams
US6195777B1 (en) * 1997-11-06 2001-02-27 Compaq Computer Corporation Loss resilient code with double heavy tailed series of redundant layers
US6081918A (en) 1997-11-06 2000-06-27 Spielman; Daniel A. Loss resilient code with cascading series of redundant layers
US6163870A (en) 1997-11-06 2000-12-19 Compaq Computer Corporation Message encoding with irregular graphing
US6081909A (en) 1997-11-06 2000-06-27 Digital Equipment Corporation Irregularly graphed encoding technique
US6073250A (en) 1997-11-06 2000-06-06 Luby; Michael G. Loss resilient decoding technique
JP3472115B2 (ja) 1997-11-25 2003-12-02 Ｋｄｄｉ株式会社 マルチチャンネルを用いるビデオデータ伝送方法及びその装置
US6243846B1 (en) 1997-12-12 2001-06-05 3Com Corporation Forward error correction system for packet based data and real time media, using cross-wise parity calculation
US5870412A (en) * 1997-12-12 1999-02-09 3Com Corporation Forward error correction system for packet based real time media
US6849803B1 (en) * 1998-01-15 2005-02-01 Arlington Industries, Inc. Electrical connector
US6097320A (en) 1998-01-20 2000-08-01 Silicon Systems, Inc. Encoder/decoder system with suppressed error propagation
US6751623B1 (en) 1998-01-26 2004-06-15 At&T Corp. Flexible interchange of coded multimedia facilitating access and streaming
US6226301B1 (en) 1998-02-19 2001-05-01 Nokia Mobile Phones Ltd Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system
US6141788A (en) 1998-03-13 2000-10-31 Lucent Technologies Inc. Method and apparatus for forward error correction in packet networks
US6278716B1 (en) 1998-03-23 2001-08-21 University Of Massachusetts Multicast with proactive forward error correction
IL123819A (en) 1998-03-24 2001-09-13 Geo Interactive Media Group Lt Network media streaming
WO1999052282A1 (en) 1998-04-02 1999-10-14 Sarnoff Corporation Bursty data transmission of compressed video data
US6185265B1 (en) * 1998-04-07 2001-02-06 Worldspace Management Corp. System for time division multiplexing broadcast channels with R-1/2 or R-3/4 convolutional coding for satellite transmission via on-board baseband processing payload or transparent payload
US6067646A (en) * 1998-04-17 2000-05-23 Ameritech Corporation Method and system for adaptive interleaving
US6018359A (en) * 1998-04-24 2000-01-25 Massachusetts Institute Of Technology System and method for multicast video-on-demand delivery system
US6445717B1 (en) 1998-05-01 2002-09-03 Niwot Networks, Inc. System for recovering lost information in a data stream
US6421387B1 (en) 1998-05-15 2002-07-16 North Carolina State University Methods and systems for forward error correction based loss recovery for interactive video transmission
US6937618B1 (en) 1998-05-20 2005-08-30 Sony Corporation Separating device and method and signal receiving device and method
US6333926B1 (en) 1998-08-11 2001-12-25 Nortel Networks Limited Multiple user CDMA basestation modem
BR9913277A (pt) 1998-09-04 2001-09-25 At & T Corp Codificação de bloco-espaço e codificação de canal combinado em um arranjo de multi-antenas
US6415326B1 (en) 1998-09-15 2002-07-02 Microsoft Corporation Timeline correlation between multiple timeline-altered media streams
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6320520B1 (en) 1998-09-23 2001-11-20 Digital Fountain Information additive group code generator and decoder for communications systems
US7243285B2 (en) 1998-09-23 2007-07-10 Digital Fountain, Inc. Systems and methods for broadcasting information additive codes
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US6704370B1 (en) * 1998-10-09 2004-03-09 Nortel Networks Limited Interleaving methodology and apparatus for CDMA
IT1303735B1 (it) 1998-11-11 2001-02-23 Falorni Italia Farmaceutici S Acidi ialuronici reticolati e loro usi medici.
US6408128B1 (en) 1998-11-12 2002-06-18 Max Abecassis Replaying with supplementary information a segment of a video
US6483736B2 (en) 1998-11-16 2002-11-19 Matrix Semiconductor, Inc. Vertically stacked field programmable nonvolatile memory and method of fabrication
JP2000151426A (ja) 1998-11-17 2000-05-30 Toshiba Corp インターリーブ・デインターリーブ回路
US6166544A (en) 1998-11-25 2000-12-26 General Electric Company MR imaging system with interactive image contrast control
US6876623B1 (en) * 1998-12-02 2005-04-05 Agere Systems Inc. Tuning scheme for code division multiplex broadcasting system
AU1966699A (en) 1998-12-03 2000-07-03 Fraunhofer-Gesellschaft Zur Forderung Der Angewandten Forschung E.V. Apparatus and method for transmitting information and apparatus and method for receiving information
US6637031B1 (en) 1998-12-04 2003-10-21 Microsoft Corporation Multimedia presentation latency minimization
US20030195974A1 (en) 1998-12-04 2003-10-16 Ronning Joel A. Apparatus and method for scheduling of search for updates or downloads of a file
US6496980B1 (en) 1998-12-07 2002-12-17 Intel Corporation Method of providing replay on demand for streaming digital multimedia
US6223324B1 (en) * 1999-01-05 2001-04-24 Agere Systems Guardian Corp. Multiple program unequal error protection for digital audio broadcasting and other applications
JP3926499B2 (ja) 1999-01-22 2007-06-06 株式会社日立国際電気 畳み込み符号軟判定復号方式の受信装置
US6618451B1 (en) 1999-02-13 2003-09-09 Altocom Inc Efficient reduced state maximum likelihood sequence estimator
US6041001A (en) * 1999-02-25 2000-03-21 Lexar Media, Inc. Method of increasing data reliability of a flash memory device without compromising compatibility
EP1083496A1 (en) 1999-03-03 2001-03-14 Sony Corporation Transmitter, receiver, transmitter/receiver system, transmission method and reception method
US6785323B1 (en) * 1999-11-22 2004-08-31 Ipr Licensing, Inc. Variable rate coding for forward link
US6401239B1 (en) 1999-03-22 2002-06-04 B.I.S. Advanced Software Systems Ltd. System and method for quick downloading of electronic files
US6466698B1 (en) 1999-03-25 2002-10-15 The United States Of America As Represented By The Secretary Of The Navy Efficient embedded image and video compression system using lifted wavelets
US6609223B1 (en) 1999-04-06 2003-08-19 Kencast, Inc. Method for packet-level fec encoding, in which on a source packet-by-source packet basis, the error correction contributions of a source packet to a plurality of wildcard packets are computed, and the source packet is transmitted thereafter
US6535920B1 (en) * 1999-04-06 2003-03-18 Microsoft Corporation Analyzing, indexing and seeking of streaming information
JP3256517B2 (ja) 1999-04-06 2002-02-12 インターナショナル・ビジネス・マシーンズ・コーポレーション 符号化回路、回路、パリティ生成方法及び記憶媒体
US6804202B1 (en) 1999-04-08 2004-10-12 Lg Information And Communications, Ltd. Radio protocol for mobile communication system and method
US7885340B2 (en) 1999-04-27 2011-02-08 Realnetworks, Inc. System and method for generating multiple synchronized encoded representations of media data
FI113124B (fi) 1999-04-29 2004-02-27 Nokia Corp Tiedonsiirto
DE60028120T2 (de) 1999-05-06 2006-12-28 Sony Corp. Datenverarbeitungsverfahren und -gerät, Datenwiedergabeverfahren und -gerät, Datenaufzeichnungsmedien
KR100416996B1 (ko) 1999-05-10 2004-02-05 삼성전자주식회사 이동 통신시스템에서 라디오링크프로토콜에 따른 가변 길이의 데이터 송수신 장치 및 방법
US6229824B1 (en) 1999-05-26 2001-05-08 Xm Satellite Radio Inc. Method and apparatus for concatenated convolutional endcoding and interleaving
AU5140200A (en) 1999-05-26 2000-12-18 Enounce, Incorporated Method and apparatus for controlling time-scale modification during multi-media broadcasts
US6154452A (en) 1999-05-26 2000-11-28 Xm Satellite Radio Inc. Method and apparatus for continuous cross-channel interleaving
JP2000353969A (ja) 1999-06-11 2000-12-19 Sony Corp デジタル音声放送の受信機
US6577599B1 (en) 1999-06-30 2003-06-10 Sun Microsystems, Inc. Small-scale reliable multicasting
IL141800A0 (en) 1999-07-06 2002-03-10 Samsung Electronics Co Ltd Rate matching device and method for a data communication system
US6643332B1 (en) 1999-07-09 2003-11-04 Lsi Logic Corporation Method and apparatus for multi-level coding of digital signals
JP3451221B2 (ja) 1999-07-22 2003-09-29 日本無線株式会社 誤り訂正符号化装置、方法及び媒体、並びに誤り訂正符号復号装置、方法及び媒体
US6279072B1 (en) 1999-07-22 2001-08-21 Micron Technology, Inc. Reconfigurable memory with selectable error correction storage
US6453440B1 (en) 1999-08-04 2002-09-17 Sun Microsystems, Inc. System and method for detecting double-bit errors and for correcting errors due to component failures
JP2001060934A (ja) 1999-08-20 2001-03-06 Matsushita Electric Ind Co Ltd Ｏｆｄｍ通信装置
US6430233B1 (en) 1999-08-30 2002-08-06 Hughes Electronics Corporation Single-LNB satellite data receiver
JP4284774B2 (ja) * 1999-09-07 2009-06-24 ソニー株式会社 送信装置、受信装置、通信システム、送信方法及び通信方法
EP1131930B1 (en) 1999-09-27 2007-01-17 Koninklijke Philips Electronics N.V. Partitioning of file for emulating streaming
US7529806B1 (en) * 1999-11-04 2009-05-05 Koninklijke Philips Electronics N.V. Partitioning of MP3 content file for emulating streaming
JP2001094625A (ja) 1999-09-27 2001-04-06 Canon Inc データ通信装置、データ通信方法及び記憶媒体
US20050160272A1 (en) 1999-10-28 2005-07-21 Timecertain, Llc System and method for providing trusted time in content of digital data files
US6523147B1 (en) * 1999-11-11 2003-02-18 Ibiquity Digital Corporation Method and apparatus for forward error correction coding for an AM in-band on-channel digital audio broadcasting system
AUPQ403399A0 (en) 1999-11-12 1999-12-09 Canon Kabushiki Kaisha Image compression
US6678855B1 (en) * 1999-12-02 2004-01-13 Microsoft Corporation Selecting K in a data transmission carousel using (N,K) forward error correction
US6748441B1 (en) 1999-12-02 2004-06-08 Microsoft Corporation Data carousel receiving and caching
US7149359B1 (en) 1999-12-16 2006-12-12 Microsoft Corporation Searching and recording media streams
US6798791B1 (en) 1999-12-16 2004-09-28 Agere Systems Inc Cluster frame synchronization scheme for a satellite digital audio radio system
US6487692B1 (en) 1999-12-21 2002-11-26 Lsi Logic Corporation Reed-Solomon decoder
US6965636B1 (en) 2000-02-01 2005-11-15 2Wire, Inc. System and method for block error correction in packet-based digital communications
US20020009137A1 (en) * 2000-02-01 2002-01-24 Nelson John E. Three-dimensional video broadcasting system
WO2001057667A1 (en) 2000-02-03 2001-08-09 Bandwiz, Inc. Data streaming
IL140504A0 (en) 2000-02-03 2002-02-10 Bandwiz Inc Broadcast system
US7304990B2 (en) 2000-02-03 2007-12-04 Bandwiz Inc. Method of encoding and transmitting data over a communication medium through division and segmentation
JP2001251287A (ja) 2000-02-24 2001-09-14 Geneticware Corp Ltd ハードウエア保護内部秘匿鍵及び可変パスコードを利用する機密データ伝送方法
US6765866B1 (en) 2000-02-29 2004-07-20 Mosaid Technologies, Inc. Link aggregation
DE10009443A1 (de) 2000-02-29 2001-08-30 Philips Corp Intellectual Pty Empfänger und Verfahren zum Detektieren und Dekodieren eines DQPSK-modulierten und kanalkodierten Empfangssignals
US6384750B1 (en) 2000-03-23 2002-05-07 Mosaid Technologies, Inc. Multi-stage lookup for translating between signals of different bit lengths
JP2001274776A (ja) 2000-03-24 2001-10-05 Toshiba Corp 情報データ伝送システムとその送信装置及び受信装置
US6510177B1 (en) * 2000-03-24 2003-01-21 Microsoft Corporation System and method for layered video coding enhancement
WO2001076077A2 (en) 2000-03-31 2001-10-11 Ted Szymanski Transmitter, receiver, and coding scheme to increase data rate and decrease bit error rate of an optical data link
US6473010B1 (en) 2000-04-04 2002-10-29 Marvell International, Ltd. Method and apparatus for determining error correction code failure rate for iterative decoding algorithms
US8572646B2 (en) 2000-04-07 2013-10-29 Visible World Inc. System and method for simultaneous broadcast for personalized messages
US7073191B2 (en) 2000-04-08 2006-07-04 Sun Microsystems, Inc Streaming a single media track to multiple clients
US6631172B1 (en) 2000-05-01 2003-10-07 Lucent Technologies Inc. Efficient list decoding of Reed-Solomon codes for message recovery in the presence of high noise levels
US6742154B1 (en) 2000-05-25 2004-05-25 Ciena Corporation Forward error correction codes for digital optical network optimization
US6694476B1 (en) * 2000-06-02 2004-02-17 Vitesse Semiconductor Corporation Reed-solomon encoder and decoder
US6738942B1 (en) 2000-06-02 2004-05-18 Vitesse Semiconductor Corporation Product code based forward error correction system
US7373413B1 (en) 2000-06-28 2008-05-13 Cisco Technology, Inc. Devices and methods for minimizing start up delay in transmission of streaming media
GB2366159B (en) 2000-08-10 2003-10-08 Mitel Corp Combination reed-solomon and turbo coding
US6834342B2 (en) 2000-08-16 2004-12-21 Eecad, Inc. Method and system for secure communication over unstable public connections
KR100447162B1 (ko) 2000-08-19 2004-09-04 엘지전자 주식회사 래디오 링크 콘트롤(ｒｌｃ)에서 프로토콜 데이터 유닛(ｐｄｕ) 정보의 길이 지시자(ｌｉ) 처리방법
JP2002073625A (ja) 2000-08-24 2002-03-12 Nippon Hoso Kyokai <Nhk> 放送番組に同期した情報提供の方法、サーバ及び媒体
US7340664B2 (en) 2000-09-20 2008-03-04 Lsi Logic Corporation Single engine turbo decoder with single frame size buffer for interleaving/deinterleaving
US7151754B1 (en) 2000-09-22 2006-12-19 Lucent Technologies Inc. Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding
US6486803B1 (en) 2000-09-22 2002-11-26 Digital Fountain, Inc. On demand encoding with a window
US7031257B1 (en) * 2000-09-22 2006-04-18 Lucent Technologies Inc. Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol
US7490344B2 (en) 2000-09-29 2009-02-10 Visible World, Inc. System and method for seamless switching
US6763392B1 (en) 2000-09-29 2004-07-13 Microsoft Corporation Media streaming methods and arrangements
US6411223B1 (en) 2000-10-18 2002-06-25 Digital Fountain, Inc. Generating high weight encoding symbols using a basis
US7613183B1 (en) 2000-10-31 2009-11-03 Foundry Networks, Inc. System and method for router data aggregation and delivery
US6694478B1 (en) 2000-11-07 2004-02-17 Agere Systems Inc. Low delay channel codes for correcting bursts of lost packets
US6732325B1 (en) 2000-11-08 2004-05-04 Digeo, Inc. Error-correction with limited working storage
US20020133247A1 (en) 2000-11-11 2002-09-19 Smith Robert D. System and method for seamlessly switching between media streams
US7072971B2 (en) * 2000-11-13 2006-07-04 Digital Foundation, Inc. Scheduling of multiple files for serving on a server
DE20020251U1 (de) * 2000-11-29 2001-02-22 Autoliv Dev Kraftbegrenzerretractor mit darauf abgestimmtem Gurtband
US7240358B2 (en) 2000-12-08 2007-07-03 Digital Fountain, Inc. Methods and apparatus for scheduling, serving, receiving media-on demand for clients, servers arranged according to constraints on resources
CA2429827C (en) 2000-12-15 2009-08-25 British Telecommunications Public Limited Company Transmission and reception of audio and/or video material
EP2071827A3 (en) 2000-12-15 2010-08-25 BRITISH TELECOMMUNICATIONS public limited company Transmission and reception of audio and/or video material
US6850736B2 (en) * 2000-12-21 2005-02-01 Tropian, Inc. Method and apparatus for reception quality indication in wireless communication
US7143433B1 (en) 2000-12-27 2006-11-28 Infovalve Computing Inc. Video distribution system using dynamic segmenting of video data files
US20020085013A1 (en) 2000-12-29 2002-07-04 Lippincott Louis A. Scan synchronized dual frame buffer graphics subsystem
NO315887B1 (no) 2001-01-04 2003-11-03 Fast Search & Transfer As Fremgangsmater ved overforing og soking av videoinformasjon
US20080059532A1 (en) * 2001-01-18 2008-03-06 Kazmi Syed N Method and system for managing digital content, including streaming media
KR100674423B1 (ko) * 2001-01-19 2007-01-29 엘지전자 주식회사 송/수신 시스템 및 데이터 처리 방법
DE10103387A1 (de) 2001-01-26 2002-08-01 Thorsten Nordhoff Windkraftanlage mit einer Einrichtung zur Hindernisbefeuerung bzw. Nachtkennzeichnung
FI118830B (fi) 2001-02-08 2008-03-31 Nokia Corp Tietovirran toisto
US6868083B2 (en) 2001-02-16 2005-03-15 Hewlett-Packard Development Company, L.P. Method and system for packet communication employing path diversity
JP2004531925A (ja) 2001-03-05 2004-10-14 インタービデオインコーポレイテッド 圧縮されたビデオビットストリームにおける冗長な動きベクトルを符号化し復号するシステム及び方法
US20020129159A1 (en) 2001-03-09 2002-09-12 Michael Luby Multi-output packet server with independent streams
KR100464360B1 (ko) 2001-03-30 2005-01-03 삼성전자주식회사 고속 패킷 데이터 전송 이동통신시스템에서 패킷 데이터채널에 대한 효율적인 에너지 분배 장치 및 방법
US20020143953A1 (en) 2001-04-03 2002-10-03 International Business Machines Corporation Automatic affinity within networks performing workload balancing
US6785836B2 (en) 2001-04-11 2004-08-31 Broadcom Corporation In-place data transformation for fault-tolerant disk storage systems
US6820221B2 (en) 2001-04-13 2004-11-16 Hewlett-Packard Development Company, L.P. System and method for detecting process and network failures in a distributed system
US7010052B2 (en) * 2001-04-16 2006-03-07 The Ohio University Apparatus and method of CTCM encoding and decoding for a digital communication system
US6910220B2 (en) 2001-04-20 2005-06-21 Radio Computing Services, Inc. Demand-based goal-driven scheduling system
US7035468B2 (en) 2001-04-20 2006-04-25 Front Porch Digital Inc. Methods and apparatus for archiving, indexing and accessing audio and video data
TWI246841B (en) 2001-04-22 2006-01-01 Koninkl Philips Electronics Nv Digital transmission system and method for transmitting digital signals
US20020191116A1 (en) 2001-04-24 2002-12-19 Damien Kessler System and data format for providing seamless stream switching in a digital video recorder
US20020194608A1 (en) 2001-04-26 2002-12-19 Goldhor Richard S. Method and apparatus for a playback enhancement system implementing a "Say Again" feature
US6497479B1 (en) 2001-04-27 2002-12-24 Hewlett-Packard Company Higher organic inks with good reliability and drytime
US7962482B2 (en) 2001-05-16 2011-06-14 Pandora Media, Inc. Methods and systems for utilizing contextual feedback to generate and modify playlists
US6633856B2 (en) 2001-06-15 2003-10-14 Flarion Technologies, Inc. Methods and apparatus for decoding LDPC codes
US7076478B2 (en) 2001-06-26 2006-07-11 Microsoft Corporation Wrapper playlists on streaming media services
US6745364B2 (en) 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
JP2003018568A (ja) 2001-06-29 2003-01-17 Matsushita Electric Ind Co Ltd 再生システム、サーバ装置及び再生装置
US7349691B2 (en) 2001-07-03 2008-03-25 Microsoft Corporation System and apparatus for performing broadcast and localcast communications
JP2003022232A (ja) 2001-07-06 2003-01-24 Fujitsu Ltd コンテンツデータ転送システム
DE10133237B4 (de) 2001-07-09 2007-04-19 Siemens Ag Verfahren für die Computertomographie sowie Computertomographie(CT-)Gerät
US6895547B2 (en) 2001-07-11 2005-05-17 International Business Machines Corporation Method and apparatus for low density parity check encoding of data
US6928603B1 (en) 2001-07-19 2005-08-09 Adaptix, Inc. System and method for interference mitigation using adaptive forward error correction in a wireless RF data transmission system
JP4766440B2 (ja) 2001-07-27 2011-09-07 日本電気株式会社 携帯端末装置及び携帯端末装置の音響再生システム
US6961890B2 (en) * 2001-08-16 2005-11-01 Hewlett-Packard Development Company, L.P. Dynamic variable-length error correction code
US7110412B2 (en) 2001-09-18 2006-09-19 Sbc Technology Resources, Inc. Method and system to transport high-quality video signals
FI115418B (fi) 2001-09-20 2005-04-29 Oplayo Oy Adaptiivinen mediavirta
US6990624B2 (en) 2001-10-12 2006-01-24 Agere Systems Inc. High speed syndrome-based FEC encoder and decoder and system using same
US7480703B2 (en) 2001-11-09 2009-01-20 Sony Corporation System, method, and computer program product for remotely determining the configuration of a multi-media content user based on response of the user
US7003712B2 (en) 2001-11-29 2006-02-21 Emin Martinian Apparatus and method for adaptive, multimode decoding
JP2003174489A (ja) 2001-12-05 2003-06-20 Ntt Docomo Inc ストリーミング配信装置、ストリーミング配信方法
EP1454250A4 (en) 2001-12-15 2010-08-25 Thomson Licensing SYSTEM AND METHOD FOR MODIFYING A VIDEO DATA FLOW BASED ON A CLIENT OR NETWORK ENVIRONMENT
FI114527B (fi) 2002-01-23 2004-10-29 Nokia Corp Kuvakehysten ryhmittely videokoodauksessa
EP1670259A3 (en) 2002-01-23 2010-03-03 Nokia Corporation Grouping of image frames in video coding
EP1472847A1 (en) * 2002-01-30 2004-11-03 Koninklijke Philips Electronics N.V. Streaming multimedia data over a network having a variable bandwidth
AU2003211057A1 (en) 2002-02-15 2003-09-09 Digital Fountain, Inc. System and method for reliably communicating the content of a live data stream
EP1481553A1 (en) * 2002-02-25 2004-12-01 Sony Electronics Inc. Method and apparatus for supporting avc in mp4
JP4126928B2 (ja) 2002-02-28 2008-07-30 日本電気株式会社 プロキシサーバ及びプロキシ制御プログラム
JP4116470B2 (ja) 2002-03-06 2008-07-09 ヒューレット・パッカード・カンパニー メディア・ストリーミング配信システム
FR2837332A1 (fr) 2002-03-15 2003-09-19 Thomson Licensing Sa Dispositif et procede d'insertion de codes de correction d'erreurs et de reconstitution de flux de donnees, et produits correspondants
WO2003090391A1 (en) 2002-04-15 2003-10-30 Nokia Corporation Rlp logical layer of a communication station
US6677864B2 (en) * 2002-04-18 2004-01-13 Telefonaktiebolaget L.M. Ericsson Method for multicast over wireless networks
JP3689063B2 (ja) 2002-04-19 2005-08-31 松下電器産業株式会社 データ受信装置及びデータ配信システム
JP3629008B2 (ja) 2002-04-19 2005-03-16 松下電器産業株式会社 データ受信装置及びデータ配信システム
WO2003092305A1 (en) 2002-04-25 2003-11-06 Sharp Kabushiki Kaisha Image encodder, image decoder, record medium, and image recorder
US20030204602A1 (en) 2002-04-26 2003-10-30 Hudson Michael D. Mediated multi-source peer content delivery network architecture
US7058664B1 (en) 2002-04-29 2006-06-06 Sprint Communications Company L.P. Method and system for data recovery
US7177658B2 (en) 2002-05-06 2007-02-13 Qualcomm, Incorporated Multi-media broadcast and multicast service (MBMS) in a wireless communications system
US7200388B2 (en) 2002-05-31 2007-04-03 Nokia Corporation Fragmented delivery of multimedia
US20040083015A1 (en) 2002-06-04 2004-04-29 Srinivas Patwari System for multimedia rendering in a portable device
MXPA04012143A (es) 2002-06-04 2005-04-19 Qualcomm Inc Sistema para representacion de multimedios en un dispositivo portatil.
AR039964A1 (es) 2002-06-04 2005-03-09 Qualcomm Inc Metodo y sistema para emitir un contenido de multimedia en un dispositivo portatil y un medio legible por computadora
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US7570665B2 (en) 2002-06-11 2009-08-04 Telefonaktiebolaget L M Ericsson (Publ) Generation of mixed media streams
ES2445761T3 (es) * 2002-06-11 2014-03-05 Digital Fountain, Inc. Descodificación de códigos de reacción en cadena mediante inactivación
US6956875B2 (en) 2002-06-19 2005-10-18 Atlinks Usa, Inc. Technique for communicating variable bit rate data over a constant bit rate link
JP4154569B2 (ja) 2002-07-10 2008-09-24 日本電気株式会社 画像圧縮伸長装置
JP4120461B2 (ja) 2002-07-12 2008-07-16 住友電気工業株式会社 伝送データ生成方法及び伝送データ生成装置
AU2003251964A1 (en) 2002-07-16 2004-02-02 Nokia Corporation A method for random access and gradual picture refresh in video coding
CN1258921C (zh) 2002-07-30 2006-06-07 中兴通讯股份有限公司 分布式视频点播系统及其实现数据存储和访问的方法
EP1526659A4 (en) 2002-07-31 2010-12-01 Sharp Kk DATA COMMUNICATION DEVICE, ITS CONTINUOUS COMMUNICATION PROCEDURE, ITS PROCESSING PROGRAM, AND RECORDING MEDIUM ON WHICH THE PROGRAM IS RECORDED
JP2004070712A (ja) 2002-08-07 2004-03-04 Nippon Telegr & Teleph Corp <Ntt> データ配信方法，データ配信システム，分割配信データ受信方法，分割配信データ受信装置および分割配信データ受信プログラム
US7620111B2 (en) 2002-08-13 2009-11-17 Nokia Corporation Symbol interleaving
US6985459B2 (en) 2002-08-21 2006-01-10 Qualcomm Incorporated Early transmission and playout of packets in wireless communication systems
JP2004112129A (ja) * 2002-09-17 2004-04-08 Toshiba Corp 映像配信装置及び映像配信工程を実現するプログラム
JP3836858B2 (ja) 2002-09-27 2006-10-25 富士通株式会社 データ配信方法、システム、伝送方法及びプログラム
JP3534742B1 (ja) 2002-10-03 2004-06-07 株式会社エヌ・ティ・ティ・ドコモ 動画像復号方法、動画像復号装置、及び動画像復号プログラム
JP4546246B2 (ja) 2002-10-05 2010-09-15 デジタル ファウンテン， インコーポレイテッド 連鎖的暗号化反応の系統的記号化および復号化
JP2004135013A (ja) 2002-10-10 2004-04-30 Matsushita Electric Ind Co Ltd 伝送装置及び伝送方法
FI116816B (fi) 2002-10-14 2006-02-28 Nokia Corp Median suoratoisto
US8320301B2 (en) 2002-10-25 2012-11-27 Qualcomm Incorporated MIMO WLAN system
US7289451B2 (en) * 2002-10-25 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Delay trading between communication links
JP4460455B2 (ja) 2002-10-30 2010-05-12 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 適応的順方向誤り制御スキーム
JP2004165922A (ja) 2002-11-12 2004-06-10 Sony Corp 情報処理装置および方法、並びにプログラム
GB0226872D0 (en) 2002-11-18 2002-12-24 British Telecomm Video transmission
KR101044213B1 (ko) 2002-11-18 2011-06-29 브리티쉬 텔리커뮤니케이션즈 파블릭 리미티드 캄퍼니 비디오 전송 방법
JP3935419B2 (ja) 2002-11-19 2007-06-20 Ｋｄｄｉ株式会社 動画像符号化ビットレート選択方式
KR100502609B1 (ko) 2002-11-21 2005-07-20 한국전자통신연구원 Ｌｄｐｃ 코드를 이용한 부호화기 및 부호화 방법
US7086718B2 (en) 2002-11-23 2006-08-08 Silverbrook Research Pty Ltd Thermal ink jet printhead with high nozzle areal density
US8352991B2 (en) 2002-12-09 2013-01-08 Thomson Licensing System and method for modifying a video stream based on a client or network environment
JP2004192140A (ja) 2002-12-09 2004-07-08 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2004193992A (ja) 2002-12-11 2004-07-08 Sony Corp 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム
US8135073B2 (en) * 2002-12-19 2012-03-13 Trident Microsystems (Far East) Ltd Enhancing video images depending on prior image enhancements
US7164882B2 (en) * 2002-12-24 2007-01-16 Poltorak Alexander I Apparatus and method for facilitating a purchase using information provided on a media playing device
WO2004068715A2 (en) 2003-01-29 2004-08-12 Digital Fountain, Inc. Systems and processes for fast encoding of hamming codes
US7756002B2 (en) 2003-01-30 2010-07-13 Texas Instruments Incorporated Time-frequency interleaved orthogonal frequency division multiplexing ultra wide band physical layer
US7525994B2 (en) 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
US7231404B2 (en) 2003-01-31 2007-06-12 Nokia Corporation Datacast file transmission with meta-data retention
US7062272B2 (en) 2003-02-18 2006-06-13 Qualcomm Incorporated Method and apparatus to track count of broadcast content recipients in a wireless telephone network
EP1455504B1 (en) 2003-03-07 2014-11-12 Samsung Electronics Co., Ltd. Apparatus and method for processing audio signal and computer readable recording medium storing computer program for the method
JP4173755B2 (ja) 2003-03-24 2008-10-29 富士通株式会社 データ伝送サーバ
US7610487B2 (en) * 2003-03-27 2009-10-27 Microsoft Corporation Human input security codes
US7266147B2 (en) 2003-03-31 2007-09-04 Sharp Laboratories Of America, Inc. Hypothetical reference decoder
JP2004343701A (ja) 2003-04-21 2004-12-02 Matsushita Electric Ind Co Ltd データ受信再生装置、データ受信再生方法及びデータ受信再生処理プログラム
US7408486B2 (en) 2003-04-21 2008-08-05 Qbit Corporation System and method for using a microlet-based modem
JP4379779B2 (ja) 2003-04-28 2009-12-09 Ｋｄｄｉ株式会社 映像配信方式
US20050041736A1 (en) * 2003-05-07 2005-02-24 Bernie Butler-Smith Stereoscopic television signal processing method, transmission system and viewer enhancements
KR100492567B1 (ko) 2003-05-13 2005-06-03 엘지전자 주식회사 이동통신 시스템의 ｈｔｔｐ 기반 비디오 스트리밍 장치및 방법
US7113773B2 (en) 2003-05-16 2006-09-26 Qualcomm Incorporated Reliable reception of broadcast/multicast content
JP2004348824A (ja) 2003-05-21 2004-12-09 Toshiba Corp Ｅｃｃエンコード方法、ｅｃｃエンコード装置
US8161116B2 (en) 2003-05-23 2012-04-17 Kirusa, Inc. Method and system for communicating a data file over a network
JP2004362099A (ja) 2003-06-03 2004-12-24 Sony Corp サーバ装置、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
AU2004246532B2 (en) 2003-06-07 2008-03-13 Samsung Electronics Co., Ltd. Apparatus and method for organization and interpretation of multimedia data on a recording medium
KR101003413B1 (ko) 2003-06-12 2010-12-23 엘지전자 주식회사 이동통신 단말기의 전송데이터 압축/해제 방법
US7603689B2 (en) 2003-06-13 2009-10-13 Microsoft Corporation Fast start-up for digital video streams
RU2265960C2 (ru) 2003-06-16 2005-12-10 Федеральное государственное унитарное предприятие "Калужский научно-исследовательский институт телемеханических устройств" Способ передачи информации с использованием адаптивного перемежения
US7391717B2 (en) 2003-06-30 2008-06-24 Microsoft Corporation Streaming of variable bit rate multimedia content
US20050004997A1 (en) 2003-07-01 2005-01-06 Nokia Corporation Progressive downloading of timed multimedia content
US8149939B2 (en) 2003-07-07 2012-04-03 Samsung Electronics Co., Ltd. System of robust DTV signal transmissions that legacy DTV receivers will disregard
US7254754B2 (en) 2003-07-14 2007-08-07 International Business Machines Corporation Raid 3+3
KR100532450B1 (ko) 2003-07-16 2005-11-30 삼성전자주식회사 에러에 대해 강인한 특성을 가지는 데이터 기록 방법,이에 적합한 데이터 재생 방법, 그리고 이에 적합한 장치들
US20050028067A1 (en) * 2003-07-31 2005-02-03 Weirauch Charles R. Data with multiple sets of error correction codes
US7941554B2 (en) 2003-08-01 2011-05-10 Microsoft Corporation Sparse caching for streaming media
US8694869B2 (en) 2003-08-21 2014-04-08 QUALCIMM Incorporated Methods for forward error correction coding above a radio link control layer and related apparatus
CN1868157B (zh) 2003-08-21 2011-07-27 高通股份有限公司 无线链路控制层上的前向纠错编码方法和相关装置
IL157886A0 (en) * 2003-09-11 2009-02-11 Bamboo Mediacasting Ltd Secure multicast transmission
IL157885A0 (en) 2003-09-11 2004-03-28 Bamboo Mediacasting Ltd Iterative forward error correction
JP4183586B2 (ja) 2003-09-12 2008-11-19 三洋電機株式会社 映像表示装置
US7555006B2 (en) 2003-09-15 2009-06-30 The Directv Group, Inc. Method and system for adaptive transcoding and transrating in a video network
KR100608715B1 (ko) 2003-09-27 2006-08-04 엘지전자 주식회사 ＱｏＳ보장형 멀티미디어 스트리밍 서비스 시스템 및 방법
DE60307852D1 (de) 2003-09-30 2006-10-05 Ericsson Telefon Ab L M In-place Entschachtelung von Daten
US7559004B1 (en) 2003-10-01 2009-07-07 Sandisk Corporation Dynamic redundant area configuration in a non-volatile memory system
CN1954501B (zh) 2003-10-06 2010-06-16 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法
US7614071B2 (en) 2003-10-10 2009-11-03 Microsoft Corporation Architecture for distributed sending of media data
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
DE602004028849D1 (de) * 2003-10-14 2010-10-07 Panasonic Corp Datenumsetzer
US7650036B2 (en) * 2003-10-16 2010-01-19 Sharp Laboratories Of America, Inc. System and method for three-dimensional video coding
US7168030B2 (en) * 2003-10-17 2007-01-23 Telefonaktiebolaget Lm Ericsson (Publ) Turbo code decoder with parity information update
US8132215B2 (en) 2003-10-27 2012-03-06 Panasonic Corporation Apparatus for receiving broadcast signal
JP2005136546A (ja) 2003-10-29 2005-05-26 Sony Corp 送信装置および方法、記録媒体、並びにプログラム
DE602004011445T2 (de) 2003-11-03 2009-01-15 Broadcom Corp., Irvine FEC-Dekodierung mit dynamischen Parametern
US20050102371A1 (en) 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US7333993B2 (en) 2003-11-25 2008-02-19 Network Appliance, Inc. Adaptive file readahead technique for multiple read streams
KR101041762B1 (ko) 2003-12-01 2011-06-17 디지털 파운튼, 인크. 통신 채널을 통해 소스로부터 목적지로 데이터를 송신 및 인코딩하는 방법
US7428669B2 (en) 2003-12-07 2008-09-23 Adaptive Spectrum And Signal Alignment, Inc. Adaptive FEC codeword management
US7574706B2 (en) 2003-12-15 2009-08-11 Microsoft Corporation System and method for managing and communicating software updates
KR20060116040A (ko) * 2003-12-22 2006-11-13 코닌클리케 필립스 일렉트로닉스 엔.브이. 인코딩 특성들의 적응으로 컨텐츠를 전송하는 방법
US7590118B2 (en) 2003-12-23 2009-09-15 Agere Systems Inc. Frame aggregation format
JP4536383B2 (ja) 2004-01-16 2010-09-01 株式会社エヌ・ティ・ティ・ドコモ データ受信装置およびデータ受信方法
KR100770902B1 (ko) 2004-01-20 2007-10-26 삼성전자주식회사 고속 무선 데이터 시스템을 위한 가변 부호율의 오류 정정부호 생성 및 복호 장치 및 방법
KR100834750B1 (ko) 2004-01-29 2008-06-05 삼성전자주식회사 엔코더 단에서 스케일러빌리티를 제공하는 스케일러블비디오 코딩 장치 및 방법
JP4321284B2 (ja) 2004-02-03 2009-08-26 株式会社デンソー ストリーミングデータ送信装置、および情報配信システム
US7599294B2 (en) 2004-02-13 2009-10-06 Nokia Corporation Identification and re-transmission of missing parts
US7580520B2 (en) 2004-02-14 2009-08-25 Hewlett-Packard Development Company, L.P. Methods for scaling a progressively encrypted sequence of scalable data
US6989773B2 (en) 2004-02-13 2006-01-24 Hewlett-Packard Development Company, L.P. Media data encoding device
CN101099142B (zh) * 2004-03-03 2010-10-06 分组视频网络技术方案有限公司 用来从网络节点获取数字多媒体内容的系统和方法
KR100596705B1 (ko) 2004-03-04 2006-07-04 삼성전자주식회사 비디오 스트리밍 서비스를 위한 비디오 코딩 방법과 비디오 인코딩 시스템, 및 비디오 디코딩 방법과 비디오 디코딩 시스템
KR100586883B1 (ko) 2004-03-04 2006-06-08 삼성전자주식회사 비디오 스트리밍 서비스를 위한 비디오 코딩방법, 프리디코딩방법, 비디오 디코딩방법, 및 이를 위한 장치와, 이미지 필터링방법
US7609653B2 (en) 2004-03-08 2009-10-27 Microsoft Corporation Resolving partial media topologies
US20050207392A1 (en) 2004-03-19 2005-09-22 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using RLP
US7240236B2 (en) 2004-03-23 2007-07-03 Archivas, Inc. Fixed content distributed data storage using permutation ring encoding
JP4433287B2 (ja) 2004-03-25 2010-03-17 ソニー株式会社 受信装置および方法、並びにプログラム
US8842175B2 (en) 2004-03-26 2014-09-23 Broadcom Corporation Anticipatory video signal reception and processing
US20050216472A1 (en) 2004-03-29 2005-09-29 David Leon Efficient multicast/broadcast distribution of formatted data
JP2007531199A (ja) 2004-03-30 2007-11-01 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ディスクベースのマルチメディアコンテンツのための改良されたトリックモード実行をサポートするシステムおよび方法
TW200534875A (en) 2004-04-23 2005-11-01 Lonza Ag Personal care compositions and concentrates for making the same
FR2869744A1 (fr) 2004-04-29 2005-11-04 Thomson Licensing Sa Methode de transmission de paquets de donnees numeriques et appareil implementant la methode
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
EP1743431A4 (en) * 2004-05-07 2007-05-02 Digital Fountain Inc SYSTEM FOR DOWNLOADING AND RECORDING AND CONTINUOUS READING OF FILES
US7633970B2 (en) 2004-05-07 2009-12-15 Agere Systems Inc. MAC header compression for use with frame aggregation
US20050254575A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Multiple interoperability points for scalable media coding and transmission
US20050254526A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Parameter sets update in streaming applications
US20060037057A1 (en) * 2004-05-24 2006-02-16 Sharp Laboratories Of America, Inc. Method and system of enabling trick play modes using HTTP GET
US8331445B2 (en) 2004-06-01 2012-12-11 Qualcomm Incorporated Method, apparatus, and system for enhancing robustness of predictive video codecs using a side-channel based on distributed source coding techniques
US20070110074A1 (en) 2004-06-04 2007-05-17 Bob Bradley System and Method for Synchronizing Media Presentation at Multiple Recipients
US7492828B2 (en) 2004-06-18 2009-02-17 Qualcomm Incorporated Time synchronization using spectral estimation in a communication system
US7139660B2 (en) 2004-07-14 2006-11-21 General Motors Corporation System and method for changing motor vehicle personalization settings
US8112531B2 (en) * 2004-07-14 2012-02-07 Nokia Corporation Grouping of session objects
US8544043B2 (en) 2004-07-21 2013-09-24 Qualcomm Incorporated Methods and apparatus for providing content information to content servers
JP2006033763A (ja) 2004-07-21 2006-02-02 Toshiba Corp 電子機器及び通信制御方法
US7409626B1 (en) 2004-07-28 2008-08-05 Ikanos Communications Inc Method and apparatus for determining codeword interleaver parameters
US7376150B2 (en) 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
US7590922B2 (en) 2004-07-30 2009-09-15 Nokia Corporation Point-to-point repair request mechanism for point-to-multipoint transmission systems
US7930184B2 (en) 2004-08-04 2011-04-19 Dts, Inc. Multi-channel audio coding/decoding of random access points and transients
WO2006020826A2 (en) 2004-08-11 2006-02-23 Digital Fountain, Inc. Method and apparatus for fast encoding of data symbols according to half-weight codes
CN100553209C (zh) 2004-08-19 2009-10-21 诺基亚公司 为控制网络上多媒体数据的部署而对目录服务器数据进行高速缓存
JP4405875B2 (ja) * 2004-08-25 2010-01-27 富士通株式会社 エラー訂正用データの生成方法及び生成装置並びに生成プログラム及び同プログラムを格納したコンピュータ読み取り可能な記録媒体
JP2006074335A (ja) 2004-09-01 2006-03-16 Nippon Telegr & Teleph Corp <Ntt> 伝送方法、伝送システム及び伝送装置
JP4576936B2 (ja) 2004-09-02 2010-11-10 ソニー株式会社 情報処理装置、情報記録媒体、コンテンツ管理システム、およびデータ処理方法、並びにコンピュータ・プログラム
EP1638333A1 (en) * 2004-09-17 2006-03-22 Mitsubishi Electric Information Technology Centre Europe B.V. Rate adaptive video coding
JP2006115104A (ja) 2004-10-13 2006-04-27 Daiichikosho Co Ltd 高能率符号化された時系列情報をパケット化してリアルタイム・ストリーミング送信し受信再生する方法および装置
US7529984B2 (en) 2004-11-16 2009-05-05 Infineon Technologies Ag Seamless change of depth of a general convolutional interleaver during transmission without loss of data
US7751324B2 (en) 2004-11-19 2010-07-06 Nokia Corporation Packet stream arrangement in multimedia transmission
CN101061718B (zh) 2004-11-22 2010-10-13 汤姆森研究基金有限公司 用于数字订户线路系统中的频道改变的方法和设备
EP1817859A1 (en) 2004-12-02 2007-08-15 THOMSON Licensing Adaptive forward error correction
KR20060065482A (ko) 2004-12-10 2006-06-14 마이크로소프트 코포레이션 스트리밍 미디어 데이터의 코딩 비트 레이트의 제어 시스템및 프로세스
JP2006174045A (ja) 2004-12-15 2006-06-29 Ntt Communications Kk 画像配信装置、プログラム及び方法
JP2006174032A (ja) 2004-12-15 2006-06-29 Sanyo Electric Co Ltd 画像データ伝送システム、画像データ受信装置及び画像データ送信装置
US7398454B2 (en) 2004-12-21 2008-07-08 Tyco Telecommunications (Us) Inc. System and method for forward error correction decoding using soft information
PL2148479T3 (pl) 2004-12-24 2013-04-30 Aspera Inc Transfer danych masowych
JP4391409B2 (ja) 2004-12-24 2009-12-24 株式会社第一興商 高能率符号化された時系列情報をリアルタイム・ストリーミング送信し受信再生する方法と受信装置
US8015306B2 (en) 2005-01-05 2011-09-06 Control4 Corporation Method and apparatus for synchronizing playback of streaming media in multiple output devices
EP1847087A1 (en) 2005-02-08 2007-10-24 Telefonaktiebolaget LM Ericsson (publ) On-demand multi-channel streaming session over packet-switched networks
US7925097B2 (en) 2005-02-18 2011-04-12 Sanyo Electric Co., Ltd. Image display method, image coding apparatus, and image decoding apparatus
US7822139B2 (en) 2005-03-02 2010-10-26 Rohde & Schwarz Gmbh & Co. Kg Apparatus, systems, methods and computer products for providing a virtual enhanced training sequence
US20090222873A1 (en) 2005-03-07 2009-09-03 Einarsson Torbjoern Multimedia Channel Switching
US8028322B2 (en) 2005-03-14 2011-09-27 Time Warner Cable Inc. Method and apparatus for network content download and recording
US7418649B2 (en) 2005-03-15 2008-08-26 Microsoft Corporation Efficient implementation of reed-solomon erasure resilient codes in high-rate applications
US7219289B2 (en) 2005-03-15 2007-05-15 Tandberg Data Corporation Multiply redundant raid system and XOR-efficient method and apparatus for implementing the same
US7450064B2 (en) * 2005-03-22 2008-11-11 Qualcomm, Incorporated Methods and systems for deriving seed position of a subscriber station in support of unassisted GPS-type position determination in a wireless communication system
JP4487028B2 (ja) 2005-03-31 2010-06-23 ブラザー工業株式会社 配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラム
US7715842B2 (en) 2005-04-09 2010-05-11 Lg Electronics Inc. Supporting handover of mobile terminal
CA2604203A1 (en) 2005-04-13 2006-10-19 Nokia Corporation Coding, storage and signalling of scalability information
KR100643291B1 (ko) * 2005-04-14 2006-11-10 삼성전자주식회사 랜덤 엑세스의 지연을 최소화하는 비디오 복부호화 장치 및방법
KR100703776B1 (ko) * 2005-04-19 2007-04-06 삼성전자주식회사 향상된 코딩 효율을 갖는 컨텍스트 기반 적응적 산술 코딩및 디코딩 방법과 이를 위한 장치, 이를 포함하는 비디오코딩 및 디코딩 방법과 이를 위한 장치
JP4515319B2 (ja) 2005-04-27 2010-07-28 株式会社日立製作所 コンピュータシステム
US7961700B2 (en) 2005-04-28 2011-06-14 Qualcomm Incorporated Multi-carrier operation in data transmission systems
US8683066B2 (en) * 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
JP2006319743A (ja) 2005-05-13 2006-11-24 Toshiba Corp 受信装置
US8228994B2 (en) 2005-05-20 2012-07-24 Microsoft Corporation Multi-view video coding based on temporal and view decomposition
JP2008543142A (ja) 2005-05-24 2008-11-27 ノキア コーポレイション デジタル放送における階層的な送受信のための方法および装置
US7676735B2 (en) 2005-06-10 2010-03-09 Digital Fountain Inc. Forward error-correcting (FEC) coding and streaming
US7644335B2 (en) 2005-06-10 2010-01-05 Qualcomm Incorporated In-place transformations with applications to encoding and decoding various classes of codes
JP2007013436A (ja) * 2005-06-29 2007-01-18 Toshiba Corp 符号化ストリーム再生装置
JP2007013675A (ja) 2005-06-30 2007-01-18 Sanyo Electric Co Ltd ストリーミング配信システム及びサーバ
US20070006274A1 (en) * 2005-06-30 2007-01-04 Toni Paila Transmission and reception of session packets
DE102005032080A1 (de) 2005-07-08 2007-01-11 Siemens Ag Verfahren zum Senden eines Mediadatenstroms und Verfahren zum Empfangen und Erstellen eines rekonstruierten Mediadatenstroms, sowie dazugehörige Sendevorrichtung und Empfangsvorrichtung
US7725593B2 (en) * 2005-07-15 2010-05-25 Sony Corporation Scalable video coding (SVC) file format
US20070022215A1 (en) 2005-07-19 2007-01-25 Singer David W Method and apparatus for media data transmission
JP2007036666A (ja) 2005-07-27 2007-02-08 Onkyo Corp コンテンツ配信システム、クライアント及びクライアントプログラム
US7912219B1 (en) * 2005-08-12 2011-03-22 The Directv Group, Inc. Just in time delivery of entitlement control message (ECMs) and other essential data elements for television programming
US20070044133A1 (en) 2005-08-17 2007-02-22 Hodecker Steven S System and method for unlimited channel broadcasting
EP1755248B1 (en) 2005-08-19 2011-06-22 Hewlett-Packard Development Company, L.P. Indication of lost segments across layer boundaries
WO2007028137A2 (en) 2005-09-01 2007-03-08 Nokia Corporation Method for embedding svg content into an iso base media file format for progressive downloading and streaming of rich media content
WO2007029443A1 (ja) * 2005-09-09 2007-03-15 Matsushita Electric Industrial Co., Ltd. 画像処理方法、画像記録方法、画像処理装置および画像ファイルフォーマット
US7924913B2 (en) 2005-09-15 2011-04-12 Microsoft Corporation Non-realtime data transcoding of multimedia content
US20070067480A1 (en) 2005-09-19 2007-03-22 Sharp Laboratories Of America, Inc. Adaptive media playout by server media processing for robust streaming
US8879856B2 (en) * 2005-09-27 2014-11-04 Qualcomm Incorporated Content driven transcoder that orchestrates multimedia transcoding using content information
US8078686B2 (en) 2005-09-27 2011-12-13 Siemens Product Lifecycle Management Software Inc. High performance file fragment cache
US20070078876A1 (en) * 2005-09-30 2007-04-05 Yahoo! Inc. Generating a stream of media data containing portions of media files using location tags
US7720062B2 (en) 2005-10-05 2010-05-18 Lg Electronics Inc. Method of processing traffic information and digital broadcasting system
US7164370B1 (en) * 2005-10-06 2007-01-16 Analog Devices, Inc. System and method for decoding data compressed in accordance with dictionary-based compression schemes
CN100442858C (zh) * 2005-10-11 2008-12-10 华为技术有限公司 分组网络中多媒体实时传输的唇同步方法及其装置
AU2006300881B2 (en) 2005-10-11 2011-03-17 Nokia Technologies Oy System and method for efficient scalable stream adaptation
US7720096B2 (en) 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
US8654848B2 (en) 2005-10-17 2014-02-18 Qualcomm Incorporated Method and apparatus for shot detection in video streaming
EP1946563A2 (en) 2005-10-19 2008-07-23 Thomson Licensing Multi-view video coding using scalable video coding
JP4727401B2 (ja) 2005-12-02 2011-07-20 日本電信電話株式会社 無線マルチキャスト伝送システム、無線送信装置及び無線マルチキャスト伝送方法
FR2894421B1 (fr) 2005-12-07 2008-01-18 Canon Kk Procede et dispositif de decodage d'un flux video code suivant un codage hierarchique
KR100759823B1 (ko) 2005-12-08 2007-09-18 한국전자통신연구원 제로 복귀 신호 발생 장치 및 그 방법
JP4456064B2 (ja) 2005-12-21 2010-04-28 日本電信電話株式会社 パケット送信装置、受信装置、システム、およびプログラム
US20070157267A1 (en) 2005-12-30 2007-07-05 Intel Corporation Techniques to improve time seek operations
ES2383230T3 (es) 2006-01-05 2012-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Gestión de archivos contenedores de medios
US8214516B2 (en) * 2006-01-06 2012-07-03 Google Inc. Dynamic media serving infrastructure
KR20070108433A (ko) 2006-01-09 2007-11-12 한국전자통신연구원 청크 디스크립터를 이용한 ｓｖｃ 파일포맷에서의 비디오데이터 공유방법
TWI432035B (zh) 2006-01-11 2014-03-21 Nokia Corp 可縮放視訊編碼之圖像反向相容聚合技術
JP5199124B2 (ja) 2006-01-12 2013-05-15 エルジー エレクトロニクス インコーポレイティド 多視点ビデオの処理
WO2007086654A1 (en) 2006-01-25 2007-08-02 Lg Electronics Inc. Digital broadcasting system and method of processing data
US7262719B2 (en) 2006-01-30 2007-08-28 International Business Machines Corporation Fast data stream decoding using apriori information
GB0602314D0 (en) 2006-02-06 2006-03-15 Ericsson Telefon Ab L M Transporting packets
US8990153B2 (en) 2006-02-07 2015-03-24 Dot Hill Systems Corporation Pull data replication model
EP1985022B1 (en) 2006-02-08 2011-06-08 Thomson Licensing Decoding of raptor codes
CN101686107B (zh) 2006-02-13 2014-08-13 数字方敦股份有限公司 使用可变fec开销和保护周期的流送和缓冲
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US20070200949A1 (en) 2006-02-21 2007-08-30 Qualcomm Incorporated Rapid tuning in multimedia applications
JP2007228205A (ja) 2006-02-23 2007-09-06 Funai Electric Co Ltd ネットワークサーバ
US20070220118A1 (en) 2006-03-15 2007-09-20 Loyer Douglas E Systems, Methods, and Apparatus for Delivering Randomly Accessible Audio and Video Media
US8320450B2 (en) 2006-03-29 2012-11-27 Vidyo, Inc. System and method for transcoding between scalable and non-scalable video codecs
WO2007127741A2 (en) 2006-04-24 2007-11-08 Sun Microsystems, Inc. Media server system
US20080010153A1 (en) 2006-04-24 2008-01-10 Pugh-O'connor Archie Computer network provided digital content under an advertising and revenue sharing basis, such as music provided via the internet with time-shifted advertisements presented by a client resident application
US7640353B2 (en) 2006-04-27 2009-12-29 Microsoft Corporation Guided random seek support for media streaming
US7948977B2 (en) 2006-05-05 2011-05-24 Broadcom Corporation Packet routing with payload analysis, encapsulation and service module vectoring
US7971129B2 (en) 2006-05-10 2011-06-28 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems
US7525993B2 (en) 2006-05-24 2009-04-28 Newport Media, Inc. Robust transmission system and method for mobile television applications
TWM302355U (en) * 2006-06-09 2006-12-11 Jia-Bau Jeng Fixation and cushion structure of knee joint
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9380096B2 (en) * 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US20100211690A1 (en) 2009-02-13 2010-08-19 Digital Fountain, Inc. Block partitioning for a data stream
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
JP2008011404A (ja) 2006-06-30 2008-01-17 Toshiba Corp コンテンツ処理装置及びコンテンツ処理方法
JP4392004B2 (ja) 2006-07-03 2009-12-24 インターナショナル・ビジネス・マシーンズ・コーポレーション パケット回復のための符号化および復号化技術
CN102148857A (zh) 2006-07-20 2011-08-10 桑迪士克股份有限公司 内容分布系统
GB0614891D0 (en) * 2006-07-27 2006-09-06 Univ Southampton Plasmon-enhanced photo voltaic cell
US7711797B1 (en) 2006-07-31 2010-05-04 Juniper Networks, Inc. Optimizing batch size for prefetching data over wide area networks
US8209736B2 (en) * 2006-08-23 2012-06-26 Mediatek Inc. Systems and methods for managing television (TV) signals
AU2007287222A1 (en) 2006-08-24 2008-02-28 Nokia Corporation System and method for indicating track relationships in media files
US20080066136A1 (en) 2006-08-24 2008-03-13 International Business Machines Corporation System and method for detecting topic shift boundaries in multimedia streams using joint audio, visual and text cues
WO2008033060A1 (en) 2006-09-15 2008-03-20 Obigo Ab Method and device for controlling a multimedia presentation device
JP2008109637A (ja) 2006-09-25 2008-05-08 Toshiba Corp 動画像符号化装置及びその方法
US8015556B2 (en) * 2006-10-12 2011-09-06 International Business Machines Corporation Efficient method of data reshaping for multidimensional dynamic array objects in the presence of multiple object instantiations
CN1968390A (zh) 2006-10-19 2007-05-23 李卫红 一种数字视频的分级编码及播放系统
WO2008054112A2 (en) * 2006-10-30 2008-05-08 Lg Electronics Inc. Methods of performing random access in a wireless communication system
US20080104170A1 (en) 2006-10-31 2008-05-01 Microsoft Corporation Collaborative Networks for Parallel Downloads of Content
JP2008118221A (ja) 2006-10-31 2008-05-22 Toshiba Corp 復号装置及び復号方法
WO2008054100A1 (en) 2006-11-01 2008-05-08 Electronics And Telecommunications Research Institute Method and apparatus for decoding metadata used for playing stereoscopic contents
AU2007319261B2 (en) 2006-11-14 2010-12-16 Qualcomm Incorporated Systems and methods for channel switching
US8035679B2 (en) 2006-12-12 2011-10-11 Polycom, Inc. Method for creating a videoconferencing displayed image
US8027328B2 (en) 2006-12-26 2011-09-27 Alcatel Lucent Header compression in a wireless communication network
CN103559165B (zh) 2007-01-05 2016-08-17 索尼克知识产权股份有限公司 包含连续播放的视频分配系统
US20080168516A1 (en) 2007-01-08 2008-07-10 Christopher Lance Flick Facilitating Random Access In Streaming Content
WO2008084348A1 (en) 2007-01-09 2008-07-17 Nokia Corporation Method for supporting file versioning in mbms file repair
CA2656144A1 (en) 2007-01-11 2008-07-17 Panasonic Corporation Method for trick playing on streamed and encrypted multimedia
US20080172430A1 (en) 2007-01-11 2008-07-17 Andrew Thomas Thorstensen Fragmentation Compression Management
CN101543018B (zh) 2007-01-12 2012-12-26 庆熙大学校产学协力团 网络提取层单元的分组格式、使用该格式的视频编解码算法和装置以及使用该格式进行IPv6标签交换的QoS控制算法和装置
KR20080066408A (ko) 2007-01-12 2008-07-16 삼성전자주식회사 3차원 영상 처리 장치 및 방법
US8126062B2 (en) 2007-01-16 2012-02-28 Cisco Technology, Inc. Per multi-block partition breakpoint determining for hybrid variable length coding
EP2835951B1 (en) 2007-01-17 2018-08-22 Intertrust Technologies Corporation Methods, systems, and apparatus for fragmented file sharing
US7721003B2 (en) 2007-02-02 2010-05-18 International Business Machines Corporation System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client
US7805456B2 (en) 2007-02-05 2010-09-28 Microsoft Corporation Query pattern to enable type flow of element types
US20080192818A1 (en) 2007-02-09 2008-08-14 Dipietro Donald Vincent Systems and methods for securing media
CN101611612A (zh) 2007-02-23 2009-12-23 诺基亚公司 聚合媒体数据单元的向后兼容特性
US20080232357A1 (en) 2007-03-19 2008-09-25 Legend Silicon Corp. Ls digital fountain code
CN101271454B (zh) 2007-03-23 2012-02-08 百视通网络电视技术发展有限责任公司 用于iptv的多媒体内容联合搜索与关联引擎系统
JP4838191B2 (ja) 2007-05-08 2011-12-14 シャープ株式会社 ファイル再生装置、ファイル再生方法、ファイル再生を実行させるプログラム及びそのプログラムを記録した記録媒体
JP2008283571A (ja) 2007-05-11 2008-11-20 Ntt Docomo Inc コンテンツ配信装置、コンテンツ配信システム、およびコンテンツ配信方法
WO2008140261A2 (en) 2007-05-14 2008-11-20 Samsung Electronics Co., Ltd. Broadcasting service transmitting apparatus and method and broadcasting service receiving apparatus and method for effectively accessing broadcasting service
CN101309200A (zh) 2007-05-14 2008-11-19 中兴通讯股份有限公司 多媒体数据播放系统
BRPI0811117A2 (pt) 2007-05-16 2014-12-23 Thomson Licensing Aparelho e método para codificar e decodificar sinais
FR2917262A1 (fr) 2007-06-05 2008-12-12 Thomson Licensing Sas Dispositif et procede de codage d'un contenu video sous la forme d'un flux scalable.
US8487982B2 (en) 2007-06-07 2013-07-16 Reald Inc. Stereoplexing for film and video applications
US8274551B2 (en) 2007-06-11 2012-09-25 Samsung Electronics Co., Ltd. Method and apparatus for generating header information of stereoscopic image data
CN101690118B (zh) 2007-06-20 2013-08-28 艾利森电话股份有限公司 用于改进的媒体会话管理的方法和设备
KR20100030648A (ko) * 2007-06-26 2010-03-18 노키아 코포레이션 시간 레이어 스위칭 포인트들을 표시하는 시스템 및 방법
US7917702B2 (en) * 2007-07-10 2011-03-29 Qualcomm Incorporated Data prefetch throttle
US8156164B2 (en) 2007-07-11 2012-04-10 International Business Machines Corporation Concurrent directory update in a cluster file system
JP2009027598A (ja) 2007-07-23 2009-02-05 Hitachi Ltd 映像配信サーバおよび映像配信方法
CN101365096B (zh) 2007-08-09 2012-05-23 华为技术有限公司 提供视频内容的方法及相关业务设备和系统
EP2026470A1 (en) 2007-08-17 2009-02-18 Panasonic Corporation Running cyclic redundancy check over coding segments
US8327403B1 (en) 2007-09-07 2012-12-04 United Video Properties, Inc. Systems and methods for providing remote program ordering on a user device via a web server
US9237101B2 (en) * 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
CN101127898A (zh) 2007-09-20 2008-02-20 Ut斯达康通讯有限公司 流媒体系统及其多媒体文件的切片存储和流服务方法
US8233532B2 (en) 2007-09-21 2012-07-31 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Information signal, apparatus and method for encoding an information content, and apparatus and method for error correcting an information signal
CN101286157A (zh) * 2007-09-28 2008-10-15 深圳市天朗时代科技有限公司 一种文件检索方法及装置和时间流文件处理器
US8346959B2 (en) * 2007-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Client-controlled adaptive streaming
CN101136924B (zh) 2007-09-29 2011-02-09 中兴通讯股份有限公司 一种下一代网络中主叫身份标识显示的方法
EP2046044B1 (en) 2007-10-01 2017-01-18 Cabot Communications Ltd A method and apparatus for streaming digital media content and a communication system
WO2009048277A2 (en) 2007-10-09 2009-04-16 Samsung Electronics Co., Ltd. Apparatus and method for generating and parsing mac pdu in a mobile communication system
CN101409630A (zh) 2007-10-11 2009-04-15 北京大学 一种流媒体数据发送接收方法、装置及系统
WO2009054907A2 (en) 2007-10-19 2009-04-30 Swarmcast, Inc. Media playback point seeking using data range requests
US8706907B2 (en) 2007-10-19 2014-04-22 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US7895629B1 (en) 2007-11-07 2011-02-22 At&T Mobility Ii Llc Video service buffer management in a mobile rate control enabled network
US20090125636A1 (en) 2007-11-13 2009-05-14 Qiong Li Payload allocation methods for scalable multimedia servers
EP2215595B1 (en) 2007-11-23 2012-02-22 Media Patents S.L. A process for the on-line distribution of audiovisual contents with advertisements, advertisement management system, digital rights management system and audiovisual content player provided with said systems
WO2009075766A2 (en) 2007-12-05 2009-06-18 Swarmcast, Inc. Dynamic bit rate scaling
TWI355168B (en) 2007-12-07 2011-12-21 Univ Nat Chiao Tung Application classification method in network traff
JP5385598B2 (ja) 2007-12-17 2014-01-08 キヤノン株式会社 画像処理装置及び画像管理サーバ装置及びそれらの制御方法及びプログラム
JP2009152821A (ja) * 2007-12-20 2009-07-09 Sharp Corp 地上デジタル放送受信装置
US9313245B2 (en) 2007-12-24 2016-04-12 Qualcomm Incorporated Adaptive streaming for on demand wireless services
CN101197840A (zh) 2007-12-29 2008-06-11 深圳市迅雷网络技术有限公司 下载和存储文件的方法、系统、装置及生成标识的方法
CN101217553A (zh) 2008-01-15 2008-07-09 中兴通讯股份有限公司 一种媒体流的随机访问处理方法
CN101222616B (zh) 2008-01-22 2011-08-10 中兴通讯股份有限公司 点播服务中的mpeg传送流的传输处理方法
KR101506217B1 (ko) 2008-01-31 2015-03-26 삼성전자주식회사 스테레오스코픽 영상의 부분 데이터 구간 재생을 위한스테레오스코픽 영상 데이터스트림 생성 방법과 장치, 및스테레오스코픽 영상의 부분 데이터 구간 재생 방법과 장치
EP2086237B1 (en) 2008-02-04 2012-06-27 Alcatel Lucent Method and device for reordering and multiplexing multimedia packets from multimedia streams pertaining to interrelated sessions
US8151174B2 (en) 2008-02-13 2012-04-03 Sunrise IP, LLC Block modulus coding (BMC) systems and methods for block coding with non-binary modulus
KR101169160B1 (ko) 2008-02-27 2012-07-30 쿄세라 코포레이션 무선 통신 장치
US20090219985A1 (en) 2008-02-28 2009-09-03 Vasanth Swaminathan Systems and Methods for Processing Multiple Projections of Video Data in a Single Video File
US7984097B2 (en) 2008-03-18 2011-07-19 Media Patents, S.L. Methods for transmitting multimedia files and advertisements
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US20090257508A1 (en) 2008-04-10 2009-10-15 Gaurav Aggarwal Method and system for enabling video trick modes
JP5221753B2 (ja) 2008-04-14 2013-06-26 エルジー エレクトロニクス インコーポレイティド ランダムアクセス手順を行う方法及び装置
WO2009127961A1 (en) * 2008-04-16 2009-10-22 Nokia Corporation Decoding order recovery in session multiplexing
WO2009130561A1 (en) * 2008-04-21 2009-10-29 Nokia Corporation Method and device for video coding and decoding
US20100017686A1 (en) 2008-05-07 2010-01-21 Michael Luby Fast channel zapping and high quality streaming protection over a broadcast channel
US7979570B2 (en) 2008-05-12 2011-07-12 Swarmcast, Inc. Live media delivery over a packet-based computer network
JP5022301B2 (ja) 2008-05-19 2012-09-12 株式会社エヌ・ティ・ティ・ドコモ プロキシサーバおよび通信中継プログラム、並びに通信中継方法
CN101287107B (zh) * 2008-05-29 2010-10-13 腾讯科技（深圳）有限公司 媒体文件的点播方法、系统和设备
US7925774B2 (en) 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
US20100011274A1 (en) * 2008-06-12 2010-01-14 Qualcomm Incorporated Hypothetical fec decoder and signalling for decoding control
US8775566B2 (en) 2008-06-21 2014-07-08 Microsoft Corporation File format for media distribution and presentation
US8387150B2 (en) * 2008-06-27 2013-02-26 Microsoft Corporation Segmented media content rights management
US8468426B2 (en) 2008-07-02 2013-06-18 Apple Inc. Multimedia-aware quality-of-service and error correction provisioning
US8539092B2 (en) 2008-07-09 2013-09-17 Apple Inc. Video streaming using multiple channels
US20100153578A1 (en) 2008-07-16 2010-06-17 Nokia Corporation Method and Apparatus for Peer to Peer Streaming
JP2010046838A (ja) * 2008-08-20 2010-03-04 Brother Ind Ltd 画像記録装置
US8638796B2 (en) 2008-08-22 2014-01-28 Cisco Technology, Inc. Re-ordering segments of a large number of segmented service flows
KR101019634B1 (ko) 2008-09-04 2011-03-07 에스케이 텔레콤주식회사 미디어 전송 시스템 및 방법
US9355076B2 (en) 2008-09-05 2016-05-31 Thomson Licensing Method and system for dynamic play list modification
US8325796B2 (en) 2008-09-11 2012-12-04 Google Inc. System and method for video coding using adaptive segmentation
US8265140B2 (en) 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
JP5163415B2 (ja) 2008-10-07 2013-03-13 富士通株式会社 階層型変調方法、階層型復調方法、階層型変調を行う送信装置、階層型復調を行う受信装置
CN101388909A (zh) 2008-10-14 2009-03-18 中兴通讯股份有限公司 一种p2p点播系统和业务方法
US8370520B2 (en) 2008-11-24 2013-02-05 Juniper Networks, Inc. Adaptive network content delivery system
US20100169303A1 (en) * 2008-12-31 2010-07-01 David Biderman Playlists for real-time or near real-time streaming
BRPI0923917B1 (pt) 2008-12-31 2021-05-25 Apple Inc Método implementado por máquina, meio de armazenamento não transitório legível por máquina, aparelho, e sistema de processamento de dados para transmissão contínua em tempo real ou próximo ao tempo real
US8743906B2 (en) 2009-01-23 2014-06-03 Akamai Technologies, Inc. Scalable seamless digital video stream splicing
WO2010085361A2 (en) 2009-01-26 2010-07-29 Thomson Licensing Frame packing for video coding
CN102342127A (zh) * 2009-01-28 2012-02-01 诺基亚公司 用于视频编码和解码的方法和装置
JP5406942B2 (ja) 2009-01-29 2014-02-05 ドルビー ラボラトリーズ ライセンシング コーポレイション 立体画像である複数の画像をサブサンプリング及びインタリーブする方法及び装置
JP2010192944A (ja) * 2009-02-13 2010-09-02 Sony Corp コンテンツ配信装置、コンテンツ利用装置、コンテンツ配信システム、コンテンツ配信方法、およびプログラム
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US8621044B2 (en) 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
EP2420068A4 (en) 2009-04-13 2012-08-08 Reald Inc ENCRYPTION, DECOMPOSITION AND DISTRIBUTION OF STEREOSCOPIC VIDEO CONTENT WITH REINFORCED RESOLUTION
US9807468B2 (en) 2009-06-16 2017-10-31 Microsoft Technology Licensing, Llc Byte range caching
US9680892B2 (en) * 2009-06-26 2017-06-13 Adobe Systems Incorporated Providing integration of multi-bit-rate media streams
US8484152B2 (en) 2009-06-26 2013-07-09 Hbgary, Inc. Fuzzy hash algorithm
US8903895B2 (en) 2009-07-22 2014-12-02 Xinlab, Inc. Method of streaming media to heterogeneous client devices
CN101989977B (zh) 2009-08-04 2013-08-07 华为技术有限公司 富媒体实时业务实现的方法、设备、服务器和系统
US8355433B2 (en) 2009-08-18 2013-01-15 Netflix, Inc. Encoding video streams for adaptive video streaming
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US20120151302A1 (en) 2010-12-10 2012-06-14 Qualcomm Incorporated Broadcast multimedia storage and access using page maps when asymmetric memory is used
CN102835150B (zh) 2009-09-02 2015-07-15 苹果公司 用于无线系统的mac分组数据单元构造
WO2011034955A2 (en) 2009-09-15 2011-03-24 Comcast Cable Communications, Llc Control plane architecture for multicast cache-fill
US20110096828A1 (en) 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US9237387B2 (en) 2009-10-06 2016-01-12 Microsoft Technology Licensing, Llc Low latency cacheable media streaming
US9438861B2 (en) 2009-10-06 2016-09-06 Microsoft Technology Licensing, Llc Integrating continuous and sparse streaming data
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US8914835B2 (en) 2009-10-28 2014-12-16 Qualcomm Incorporated Streaming encoded video data
CN102598691B (zh) 2009-11-03 2015-02-18 瑞典爱立信有限公司 利用数据分段的可选广播传送的流传输
BR112012011581A2 (pt) 2009-11-04 2017-09-19 Huawei Tech Co Ltd sistema e método para streaming de conteúdo de mídia
KR101786050B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 전송 방법 및 장치
KR101786051B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치
CN101729857A (zh) 2009-11-24 2010-06-09 中兴通讯股份有限公司 一种接入视频服务的方法及视频播放系统
CA2783592A1 (en) 2009-12-11 2011-06-16 Nokia Corporation Apparatus and methods for describing and timing representations in streaming media files
EP2526671B1 (en) 2010-01-18 2016-11-16 Telefonaktiebolaget LM Ericsson (publ) Methods and arrangements for http media stream distribution
RU2690755C2 (ru) 2010-02-19 2019-06-05 Телефонактиеболагет Л М Эрикссон (Пабл) Способ и устройство для переключения воспроизведений в потоковой передаче по протоколу передачи гипертекста
KR101624013B1 (ko) 2010-02-19 2016-05-24 텔레폰악티에볼라겟엘엠에릭슨(펍) 에이치티티피 스트리밍에서 적응화를 위한 방법 및 장치
JP5071495B2 (ja) 2010-03-04 2012-11-14 ウシオ電機株式会社 光源装置
ES2845643T3 (es) 2010-03-11 2021-07-27 Electronics & Telecommunications Res Inst Método y aparato de emisión y recepción de datos en un sistema MIMO
US8667164B2 (en) 2010-04-26 2014-03-04 Samsung Electronics Co., Ltd. Method and apparatus for playing live content
US20110280311A1 (en) 2010-05-13 2011-11-17 Qualcomm Incorporated One-stream coding for asymmetric stereo video
US9497290B2 (en) 2010-06-14 2016-11-15 Blackberry Limited Media presentation description delta file for HTTP streaming
CN103098484A (zh) 2010-06-14 2013-05-08 汤姆森许可贸易公司 用于封装编码多组件视频的方法和装置
CN102291373B (zh) 2010-06-15 2016-08-31 华为技术有限公司 元数据文件的更新方法、装置和系统
EP2585947A1 (en) 2010-06-23 2013-05-01 Telefónica, S.A. A method for indexing multimedia information
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) * 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
KR20120010089A (ko) 2010-07-20 2012-02-02 삼성전자주식회사 Ｈｔｔｐ 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
US9131033B2 (en) * 2010-07-20 2015-09-08 Qualcomm Incoporated Providing sequence data sets for streaming video data
US9596447B2 (en) * 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9716920B2 (en) 2010-08-05 2017-07-25 Qualcomm Incorporated Signaling attributes for network-streamed video data
US8711933B2 (en) 2010-08-09 2014-04-29 Sony Computer Entertainment Inc. Random access point (RAP) formation using intra refreshing technique in video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
KR101737325B1 (ko) * 2010-08-19 2017-05-22 삼성전자주식회사 멀티미디어 시스템에서 멀티미디어 서비스의 경험 품질 감소를 줄이는 방법 및 장치
EP2614653A4 (en) 2010-09-10 2015-04-15 Nokia Corp METHOD AND APPARATUS FOR ADAPTIVE CONTINUOUS DIFFUSION
KR101206698B1 (ko) 2010-10-06 2012-11-30 한국항공대학교산학협력단 스트리밍 콘텐츠 제공 장치 및 방법
US8615023B2 (en) 2010-10-27 2013-12-24 Electronics And Telecommunications Research Institute Apparatus and method for transmitting/receiving data in communication system
WO2012093202A1 (en) 2011-01-07 2012-07-12 Nokia Corporation Method and apparatus for signaling presentation
KR101739272B1 (ko) 2011-01-18 2017-05-24 삼성전자주식회사 멀티미디어 스트리밍 시스템에서 컨텐트의 저장 및 재생을 위한 장치 및 방법
US9661104B2 (en) 2011-02-07 2017-05-23 Blackberry Limited Method and apparatus for receiving presentation metadata
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US20120208580A1 (en) 2011-02-11 2012-08-16 Qualcomm Incorporated Forward error correction scheduling for an improved radio link protocol
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US8849950B2 (en) 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US9590814B2 (en) 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6332163B1 (en) * 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
RU2297663C2 (ru) * 2001-11-29 2007-04-20 Нокиа Корпорейшн Система и способ идентификации и доступа к услугам сети
RU2290768C1 (ru) * 2006-01-30 2006-12-27 Общество с ограниченной ответственностью "Трафиклэнд" Система медиавещания в инфраструктуре оператора мобильной связи

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2640628C2 (ru) * 2015-08-13 2018-01-10 Сяоми Инк. Способ и устройство для представления мультимедийной информации
RU2656689C2 (ru) * 2016-11-08 2018-06-06 Федеральное государственное казенное военное образовательное учреждение высшего образования "Краснодарское высшее военное училище имени генерала армии С.М. Штеменко" Министерство обороны Российской Федерации Способ мультипоточного шифрования информации и устройство для его осуществления

Also Published As

Publication number Publication date
JP5666598B2 (ja) 2015-02-12
EP2481197A2 (en) 2012-08-01
JP2022070940A (ja) 2022-05-13
CN102577411B (zh) 2016-06-29
CA2854011A1 (en) 2011-03-31
JP2018088679A (ja) 2018-06-07
BR112012006374B1 (pt) 2021-07-20
JP6254208B2 (ja) 2017-12-27
CA2854017C (en) 2017-11-21
MY163822A (en) 2017-10-31
US9432433B2 (en) 2016-08-30
CA2854008C (en) 2017-06-27
US20220247807A1 (en) 2022-08-04
CN102577411A (zh) 2012-07-11
PT2481197T (pt) 2019-07-09
CA2854008A1 (en) 2011-03-31
JP7024125B2 (ja) 2022-02-22
WO2011038013A3 (en) 2011-08-11
JP2016174363A (ja) 2016-09-29
JP6852121B2 (ja) 2021-03-31
JP7352673B2 (ja) 2023-09-28
JP2015053677A (ja) 2015-03-19
KR101456987B1 (ko) 2014-11-04
KR101562274B1 (ko) 2015-10-21
CA2854017A1 (en) 2011-03-31
KR20140004262A (ko) 2014-01-10
CA2774923A1 (en) 2011-03-31
JP2021073774A (ja) 2021-05-13
PL2481197T3 (pl) 2019-09-30
CA2774923C (en) 2016-04-19
JP6685989B2 (ja) 2020-04-22
BR112012006374A2 (pt) 2017-07-18
CA2854011C (en) 2016-11-29
KR20140069368A (ko) 2014-06-09
WO2011038013A2 (en) 2011-03-31
EP2481197B1 (en) 2019-04-10
US20110238789A1 (en) 2011-09-29
DK2481197T3 (da) 2019-07-22
ES2734257T3 (es) 2019-12-05
JP2019205175A (ja) 2019-11-28
US11477253B2 (en) 2022-10-18
KR20120080208A (ko) 2012-07-16
HUE044122T2 (hu) 2019-09-30
RU2012116086A (ru) 2013-10-27
KR101395193B1 (ko) 2014-05-15
JP5911926B2 (ja) 2016-04-27
ZA201202935B (en) 2012-12-27
SI2481197T1 (sl) 2019-05-31
KR20140069369A (ko) 2014-06-09
US20160323342A1 (en) 2016-11-03
US11770432B2 (en) 2023-09-26
JP2013505680A (ja) 2013-02-14
KR101534576B1 (ko) 2015-07-09

Similar Documents

Publication Publication Date Title
US11770432B2 (en) Enhanced block-request streaming system for handling low-latency streaming
US11743317B2 (en) Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
KR101741484B1 (ko) 저-레이턴시 스트림을 처리하기 위한 개선된 블록-요청 스트리밍 시스템
RU2577473C2 (ru) Улучшенная потоковая передача по запросу блоков с использованием шаблонов и правил составления url
KR101456957B1 (ko) 협력 병렬 ｈｔｔｐ 및 순방향 에러 정정을 사용하여 향상된 블록-요청 스트리밍
CN114401420B (zh) 使用可伸缩编码的增强型块请求流送
US9380096B2 (en) Enhanced block-request streaming system for handling low-latency streaming