Поліпшена потокова передача по запиту блоків з використанням шаблонів і правил складання url

Реферат: Система потокової передачі по запиту блоків забезпечує поліпшення у взаємодії з користувачем і в ефективності смуги пропускання в таких системах, звичайно використовуючи систему захоплення, яка формує дані у вигляді, придатному для використання традиційним файловим сервером (HTTP, FTP або т. п.), причому система захоплення приймає контент і готує його у вигляді файлів або елементів даних, придатних для використання файловим сервером, який міг би включати в себе кеш. Клієнтський пристрій можна пристосувати для отримання вигоди від процесу захоплення, а також поліпшень, які сприяють кращому представленню незалежно від процесу захоплення. Клієнтські пристрої і система захоплення UA 108083 C2 (12) UA 108083 C2 можуть бути узгоджені в наявності заздалегідь певного перетворення і шаблона для виконання запитів блоків до файлових імен HTTP, які традиційний файловий сервер може приймати за допомогою використання правил складання URL. Розмір сегмента міг би задаватися приблизним чином для ефективнішої організації. UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 ПЕРЕХРЕСНІ ПОСИЛАННЯ НА СПОРІДНЕНІ ЗАЯВКИ Дана заявка є заявкою на патент, яка заявляє перевагу нижченаведених попередніх заявок, причому кожна має авторство Michael G. Luby (Майкл Дж. Лубі) та ін. і кожна називається "Enhanced Block-Request Streaming System": Попередня патентна заявка США № 61/244767, подана 22 вересня 2009 р. Попередня патентна заявка США № 61/257719, подана 3 листопада 2009 р. Попередня патентна заявка США № 61/258088, подана 4 листопада 2009 р. Попередня патентна заявка США № 61/285779, подана 11 грудня 2009 р., і Попередня патентна заявка США № 61/296725, подана 20 січня 2010 р. Дана заявка також заявляє перевагу Попередньої патентної заявки США № 61/372399, поданої 10 серпня 2010 року під авторством Ying Chen (Ін Чень) та ін. і озаглавленої "HTTP Streaming Extensions". Кожна попередня заявка, згадана вище, даним включається в цей документ шляхом відсилання у всіх відношеннях. Дане розкриття винаходу також включає в себе шляхом відсилання, як якби вони були повністю викладені в цьому документі у всіх відношеннях, наступні заявки/патенти, що належать тому ж правовласнику: Патент США № 6307487, виданий Luby (в подальшому "Luby I"); Патент США № 7068729, виданий Shokrollahi та ін. (в подальшому "Shokrollahi I"); Заявка на патент США № 11/423391, подана 9 червня 2006 р. і озаглавлена "Forward ErrorCorrecting (FEC) Coding and Streaming" під авторством Luby та ін. (в подальшому "Luby II"); Заявка на патент США № 12/103605, подана 15 квітня 2008 р., озаглавлена "Dynamic Stream Interleaving and Sub-Stream Based Delivery" під авторством Luby та ін. (в подальшому "Luby III"); Заявка на патент США № 12/705202, подана 12 лютого 2010 р., озаглавлена "Block Partitioning for а Data Stream" під авторством Pakzad та ін. (в подальшому "Pakzad"); і Заявка на патент США № 12/859161, подана 18 серпня 2010 р., озаглавлена "Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" під авторством Luby та ін. (в подальшому "Luby IV"). ГАЛУЗЬ ТЕХНІКИ, ДО ЯКОЇ НАЛЕЖИТЬ ВИНАХІД Даний винахід стосується поліпшених систем і способів мультимедійної потокової передачі, а конкретніше, систем і способів, які пристосовуються до умов мережі і буфера, щоб оптимізувати представлення потокового мультимедіа і дозволити ефективну одночасну, або розподілену у часі, доставку потокових мультимедійних даних. РІВЕНЬ ТЕХНІКИ ВИНАХОДУ Доставка потокових мультимедійних даних може стати все більш і більш важливою, оскільки вона стає загальноприйнятою для високоякісного звуку і відеозображення, які треба доставити по мережах на основі пакетів, наприклад Інтернету, стільникових і бездротових мережах, мережах в лініях електропередач та інших типах мереж. Якість, з якою можна представити доставлене потокове мультимедіа, може залежати від деякої кількості факторів, включаючи розділення (або інші атрибути) вихідного контенту, якість кодування вихідного контенту, можливості приймальних пристроїв по декодуванню і представленню мультимедіа, своєчасність і якість сигналу, прийнятого в приймачах, і т. д. Щоб створити хороше враження від потокового мультимедіа, що сприймається, можуть бути особливо важливі транспорт і своєчасність сигналу, прийнятого в приймачах. Хороший транспорт може забезпечити точність прийнятого в приймачі потоку відносно того, що відправляє відправник, тоді як своєчасність може представляти те, як швидко приймач може почати відтворення контенту після початкового запиту того контенту. Систему доставки мультимедіа можна охарактеризувати як систему, що має джерела мультимедіа, призначення мультимедіа і канали (у часі і/або в просторі), розділювальні джерела і призначення. Звичайно джерело включає в себе передавач з доступом до мультимедіа з керуванням в електронному вигляді, а приймач має можливість електронного керування прийомом мультимедіа (або його наближення) і надавання його споживачеві мультимедіа (наприклад, користувачеві, що має пристрій відображення, з'єднаний деяким способом з приймачем, запам'ятовуючим пристроєм або елементом, іншим каналом і т. д.). Хоч можливо багато варіантів, в загальному прикладі система доставки мультимедіа містить один або декілька серверів, які мають доступ до мультимедійного контенту в електронному вигляді, і одна або декілька клієнтських систем або пристроїв створюють запити мультимедіа до серверів, а сервери передають мультимедіа з використанням передавача як частини сервера, що передає до приймача у клієнта, щоб клієнт міг використати прийняте мультимедіа деяким способом. У простому прикладі є один сервер і один клієнт для заданого запиту і відповіді, але це не обов'язково так. 1 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 Традиційно системи доставки мультимедіа можна описати або моделлю "завантаження", або моделлю "потокової передачі". Модель "завантаження" могла б відрізнятися часовою незалежністю між доставкою мультимедійних даних і відтворенням мультимедіа користувачеві або пристрою-одержувачу. Як приклад мультимедіа завантажується в достатній кількості заздалегідь, коли воно потрібне або буде використовуватися, а коли воно використовується, воно вже доступне якраз в потрібній кількості у одержувача. Доставка в контексті завантаження часто виконується з використанням протоколу транспортування файлів, наприклад HTTP, FTP або Доставки файлів односпрямованим транспортом (FLUTE), і швидкість доставки можна було б визначити по потоку, що лежить в основі, і/або протоколу відстеження перевантажень, наприклад TCP/IP. Робота потоку або протоколу відстеження перевантажень може не залежати від відтворення мультимедіа користувачу або пристрою призначення, що може відбуватися одночасно із завантаженням або в який-небудь інший час. Режим "потокової передачі" міг би відрізнятися сильним зв'язком між моментом доставки мультимедійних даних і відтворенням мультимедіа користувачеві або пристрою-одержувачу. Доставка в цьому контексті часто виконується з використанням протоколу потокової передачі, наприклад Потокового протоколу реального часу (RTSP) для керування і Транспортного протоколу в режимі реального часу (RTP) для мультимедійних даних. Швидкість доставки можна було б визначити за допомогою сервера потокової передачі, часто вона співпадає зі швидкістю відтворення даних. Деякі недоліки моделі "завантаження" можуть полягати в тому, що через часову незалежність доставки і відтворення, мультимедійні дані можуть бути або не доступні, коли вони потрібні для відтворення (наприклад, через те, що доступна смуга пропускання менша швидкості передачі мультимедійних даних), спричиняючи припинення відтворення на мить ("зупинка"), що призводить до поганої взаємодії з користувачем, або мультимедійні дані потрібно буде завантажити набагато раніше відтворення (наприклад, через те, що доступна смуга пропускання більша швидкості передачі мультимедійних даних), споживаючи ресурси зберігання на приймальному пристрої, які можуть бути дефіцитними, і споживаючи цінні мережеві ресурси для доставки, які можуть розтрачуватися марно, якщо контент зрештою не відтворюється або використовується іншим чином. Перевага моделі "завантаження" може полягати в тому, що технологія, необхідна для виконання таких завантажень, наприклад HTTP, дуже зріла, широко використовується і застосовна до широкого діапазону додатків. Сервери завантаження і рішення для широкої масштабованості таких завантажень файлів (наприклад, Веб-сервери HTTP і Мережі доставки контенту) можуть бути легко доступні, роблячи розгортання послуг на основі цієї технології простим і недорогим. Деякі недоліки моделі "потокової передачі" можуть полягати в тому, що звичайно швидкість доставки мультимедійних даних не пристосовується до доступної смуги пропускання у з'єднанні від сервера до клієнта, і що необхідні спеціалізовані потокові сервери або складніша мережева архітектура, що забезпечує смугу пропускання і гарантії затримки. Хоч існують системи потокової передачі, які підтримують зміну швидкості доставки даних відповідно до доступної смуги пропускання (наприклад, Adobe Flash Adaptive Streaming), вони звичайно не так ефективні, як протоколи керування транспортними потоками завантаження, наприклад TCP, при використанні всієї доступної смуги пропускання. Останнім часом розроблені і розгорнені нові системи доставки мультимедіа на основі поєднання моделей "потокової передачі" і "завантаження". Приклад такої моделі в цьому документі називається моделлю "потокової передачі по запиту блоків", в якій клієнт мультимедіа запитує блоки мультимедійних даних в обслуговуючої інфраструктури з використанням протоколу завантаження, наприклад HTTP. Питанням в таких системах може бути можливість почати відтворення потоку, наприклад декодування і візуалізацію прийнятих аудіо- і відеопотоків з використанням персонального комп'ютера і відображення відеозображення на екрані комп'ютера і відтворення звуку через вбудовані динаміки, або, як інший приклад, декодування і візуалізацію прийнятих аудіо- і відеопотоків з використанням телевізійної приставки і відображення відеозображення на телевізійному пристрої відображення і відтворення звуку через стереосистему. Інші питання, наприклад, здатність декодувати вихідні блоки досить швидко, щоб не відставати від швидкості потокової передачі джерела, мінімізувати затримку декодування і зменшити використання доступних ресурсів CPU, є проблемами. Іншим питанням є надавання стійкого і масштабованого рішення по потоковій доставці, яке дозволяє виходити з ладу компонентам системи без несприятливого впливу на якість потоків, доставлених приймачам. 2 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 Інші проблеми могли б виникнути на основі швидко змінюваної інформації про представлення, коли вона поширюється. Таким чином, бажано мати вдосконалені процеси і пристрій. СУТЬ ВИНАХОДУ Система потокової передачі по запиту блоків забезпечує поліпшення у взаємодії з користувачем і в ефективності смуги пропускання в таких системах, звичайно використовуючи систему захоплення, яка формує дані у вигляді для використання традиційним файловим сервером (HTTP, FTP або т. п.), причому система захоплення приймає контент і готує його у вигляді файлів або елементів даних для використання файловим сервером, який міг би включати в себе або не включати кеш. Клієнтський пристрій можна пристосувати для отримання вигоди від процесу захоплення, також включаючи поліпшення, які сприяють кращому представленню незалежно від процесу захоплення. В одній особливості клієнтські пристрої і система захоплення узгоджені в тому, що є заздалегідь визначене перетворення і шаблон для виконання запитів блоків до файлових імен HTTP, які традиційний файловий сервер може приймати за допомогою використання правил складання URL. У деяких варіантах здійснення надаються нові поліпшення до способів для задавання розміру сегмента приблизним чином для ефективнішої організації. Нижченаведений докладний опис винаходу разом з прикладеними кресленнями забезпечить повніше розуміння предмета і переваг даного винаходу. КОРОТКИЙ ОПИС КРЕСЛЕНЬ Фіг. 1 зображає елементи системи потокової передачі по запиту блоків відповідно до варіантів здійснення даного винаходу. Фіг. 2 ілюструє систему потокової передачі по запиту блоків з фіг. 1, показуючи більше подробиць в елементах клієнтської системи, яка з'єднується з обслуговуючою інфраструктурою блоків ("BSI") для прийому даних, які обробляються системою захоплення контенту. Фіг. 3 ілюструє апаратну/програмну реалізацію системи захоплення. Фіг. 4 ілюструє апаратну/програмну реалізацію клієнтської системи. Фіг. 5 ілюструє можливі структури сховища контенту, показаного на фіг. 1, включаючи сегменти і файли дескриптора представлення мультимедіа ("MPD"), і розшифровку сегментів, розподіл у часі та іншу структуру у файлі MPD. Фіг. 6 ілюструє подробиці типового вихідного сегмента, який міг би зберігатися у сховищі контенту, проілюстрованому на фіг. 1 і 5. Фіг. 7a і 7b ілюструють просте та ієрархічне індексування у файлах. Фіг. 8(а) ілюструє задавання змінних розмірів блока з вирівняними точками пошуку на множині версій мультимедійного потоку. Фіг. 8(b) ілюструє задавання змінних розмірів блока з невирівняними точками пошуку на множині версій мультимедійного потоку. Фіг. 9(а) ілюструє Таблицю метаданих. Фіг. 9(b) ілюструє передачу Блоків і Таблиці метаданих від сервера до клієнта. Фіг. 10 ілюструє блоки, які не залежать від меж RAP. Фіг. 11 ілюструє безперервний і переривчастий таймінг по сегментах. Фіг. 12 - фігура, що показує особливість масштабованих блоків. Фіг. 13 зображає графічне відображення розвитку з часом деяких змінних в системі потокової передачі по запиту блоків. Фіг. 14 зображає інше графічне відображення розвитку з часом деяких змінних в системі потокової передачі по запиту блоків. Фіг. 15 зображає сітку станів залежно від порогових значень. Фіг. 16 - блок-схема алгоритму процесу, який міг би виконуватися в приймачі, який може запитувати одиночні блоки і декілька блоків в запиті. Фіг. 17 - блок-схема алгоритму гнучкого конвеєрного процесу. Фіг. 18 ілюструє приклад в деякий момент можливого набору запитів, їх пріоритетів, і по яких з'єднаннях вони можуть бути видані. Фіг. 19 ілюструє приклад можливого набору запитів, їх пріоритетів, і по яких з'єднаннях вони можуть бути видані, який [приклад] пройшов від одного моменту до іншого. Фіг. 20 - блок-схема алгоритму сумісного вибору кешуючого проксі-сервера на основі ідентифікатора файлу. Фіг. 21 ілюструє визначення синтаксису для прийнятної мови висловлювань. Фіг. 22 ілюструє приклад прийнятної хеш-функції. Фіг. 23 ілюструє приклади правил складання ідентифікатора файлу. Фіг. 24(a) - (е) ілюструють коливання смуги пропускання у з'єднань TCP. Фіг. 25 ілюструє декілька запитів HTTP вихідних даних і даних відновлення. 3 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 Фіг. 26 ілюструє зразковий час перемикання каналів з FEC і без нього. Фіг. 27 ілюструє подробиці генератора сегментів відновлення, який, як частина показаної на фіг. 1 системи захоплення, формує сегменти відновлення з вихідних сегментів і керуючих параметрів. Фіг. 28 ілюструє відношення між вихідними блоками і блоками відновлення. Фіг. 29 ілюструє процедуру для інтерактивних послуг в різні моменти на клієнті. На фігурах на однакові елементи посилаються за допомогою однакових номерів, і субіндекси надаються в круглих дужках для вказування декількох екземплярів схожих або ідентичних елементів. Поки не вказано інше, кінцевий субіндекс (наприклад, "N" або "M") не призначений бути обмежувальним до якого-небудь конкретного значення, і кількість екземплярів одного елемента може відрізнятися від кількості екземплярів іншого елемента, навіть коли ілюструється однаковий номер і повторно використовується субіндекс. ДОКЛАДНИЙ ОПИС ВИНАХОДУ Як описано в цьому документі, мета системи потокової передачі - перемістити мультимедіа з місця зберігання (або місця, де воно формується) в місце, де воно споживається, тобто представляється користувачу або іншим чином "використовується" людиною або електронним споживачем. У ідеалі система потокової передачі може забезпечувати безперервне відтворення (або, в більш загальному значенні, безперервне "споживання") на приймаючій стороні і може почати відтворення потоку або сукупності потоків незабаром після того, як користувач запитав потік або потоки. З причин ефективності також бажано, щоб кожний потік зупинявся, як тільки користувач вказує, що потік вже не потрібен, наприклад, коли користувач перемикається з одного потоку на інший потік або він слідує представленню потоку, наприклад потоку "субтитрів". Якщо мультимедійний компонент, наприклад відеозображення, продовжує представлятися, але інший потік вибирається для представлення цього мультимедійного компонента, часто переважно зайняти обмежену смугу пропускання новим потоком і зупинити старий потік. Система потокової передачі по запиту блоків відповідно до варіантів здійснення, описаних в цьому документі, забезпечує багато переваг. Потрібно розуміти, що життєздатна система не повинна включати в себе всі описані в цьому документі ознаки, оскільки деякі застосування могли б забезпечити відповідно задовільне враження не з усіма ознаками, описаними в цьому документі. ПОТОКОВА ПЕРЕДАЧА HTTP Потокова передача HTTP є спеціальним типом потокової передачі. При потоковій передачі HTTP джерела могли б бути стандартними веб-серверами і мережами доставки контенту (CDN) і могли б використовувати стандартний HTTP. Ця методика може торкатися сегментації потоку і використання декількох потоків, всі в рамках стандартизованих запитів HTTP. Мультимедіа, наприклад відеозображення, може кодуватися з декількома швидкостями передачі бітів, щоб сформувати різні версії, або відображення. Термін "версія" і "відображення" в цьому документі використовуються синонімічно. Кожну версію або відображення можна розбити на дрібніші фрагменти, де, можливо близько декілька секунд кожний, щоб утворити сегменти. Кожний сегмент тоді можна зберегти на веб-сервері або CDN у вигляді окремого файлу. На стороні клієнта потім можна виконувати запити з використанням HTTP до окремих сегментів, які безшовно стикуються разом за допомогою клієнта. Клієнт може перемикатися на різні швидкості даних на основі доступної смуги пропускання. Клієнт також може запитувати декілька відображень, причому кожне представляє різний мультимедійний компонент, і може відтворювати мультимедіа в цих відображеннях одночасно і синхронно. Тригери для перемикання можуть включати в себе, наприклад, зайнятість буфера і мережеві виміри. При роботі в стійкому стані клієнт може задати темп запитів до сервера, щоб підтримувати цільову зайнятість буфера. Переваги потокової передачі HTTP можуть включати в себе адаптацію швидкості передачі бітів, швидкий запуск і пошук, і мінімальну непотрібну доставку. Ці переваги походять з керування доставкою, щоб вона тільки дещо випереджала відтворення, використовуючи по максимуму доступну смугу пропускання (за допомогою мультимедіа зі змінною швидкістю) і оптимізуючи сегментацію потоку і інтелектуальні процедури на клієнті. Опис представлення мультимедіа може надаватися клієнту потокової передачі HTTP, так що клієнт може використовувати сукупність файлів (наприклад, у форматах, заданих 3GPP, в цьому документі називається сегментами 3gp) для надавання користувачеві послуги потокової передачі. Опис представлення мультимедіа, і по можливості оновлення цього опису представлення мультимедіа, описують представлення мультимедіа, яке є структурованою сукупністю сегментів, причому кожний містить мультимедійні компоненти, так що клієнт може 4 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 представляти включене мультимедіа синхронізованим способом і може забезпечити розширені функціональні можливості, наприклад пошук, перемикання швидкостей передачі бітів і спільне представлення мультимедійних компонентів в різних відображеннях. Клієнт може використовувати інформацію опису представлення мультимедіа різними способами для надавання послуги. Зокрема, з опису представлення мультимедіа клієнт потокової передачі HTTP може визначити, до яких сегментів в сукупності можна звертатися, щоб дані були застосовні до можливості клієнта і користувача в рамках послуги потокової передачі. У деяких варіантах здійснення опис представлення мультимедіа може бути статичним, хоч сегменти могли б створюватися динамічно. Опис представлення мультимедіа може бути як можна більш компактним, щоб мінімізувати час доступу і завантаження для послуги. Іншу з'єднуваність з виділеним сервером можна мінімізувати, наприклад, регулярну або часту часову синхронізацію між клієнтом і сервером. Представлення мультимедіа може створюватися для дозволу доступу терміналам з різними можливостями, наприклад доступом до різних типів мереж доступу, з різними поточними мережевими умовами, розмірами дисплеїв, швидкостями доступу і підтримкою кодеків. Клієнт тоді може витягувати відповідну інформацію для надавання користувачеві послуги потокової передачі. Опис представлення мультимедіа також може забезпечити гнучкість розгортання і компактність відповідно до вимог. У найпростішому випадку кожне Альтернативне відображення може зберігатися в одиночному файлі 3GP, тобто у файлі, який відповідає 3GPP TS26.244, або в будь-якому іншому файлі, який відповідає базовому формату мультимедійного файлу ISO, який заданий в ISO/IEC 14496-12 або похідних специфікаціях (наприклад, формат файлу 3GP, описаний в Технічному описі 3GPP 26.244). У частині цього документа, що залишилася, при посиланні на файл 3GP потрібно розуміти, що ISO/IEC 14496-12 і похідні специфікації можуть відобразити всі описані ознаки у більш загальний базовий формат мультимедійного файлу ISO, який заданий в ISO/IEC 14496-12 або будь-яких похідних специфікаціях. Клієнт тоді може запитати початкову частину файлу, щоб дізнатися метадані мультимедіа (які звичайно зберігаються в блоці Заголовка фільму, що також називається блоком "moov"), разом з моментами фрагментів фільму і байтовими зміщеннями. Клієнт потім може видавати часткові запити GET HTTP для отримання фрагментів фільму при необхідності. У деяких варіантах здійснення може бути бажано, розділити кожне відображення на декілька сегментів. Якщо формат сегмента основується на форматі файлу 3GP, то сегменти містять часові секції, що не перекриваються, фрагментів фільму, що називаються "розділенням по часу". Кожний з цих сегментів може містити декілька фрагментів фільму, і кожний може бути допустимим самостійним файлом 3GP. У іншому варіанті здійснення відображення розділяється на вихідний сегмент, що містить метадані (звичайно це блок Заголовка фільму "moov"), і набір мультимедійних сегментів, що містять мультимедійні дані, і об'єднання вихідного сегмента і будь-якого мультимедійного сегмента утворює файл 3GP, а також об'єднання вихідного сегмента і всіх мультимедійних сегментів одного відображення утворює допустимий файл 3GP. Все представлення може бути утворене шляхом відтворення кожного сегмента по черзі, перетворюючи локальні часові відмітки всередині файлу в глобальний час представлення відповідно до часу початку кожного відображення. Слід відмітити, що по всьому даному опису посилання на "сегмент" потрібно розуміти як такі, що включають в себе будь-який об'єкт даних, який повністю або частково створений або зчитаний з носія інформації або іншим чином отриманий в результаті запиту по протоколу завантаження файлу, включаючи, наприклад, запит HTTP. Наприклад, у випадку HTTP об'єкти даних можуть зберігатися у фактичних файлах, що знаходяться на диску або іншому носії інформації, підключеному або, що створює частину сервера HTTP, або об'єкти даних можуть створюватися за допомогою сценарію CGI або іншої динамічно виконуваної програми, яка виконується у відповідь на запит HTTP. Термін "файл" і "сегмент" в цьому документі використовуються синонімічно, поки не вказано інше. У випадку HTTP сегмент може розглядатися у вигляді головної частини відповіді на запит HTTP. Термін "представлення" і "елемент вмісту" в цьому документі використовуються синонімічно. У багатьох прикладах представлення є звуком, відеозображенням або іншим мультимедійним представленням, яке має заданий час "відтворення", однак можливі інші варіанти. Термін "блок" і "фрагмент" в цьому документі використовуються синонімічно, поки не вказано інше, і звичайно належать до найменшого комплексу даних, який індексується. На основі доступного індексування клієнт може запитувати різні частини фрагмента в різних запитах HTTP або може запитувати один або декілька послідовних фрагментів або частин 5 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 фрагментів в одному запиті HTTP. У випадку, коли використовуються сегменти на основі базового формату мультимедійного файлу ISO або сегменти на основі формату файлу 3GP, фрагмент звичайно стосується фрагмента фільму, заданого у вигляді поєднання блока заголовка фрагмента фільму ("moof") і блока мультимедійних даних ("mdat"). У цьому документі мережа, що переносить дані, передбачається пакетною мережею, щоб спростити описи в цьому документі, з розумінням того, що після прочитання цього розкриття винаходу фахівець в даній галузі техніки може застосувати варіанти здійснення даного винаходу, описані в цьому документі, до інших типів мереж передачі, наприклад мереж з безперервним бітовим потоком. У цьому документі коди FEC передбачаються такими, що забезпечують захист від тривалого і змінного часу доставки даних, щоб спростити описи в цьому документі, з розумінням того, що після прочитання цього розкриття винаходу фахівець в даній галузі техніки може застосувати варіанти здійснення даного винаходу до інших типів проблем передачі даних, наприклад, спотворення при інвертуванні розрядів даних. Наприклад, за відсутності FEC, якщо остання частина запитаного фрагмента надходить набагато пізніше або має великий розкид під час надходження, ніж попередні частини фрагмента, то час перемикання контенту може бути більшим і змінним, тоді як з використанням FEC і паралельних запитів тільки більшість даних, запитаних для фрагмента, повинна надійти до того, як їх можна відновити, за допомогою цього зменшуючи час перемикання контенту і нестабільність часу перемикання контенту. У цьому описі можна було б передбачити, що дані, які треба кодувати (тобто вихідні дані), розбиті на "символи" однакової довжини, які можуть мати будь-яку довжину (аж до одного розряду), але символи могли б мати різні довжини для різних частин даних, наприклад, різні розміри символів могли б використовуватися для різних блоків даних. У цьому описі, щоб спростити описи в цьому документі, передбачається, що FEC застосовується до "блока" або "фрагмента" даних за раз, тобто "блок" є "вихідним блоком" для цілей кодування і декодування FEC. Клієнтський пристрій може використовувати індексування сегмента, описане в цьому документі, щоб допомогти у визначенні структури вихідного блока в сегменті. Фахівець в даній галузі техніки може застосувати варіанти здійснення даного винаходу до інших типів структур вихідного блока, наприклад, вихідний блок може бути частиною фрагмента або включати в себе один або декілька фрагментів або частин фрагментів. Коди FEC, розглянуті для використання з потоковою передачею по запиту блоків, звичайно є систематичними кодами FEC, тобто вихідні символи вихідного блока можуть включатися як частина кодування вихідного блока, і таким чином передаються вихідні символи. Як визнає фахівець в даній галузі техніки, варіанти здійснення, описані в цьому документі, в однаковій мірі застосовуються до кодів FEC, які не є систематичними. Систематичний кодер FEC формує з вихідного блока вихідних символів деяку кількість символів відновлення, і поєднання щонайменше деяких з вихідних символів і символів відновлення є кодованими символами, які відправляються по каналу, що представляє вихідний блок. Деякі коди FEC можуть бути корисні для ефективного формування такої кількості символів відновлення, яка необхідна, наприклад "інформаційні адитивні коди" або "фонтанні коди", і приклади цих кодів включають в себе "коди ланцюгової реакції" і "коди багатоетапної ланцюгової реакції". Інші коди FEC, наприклад коди Ріда-Соломона, практично можуть формувати тільки обмежену кількість символів відновлення для кожного вихідного блока. У багатьох цих прикладах передбачається, що клієнт з'єднується з сервером мультимедіа або множиною серверів мультимедіа, і клієнт запитує потокове мультимедіа по каналу або множині каналів від сервера мультимедіа або множини серверів мультимедіа. Однак також можливе складніше компонування. ПРИКЛАДИ ПЕРЕВАГ При потоковій передачі по запиту блоків клієнт мультимедіа підтримує зв'язок між синхронізацією цих запитів блоків і синхронізацією відтворення мультимедіа для користувача. Ця модель може зберігати переваги моделі "завантаження", описаної вище, нарівні із запобіганням деяких недоліків, які відбуваються від звичайного розриву відтворення мультимедіа і доставки даних. Модель потокової передачі по запиту блоків робить доступною використання механізмів контролю швидкості і відстеження перевантажень в транспортних протоколах, наприклад TCP, щоб гарантувати, що максимальна доступна смуга пропускання використовується для мультимедійних даних. Більше того, розділення представлення мультимедіа на блоки дозволяє вибирати кожний блок кодованих мультимедійних даних з набору декількох доступних кодувань. Цей вибір може основуватися на будь-якій кількості критеріїв, включаючи узгодження швидкості мультимедійних даних з доступною смугою пропускання, навіть коли доступна смуга 6 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 пропускання змінюється з часом, узгодження дозволу мультимедіа або складності декодування з можливостями або конфігурацією клієнта, або узгодження з користувацькими перевагами, наприклад мовами. Вибір також може включати в себе завантаження і представлення допоміжних компонентів, наприклад компонентів доступності, прихованих субтитрів, субтитрів, відеозображення на мові глухонімих і т. д. Приклади існуючих систем, що використовують модель потокової передачі по запиту блоків, включають в себе Move Networks™, Microsoft Smooth Streaming і Протокол потокової передачі в Apple iPhone™. Звичайно кожний блок мультимедійних даних може зберігатися на сервері як окремий файл, а потім протокол, наприклад HTTP, в поєднанні з програмним забезпеченням сервера HTTP, що виконується на сервері, використовується для запиту файлу як якоїсь одиниці. Звичайно клієнту надаються файли метаданих, які можуть мати, наприклад, формат розширюваної мови розмітки (XML) або текстовий формат списку відтворення або двійковий формат, які описують особливості представлення мультимедіа, наприклад доступні кодування (наприклад, необхідну смугу пропускання, розділення, параметри кодування, тип мультимедіа, мову), що звичайно називаються "відображеннями" в цьому документі, і спосіб, яким кодування розділені на блоки. Наприклад, метадані можуть включати в себе Уніфікований покажчик ресурсу (URL) для кожного блока. Самі URL можуть надавати схему, наприклад, що передується рядком "http://" для вказування, що протоколом, який треба використовувати для доступу до документованого ресурсу, є HTTP. Іншим прикладом є "ftp://" для вказування, що протоколом, який треба використовувати, є FTP. У інших системах, наприклад, блоки мультимедіа можуть створюватися сервером "на ходу" у відповідь на запит від клієнта, який вказує частину представлення мультимедіа, в момент, який запитується. Наприклад, у випадку HTTP зі схемою "http://" виконання запиту з цим URL надає відповідь на запит, який містить деякі характерні дані в головній частині цієї відповіді на запит. Реалізація в мережі того, як формувати цю відповідь на запит, може бути досить різною, залежно від реалізації сервера, обслуговуючого такі запити. Звичайно кожний блок може бути декодованим незалежно. Наприклад, у випадку відеозображення кожний блок може починатися з "точки пошуку". У деяких схемах кодування точка пошуку називається "Точками довільного доступу" або "RAP", хоч не всі RAP можуть призначатися точкою пошуку. Аналогічним чином в інших схемах кодування точка пошуку починається в кадрі "Незалежного оновлення даних", або "IDR", у разі кодування відеозображення H.264, хоч не всі IDR можуть призначатися точкою пошуку. Точка пошуку є положенням у відеозображенні (або іншому), де декодер може почати декодування без необхідності яких-небудь даних про попередні кадри або даних або вибірок, що могло б бути випадком, коли кадр або вибірка, яка декодується, кодувалася не автономно, а, наприклад, як різниця між поточним кадром і попереднім кадром. Питанням в таких системах може бути можливість почати відтворення потоку, наприклад декодування і візуалізацію прийнятих аудіо - і відеопотоків з використанням персонального комп'ютера і відображення відеозображення на екрані комп'ютера і відтворення звуку через вбудовані динаміки, або, як інший приклад, декодування і візуалізацію прийнятих аудіо - і відеопотоків з використанням телевізійної приставки і відображення відеозображення на телевізійному пристрої відображення і відтворення звуку через стереосистему. Першочерговою задачею може бути мінімізація затримки між тим, коли користувач вирішує подивитися новий контент, доставлений у вигляді потоку, і виконує дію, яка виражає це рішення, наприклад, користувач, натискає на посилання у вікні оглядача або на кнопку відтворення на пристрої дистанційного керування, і тим, коли контент починає відображатися на екрані користувача, що надалі називається "часом перемикання контенту". Кожна з цих задач може бути вирішена за допомогою елементів поліпшеної системи, описаної в цьому документі. Прикладом перемикання контенту є те, коли користувач дивиться перший контент, доставлений за допомогою першого потоку, і потім користувач вирішує подивитися другий контент, доставлений за допомогою другого потоку, і ініціює дію для початку перегляду другого контенту. Другий потік може відправлятися з такого ж набору або іншого набору серверів, що і перший потік. Іншим прикладом перемикання контенту є те, коли користувач відвідує веб-сайт і вирішує почати перегляд першого контенту, доставленого за допомогою першого потоку, шляхом натиснення на посилання у вікні оглядача. Аналогічним чином користувач може вирішити почати відтворення контенту не з початку, а з деякого часу в рамках потоку. Користувач вказує своєму клієнтському пристрою перейти до положення у часі, і користувач міг передбачати, що вибраний час візуалізується вмить. Мінімізація часу перемикання контенту важлива для перегляду відеозображення, щоб забезпечити користувачам враження 7 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 високоякісного швидкого перегляду контенту при пошуку і відборі широкого діапазону доступного контенту. Останнім часом стало сталою практикою розглядати використання кодів Прямого виправлення помилок (FEC) для захисту потокового мультимедіа під час передачі. При відправленні по пакетній мережі, приклади якої включають в себе Інтернет і бездротові мережі, наприклад, стандартизовані групами, такими як 3GPP, 3GPP2 і DVB, вихідний потік вміщується в пакети, коли формується, або стає доступним, і відповідно пакети можуть використовуватися для перенесення вихідного потоку або потоку контенту в порядку, яким він формується, або стає доступним приймачам. У типовому застосуванні кодів FEC до цих типів сценаріїв кодер може використовувати код FEC при створенні пакетів відновлення, які потім відправляються додатково до вихідних пакетів, що містять вихідний потік. Пакети відновлення мають таку властивість, що коли відбувається втрата вихідних пакетів, прийняті пакети відновлення можуть використовуватися для відновлення даних, що містяться у втрачених вихідних пакетах. Пакети відновлення можуть використовуватися для відновлення вмісту втрачених вихідних пакетів, які втрачені повністю, але також могли б використовуватися для відновлення, коли відбувається часткова втрата пакетів, або повністю прийняті пакети відновлення, або навіть частково прийняті пакети відновлення. Таким чином, повністю або частково прийняті пакети відновлення можуть використовуватися для відновлення повністю або частково втрачених вихідних пакетів. У ще одних прикладах інші типи спотворення можуть виникати у відправлених даних, наприклад, значення розрядів можуть інвертуватися, і відповідно пакети відновлення можуть використовуватися для виправлення такого спотворення і забезпечення як можна точнішого відновлення вихідних пакетів. У інших прикладах вихідний потік не обов'язково відправляється в дискретних пакетах, а замість цього може відправлятися, наприклад, у вигляді безперервного потоку двійкових сигналів. Є багато прикладів кодів FEC, які можуть використовуватися для забезпечення захисту вихідного потоку. Коди Ріда-Соломона є загальновідомими кодами для корекції зі стиранням помилок в системах зв'язку. Для корекції зі стиранням помилок, наприклад, в мережах пакетної передачі даних загальновідома ефективна реалізація кодів Ріда-Соломона використовує матриці Коші або Вандермонда, які описані в L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", Computer Communication Review, 27(2):24-36 (квітень 1997) (в подальшому "Rizzo"), і Bloemer та ін., "An XOR-Based Erasure-Resilient Coding Scheme", Технічний звіт TR-95-48, Міжнародний інститут обчислювальної техніки, Берклі, Каліфорнія (1995) (в подальшому - "XOR-Reed-Solomon") або де-небудь ще. Інші приклади кодів FEC включають в себе коди LDPC, коди ланцюгової реакції, наприклад описані в Luby I, і коди багатоетапної ланцюгової реакції, наприклад в Shokrollahi I. Приклади процесу декодування FEC для різновидів кодів Ріда-Соломона описуються в Rizzo і XOR-Reed-Solomon. У тих прикладах декодування може застосовуватися після того, як прийнята достатня кількість пакетів вихідних даних і даних відновлення. Процес декодування може мати великий об'єм обчислень, і залежно від доступних ресурсів CPU може вимагати значного часу для завершення відносно тривалості часу, зайнятого мультимедіа в блоці. Приймач може враховувати цю тривалість часу, необхідну для декодування, при обчисленні затримки, необхідної між початком прийому мультимедійного потоку і відтворенням мультимедіа. Ця затримка через декодування сприймається користувачем як затримка між запитом конкретного мультимедійного потоку і початком відтворення. Відповідно бажано мінімізувати цю затримку. У багатьох застосуваннях пакети можуть додатково поділятися на символи, до яких застосовується процес FEC. Пакет може містити один або декілька символів (або менше одного символу, але звичайно символи не діляться між групами пакетів, поки стани помилки серед груп пакетів відомі як сильно взаємопов'язані). Символ може мати будь-який розмір, але часто розмір символу складає не більше розміру пакету. Вихідні символи є тими символами, які кодують дані, які треба передати. Символи відновлення є символами, сформованими з вихідних символів, прямо або непрямо додатково до вихідних символів (тобто дані, які треба передати, можна відновити повністю, якщо всі вихідні символи доступні і ніякі символи відновлення не доступні). Деякі коди FEC можуть бути блоковими, в яких операції кодування залежать від символу (символів), які знаходяться в блоці, і можуть не залежати від символів поза тим блоком. За допомогою блокового кодування кодер FEC може сформувати символи відновлення для блока з вихідних символів в тому блоці, потім перейти до наступного блока і не потребувати звернення до вихідних символів крім символів для поточного блока, що кодується. При передачі 8 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 вихідний блок, що містить вихідні символи, можна представити кодованим блоком, що містить кодовані символи (які могли б бути деякими вихідними символами, деякими символами відновлення або тими та іншими). При наявності символів відновлення не всі вихідні символи необхідні в кожному кодованому блоці. Для деяких кодів FEC, особливо кодів Ріда-Соломона, час кодування і декодування може непрактично рости із зростанням кількості кодованих символів на вихідний блок. Таким чином, на практиці часто існує практична верхня межа (255 є приблизною практичною межею для деяких застосувань) для загальної кількості кодованих символів, які можуть формуватися з розрахунку на вихідний блок, особливо в типовому випадку, коли процес кодування або декодування Ріда-Соломона виконується спеціальними апаратними засобами, наприклад, процеси MPE-FEC, які використовують коди Ріда-Соломона, включені як частина стандарту DVB-H для захисту потоків від втрати пакетів, реалізовуються в спеціалізованих апаратних засобах в стільниковому телефоні, які обмежуються всього 255 кодованими символами РідаСоломона на вихідний блок. Оскільки символи часто необхідно вміщувати в окремі корисні навантаження пакетів, це встановлює практичну верхню межу на максимальну довжину вихідного блока, що кодується. Наприклад, якщо корисне навантаження пакету обмежується 1024 байтами або менше, і кожний пакет несе один кодований символ, то кодований вихідний блок може складати не більше 255 кілобайт, і це, звичайно, також є верхньою межею розміру самого вихідного блока. Інші питання, наприклад, здатність декодувати вихідні блоки досить швидко, щоб не відставати від швидкості потокової передачі джерела, мінімізувати затримку декодування, внесену декодування FEC, і використовувати тільки невелику частину доступного CPU в приймальному пристрої в будь-який момент часу протягом декодування FEC, вирішуються за допомогою елементів, описаних в цьому документі. Необхідність надавання стійкого і масштабованого рішення по потоковій доставці, яке дозволяє виходити з ладу компонентам системи без несприятливого впливу на якість потоків, доставлених приймачам. Система потокової передачі по запиту блоків повинна підтримувати зміни в структурі або метаданих представлення, наприклад, зміни кількості доступних кодувань мультимедіа або зміни параметрів кодувань мультимедіа, наприклад швидкості передачі бітів, дозвіл, співвідношення сторін або кодеків відеозображення або параметрів кодеків, або зміни інших метаданих, наприклад URL, асоційованих з файлами контенту. Такі зміни можуть бути необхідні з деяких причин, включаючи редагування контенту одночасно з різних джерел, наприклад реклами або різних сегментів більшого представлення, модифікацію URL або інших параметрів, які стають необхідні внаслідок змін в обслуговуючій інфраструктурі, наприклад, через конфігураційні зміни, збої обладнання або відновлення зі збоїв обладнання, або з інших причин. Існують способи, в яких представлення може керуватися за допомогою файлу списку відтворення, що постійно оновлюється. Оскільки цей файл постійно оновлюється, то щонайменше деякі зміни, описані вище, можна виробити в рамках цих оновлень. Недолік традиційного способу полягає в тому, що клієнтські пристрої зобов'язані весь час відшукувати файл списку відтворення, що називається "опитуванням", створюючи навантаження на обслуговуючу інфраструктуру, і що цей файл не можна кешувати довше інтервалу оновлення, роблячи ще складнішою задачу для обслуговуючої інфраструктури. Це вирішується за допомогою елементів в цьому документі, так що оновлення описаного вище вигляду забезпечуються без необхідності в постійному опитуванні файлу метаданих клієнтами. Іншою проблемою, особливо в інтерактивних послугах, звичайно відомою з мовленнєвого поширення, є відсутність можливості у користувача переглядати контент, який був трансльований раніше часу, коли користувач приєднався до програми. Звичайно локальний персональний запис споживає зайве локальне сховище або не можливий, оскільки клієнт не настроївся на програму, або заборонений правилами захисту контенту. Мережевий запис і відкладений перегляд переважні, але вимагають окремих з'єднань користувача із сервером і роздільного протоколу доставки і інфраструктури крім інтерактивних послуг, призводячи до дубльованої інфраструктури і значних витрат сервера. Це також вирішується за допомогою елементів, описаних в цьому документі. ОГЛЯД СИСТЕМИ Один варіант здійснення винаходу описується з посиланням на фіг. 1, яка показує спрощену схему системи потокової передачі по запиту блоків, що здійснює винахід. На фіг. 1 ілюструється система 100 потокової передачі блоків, що містить обслуговуючу інфраструктуру 101 блоків ("BSI"), що в свою чергу містить систему 103 захоплення для захоплення контенту 102, підготовки цього контенту і його упаковки для послуги від сервера 104 9 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 потокової передачі HTTP шляхом збереження його в сховищі 110 контенту, яке доступне системі 103 захоплення і серверу 104 потокової передачі HTTP. Як показано, система 100 також могла б включати в себе кеш 106 HTTP. При роботі клієнт 108, наприклад клієнт потокової передачі HTTP, відправляє запити 112 на сервер 104 потокової передачі HTTP і приймає відповіді 114 від сервера 104 потокової передачі HTTP або з кеша 106 HTTP. У кожному випадку елементи, показані на фіг. 1, могли б бути реалізовані, щонайменше частково, в програмному забезпеченні, що містить програмний код, який виконується на процесорі або іншій електроніці. Контент міг би містити фільми, звук, плоске (2D) відеозображення, об'ємне відеозображення (3D), інші типи відеозображення, зображення, синхронізований текст, синхронізовані метадані або т. п. Деякий контент міг би включати в себе дані, які треба представляти або споживати спланованими за часом, наприклад дані для представлення допоміжної інформації (ідентифікатор станції, реклама, котирування акцій, послідовності Flash™ і т. д.) разом з іншим мультимедіа, що відтворюється. Також могли б використовуватися інші гібридні представлення, які об'єднують інше мультимедіа і/або виходять за межі просто звуку і відеозображення. Як проілюстровано на фіг. 2, блоки мультимедіа можуть зберігатися в обслуговуючій інфраструктурі 101(1) блоків, яка могла б бути, наприклад, сервером HTTP, пристроєм Мережі доставки контенту, посередником HTTP, посередником або сервером FTP або деяким іншим сервером або системою мультимедіа. Обслуговуюча інфраструктура 101(1) блоків підключається до мережі 122, яка могла б бути, наприклад, мережею по Інтернет-протоколу ("IP"), такою як Інтернет. Клієнт системи потокової передачі по запиту блоків показаний таким, що містить шість функціональних компонентів, а саме селектор 123 блоків, що забезпечується описаними вище метаданими і, що виконує функцію вибору блоків або часткових блоків, які треба запитати, з множини доступних блоків, вказаної метаданими, запитувач 124 блоків, який приймає команди запитів від селектора 123 блоків і виконує операції, необхідні для відправки запиту заданого блока, частин блока або декількох блоків в обслуговуючу інфраструктуру 101(1) блоків по мережі 122 і для прийому даних, що містять блок у відповідь, а також буфер 125 блоків, монітор 126 буфера, декодер 127 мультимедіа і один або декілька перетворювачів 128 мультимедіа, які полегшують споживання мультимедіа. Дані блоків, прийняті запитувачем 124 блоків, передаються для часового зберігання в буфер 125 блоків, який зберігає мультимедійні дані. Як альтернатива прийняті дані блоків можуть зберігатися безпосередньо в буфері 125 блоків, як проілюстровано на фіг. 1. Декодер 127 мультимедіа забезпечується мультимедійними даними за допомогою буфера 125 блоків і виконує такі перетворення над цими даними, які необхідні для надавання відповідних вхідних даних в перетворювачі 128 мультимедіа, які візуалізують мультимедіа у вигляді, прийнятному для користувача або іншого споживання. Приклади перетворювачів мультимедіа включають в себе пристрої візуального відображення, які можна зустріти в мобільних телефонах, комп'ютерних системах або телевізорах, а також могли б включати в себе звуковідтворювані пристрої, наприклад динаміки або навушники. Прикладом декодера мультимедіа була б функція, яка перетворює дані у форматі, описаному в стандарті кодування відеозображення H.264, в аналогові або цифрові відображення відеокадрів, наприклад карту елементів зображення YUV-формату з асоційованими часовими відмітками представлення для кожного кадру або вибірки. Монітор 126 буфера приймає інформацію щодо вмісту буфера 125 блоків і на основі цієї інформації і, по можливості, іншої інформації надає вхідні дані в селектор 123 блоків, який використовується для визначення відбору блоків для запиту, що описується в цьому документі. У термінології, що використовується в цьому документі, кожний блок має "час відтворення" або "тривалість", яка являє собою кількість часу, яка зайняла б у приймача відтворення мультимедіа, включеного в блок, з нормальною швидкістю. У деяких випадках відтворення мультимедіа в блоці може залежати від того, чи прийняті вже дані з попередніх блоків. У рідкісних випадках відтворення деякого мультимедіа в блоці може залежати від подальшого блока, і в цьому випадку час відтворення для блока задається відносно мультимедіа, яке можна відтворити в блоці без звертання до подальшого блока, а час відтворення для подальшого блока збільшується на час відтворення мультимедіа в цьому блоці, який можна відтворити тільки після прийому подальшого блока. Оскільки включення мультимедіа в блок, який залежить від подальших блоків, є нечастим випадком, в частині цього розкриття винаходу, що залишилася, ми допускаємо, що мультимедіа в одному блоці не залежить від подальших блоків, але зазначимо, що фахівці в даній галузі техніки визнають, що цей різновид можна легко додати в описані нижче варіанти здійснення. Приймач може мати елементи керування, наприклад "пауза", "швидка перемотка уперед", "перемотка назад" і т. д., що може призвести до споживання блока при відтворенні з різною 10 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 швидкістю, але якщо приймач може отримати і декодувати кожну подальшу послідовність блоків в сукупний час, менше або, що дорівнює їх сукупному часу відтворення за винятком останнього блока в послідовності, то приймач може представити користувачеві мультимедіа без зупинки. У деяких описах в цьому документі конкретне положення в мультимедійному потоці називається конкретним "часом" в мультимедіа, відповідним часу, який пройшов би між початком відтворення мультимедіа і часом, коли досягається конкретне положення у відеопотоці. Час або положення в мультимедійному потоці є традиційним поняттям. Наприклад, там, де відеопотік містить 24 кадри за секунду, про перший кадр можна сказати, що він має положення або час t=0,0 секунд, а про 241-ий кадр можна сказати, що він має положення або час t=10,0 секунд. Природно, у відеопотоці на основі кадрів положення або час не повинні бути безперервними, оскільки кожний із розрядів в потоці від першого розряду 241-го кадру до точно перед першим розрядом 242-го кадру могли б усі мати однакове значення часу. Беручи до уваги вищенаведену термінологію, система потокової передачі по запиту блоків (BRSS) містить один або декілька клієнтів, які створюють запити до одного або декількох серверів контента (наприклад, серверів HTTP, серверів FTP і т. д.). Система захоплення містить один або декілька процесорів захоплення, причому процесор захоплення приймає контент (в режимі реального часу або ні), обробляє контент для використання за допомогою BRSS і зберігає його в сховищі, доступному серверам контенту, по можливості також, разом з метаданими, сформованими процесором захоплення. BRSS також могла б містити кеші контенту, які узгоджені з серверами контенту. Сервери контенту і кеші контенту можуть бути традиційними серверами HTTP і кешами HTTP, які приймають запити файлів або сегментів у вигляді запитів HTTP, які включають в себе URL і також можуть включати в себе байтовий діапазон, щоб запитати не весь файл або сегмент, вказаний за допомогою URL. Клієнти могли б включати в себе традиційний клієнт HTTP, який запитує сервери HTTP і обробляє відповіді на ті запити, причому клієнт HTTP керується новою клієнтською системою, яка формулює запити, передає їх клієнту HTTP, отримує відповіді від клієнта HTTP і обробляє їх (або зберігає, перетворює і т. д.) для того, щоб надати програвачу представлень для відтворення клієнтським пристроєм. Звичайно клієнтська система заздалегідь не знає, яке мультимедіа потребуватиметься (оскільки потреби могли б залежати від вводу користувача, змін у вводі користувача і т. д.), тому кажуть, що це "потокова" система, в якій мультимедіа "споживається", як тільки воно приймається, або незабаром після цього. Внаслідок затримки відповіді і обмеження смуги пропускання можуть викликати затримки в представленні, наприклад, викликаючи припинення представлення, коли потік доганяє те місце, де користувач споживає представлення. Щоб забезпечити представлення, яке сприймається як таке, що має хорошу якість, деяка кількість подробиць може бути реалізована в BRSS на стороні клієнта, на стороні захоплення або на обох сторонах. У деяких випадках подробиці, які реалізовуються, виконуються з урахуванням і для розгляду інтерфейсу клієнт-сервер в мережі. У деяких варіантах здійснення клієнтська система і система захоплення проінформовані про поліпшення, тоді як в інших варіантах здійснення тільки одна сторона проінформована про поліпшення. У таких випадках вся система виграє від поліпшення, навіть якщо одна сторона не проінформована про це, хоч в інших випадках вигода виникає, тільки якщо обидві сторони проінформовані про це, а коли одна сторона не проінформована, вона як і раніше працює без збою. Як проілюстровано на фіг. 3, система захоплення може бути реалізована у вигляді поєднання апаратних і програмних компонентів відповідно до різних варіантів здійснення. Система захоплення може містити набір команд, який може виконуватися для спонукання системи виконати будь-яку одну або декілька методологій, розглянутих в цьому документі. Система може бути реалізована як спеціальна машина у вигляді комп'ютера. Система може бути серверним комп'ютером, персональним комп'ютером (ПК) або будь-якою системою, що допускає виконання набору команд (послідовно або іншим чином), які задають дії, які повинна виконати система. Крім того, хоч ілюструється тільки одна система, термін "система" також потрібно використовувати як такий, що включає будь-яку сукупність систем, які окремо або одночасно виконують набір (або декілька наборів) команд для виконання будь-якої однієї або декількох методологій, розглянутих в цьому документі. Система захоплення може включати в себе процесор 302 захоплення (наприклад, центральний процесор (CPU)), запам'ятовуючий пристрій 304, який може зберігати програмний код під час виконання, і дискове сховище 306, всі з яких взаємодіють один з одним по шині 300. Система може додатково включати в себе дисплей 308 (наприклад, рідкокристалічний дисплей (LCD) або електронно-променеву трубку (CRT)). Система також може включати в себе пристрій 11 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 310 буквено-цифрового вводу (наприклад, клавіатуру) і мережевий інтерфейс 312 для прийому джерела контенту і доставки в сховищі контенту. Дисковий запам'ятовуючий пристрій 306 може включати в себе машиночитаний носій, на якому може зберігатися один або декілька наборів команд (наприклад, програмне забезпечення), що втілюють будь-яку одну або декілька методологій або функцій, описаних в цьому документі. Команди також можуть знаходитися, повністю або, щонайменше частково, в запам'ятовуючому пристрої 304 і/або в процесорі 302 захоплення під час їх виконання системою, причому запам'ятовуючий пристрій 304 і процесор 302 захоплення також складають машиночитані носії. Як проілюстровано на фіг. 4, клієнтська система може бути реалізована у вигляді поєднання апаратних і програмних компонентів відповідно до різних варіантів здійснення. Клієнтська система може містити набір команд, який може виконуватися для спонукання системи виконати будь-яку одну або декілька методологій, розглянутих в цьому документі. Система може бути реалізована як спеціальна машина у вигляді комп'ютера. Система може бути серверним комп'ютером, персональним комп'ютером (ПК) або будь-якою системою, що допускає виконання набору команд (послідовно або іншим чином), які задають дії, які повинна виконати система. Крім того, хоч ілюструється тільки одна система, термін "система" також потрібно використовувати як такий, що включає будь-яку сукупність систем, які по окремості або одночасно виконують набір (або декілька наборів) команд для виконання будь-якої однієї або декількох методологій, розглянутих в цьому документі. Клієнтська система може включати в себе процесор 402 клієнта (наприклад, центральний процесор (CPU)), запам'ятовуючий пристрій 404, який може зберігати програмний код під час виконання, і дискове сховище 406, всі з яких взаємодіють один з одним по шині 400. Система може додатково включати в себе дисплей 408 (наприклад, рідкокристалічний дисплей (LCD) або електронно-променеву трубку (CRT)). Система також може включати в себе пристрій 410 буквено-цифрового вводу (наприклад, клавіатуру) і мережевий інтерфейс 412 для відправки запитів і прийому відповідей. Дисковий запам'ятовуючий пристрій 406 може включати в себе машиночитаний носій, на якому може зберігатися один або декілька наборів команд (наприклад, програмне забезпечення), що втілюють будь-яку одну або декілька методологій або функцій, описаних в цьому документі. Команди також можуть знаходитися, повністю або, щонайменше частково, в запам'ятовуючому пристрої 404 і/або в процесорі 402 клієнта під час їх виконання системою, причому запам'ятовуючий пристрій 404 і процесор 402 клієнта також складають машиночитані носії. ВИКОРИСТАННЯ ФОРМАТУ ФАЙЛУ 3GPP Формат файлу 3GPP або будь-який інший файл на основі базового формату мультимедійного файлу ISO, наприклад формату файлу MP4 або формату файлу 3GPP2, може використовуватися як контейнерний формат для потокової передачі HTTP з наступними особливостями. Індекс сегмента може включатися в кожний сегмент, щоб сигналізувати часові зміщення і байтові діапазони, так що клієнт може завантажувати відповідні фрагменти файлів або мультимедійні сегменти при необхідності. Хронометраж глобального представлення всього представлення мультимедіа і локальний хронометраж в кожному файлі 3GP або мультимедійному сегменті можна точно вирівняти. Доріжки в одному файлі 3GP або мультимедійному сегменті можна точно вирівняти. Доріжки між відображеннями також можна вирівняти шляхом призначення кожної з них глобальної часової шкали, так що перемикання по відображенню може бути плавним, і спільне представлення мультимедійних компонентів в різних відображеннях може бути синхронним. Формат файлу може містити профіль для Адаптивної потокової передачі з наступними властивостями. Всі дані фільму можуть міститися у фрагментах фільму - блок "moov" може не містити ніякої вибіркової інформації. Вибіркові дані звуку і відеозображення можуть чергуватися, з аналогічними вимогами відносно профілю прогресивного завантаження, який заданий в TS26.244. Блок "moov" можна вмістити в початок файлу, з подальшими даними зміщення фрагмента, що також називаються індексом сегмента, що містить інформацію про зміщення у часових і байтових діапазонах для кожного фрагмента або щонайменше підмножини фрагментів в сегменті, що містить. Опису представлення мультимедіа також можна посилатися на файли, які йдуть за існуючим профілем Прогресивного завантаження. У цьому випадку клієнт може використовувати Опис представлення мультимедіа просто для вибору відповідної альтернативної версії серед декількох доступних версій. Клієнти також можуть використовувати часткові запити get HTTP з файлами, сумісними з профілем Прогресивного завантаження, щоб 12 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 запитувати підмножини кожної альтернативної версії і за допомогою цього реалізувати менш ефективну форму адаптивної потокової передачі. У цьому випадку різні відображення, що містять мультимедіа в профілі прогресивного завантаження, як і раніше можуть дотримуватися загальної глобальної часової шкали, щоб зробити можливим плавне перемикання між відображеннями. ОГЛЯД ПРОГРЕСИВНИХ СПОСОБІВ У наступних розділах описуються способи для вдосконалених систем потокової передачі по запиту блоків. Потрібно розуміти, що деякі з цих поліпшень можуть використовуватися разом або без інших цих поліпшень, залежно від потреб застосування. У загальному процесі приймач запитує у сервера або іншого передавача певні блоки або частини блоків даних. Файли, що також називаються сегментами, можуть містити декілька блоків і асоціюються з одним відображенням мультимедійного представлення. Переважно, щоб формувалася інформація індексування, що також називається "індексуванням сегмента" або "картою сегмента", яка забезпечує перетворення з моментів відтворення або декодування в байтові зміщення відповідних блоків або фрагментів у сегменті. Це індексування сегмента може включатися в сегмент, звичайно на початку сегмента (щонайменше частина карти сегмента знаходиться на початку) і часто є невеликим. Індекс сегмента також може надаватися в окремому сегменті або файлі індексу. Особливо у випадках, коли індекс сегмента міститься в сегменті, приймач може швидко завантажити частину або всю цю карту сегмента і згодом використовувати її для визначення перетворення між часовими зміщеннями і відповідними байтовими положеннями фрагментів, асоційованих з тими часовими зміщеннями у файлі. Приймач може використовувати байтове зміщення для запиту даних з фрагментів, асоційованих з конкретними часовими зміщеннями, без необхідності завантажувати всі дані, асоційовані з іншими фрагментами, не асоційованими з часовими зміщеннями, що цікавлять. Таким чином, карта сегмента або індексування сегмента може значно збільшити можливість приймача по безпосередньому зверненню до частин сегмента, які підходять для поточних часових зміщень, що цікавлять, з вигодами, що включають поліпшений час перемикання контенту, можливість швидко перемкнутися з одного відображення на інше, коли змінюються мережеві умови, і зменшену втрату мережевих ресурсів при завантаженні мультимедіа, яке не відтворюється на приймачі. Якщо розглядається перемикання з одного відображення (що називається в цьому документі "початковим" відображенням) на інше відображення (що називається в цьому документі "цільовим" відображенням), то індекс сегмента також може використовуватися для ідентифікації часу початку точки довільного доступу в цільовому відображенні, щоб ідентифікувати об'єм даних, який треба запитати в початковому відображенні, щоб гарантувати, що плавне перемикання забезпечується в тому значенні, що мультимедіа в початковому відображенні завантажується аж до часу представлення, так що відтворення цільового відображення може початися плавно з точки довільного доступу. Ті блоки представляють сегменти відеозображення або іншого мультимедіа, які потрібні запитуючому приймачу для формування виводу для користувача приймача. Приймач мультимедіа може бути клієнтським пристроєм, наприклад, коли приймач приймає контент від сервера, який передає контент. Приклади включають в себе телевізійні приставки, комп'ютери, ігрові приставки, спеціально обладнані телевізори, кишенькові пристрої, спеціально обладнані мобільні телефони або інші клієнтські приймачі. У цьому документі описуються багато які способи розширеного керування буфером. Наприклад, спосіб керування буфером дає можливість клієнтам запитувати блоки мультимедіа найвищої якості, які можна безперервно прийняти у час для відтворення. Властивість змінного розміру блока підвищує ефективність стиснення. Можливість мати декілька з'єднань для передачі блоків пристрою, що запитує, нарівні з обмеженням частоти запитів забезпечує підвищену ефективність передачі. Частково прийняті блоки даних можуть використовуватися для продовження представлення мультимедіа. З'єднання може повторно використовуватися для декількох блоків без необхідності фіксувати з'єднання на початку для конкретного набору блоків. Узгодженість при виборі серверів з числа декількох можливих серверів декількома клієнтами поліпшується, що зменшує частоту дубльованого контенту на найближчих серверах і підвищує ймовірність того, що сервер містить весь файл. Клієнти можуть запитувати блоки мультимедіа на основі метаданих (наприклад, доступних кодувань мультимедіа), які вбудовуються в URL для файлів, що містять блоки мультимедіа. Система може передбачити обчислення і мінімізацію величини часу буферизації, необхідного до того, як можна починати відтворення контенту, без подальших пауз при відтворенні мультимедіа. Доступна смуга 13 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 пропускання може спільно використовуватися декількома блоками мультимедіа, скоректована, коли наближається час відтворення кожного блока, щоб при необхідності велику частку доступної смуги пропускання можна було виділити блоку з найближчим часом відтворення. Потокова передача HTTP може застосовувати метадані. Метадані рівня представлення включають в себе, наприклад, тривалість потоку, доступні кодування (швидкості передачі бітів, кодеки, просторові дозволи, частоти кадрів, мову, типи мультимедіа), покажчики на метадані потоку для кожного кодування і захист контенту (інформацію керування цифровими правами (DRM)). Метадані потоку можуть бути URL для файлів сегментів. Метадані сегмента можуть включати в себе байтовий діапазон порівняно з часовою інформацією для запитів в сегменті та ідентифікацію Точок довільного доступу (RAP) або інших точок пошуку, причому частина або вся ця інформація може бути частиною індексування сегмента або карти сегмента. Потоки можуть містити декілька кодувань одного і того ж контенту. Кожне кодування потім можна розбити на сегменти, де кожний сегмент відповідає одиниці зберігання або файлу. У випадку HTTP сегмент звичайно є ресурсом, до якого можна звертатися по URL, і запит такого URL призводить до повернення сегмента як головної частини повідомлення у відповідь на запит. Сегменти можуть містити декілька груп зображень (GoP). Кожна GoP може додатково містити декілька фрагментів, причому індексування сегмента надає інформацію про часове/байтове зміщення для кожного фрагмента, тобто одиницею індексування є фрагмент. Фрагменти або частини фрагментів можна запитувати по паралельних з'єднаннях TCP, щоб збільшити пропускну здатність. Це може пом'якшити проблеми, які виникають при спільному використанні з'єднань у вузькому каналі або коли з'єднання втрачаються через перевантаження, відповідно збільшуючи загальну швидкість і надійність доставки, що може істотно підвищити швидкість і надійність часу перемикання контенту. Смугою пропускання можна пожертвувати заради затримки шляхом надмірного запиту, але потрібно дотримувати обережність, щоб уникнути створення запитів дуже далеко в майбутнє, що може збільшити ризик "інформаційного голоду". Декілька запитів сегментів на одному і тому ж сервері можна організувати в конвеєр (виконуючи наступний запит перед тим, як завершується поточний запит), щоб уникнути затримок запуску, що повторюються TCP. Запити послідовних фрагментів можна згрупувати в один запит. Деякі CDN віддають перевагу великим файлам і можуть ініціювати фонові вибірки всього файлу із сервера-джерела, коли перший раз бачать запит діапазону. Однак більшість CDN будуть обслуговувати запити діапазону з кеша, якщо дані доступні. Тому може бути корисним віднести деяку частину клієнтських запитів до всього файлу сегмента. Ці запити пізніше можна відмінити при необхідності. Допустимі точки перемикання можуть бути точками пошуку, зокрема RAP, в цільовому потоці. Можливі різні реалізації, наприклад фіксовані структури GoP або вирівнювання RAP по потоках (на основі початку мультимедіа або на основі GoP). У одному варіанті здійснення сегменти і GoP можуть бути вирівняні по потоках з різною швидкістю. У цьому варіанті здійснення GoP можуть мати змінний розмір і можуть містити декілька фрагментів, але фрагменти не вирівняні між потоками з різною швидкістю. У деяких варіантах здійснення може вигідно застосовуватися надмірність файлу. У цих варіантах здійснення код стирання застосовується до кожного фрагмента для формування надмірних версій даних. Переважно форматування джерела не змінюється через використання FEC, і додаткові сегменти відновлення, наприклад, у вигляді залежного відображення від початкового відображення, що містять дані відновлення FEC, формуються і стають доступними як додатковий етап в системі захоплення. Клієнт, який здатний відновити фрагмент з використанням тільки вихідних даних для того фрагмента, може запитувати від серверів тільки вихідні дані для фрагмента в сегменті. Якщо сервери недоступні або з'єднання із серверами повільне, що може визначатися або до, або після запиту вихідних даних, то можна запитати додаткові дані відновлення для фрагмента із сегмента відновлення, що зменшує час для надійної доставки достатніх даних для відновлення фрагмента, по можливості використовуючи декодування FEC, щоб використати поєднання прийнятих вихідних даних і даних відновлення для відновлення вихідних даних фрагмента. Крім того, можна запитати додаткові дані відновлення, щоб зробити можливим відновлення фрагмента, якщо фрагмент стає терміновим, тобто його час відтворення стає близьким, що збільшує частку даних для того фрагмента на лінії зв'язку, але ефективніше, ніж закриття інших з'єднань на лінії зв'язку для звільнення смуги пропускання. Це також може зменшити ризик "інформаційного голоду" від використання паралельних з'єднань. 14 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 Форматом фрагмента може бути збережений потік пакетів Транспортного протоколу в режимі реального часу (RTP) із синхронізацією звуку/відеозображення, що досягається по протоколу керування передачею в реальному масштабі часу (RTCP). Форматом сегмента також може бути збережений потік пакетів MPEG-2 із синхронізацією звуку/відеозображення, що досягається по внутрішній синхронізації транспортного потоку (TS) MPEG-2. ВИКОРИСТАННЯ СИГНАЛІЗАЦІЇ І/АБО СТВОРЕННЯ БЛОКА, ЩОБ ЗРОБИТИ ЕФЕКТИВНІШОЮ ПОТОКОВУ ПЕРЕДАЧУ Деяка кількість властивостей може використовуватися в системі потокової передачі по запиту блоків для забезпечення поліпшеної продуктивності. Продуктивність може належати до можливості відтворювати представлення без зупинки, отримання мультимедійних даних в рамках обмежень смуги пропускання і/або виконання цього в рамках обмежених ресурсів процесора на клієнтові, сервері і/або системі захоплення. Деякі з цих властивостей зараз будуть описуватися. ІНДЕКСУВАННЯ В СЕГМЕНТАХ Щоб сформулювати часткові запити GET для фрагментів фільму, клієнта можна інформувати про байтове зміщення і час початку при декодуванні або час представлення всіх мультимедійних компонентів, що містяться у фрагментах у файлі або сегменті, а також про те, які фрагменти починаються або містять Точки довільного доступу (і тому підходять для використання як точки перемикання між альтернативними відображеннями), де ця інформація часто називається індексуванням сегмента або картою сегмента. Час початку при декодуванні або час представлення можуть виражатися безпосередньо або можуть виражатися як дельти (зміни) відносно початкового моменту. Ця інформація індексування часового і байтового зміщення може потребувати щонайменше 8 байт даних на фрагмент фільму. Як приклад для двогодинного фільму, що міститься в одиночному файлі, з фрагментами фільму по 500 мс це склало б в результаті близько 112 кілобайт даних. Завантаження всіх цих даних при запуску представлення може призвести до значної додаткової затримки запуску. Однак дані про часове і байтове зміщення можуть кодуватися ієрархічно, щоб клієнт міг швидко знайти невелику порцію даних про час і зміщення, відповідну моменту в представленні, в якому він бажає почати. Інформація також може розповсюджуватися в сегменті, так що деяке уточнення індексу сегмента може розташовуватися так, що чергується з мультимедійними даними. Зазначимо, що якщо відображення розділяється за часом на декілька сегментів, використання цього ієрархічного кодування може бути не потрібним, оскільки повні дані про час і зміщення для кожного сегмента вже можуть бути досить малими. Наприклад, якщо сегменти складають одну хвилину замість двох годин у вищенаведеному прикладі, то інформація індексування часового-байтового зміщення складає близько 1 кілобайта даних, що звичайно може вміститися в один пакет TCP/IP. Різні варіанти можливі для додавання даних про часове і байтове зміщення фрагмента у файл 3GPP: По-перше, для цієї мети може використовуватися Блок довільного доступу до фрагмента фільму ("MFRA"). MFRA надає таблицю, яка може допомагати програмам зчитування у відшукуванні точок довільного доступу у файлі, використовуючи фрагменти фільму. У підтримку цій функції MFRA, між іншим, містить байтові зміщення блоків MFRA, що містять точки довільного доступу. MFRA можна вмістити в кінець файлу або поруч з ним, але це не обов'язково так. Шляхом сканування з кінця файлу в пошуках Блока зміщення довільного доступу до фрагмента фільму і використання інформації про розмір в ньому можна знайти початок блока довільного доступу до фрагмента фільму. Однак вміщення MFRA в кінець для потокової передачі HTTP звичайно потребує щонайменше 3-4 запитів HTTP для доступу до потрібних даних: щонайменше один для запиту MFRA з кінця файлу, один для отримання MFRA і нарешті, один для отримання потрібного фрагмента у файлі. Тому вміщення на початок може бути бажаним, оскільки тоді MFRA може бути завантажений разом з першими мультимедійними даними в одному запиті. Також використання MFRA для потокової передачі HTTP може бути неефективним, оскільки не потрібна ніяка інформація в "MFRA", крім часу і moof_offset, і задавання зміщень замість довжин може потребувати більше розрядів. По-друге, може використовуватися Блок розташування елементів ("ILOC"). "ILOC" надає каталог ресурсів метаданих в цьому або інших файлах шляхом визначення місцеположення файлу, що містить їх, їх зміщення в тому файлі і їх довжини. Наприклад, система могла б об'єднати всі ресурси метаданих із зовнішнім посиланням в одному файлі, відповідно 15 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 коректуючи зміщення файлів і посилання на файли. Однак "ILOC" призначений для задавання розташування метаданих, тому йому може бути важко, співіснувати з реальними метаданими. Нарешті, і можливо найбільш відповідним є опис нового блока, що називається Блоком покажчика часу ("TIDX"), спеціально виділеного для мети надавання точних моментів або тривалості фрагментів і байтового зміщення ефективним способом. Детальніше це описується в наступному розділі. Альтернативним блоком з такими ж функціональними можливостями може бути Блок індексу сегмента ("SIDX"). У цьому документі, поки не вказано інше, ці два блоки могли б бути взаємозамінними, оскільки обидва блоки забезпечують можливість надати точні моменти або тривалість фрагментів і байтове зміщення ефективним способом. Різниця між TIDX і SIDX надається нижче. Повинно бути, очевидно, як змінювати блоки TIDX і блоки SIDX, оскільки обидва блоки реалізовують індекс сегмента. ІНДЕКСУВАННЯ СЕГМЕНТА Сегмент має встановлений час початку і встановлену кількість байт. Декілька фрагментів можуть бути об'єднані в одиночний сегмент, і клієнти можуть видавати запити, які ідентифікують певний байтовий діапазон в сегменті, який відповідає необхідному фрагменту або підмножині фрагмента. Наприклад, коли HTTP використовується як протокол запиту, то для цієї мети може використовуватися Заголовок діапазону HTTP. Цей підхід потребує, щоб у клієнта був доступ до "індексу сегмента" у сегмента, який задає положення різних фрагментів в сегменті. Цей "індекс сегмента" може надаватися як частина метаданих. Цей підхід має результатом те, що треба створювати і керувати набагато меншою кількістю файлів порівняно з підходом, де кожний блок зберігається в окремому файлі. Керування створенням, передачею і зберіганням дуже великих кількостей файлів (які могли б вирости до багатьох тисяч для представлення довжиною, наприклад, за 1 годину) може бути складним і схильним до помилок, і тому скорочення кількості файлів символізує перевагу. Якщо клієнт знає тільки потрібний час початку меншої частини сегмента, то він міг би запитати весь файл, потім зчитати файл від початку до кінця для визначення відповідного місця початку відтворення. Щоб поліпшити використання смуги пропускання, сегменти можуть включати в себе індексний файл як метадані, причому індексний файл встановлює відповідність байтових діапазонів окремих блоків з часовими діапазонами, яким відповідають блоки, що називається індексуванням сегмента або картою сегмента. Ці метадані можуть бути відформатовані у вигляді XML-даних або можуть бути двійковими, наприклад, відповідаючи структурі атома і блока у форматі файлу 3GPP. Індексування може бути простим, при якому часові і байтові діапазони кожного блока є абсолютними відносно початку файлу, або вони можуть бути ієрархічними, коли деякі блоки групуються в батьківські блоки (а ті в блоки предків і т. д.), і часовий і байтовий діапазон для заданого блока виражається відносно часового і/або байтового діапазону батьківського блока цього блока. ПРИКЛАД СТРУКТУРИ КАРТИ ІНДЕКСУВАННЯ У одному варіанті здійснення вихідні дані для одного відображення мультимедійного потоку можуть міститися в одному або декількох мультимедійних файлах, що називаються в цьому документі "мультимедійним сегментом", причому кожний мультимедійний сегмент містить мультимедійні дані, що використовуються для відтворення безперервного часового сегмента мультимедіа, наприклад, 5 хвилин відтворення мультимедіа. Фіг. 6 показує зразкову загальну структуру мультимедійного сегмента. У кожному сегменті або на початку, або по всьому початковому сегменту також може бути присутньою інформація індексування, яка містить карту сегмента з часовим/байтовим зміщенням. Карта сегмента з часовим/байтовим зміщенням в одному варіанті здійснення може бути списком пар часового/байтового зміщення (Т(0), В(0)), (Т(1), В(1)), (Т(i), В(i)), (Т(n), В(n)), де Т(i-1) представляє час початку в сегменті для відтворення i-ого фрагмента мультимедіа відносно вихідного часу початку мультимедіа серед всіх мультимедійних сегментів, Т(i) представляє час закінчення для i-ого фрагмента (і відповідно час початку для наступного фрагмента), а байтове зміщення В(i-1) є відповідним індексом байта початку даних в цьому вихідному сегменті, де починається i-ий фрагмент мультимедіа відносно початку вихідного сегмента, і В(i) - відповідний індекс кінцевого байта i-го фрагмента (і відповідно індекс першого байта наступного фрагмента). Якщо сегмент містить декілька мультимедійних компонентів, то Т(i) і В(i) можуть надаватися для кожного компонента в сегменті абсолютним способом, або вони можуть виражатися відносно іншого мультимедійного компонента, який служить опорним мультимедійним компонентом. У цьому варіанті здійснення кількість фрагментів у вихідному сегменті дорівнює n, де n може змінюватися від сегмента до сегмента. 16 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 У іншому варіанті здійснення часове зміщення в індексі сегмента для кожного фрагмента може визначатися за допомогою абсолютного часу початку першого фрагмента і тривалості кожного фрагмента. У цьому випадку індекс сегмента може документувати час початку першого фрагмента і тривалість всіх фрагментів, які включаються в сегмент. Індекс сегмента також може документувати тільки підмножину фрагментів. У цьому випадку індекс сегмента документує тривалість субсегмента, який задається у вигляді одного або декількох послідовних фрагментів, що закінчуються або в кінці утримуючого сегмента, що або на початку наступного субсегмента. Для кожного фрагмента також може бути присутнім значення, яке вказує, чи починається фрагмент в точці пошуку чи містить її, тобто в точці, в якій ніяке мультимедіа після тієї точки не залежить ні від якого мультимедіа перед тією точкою, і відповідно мультимедіа далі з того фрагмента можна відтворити незалежно від попередніх фрагментів. Точки пошуку звичайно є точками в мультимедіа, причому відтворення може починатися незалежно від всіх попередніх мультимедіа. Фіг. 6 також показує простий приклад можливого індексування сегмента для вихідного сегмента. У тому прикладі значення часового зміщення виражається в одиницях мілісекунд, і відповідно перший фрагмент цього вихідного сегмента починається через 20 секунд від початку мультимедіа, і перший фрагмент має час відтворення в 485 мілісекунд. Байтове зміщення початку першого фрагмента дорівнює 0, а байтове зміщення кінця першого фрагмента/початку другого фрагмента дорівнює 50245, і відповідно перший фрагмент має розмір 50245 байт. Якщо фрагмент або субсегмент не починається з точки довільного доступу, але точка довільного доступу міститься у фрагменті або субсегменті, то може задаватися різниця часу декодування або часу представлення між часом початку і фактичним часом RAP. Це дає можливість клієнту у випадку перемикання на цей мультимедійний сегмент точно дізнатися час до того, як треба буде представити перемикання з відображення. В доповнення або замість простого або ієрархічного індексування могло б використовуватися гірляндне індексування і/або гібридне індексування. Оскільки тривалість вибірок для різних доріжок може бути не однаковою (наприклад, відліки відеосигналу могли б відображатися протягом 33 мс, тоді як звуковий відлік міг би тривати 80 мс), то різні доріжки у Фрагменті фільму могли б не починатися і закінчуватися точно в один і то ж час, тобто звук може починатися трохи раніше або трохи пізніше відеозображення, причому зворотне вірне для попереднього фрагмента, для компенсації. Щоб уникнути невизначеності, часові відмітки, задані в даних часового і байтового зміщення, можуть задаватися відносно конкретної доріжки, і це може бути одна і та ж доріжка для кожного відображення. Звичайно це буде відеодоріжка. Це дозволяє клієнту ідентифікувати точно наступний відеокадр, коли він перемикає відображення. Можна приймати міри протягом представлення, щоб підтримувати суворі відношення між шкалами часу доріжки і часом представлення, щоб забезпечити плавне відтворення і збереження синхронізації звуку/відеозображення, незважаючи на вищезазначену проблему. Фіг. 7 ілюструє деякі приклади, наприклад, простий індекс 700 та ієрархічний індекс 702. Нижче надаються два конкретні приклади блока, які містять карту сегмента, один називається Блоком покажчика часу ("TIDX"), а інший називається ("SIDX"). Визначення відповідає структурі блока відповідно до базового формату мультимедійного файлу ISO. Інші виконання для таких блоків, щоб задати аналогічний синтаксис і таку ж семантику і функціональні можливості, повинні бути очевидні читачеві. БЛОК ПОКАЖЧИКА ЧАСУ Визначення Тип блока: "tidx" Контейнер: Файл Обов'язковий: Ні Кількість: Будь-яке число з нуля або одиниці Блок покажчика часу може надати набір індексів часового і байтового зміщення, які асоціюють деякі зони файлу з деякими інтервалами часу представлення. Блок покажчика часу може включати в себе поле targettype, яке вказує тип даних, на які посилаються. Наприклад, Блок покажчика часу з "targettype moof" надає індекс Фрагментів мультимедіа, що містяться у файлі, в показниках часових і байтових зміщень. Блок покажчика часу з targettype Блока покажчика часу може використовуватися для побудови ієрархічного покажчика часу, що дозволяє користувачам файлу швидко перейти в необхідну частину індексу. Індекс сегмента може містити, наприклад, наступний синтаксис: aligned(8) class TimeIndexBox extends FullBox('frai') { unsigned int(32) targettype; 17 UA 108083 C2 5 10 15 20 25 30 35 40 45 50 55 60 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=1; i