RU2718170C2 - Определение местоположений событий доставки мультимедиа для транспортировки мультимедиа - Google Patents

Определение местоположений событий доставки мультимедиа для транспортировки мультимедиа Download PDF

Info

Publication number
RU2718170C2
RU2718170C2 RU2018124449A RU2018124449A RU2718170C2 RU 2718170 C2 RU2718170 C2 RU 2718170C2 RU 2018124449 A RU2018124449 A RU 2018124449A RU 2018124449 A RU2018124449 A RU 2018124449A RU 2718170 C2 RU2718170 C2 RU 2718170C2
Authority
RU
Russia
Prior art keywords
mde
data
locations
mdes
determining
Prior art date
Application number
RU2018124449A
Other languages
English (en)
Other versions
RU2018124449A3 (ru
RU2018124449A (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 RU2018124449A3 publication Critical patent/RU2018124449A3/ru
Publication of RU2018124449A publication Critical patent/RU2018124449A/ru
Application granted granted Critical
Publication of RU2718170C2 publication Critical patent/RU2718170C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] 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/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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Warehouses Or Storage Devices (AREA)

Abstract

Изобретение относится к средствам транспортировки мультимедийных данных. Технический результат заключается в предотвращении недостаточного наполнения буфера на клиентском устройстве. Посредством модуля отправки протокола на основе файла устройства-источника осуществляют прием потока данных, содержащих сегменты мультимедийных данных от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL). Определяют местоположения событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, определение одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство. Предоставляют MDE и данные, представляющие требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня. 4 н. и 32 з.п. ф-лы, 14 ил.

Description

[0001] Настоящая заявка испрашивает приоритет предварительной заявки США № 62/276,674, поданной 8 января 2016, содержание которой включено в настоящее описание посредством ссылки.
ОБЛАСТЬ ТЕХНИКИ
[0002] Настоящее раскрытие относится к транспортировке мультимедийных данных.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
[0003] Возможности цифрового аудио и видео могут быть включены в широкий диапазон устройств, включая цифровые телевизоры, системы цифрового прямого вещания, беспроводные широковещательные системы, персональные цифровые помощники (PDA), портативные или настольные компьютеры, цифровые камеры, устройства цифровой записи, цифровые медиаплееры, видеоигровые устройства, игровые приставки, сотовые или спутниковые радиотелефоны, устройства видеоконференц-связи и т.п.
[0004] Мультимедийные данные, такие как аудио- и видеоданные, могут быть сжаты для транспортировки. Сжатие обычно включает в себя кодирование мультимедийных данных. После того как мультимедийные данные были закодированы, видеоданные могут быть пакетированы для передачи или хранения. Мультимедийные данные могут быть скомпонованы в мультимедийный файл, соответствующий любому из множества стандартов, таких как базовый формат мультимедийных файлов Международной организации по стандартизации (ISO BMFF) и его расширения, такие как AVC.
[0005] Различные методы могут использоваться для транспортировки мультимедийных данных через компьютерную сеть. Например, мультимедийные данные могут доставляться посредством протокола широковещательной передачи или протокола одноадресной передачи. В протоколе широковещательной передачи, серверное устройство отправляет мультимедийные данные на множество клиентских устройств-подписчиков. В протоколе одноадресной передачи, клиентское устройство запрашивает мультимедийные данные с серверного устройства, а серверное устройство доставляет мультимедийные данные в ответ на запрос.
КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
[0006] В общем, настоящее раскрытие описывает методы, относящиеся к поддержке событий доставки мультимедиа (MDE), используемых, например, в доставке байтового диапазона с медиа-поддержкой через ROUTE (ATSC Working Draft: Signaling, Delivery, Synchronization, and Error Protection, November 20, 2015) и MMT (ISO/IEC: ISO/IEC 23008-1 2nd edition, Information technology-High efficiency coding and media delivery in heterogeneous environments-Part 1: MPEG media transport (MMT)) или FLUTE (RFC 6726, который является соответствующей частью ROUTE). Эти методы доставки могут дополнительно использовать широковещательную Динамическую адаптивную потоковую передачу по HTTP (DASH), Общий формат мультимедийных приложений (CMAF) или аналогичные способы доставки мультимедийных данных Сегмента или на основе байтового диапазона с поддержкой мультимедиа. Настоящее раскрытие также описывает методы определения временной маркировки обнаруженных MDE и адаптивные методы для доставки на физическом уровне, которые учитывают влияние ранней доставки мультимедиа по отношению к выровненному по медиа кадрированию физического уровня.
[0007] В одном примере, способ транспортировки мультимедийных данных включает в себя, выполняемый модулем отправки протокола на основе файла устройства-источника, прием потока данных, содержащих сегменты мультимедийных данных, от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI), определение местоположений событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, определение одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и предоставление MDE и данных, представляющих требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами (слотами) доставки для модуля отправки физического уровня.
[0008] В другом примере, устройство для транспортировки мультимедийных данных включает в себя сегментатор, сконфигурированный для формирования потока данных, содержащих сегменты мультимедийных данных, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, например, формата ISO BMFF, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI). Устройство также включает в себя модуль отправки физического уровня, сконфигурированный, чтобы доставлять события доставки мультимедиа (MDE) на клиентское устройство в соответствии с требованиями к времени передачи для MDE, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, причем модуль отправки физического уровня сконфигурирован с доступными временными интервалами доставки для приема данных, подлежащих доставке. Устройство дополнительно включает в себя модуль отправки протокола на основе файла, сконфигурированный, чтобы принимать поток данных, содержащих сегменты мультимедийных данных, от сегментатора, определять местоположения MDE в потоке мультимедийных данных, определять одно или несколько требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и предоставлять MDE и данные, представляющие требования к времени передачи, на модуль отправки физического уровня в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
[0009] В другом примере, устройство для транспортировки мультимедийных данных включает в себя сегментатор, сконфигурированный, чтобы формировать поток данных, содержащих сегменты мультимедийных данных, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI). Устройство также включает в себя модуль отправки физического уровня, сконфигурированный, чтобы доставлять события доставки мультимедиа (MDE) на клиентское устройство в соответствии с требованиями к времени передачи для MDE, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, причем модуль отправки физического уровня сконфигурирован с доступными временными интервалами доставки для приема данных, подлежащих доставке. Устройство дополнительно включает в себя средство для приема потока данных, содержащих сегменты мультимедийных данных, от сегментатора, средство для определения местоположений MDE в потоке мультимедийных данных, средство для определения одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и средство для предоставления MDE и данных, представляющих требования к времени передачи, на модуль отправки физического уровня в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
[0010] В другом примере, считываемый компьютером носитель данных содержит сохраненные на нем инструкции, которые, при исполнении, побуждают модуль отправки протокола на основе файла устройства-источника принимать поток данных, содержащих сегменты мультимедийных данных, от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI), определять местоположения событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, определять одно или несколько требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и предоставлять MDE и данные, представляющие требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
[0011] Подробности одного или нескольких примеров приведены на прилагаемых чертежах и в описании ниже. Другие признаки, задачи и преимущества будут очевидны из описания и чертежей и из формулы изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0012] Фиг. 1 - блок-схема, иллюстрирующая примерную систему, которая реализует методы потоковой передачи мультимедийных данных по сети.
[0013] Фиг. 2 - блок-схема, иллюстрирующая более подробно примерный набор компонентов модуля 52 извлечения согласно фиг. 1.
[0014] Фиг. 3 - концептуальная диаграмма, иллюстрирующая элементы примерного мультимедийного контента.
[0015] Фиг. 4 - блок-схема, иллюстрирующая элементы примерного видеофайла, который может соответствовать сегменту представления.
[0016] Фиг. 5 - блок-схема, иллюстрирующая примерную систему инфраструктуры широковещательной динамической адаптивной потоковой передачи по HTTP (DASH).
[0017] Фиг. 6 - концептуальная диаграмма, иллюстрирующая примерный состав высокого уровня MDE.
[0018] Фиг. 7 - концептуальная диаграмма, иллюстрирующая примерную каденцию (последовательность) типа кадра и соответствующие определенные MDE.
[0019] Фиг. 8 - концептуальная диаграмма, представляющая упрощенное представление системного времени.
[0020] Фиг. 9 - блок-схема, представляющая временное отношение в инфраструктуре передачи.
[0021] Фиг. 10 - концептуальная диаграмма, иллюстрирующая множество сегментов на группу изображений (картинок) (GOP) со ступенчатым местоположением точки произвольного доступа (RAP).
[0022] Фиг. 11 - концептуальная диаграмма, иллюстрирующая минимальную задержку для времени декодирования для воспроизведения мультимедиа.
[0023] Фиг. 12 - концептуальная диаграмма, иллюстрирующая опциональную синхронизацию физического уровня и связанные метаданные.
[0024] Фиг. 13 - блок-схема последовательности операций, иллюстрирующая примерную последовательность событий обнаружения.
[0025] Фиг. 14 - блок-схема последовательности операций, иллюстрирующая другой примерный способ в соответствии с методами настоящего раскрытия.
ПОДРОБНОЕ ОПИСАНИЕ
[0026] В общем, настоящее раскрытие описывает методы, связанные с транспортировкой мультимедийных данных. Методы этого раскрытия могут выполняться серверным устройством или другим устройством-источником, которое передает мультимедийные данные на клиентское устройство. В частности, устройство-источник может включать в себя сегментатор, модуль отправки протокола на основе файла и модуль отправки физического уровня. Сегментатор может соответствовать модулю, который формирует сегменты мультимедийных данных, причем сегменты соответствуют, например, сегментам динамической адаптивной потоковой передачи по HTTP (DASH). Например, сегментатор может инкапсулировать единицы уровня сетевой абстракции (NAL) в соответствующие сегменты DASH, где каждый сегмент может быть ассоциирован с отдельным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI). Модуль отправки протокола на основе файла может быть сконфигурирован, чтобы отправлять данные с использованием протокола на основе файла, такого как Доставка файла однонаправленной транспортировкой (FLUTE) или ROUTE. Модуль отправки физического уровня может отправлять мультимедийные данные на физическом уровне, например, используя Ethernet.
[0027] В соответствии с методами, описанными в настоящем раскрытии, сегментатор может предоставлять сегменты мультимедийных данных в форме потока сегментов на модуль отправки протокола на основе файла. Таким образом, модуль отправки протокола на основе файла может принимать поток данных, включающий в себя сегменты мультимедийных данных, от сегментатора. Затем модуль отправки протокола на основе файла может определять местоположения событий доставки мультимедиа (MDE) в потоке мультимедийных данных. В одном примере, модуль отправки протокола на основе файла может формировать MDE из потока мультимедийных данных. Например, модуль отправки протокола на основе файла может определять, какие части потока должны быть включены в конкретное MDE, так что MDE включает в себя данные, которые полезны для декодера мультимедийных данных (например, данные, которые могут быть надлежащим образом декодированы посредством декодера мультимедийных данных, в предположении, что предыдущие данные были доставлены корректным образом).
[0028] Для определения местоположений MDE, модуль отправки протокола на основе файла может использовать методы сопоставления шаблонов, в которых модуль отправки протокола на основе файла сконфигурирован с одним или несколькими шаблонами для мультимедийных данных, включенных в поток. Такие шаблоны могут представлять, например, упорядочение мультимедийных данных в иерархическом порядке декодирования. Например, видеоданные могут быть упорядочены в соответствии с определенным количеством интра-предсказанных (с внутрикадровым предсказанием) кадров (I-кадров), за которыми следует определенное количество однонаправленных интер-предсказанных (с межкадровым предсказанием) кадров (P-кадров), за которыми следует (или заполняется в промежутках) определенное количество двунаправленных интер-предсказанных кадров (B-кадров). Модуль отправки протокола на основе файла может определять местоположения MDE на основе обнаружения I-, P- и B-кадров и, например, определять, что MDE включает в себя видеопоследовательность, начинающуюся с первого I-кадра и заканчивающуюся последним B-кадром перед последующим I-кадром, в качестве одного примера. Кроме того, модуль отправки протокола на основе файла может определять, что видео MDE соответствует конкретному байтовому диапазону сегмента, где байтовый диапазон заканчивается на границе кадра. В качестве другого примера, модуль отправки протокола на основе файла может определять, что аудио MDE содержат фиксированное количество аудиокадров.
[0029] В качестве другого примера, чтобы определить местоположения MDE (например, для формирования MDE), модуль отправки протокола на основе файла может быть сконфигурирован в соответствии с правилами, которые определяют местоположения различных типов мультимедийных данных, таких как аудиоданные, видеоданные и/или временные текстовые данные, в потоке. Правила могут определять, например, расположение различных типов мультимедийных данных в потоке, так что модуль отправки протокола на основе файла может различать типы мультимедийных данных и распределять типы мультимедийных данных по соответствующим MDE.
[0030] Кроме того, модуль отправки протокола на основе файла также может определять одно или несколько требований к времени доставки (также называемых требованиями к времени передачи) для MDE, где требования к времени передачи представляют моменты времени, в которые MDE должны быть отправлены на клиентское устройство. Например, требования к времени передачи могут представлять собой самые ранние и/или самые последние моменты времени, когда MDE должны быть отправлены на клиентское устройство. MDE могут иметь требования самого раннего времени, в которое MDE могут быть отправлены на клиентское устройство, чтобы, например, предотвратить переполнение буфера на клиентском устройстве. MDE могут также иметь требования самого последнего времени, в которое MDE могут быть отправлены на клиентское устройство, чтобы, например, предотвратить недостаточное наполнение буфера на клиентском устройстве.
[0031] Модуль отправки протокола на основе файла может затем отправлять MDE в модуль отправки физического уровня вместе с данными, представляющими требования к времени передачи. В частности, модуль отправки протокола на основе файла может определять доступные временные интервалы доставки для модуля отправки физического уровня и отправлять MDE и данные требований к времени передачи на модуль отправки физического уровня, так что модуль отправки физического уровня может доставлять MDE в соответствии с требованиями к времени передачи.
[0032] Устройство-источник, рассмотренное выше, может быть сконфигурировано для потоковой передачи данных в соответствии с протоколом потоковой передачи HTTP, таким как DASH. В потоковой передаче HTTP, часто используемые операции включают HEAD, GET и частичное GET. Операция HEAD извлекает заголовок файла, ассоциированного с данным унифицированным указателем ресурса (URL), унифицированным именем ресурса (URN) или унифицированным идентификатором ресурса (URI), без извлечения полезной нагрузки, ассоциированной с URL, URN или URI. Операция GET извлекает весь файл, связанный с данным URL, URN или URI. Операция частичного GET принимает байтовый диапазон в качестве входного параметра и извлекает непрерывное количество байтов файла, где количество байтов соответствует принятому байтовому диапазону. Таким образом, фрагменты фильма могут быть предоставлены для потоковой передачи HTTP, поскольку операция частичного GET может получить один или несколько отдельных фрагментов фильма. Во фрагменте фильма может быть несколько фрагментов трека из разных треков. В потоковой передаче HTTP представление мультимедиа может представлять собой структурированный набор данных, доступных клиенту. Клиент может запрашивать и загружать информацию мультимедийных данных, чтобы предоставлять пользователю услугу потоковой передачи.
[0033] В примере потоковой передачи 3GPP-данных с использованием потоковой передачи HTTP, может иметься несколько представлений для видео- и/или аудиоданных мультимедийного контента. Как объяснено ниже, различные представления могут соответствовать различным характеристикам кодирования (например, различным профилям или уровням стандарта кодирования видео), различным стандартам кодирования или расширениям стандартов кодирования (таких как многовидовые и/или масштабируемые расширения) или различным битрейтам (битовым скоростям). Проявление таких представлений может быть определено в структуре данных описания представления мультимедиа (MPD). Представление мультимедиа может соответствовать структурированному набору данных, доступному для клиентского устройства потоковой передачи HTTP. Клиентское устройство потоковой передачи HTTP может запрашивать и загружать информацию мультимедийных данных для предоставления потоковой услуги пользователю клиентского устройства. Представление мультимедиа может быть описано в структуре данных MPD, которая может включать в себя обновления MPD.
[0034] Представление мультимедиа может содержать последовательность из одного или нескольких периодов. Периоды могут быть определены элементом Period (период) в MPD. Каждый период может иметь атрибут start (начало) в MPD. MPD может включать в себя атрибут start и атрибут availableStartTime (доступное время начала) для каждого периода. Для услуг реального времени, сумма атрибута start периода и атрибута availableStartTime MPD может указывать время доступности периода в формате UTC, в частности, первый сегмент мультимедиа каждого представления в соответствующем периоде. Для услуг по требованию атрибут start первого периода может быть 0. Для любого другого периода, атрибут start может указывать смещение по времени между временем начала соответствующего периода относительно времени начала первого периода. Каждый период может длиться до начала следующего периода или до конца представления мультимедиа в случае последнего периода. Времена начала периода могут быть точными. Они могут отражать фактическую временную диаграмму, являющуюся результатом воспроизведения мультимедиа всех предыдущих периодов.
[0035] Каждый период может содержать одно или несколько представлений для одного и того же мультимедийного контента. Представление может быть одним из нескольких альтернативных закодированных версий аудио- или видеоданных. Представления могут различаться типами кодирования, например, битрейтом, разрешением и/или кодеком для видеоданных и битрейтом, языком и/или кодеком для аудиоданных. Срочное представление может использоваться, чтобы ссылаться на секцию (раздел) закодированных аудио- или видеоданных, соответствующих конкретному периоду мультимедийного контента и закодированных определенным образом.
[0036] Представления конкретного периода могут быть назначены группе, указанной атрибутом в MPD, указывающим набор адаптации, к которому принадлежат представления. Представления в одном наборе адаптации обычно рассматриваются как альтернативы друг другу в том смысле, что клиентское устройство может динамически и плавно переключаться между этими представлениями, например, для выполнения адаптации к ширине полосы (пропускной способности). Например, каждое представление видеоданных за конкретный период может быть назначено одному набору адаптации, так что любое из представлений может быть выбрано для декодирования для представления мультимедийных данных, таких как видеоданные или аудиоданные, мультимедийного контента для соответствующего периода. Мультимедийный контент в течение одного периода может быть представлен любым одним из представлений из группы 0, если они есть, или комбинацией не более одного представления из каждой ненулевой группы, в некоторых примерах. Данные о времени (синхронизации) для каждого представления периода могут быть выражены относительно времени начала периода.
[0037] Представление может включать в себя один или несколько сегментов. Каждое представление может включать в себя сегмент инициализации, или каждый сегмент представления может быть само-инициализирующимся. Когда присутствует, сегмент инициализации может содержать информацию инициализации для доступа к представлению. Как правило, сегмент инициализации не содержит мультимедийных данных. На сегмент можно однозначно ссылаться посредством идентификатора, такого как унифицированный указатель ресурса (URL), унифицированное имя ресурса (URN) или унифицированный идентификатор ресурса (URI). MPD может предоставлять идентификаторы для каждого сегмента. В некоторых примерах MPD также может предоставлять байтовые диапазоны в форме атрибута range (диапазон), который может соответствовать данным для сегмента в файле, доступном посредством URL, URN или URI.
[0038] Различные представления могут быть выбраны для по существу одновременного извлечения для различных типов мультимедийных данных. Например, клиентское устройство может выбирать аудио представление, видео представление и временное текстовое представление, из которого извлекаются сегменты. В некоторых примерах, клиентское устройство может выбирать определенные наборы адаптации для выполнения адаптации к пропускной способности. То есть, клиентское устройство может выбирать набор адаптации, включающий в себя видео представления, набор адаптации, включающий в себя аудио представления, и/или набор адаптации, включающий в себя временной (спланированный по времени, синхронизированный) текст. В качестве альтернативы, клиентское устройство может выбирать наборы адаптации для определенных типов мультимедиа (например, видео) и непосредственно выбирать представления для других типов мультимедиа (например, аудио и/или синхронизированный текст).
[0039] Фиг. 1 является блок-схемой, иллюстрирующей примерную систему 10, которая реализует методы потоковой передачи мультимедийных данных по сети. В этом примере, система 10 включает в себя устройство 20 подготовки контента, серверное устройство 60 и клиентское устройство 40. Клиентское устройство 40 и серверное устройство 60 коммуникативно связаны сетью 74, которая может содержать Интернет. В некоторых примерах, устройство 20 подготовки контента и серверное устройство 60 также могут быть связаны сетью 74 или другой сетью или могут быть непосредственно коммуникативно связаны. В некоторых примерах, устройство 20 подготовки контента и серверное устройство 60 могут содержать одно и то же устройство.
[0040] Устройство 20 подготовки контента в примере на фиг. 1, содержит источник 22 аудио и источник 24 видео. Источник 22 аудио может содержать, например, микрофон, который формирует электрические сигналы, представляющие захваченные аудиоданные, которые должны быть закодированы аудиокодером 26. Альтернативно, источник 22 аудио может содержать устройство хранения данных, хранящее ранее записанные аудиоданные, генератор аудиоданных, такой как компьютеризованный синтезатор, или любой другой источник аудиоданных. Источник 24 видео может содержать видеокамеру, которая формирует видеоданные, которые должны быть закодированы видеокодером 28, носитель хранения данных, закодированный ранее записанными видеоданными, модуль генерации видеоданных, такой как источник компьютерной графики, или любой другой источник видеоданных. Устройство 20 подготовки контента не обязательно коммуникативно связано с серверным устройством 60 во всех примерах, но может хранить мультимедийный контент на отдельном носителе, который считывается серверным устройством 60.
[0041] Необработанные (исходные) аудио- и видеоданные могут содержать аналоговые или цифровые данные. Аналоговые данные могут быть оцифрованы перед кодированием аудиокодером 26 и/или видеокодером 28. Источник 22 аудио может получать аудиоданные от говорящего участника, когда говорящий участник говорит, а источник 24 видео может одновременно получать видеоданные говорящего участника. В других примерах, источник 22 аудио может содержать считываемый компьютером носитель данных, содержащих сохраненные аудиоданные, а источник 24 видео может содержать считываемый компьютером носитель данных, содержащих сохраненные видеоданные. Таким образом, методы, описанные в настоящем раскрытии, могут применяться для реальных, потоковых, аудио- и видеоданных в реальном времени или для архивированных, предварительно записанных аудио- и видеоданных.
[0042] Аудиокадры, которые соответствуют видеокадрам, обычно представляют собой аудиокадры, содержащие аудиоданные, которые были захвачены (или сгенерированы) источником 22 аудио одновременно с видеоданными, захваченными (или сгенерированными) источником 24 видео, которые содержатся в видеокадрах. Например, в то время как говорящий участник в общем производит аудиоданные в разговоре, источник 22 аудио захватывает аудиоданные, а источник 24 видео одновременно захватывает видеоданные говорящего участника, то есть, в то время когда источник 22 аудио захватывает аудиоданные. Следовательно, аудиокадр может соответствовать по времени одному или нескольким конкретным видеокадрам. Соответственно, аудиокадр, соответствующий видеокадру, обычно соответствует ситуации, в которой аудиоданные и видеоданные были захвачены одновременно, и для которой аудиокадр и видеокадр содержат, соответственно, аудиоданные и видеоданные, которые были захвачены одновременно.
[0043] В некоторых примерах, аудиокодер 26 может кодировать временную метку в каждом закодированном аудиокадре, которая представляет время, в которое были записаны аудиоданные для кодированного аудиокадра, и аналогичным образом видеокодер 28 может кодировать временную метку в каждом кодированном видеокадре, которая представляет время, в которое записывались видеоданные для кодированного видеокадра. В таких примерах, аудиокадр, соответствующий видеокадру, может содержать аудиокадр, содержащий временную метку, а видеокадр может содержать ту же самую временную метку. Устройство 20 подготовки контента может включать в себя внутренние часы, из которых аудиокодер 26 и/или видеокодер 28 могут генерировать временные метки, или которые источник 22 аудио и источник 24 видео могут использовать, чтобы ассоциировать аудио- и видеоданные, соответственно, с временной меткой.
[0044] В некоторых примерах, источник 22 аудио может отправлять данные в аудиокодер 26 в соответствии с временем, в которое записывались аудиоданные, а источник 24 видео может отправлять данные в видеокодер 28 в соответствии с временем, в которое записывались видеоданные. В некоторых примерах, аудиокодер 26 может кодировать идентификатор последовательности в закодированных аудиоданных для указания относительного временного порядка закодированных аудиоданных, но без обязательного указания абсолютного времени, в которое записывались аудиоданные, и аналогичным образом, видеокодер 28 может также использовать идентификаторы последовательности для указания относительного временного порядка закодированных видеоданных. Аналогичным образом, в некоторых примерах, идентификатор последовательности может отображаться или иным образом коррелироваться с временной меткой.
[0045] Аудиокодер 26 обычно формирует поток закодированных аудиоданных, тогда как видеокодер 28 формирует поток закодированных видеоданных. Каждый отдельный поток данных (аудио или видео) может упоминаться как элементарный поток. Элементарный поток представляет собой одиночный цифровой (возможно сжатый) компонент представления. Например, кодированная видео или аудио часть представления может быть элементарным потоком. Элементарный поток может быть преобразован в пакетированный элементарный поток (PES) перед инкапсулированием в видеофайле. В том же представлении, ID потока может использоваться для того, чтобы различать пакеты PES, принадлежащие одному элементарному потоку, от других. Базовой единицей данных элементарного потока является пакет пакетированного элементарного потока (PES). Таким образом, закодированные видеоданные в общем соответствуют элементарным видеопотокам. Аналогично, аудиоданные соответствуют одному или нескольким элементарным потокам.
[0046] В примере на фиг. 1, модуль 30 инкапсуляции устройства 20 подготовки контента принимает элементарные потоки, содержащие закодированные видеоданные, от видеокодера 28 и элементарные потоки, содержащие закодированные аудиоданные, от аудиокодера 26. В некоторых примерах, видеокодер 28 и аудиокодер 26 могут включать в себя, каждый, пакетизатор для формирования пакетов PES из закодированных данных. В других примерах, видеокодер 28 и аудиокодер 26 могут взаимодействовать, каждый, с соответствующими пакетизаторами для формирования пакетов PES из закодированных данных. В других примерах, модуль 30 инкапсуляции может включать в себя пакетизаторы для формирования пакетов PES из закодированных аудио- и видеоданных.
[0047] Видеокодер 28 может кодировать видеоданные мультимедийного контента различными способами, чтобы формировать различные представления мультимедийного контента с различными битрейтами и с различными характеристиками, такими как пиксельное разрешение, частота кадров, соответствие различным стандартам кодирования, соответствие различным профилям и/или уровням профилей для различных стандартов кодирования, представления, имеющие один или несколько видов (например, для двумерного или трехмерного воспроизведения), или другие такие характеристики. Представление, как используется в настоящем раскрытии, может содержать одно из аудиоданных, видеоданных, текстовых данных (например, для скрытых титров) или другие такие данные. Представление может включать в себя элементарный поток, такой как аудио элементарный поток или видео элементарный поток. Каждый пакет PES может включать в себя steam_id, который идентифицирует элементарный поток, к которому принадлежит пакет PES. Модуль 30 инкапсуляции отвечает за сборку элементарных потоков в видеофайлы (например, сегменты) различных представлений.
[0048] Модуль 30 инкапсуляции принимает пакеты PES для элементарных потоков представления от аудиокодера 26 и видеокодера 28 и формирует соответствующие единицы уровня сетевой абстракции (NAL) из пакетов PES. В примере H.264/AVC (расширенное кодирование видео), сегменты кодированного видео организованы в единицы NAL, которые предоставляют ʺудобные для (адаптированные к) сетиʺ приложения для представления видео, такие как видеотелефония, хранение, трансляция или потоковая передача. Единицы NAL могут быть распределены по категориям на единицы NAL уровня кодирования видео (VCL) и единицы не-VCL NAL. Единицы VCL могут содержать механизм сжатия ядра и могут включать в себя данные уровня блока, макроблока и/или вырезки. Другие единицы NAL могут представлять собой единицы не-VCL NAL. В некоторых примерах, кодированная картинка в один момент времени, обычно представленная как первично закодированная картинка, может содержаться в единице доступа, которая может включать в себя одну или несколько единиц NAL.
[0049] Единицы не-VCL NAL могут включать в себя, среди прочего, единицы NAL набора параметров и единицы SEI NAL. Наборы параметров могут содержать информацию заголовка уровня последовательности (в наборах параметров последовательности (SPS)) и редко изменяющуюся информацию заголовка уровня картинки (в наборах параметров картинки (PPS)). С наборами параметров (например, PPS и SPS), редко изменяющуюся информацию не требуется повторять для каждой последовательности или картинки, поэтому эффективность кодирования может быть улучшена. Кроме того, использование наборов параметров может обеспечить возможность внеполосной передачи важной информации заголовка, избегая необходимости в избыточных передачах для устойчивости к ошибкам. В примерах внеполосной передачи, единицы NAL набора параметров могут передаваться на другом канале, чем другие единицы NAL, такие как единицы SEI NAL.
[0050] Дополнительная информация об улучшении (SEI) может содержать информацию, которая необязательна для декодирования закодированных выборок картинок из единиц VCL NAL, но может содействовать в процессах, связанных с декодированием, отображением, устойчивостью к ошибкам и другими целями. Сообщения SEI могут содержаться в единицах не-VCL NAL. Сообщения SEI являются нормативной частью некоторых стандартных спецификаций и, следовательно, не всегда являются обязательными для совместимой со стандартом реализации декодера. Сообщения SEI могут представлять собой сообщения SEI уровня последовательности или сообщения SEI уровня картинки (изображения). Некоторая информация уровня последовательности может содержаться в сообщениях SEI, таких как сообщения SEI с информацией о масштабируемости в примере SVC и сообщения SEI с информацией о масштабируемости в MVC. Эти примерные сообщения SEI могут переносить информацию, например, об извлечении рабочих точек и характеристиках рабочих точек. Кроме того, модуль 30 инкапсуляции может формировать файл манифеста (описания), такой как дескриптор представления мультимедиа (MPD), который описывает характеристики представлений. Модуль 30 инкапсуляции может форматировать MPD в соответствии с расширяемым языком разметки (XML).
[0051] Модуль 30 инкапсуляции может предоставлять данные для одного или нескольких представлений мультимедийного контента вместе с файлом манифеста (например, MPD) на интерфейс 32 вывода. Интерфейс 32 вывода может содержать сетевой интерфейс или интерфейс для записи на носитель хранения данных, такой как интерфейс универсальной последовательной шины (USB), средство или устройство записи CD или DVD, интерфейс для магнитных или флеш-носителей хранения данных или другие интерфейсы для хранения или передачи мультимедийных данных. Модуль 30 инкапсуляции может предоставлять данные каждого из представлений мультимедийного контента в интерфейс 32 вывода, который может отправлять данные на серверное устройство 60 через сетевую передачу или носитель хранения данных. В примере на фиг. 1, серверное устройство 60 включает в себя носитель 62 хранения данных, который хранит различный мультимедийный контент 64, каждый из которых включает в себя соответствующий файл 66 манифеста и одно или несколько представлений 68A-68N (представлений 68). В некоторых примерах интерфейс 32 вывода может также отправлять данные непосредственно в сеть 74.
[0052] В некоторых примерах, представления 68 могут быть разделены на наборы адаптации. То есть, различные поднаборы представлений 68 могут включать в себя соответствующие общие наборы характеристик, такие как кодек, профиль и уровень, разрешение, количество видов, файловый формат для сегментов, информация о типе текста, которая может идентифицировать язык или другие характеристики текста, подлежащего отображению с представлением, и/или аудиоданные, подлежащие декодированию и представлению, например, динамиками, информация об углах камеры, которая может описывать угол камеры или реальную перспективу камеры сцены для представлений в наборе адаптации, информация о рейтинге, которая описывает пригодность контента для конкретных аудиторий, или тому подобное.
[0053] Файл 66 манифеста может включать в себя данные, указывающие поднаборы представлений 68, соответствующие конкретным наборам адаптации, и общие характеристики для наборов адаптации. Файл 66 манифеста может также включать в себя данные, представляющие индивидуальные характеристики, такие как битрейты, для отдельных представлений наборов адаптации. Таким образом, набор адаптации может обеспечить упрощенную адаптацию к пропускной способности сети. Представления в наборе адаптации могут быть указаны с использованием дочерних элементов для элемента набора адаптации из файла 66 манифеста.
[0054] Серверное устройство 60 включает в себя модуль 70 обработки запроса и сетевой интерфейс 72. В некоторых примерах, серверное устройство 60 может включать в себя множество сетевых интерфейсов. Кроме того, любые или все из функций серверного устройства 60 могут быть реализованы на других устройствах сети доставки контента, таких как маршрутизаторы, мосты, прокси-устройства, коммутаторы или другие устройства. В некоторых примерах, промежуточные устройства сети доставки контента могут кэшировать данные мультимедийного контента 64 и включать в себя компоненты, которые в основном соответствуют компонентам серверного устройства 60. В общем, сетевой интерфейс 72 сконфигурирован для отправки и приема данных по сети 74.
[0055] Модуль 70 обработки запроса сконфигурирован для приема сетевых запросов от клиентских устройств, таких как клиентское устройство 40, для данных носителя 62 хранения данных. Например, модуль 70 обработки запроса может реализовывать протокол передачи гипертекста (HTTP) версии 1.1, как описано в RFC 2616, ʺHypertext Transfer Protocol - HTTP/1.1ʺ, R. Fielding et al, Network Working Group, IETF, June 1999. То есть, модуль 70 обработки запроса может быть сконфигурирован для приема запросов HTTP GET или частичного GET и предоставления данных мультимедийного контента 64 в ответ на запросы. Запросы могут указывать сегмент одного из представлений 68, например, используя URL или URI сегмента. В некоторых примерах, запросы могут также указывать один или несколько байтовых диапазонов сегмента, таким образом, включая запросы частичного GET. Модуль 70 обработки запроса также может быть сконфигурирован для обслуживания запросов HTTP HEAD для предоставления данных заголовка сегмента одного из представлений 68. В любом случае, модуль 70 обработки запроса может быть сконфигурирован для обработки запросов, чтобы предоставлять запрошенные данные запрашивающему устройству, такому как клиентское устройство 40.
[0056] Дополнительно или альтернативно, модуль 70 обработки запроса может быть сконфигурирован для доставки мультимедийных данных через широковещательный или многоадресный протокол, такой как eMBMS или DVB-T/T2. Устройство 20 подготовки контента может создавать сегменты DASH и/или подсегменты по существу таким же образом, как описано, но серверное устройство 60 может доставлять эти сегменты или подсегменты с использованием eMBMS, DVB-T/T2 или другого широковещательного или многоадресного сетевого транспортного протокола. Например, модуль 70 обработки запроса может быть сконфигурирован для приема запроса присоединения к группе многоадресной (групповой) передачи от клиентского устройства 40. То есть, серверное устройство 60 может объявлять адрес Интернет-протокола (IP), ассоциированный с группой многоадресной передачи, на клиентские устройства, включая клиентское устройство 40, ассоциированный с конкретным мультимедийным контентом (например, трансляцией реального события). Клиентское устройство 40, в свою очередь, может направить запрос на присоединение к группе многоадресной передачи. Этот запрос может распространяться через сеть 74, например, на маршрутизаторы, составляющие сеть 74, так что маршрутизаторы побуждаются направлять трафик, предназначенный для IP-адреса, ассоциированного с группой многоадресной передачи, на клиентские устройства-подписчики, такие как клиентское устройство 40.
[0057] Кроме того, сетевой интерфейс 72 серверного устройства 60 может быть сконфигурирован для выполнения методов настоящего раскрытия. Дополнительно или альтернативно, модуль 70 обработки запроса и сетевой интерфейс 72 могут быть сконфигурированы для выполнения методов настоящего раскрытия. В целях пояснения, предполагается, что сетевой интерфейс 72 включает в себя подкомпоненты, которые явно не показаны на фиг. 1, такие как различные примеры, рассмотренные более подробно ниже. Например, сетевой интерфейс 72 может включать в себя отправитель, планировщик, формирователь кадров и усилитель-возбудитель. Кроме того, в этом примере модуль 30 инкапсуляции представляет собой пример сегментатора (то есть модуля, который формирует сегменты мультимедийных данных, где сегменты представляют отдельные файлы, ассоциированные с соответствующими URL/URI). В частности, модуль 30 инкапсуляции может инкапсулировать MDE в сегментах, где каждый сегмент может включать в себя одно или несколько MDE.
[0058] В соответствии с методами настоящего раскрытия, модуль 30 инкапсуляции может обеспечивать поток сегментов мультимедийных данных на серверное устройство 60, которое в конечном итоге направляет поток сегментов в сетевой интерфейс 72 для передачи на клиентское устройство 40. Поток сегментов может соответствовать представлению, такому как одно из представлений 68. Кроме того, модуль 30 инкапсуляции может предоставлять данные, представляющие требования к времени передачи для MDE, включенных в сегменты, на серверное устройство 60, которое в свою очередь в конечном итоге направляет требования к времени передачи на сетевой интерфейс 72. Например, требования к времени передачи могут быть указаны в файле 66 манифеста. Требования к времени передачи обычно указывают самое раннее и/или самое последнее время, когда MDE должны быть доставлены на клиентское устройство 40. Таким образом, сетевой интерфейс 72 может отправлять MDE (например, сегменты или байтовые диапазоны сегментов) на клиентское устройство 40 в соответствии с требованиями к времени передачи. Например, сетевой интерфейс 72 может доставлять MDE таким образом, что MDE поступают не раньше, чем самое раннее время передачи, и/или не позднее самого последнего времени передачи на клиентское устройство 40.
[0059] Как показано в примере на фиг. 1, мультимедийный контент 64 включает в себя файл 66 манифеста, который может соответствовать описанию представления мультимедиа (MPD). Файл 66 манифеста может содержать описания различных альтернативных представлений 68 (например, услуг видео с различными качествами), и описание может включать в себя, например, информацию кодека, значение профиля, значение уровня, битрейт и другие описательные характеристики представлений 68. Клиентское устройство 40 может извлекать MPD представления мультимедиа для определения, как получать доступ к сегментам представлений 68.
[0060] В частности, модуль 52 извлечения может извлекать данные конфигурации (не показаны) клиентского устройства 40 для определения возможностей декодирования видеодекодера 48 и возможностей визуализации видеовыхода 44. Данные конфигурации могут также включать в себя любые или все из языкового предпочтения, выбранного пользователем клиентского устройства 40, одной или нескольких перспектив камеры, соответствующих предпочтениям глубины, установленным пользователем клиентского устройства 40, и/или предпочтения рейтинга, выбранного пользователем клиентского устройства 40. Модуль 52 извлечения может содержать, например, веб-браузер или мультимедийный клиент, сконфигурированный, чтобы отправлять запросы HTTP GET и частичного GET. Модуль 52 извлечения может соответствовать инструкциям программного обеспечения, исполняемым одним или несколькими процессорами или блоками обработки (не показаны) клиентского устройства 40. В некоторых примерах, все или части функциональных возможностей, описанных в отношении модуля 52 извлечения, могут быть реализованы в аппаратных средствах или в сочетании аппаратных средств, программного обеспечения и/или встроенного программного обеспечения, где требуемые аппаратные средства могут быть обеспечены, чтобы исполнять инструкции для программного обеспечения или встроенного программного обеспечения.
[0061] Модуль 52 извлечения может сравнивать возможности декодирования и визуализации (рендеринга) клиентского устройства 40 с характеристиками представлений 68, указанными информацией файла 66 манифеста. Модуль 52 извлечения может сначала извлечь по меньшей мере часть файла 66 манифеста для определения характеристик представлений 68. Например, модуль 52 извлечения может запрашивать часть файла 66 манифеста, которая описывает характеристики одного или нескольких наборов адаптации. Модуль 52 извлечения может выбирать поднабор представлений 68 (например, набор адаптации), имеющих характеристики, которые могут быть удовлетворены возможностями кодирования и визуализации клиентского устройства 40. Модуль 52 извлечения может затем определять битрейты для представлений в наборе адаптации, определять доступную в текущее время величину пропускной способности сети и извлекать сегменты из одного из представлений, имеющих битрейт, который может быть удовлетворен пропускной способностью сети.
[0062] В общем, представления более высокого битрейта могут обеспечить воспроизведение видео более высокого качества, тогда как представления более низкого битрейта могут обеспечить воспроизведение видео достаточного качества, когда доступная пропускная способность сети снижается. Соответственно, когда доступная пропускная способность сети относительно высока, модуль 52 извлечения может извлекать данные из представлений относительно высокого битрейта, а когда доступная пропускная способность сети низкая, модуль 52 извлечения может извлекать данные из представлений относительно низкого битрейта. Таким образом, клиентское устройство 40 может осуществлять потоковую передачу мультимедийных данных по сети 74, одновременно адаптируясь к изменяющейся доступности сетевой пропускной способности сети 74.
[0063] Дополнительно или альтернативно, модуль 52 извлечения может быть сконфигурирован для приема данных в соответствии с широковещательным или многоадресным сетевым протоколом, таким как eMBMS или IP многоадресная передача. В таких примерах, модуль 52 извлечения может отправить запрос на присоединение к сетевой группе многоадресной передачи, ассоциированной с конкретным мультимедийным контентом. После присоединения к группе многоадресной передачи, модуль 52 извлечения может принимать данные группы многоадресной передачи без дополнительных запросов, выдаваемых на серверное устройство 60 или устройство 20 подготовки контента. Модуль 52 извлечения может отправить запрос о выходе из группы многоадресной передачи, когда нет необходимости в данных группы многоадресной передачи, например, для остановки воспроизведения или для переключения каналов на другую группу многоадресной передачи.
[0064] Сетевой интерфейс 54 может принимать и предоставлять данные сегментов выбранного представления на модуль 52 извлечения, который, в свою очередь, может предоставить сегменты на модуль 50 декапсуляции. Модуль 50 декапсуляции может декапсулировать элементы видеофайла в компонентные потоки PES, депакетировать потоки PES для извлечения закодированных данных и отправлять закодированные данные на аудиодекодер 46 или видеодекодер 48 в зависимости от того, являются ли закодированные данные частью аудио- или видеопотока, например, как указано заголовками пакета PES потока. Аудиодекодер 46 декодирует закодированные аудиоданные и отправляет декодированные аудиоданные на аудиовыход 42, тогда как видеодекодер 48 декодирует кодированные видеоданные и отправляет декодированные видеоданные, которые могут включать в себя множество видов (представлений) потока, на видеовыход 44.
[0065] Видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, модуль 30 инкапсуляции, модуль 52 извлечения и модуль 50 декапсуляции, каждый, могут быть реализованы как любая из множества подходящих схем обработки, как это применимо, таких как один или несколько микропроцессоров, процессоров цифровых сигналов (DSP), специализированных интегральных схем (ASIC), программируемых вентильных матриц (FPGA), дискретных логических схем, программное обеспечение, аппаратные средства, встроенное программное обеспечение или любые их комбинации. Каждый из видеокодера 28 и видеодекодера 48 может быть включен в один или несколько кодеров или декодеров, каждый из которых может быть интегрирован как часть объединенного видеокодера/декодера (кодека). Аналогично, каждый из аудиокодера 26 и аудиодекодера 46 может быть включен в один или несколько кодеров или декодеров, каждый из которых может быть интегрирован как часть объединенного кодека. Устройство, включающее в себя видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, модуль 30 инкапсуляции, модуль 52 извлечения и/или модуль 50 декапсуляции, может содержать интегральную схему, микропроцессор и/или устройство беспроводной связи, такое как сотовый телефон.
[0066] Клиентское устройство 40, серверное устройство 60 и/или устройство 20 подготовки контента могут быть сконфигурированы для работы в соответствии с методами настоящего раскрытия. К примеру, настоящее раскрытие описывает эти методы в отношении клиентского устройства 40 и серверного устройства 60. Однако следует понимать, что устройство 20 подготовки контента может быть сконфигурировано для выполнения этих методов вместо серверного устройства 60 или в дополнение к нему.
[0067] Модуль 30 инкапсуляции может формировать единицы NAL, содержащие заголовок, который идентифицирует программу, к которой принадлежит единица NAL, а также полезную нагрузку, например, аудиоданные, видеоданные или данные, которые описывают транспортный или программный поток, которому соответствует единица NAL. Например, в H.264/AVC, единица NAL включает в себя 1-байтовый заголовок и полезную нагрузку разного размера. Единица NAL, включающая в себя видеоданные в своей полезной нагрузке, может содержать различные уровни детализации видеоданных. Например, единица NAL может содержать блок видеоданных, множество блоков, вырезку видеоданных или целое изображение (картинку) видеоданных. Модуль 30 инкапсуляции может принимать кодированные видеоданные от видеокодера 28 в форме пакетов PES элементарных потоков. Модуль 30 инкапсуляции может ассоциировать каждый элементарный поток с соответствующей программой.
[0068] Модуль 30 инкапсуляции также может компоновать единицы доступа из множества единиц NAL. В общем, единица доступа может содержать одну или несколько единиц NAL для представления кадра видеоданных, а также аудиоданные, соответствующие кадру, когда такие аудиоданные доступны. Единица доступа обычно включает в себя все единицы NAL для одного временного экземпляра (выборки) вывода, например, все аудио- и видеоданные для одного временного экземпляра. Например, если каждое представление имеет частоту кадров 20 кадров в секунду (кадр/с), то каждый временной экземпляр может соответствовать временному интервалу 0,05 секунды. В течение этого временного интервала, отдельные кадры для всех представлений одной и той же единицы доступа (одного и того же временного экземпляра) могут визуализироваться одновременно. В одном примере, единица доступа может содержать кодированную картинку в одном временном экземпляре, которая может быть представлена как первично кодированная картинка.
[0069] Соответственно, единица доступа может содержать все аудио- и видеокадры общего временного экземпляра, например, все представления, соответствующие времени X. В настоящем раскрытии, закодированная картинка конкретного представления также упоминается как ʺкомпонентное представлениеʺ. То есть, компонентное представление может содержать кодированное изображение (или кадр) для определенного вида в определенное время. Соответственно, единица доступа может быть определена как содержащая все компоненты представления общего временного экземпляра. Порядок декодирования единиц доступа не обязательно должен совпадать с порядком вывода или отображения.
[0070] Представление мультимедиа может включать в себя описание представления мультимедиа (MPD), которое может содержать описания различных альтернативных представлений (например, услуг видео с разным качеством), и описание может включать в себя, например, информацию кодека, значение профиля и значение уровня. MPD является одним примером файла манифеста, такого как файл 66 манифеста. Клиентское устройство 40 может извлекать MPD представления мультимедиа, чтобы определить, как получить доступ к фрагментам фильмов различных представлений. Фрагменты фильма могут быть размещены в боксах фрагментов фильмов (moof boxes) видеофайлов.
[0071] Файл 66 манифеста (который может содержать, например, MPD) может объявлять о доступности сегментов представлений 68. То есть MPD может включать в себя информацию, указывающую физическое время, в которое первый сегмент одного из представлений 68 становится доступным, а также информацию, указывающую длительность сегментов в представлениях 68. Таким образом, модуль 52 извлечения клиентского устройства 40 может определять, когда доступен каждый сегмент, на основе начального времени, а также продолжительности сегментов, предшествующих конкретному сегменту.
[0072] После того, как модуль 30 инкапсуляции скомпоновал единицы NAL и/или единицы доступа в видеофайл на основе принятых данных, модуль 30 инкапсуляции передает видеофайл на интерфейс 32 вывода для вывода. В некоторых примерах, модуль 30 инкапсуляции может сохранять видеофайл локально или отправлять видеофайл на удаленный сервер через интерфейс 32 вывода, вместо того, чтобы отправлять видеофайл непосредственно на клиентское устройство 40. Интерфейс 32 вывода может содержать, например, передатчик, приемопередатчик, устройство для записи данных на считываемый компьютером носитель, такой как, например, оптический накопитель, накопитель магнитных носителей (например, накопитель гибких дисков), порт универсальной последовательной шины (USB), сетевой интерфейс или другой интерфейс вывода. Интерфейс 32 вывода выдает видеофайл на считываемый компьютером носитель, такой как, например, сигнал передачи, магнитный носитель, оптический носитель, память, флэш-накопитель или другой считываемый компьютером носитель.
[0073] Сетевой интерфейс 54 может принимать единицу NAL или единицу доступа через сеть 74 и предоставлять единицу NAL или единицу доступа в модуль 50 декапсуляции через модуль 52 извлечения. Модуль 50 декапсуляции может декапсулировать элементы видеофайла в компонентные потоки PES, депакетировать потоки PES для извлечения закодированных данных и отправлять закодированные данные в аудиодекодер 46 или видеодекодер 48 в зависимости от того, являются ли закодированные данные частью аудио- или видеопотока, например, как указано в заголовках пакетов PES потока. Аудиодекодер 46 декодирует закодированные аудиоданные и отправляет декодированные аудиоданные на аудиовыход 42, тогда как видеодекодер 48 декодирует закодированные видеоданные и отправляет декодированные видеоданные, которые могут включать в себя множество представлений потока, на видеовыход 44.
[0074] Некоторые элементы примера на фиг. 1 могут быть сконфигурированы для выполнения методов настоящего раскрытия. Например, сетевой интерфейс 72 и/или модуль 70 обработки запроса могут быть сконфигурированы для работы независимо или совместно с выполнением методов настоящего раскрытия.
[0075] На фиг. 2 показана блок-схема, более подробно иллюстрирующая примерный набор компонентов модуля 52 извлечения согласно фиг. 1. В этом примере, модуль 52 извлечения включает в себя модуль 100 промежуточного программного обеспечения eMBMS, клиент 110 DASH и мультимедийное приложение 112.
[0076] В этом примере, модуль 100 промежуточного программного обеспечения eMBMS дополнительно включает в себя модуль 106 приема eMBMS, кэш 104 и серверный модуль 102. В этом примере, модуль 106 приема eMBMS сконфигурирован для приема данных через eMBMS, например, согласно Доставке файлов посредством однонаправленной транспортировки (FLUTE), как описано в T. Paila et al., ʺFLUTE-File Delivery over Unidirectional Transportʺ, Network Working Group, RFC 6726, Nov. 2012, доступный в http://tools.ietf.org/html/rfc6726. То есть модуль 106 приема eMBMS может принимать файлы посредством широковещательной передачи, например, серверного устройства 60, которое может выступать в качестве BM-SC.
[0077] Когда модуль 100 промежуточного программного обеспечения eMBMS принимает данные для файлов, модуль промежуточного программного обеспечения eMBMS может сохранить принятые данные в кеше 104. Кэш 104 может содержать считываемый компьютером носитель данных, такой как флэш-память, жесткий диск, ОЗУ или любой другой подходящий носитель.
[0078] Локальный серверный модуль 102 может выступать в качестве сервера для клиента 110 DASH. Например, локальный серверный модуль 102 может предоставлять файл MPD или другой файл манифеста клиенту 110 DASH. Локальный серверный модуль 102 может объявлять моменты времени доступности для сегментов в файле MPD, а также гиперссылки, из которых могут быть извлечены сегменты. Эти гиперссылки могут включать в себя префикс адреса локального хоста, соответствующий клиентскому устройству 40 (например, 127.0.0.1 для IPv4). Таким образом, клиент 110 DASH может запрашивать сегменты из локального серверного модуля 102, используя запросы HTTP GET или частичного GET. Например, для сегмента, доступного по ссылке http://127.0.0.1/repl/seg3, клиент 110 DASH может создать запрос HTTP GET, который включает в себя запрос для http://127.0.0.1/repl/seg3, и отправить запрос на локальный серверный модуль 102. Локальный серверный модуль 102 может извлекать запрошенные данные из кэша 104 и предоставлять данные клиенту 110 DASH в ответ на такие запросы.
[0079] Фиг. 3 представляет собой концептуальную схему, иллюстрирующую элементы примерного мультимедийного контента 120. Мультимедийный контент 120 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному на носителе 62 хранения данных. В примере согласно фиг. 3, мультимедийный контент 120 включает в себя описание представления мультимедиа (MPD) 122 и множество представлений 124A-124N (представлений 124). Представление 124A включает в себя опциональные данные 126 заголовка и сегменты 128A-128N (сегменты 128), тогда как представление 124N включает в себя опциональные данные 130 заголовка и сегменты 132A-132N (сегменты 132). Буква N используется для обозначения последнего фрагмента фильма в каждом из представлений 124 для удобства. В некоторых примерах, могут иметься разные количества фрагментов фильма среди представлений 124.
[0080] MPD 122 может содержать структуру данных, отдельную от представлений 124. MPD 122 может соответствовать файлу 66 манифеста согласно фиг. 1. Аналогично, представления 124 могут соответствовать представлениям 68 согласно фиг. 2. В общем, MPD 122 может включать в себя данные, которые обычно описывают характеристики представлений 124, такие как характеристики кодирования и визуализации, наборы адаптации, профиль, которому соответствует MPD 122, информация о типе текста, информация об углах камеры, информация о рейтинге, информация трюкового (специального) режима (например, информация, указывающая представления, которые включают временные подпоследовательности) и/или информация для извлечения удаленных периодов (например, для вставки целевой рекламы в мультимедийный контент во время воспроизведения).
[0081] Данные 126 заголовка, если они имеются, могут описывать характеристики сегментов 128, например, временные местоположения точек произвольного доступа (RAP, также упоминаемых как точки доступа к потоку (SAP)), какие из сегментов 128 включают в себя точки произвольного доступа, байтовые смещения относительно точек произвольного доступа в сегментах 128, унифицированные указатели ресурсов (URL) или URI сегментов 128 или другие аспекты сегментов 128. Данные 130 заголовка, если они имеются, могут описывать аналогичные характеристики для сегментов 132. Дополнительно или альтернативно, такие характеристики могут полностью включаться в MPD 122.
[0082] Сегменты 128, 124 включают в себя одну или несколько выборок кодированного видео, каждая из которых может включать в себя кадры или вырезки (фрагменты) видеоданных. Каждая из выборок кодированного видео сегментов 128 может иметь сходные характеристики, например, требования по высоте, ширине и пропускной способности. Такие характеристики могут быть описаны посредством данных MPD 122, хотя такие данные не иллюстрируются в примере на фиг. 3. MPD 122 может включать в себя характеристики, описанные в спецификации 3GPP, с добавлением любой или всей из сигнализируемой информации, описанной в настоящем раскрытии.
[0083] Каждый из сегментов 128, 132 может быть ассоциирован с уникальным унифицированным указателем ресурсов (URL) или URI. Таким образом, каждый из сегментов 128, 132 может независимо извлекаться с использованием сетевого протокола потоковой передачи, такого как DASH. Таким образом, целевое устройство, такое как клиентское устройство 40, может использовать запрос HTTP GET для извлечения сегментов 128 или 132. В некоторых примерах, клиентское устройство 40 может использовать запросы HTTP частичного GET для извлечения конкретных байтовых диапазонов сегментов 128 или 132.
[0084] Фиг. 4 является блок-схемой, иллюстрирующей элементы примерного видеофайла 150, который может соответствовать сегменту представления, такому как один из сегментов 114, 124 на фиг. 3. Хотя пример согласно фиг. 4 иллюстрирует видеофайл, следует понимать, что аудиофайл или другой файл может включать в себя данные, аналогичные данным видеофайла 150. Каждый из сегментов 128, 132 может включать в себя данные, которые по существу соответствуют компоновке данных, проиллюстрированных в примере согласно фиг. 4. Можно сказать, что видеофайл 150 инкапсулирует сегмент. Как описано выше, видеофайлы в соответствии с базовым форматом мультимедийных файлов ISO и его расширениями хранят данные в последовательности объектов, упоминаемых как ʺboxesʺ (боксы, поля, ячейки). В примере на фиг. 4, видеофайл 150 включает в себя бокс 152 типа файла (FTYP), бокс 154 фильма (MOOV), боксы 162 индексов сегментов (sidx), боксы 164 фрагментов фильма (MOOF) и бокс 166 произвольного доступа к фрагменту фильма (MFRA). Хотя фиг. 4 представляет собой пример видеофайла, следует понимать, что другие мультимедийные файлы могут включать в себя другие типы мультимедийных данных (например, аудиоданные, временные текстовые данные и т.п.), которые структурированы аналогично данным видеофайла 150, в соответствии с базовым форматом мультимедийного файла ISO и его расширениями.
[0085] Бокс 152 типа файла (FTYP) обычно описывает тип файла для видеофайла 150. Бокс 152 типа файла может включать в себя данные, которые идентифицируют спецификацию, которая описывает наилучшее использование для видеофайла 150. Бокс 152 типа файла может альтернативно быть помещен перед боксом 154 MOOV, боксами 164 фрагментов фильма и/или боксом 166 MFRA.
[0086] В некоторых примерах, сегмент, такой как видеофайл 150, может включать в себя бокс обновления MPD (не показан) перед боксом 152 FTYP. Бокс обновления MPD может включать в себя информацию, указывающую, что MPD, соответствующее представлению, включающему в себя видеофайл 150, должно быть обновлено, вместе с информацией для обновления MPD. Например, бокс обновления MPD может предоставить URI или URL для ресурса, который будет использоваться для обновления MPD. В качестве другого примера, бокс обновления MPD может включать в себя данные для обновления MPD. В некоторых примерах бокс обновления MPD может следовать сразу за боксом типа сегмента (STYP) (не показан) видеофайла 150, где бокс STYP может определять тип сегмента для видеофайла 150. Фиг. 7, более подробно рассмотренная ниже, предоставляет дополнительную информацию относительно бокса обновления MPD.
[0087] Бокс 154 MOOV, в примере согласно фиг. 4, включает в себя бокс 156 заголовка фильма (MVHD), бокс 158 трека (TRAK) и один или несколько боксов 160 расширения фильма (MVEX). В общем, бокс 156 MVHD может описывать общие характеристики видеофайла 150. Например, бокс MVHD 156 может включать в себя данные, которые описывают, когда видеофайл 150 был первоначально создан, когда видеофайл 150 был последний раз изменен, временной масштаб для видеофайла 150, длительность воспроизведения для видеофайла 150 или другие данные, которые обычно описывают видеофайл 150.
[0088] Бокс 158 TRAK может включать в себя данные для трека (дорожки) видеофайла 150. Бокс 158 TRAK может включать в себя бокс заголовка (TKHD) трека, который описывает характеристики трека, соответствующего боксу TRAK 158. В некоторых примерах, бокс 158 TRAK может включать в себя картинки (кадры) кодированного видео, в то время как в других примерах картинки кодированного видео трека могут быть включены во фрагменты 164 фильма, ссылки на которые могут даваться данными бокса 158 TRAK и/или боксов 162 sidx.
[0089] В некоторых примерах, видеофайл 150 может включать в себя более одного трека. Соответственно, бокс 154 MOOV может включать в себя количество боксов TRAK, равное количеству треков в видеофайле 150. Бокс 158 TRAK может описывать характеристики соответствующего трека видеофайла 150. Например, бокс 158 TRAK может описывать временную и/или пространственную информацию для соответствующего трека. Бокс TRAK, подобно боксу 158 TRAK из бокса 154 MOOV, может описывать характеристики трека набора параметров, когда модуль 30 инкапсуляции (фиг. 3) включает в себя трек набора параметров в видеофайле, таком как видеофайл 150. Модуль 30 инкапсуляции может сигнализировать наличие сообщений SEI уровня последовательности в треке набора параметров в боксе TRAK, описывающем трек набора параметров.
[0090] Боксы 160 MVEX могут описывать характеристики соответствующих фрагментов 164 фильма, например, чтобы сигнализировать, что видеофайл 150 включает в себя фрагменты 164 фильма, в дополнение к видеоданным, включенным в бокс 154 MOOV, если имеются. В контексте потоковых видеоданных, картинки кодированного видео могут быть включены во фрагменты 164 фильма, а не в бокс 154 MOOV. Соответственно, все выборки кодированного видео могут быть включены во фрагменты 164 фильма, а не в бокс 154 MOOV.
[0091] Бокс 154 MOOV может включать в себя количество боксов 160 MVEX, равное количеству фрагментов 164 видео в видеофайле 150. Каждый из боксов MVEX 160 может описывать характеристики соответствующего одного из фрагментов 1664 фильма. Например, каждый бокс MVEX может включать в себя бокс бокса заголовка продолжительности фильма (MEHD), который описывает временную длительность для соответствующего одного из фрагментов 164 фильма.
[0092] Как отмечено выше, модуль 30 инкапсуляции может хранить набор данных последовательности, установленный в выборке видео, которая не включает в себя фактические кодированные видеоданные. Выборка видео в общем случае может соответствовать единице доступа, которая является представлением кодированной картинки в конкретном временном экземпляре. В контексте AVC, кодированная картинка включает в себя одну или несколько единиц VCL NAL, которые содержат информацию для построения всех пикселов единицы доступа и других ассоциированных единиц не-VCL NAL, таких как сообщения SEI. Соответственно, модуль 30 инкапсуляции может включать в себя набор данных последовательности, который может включать в себя сообщения SEI уровня последовательности, в одном из фрагментов 164 фильма. Модуль 30 инкапсуляции может дополнительно сигнализировать о наличии набора данных последовательности и/или сообщений SEI уровня последовательности как присутствующих в одном из фрагментов 164 фильма, в одном из боксов 160 MVEX, соответствующем одному из фрагментов 164 фильма.
[0093] Боксы 162 SIDX являются опциональными элементами видеофайла 150. То есть видеофайлы, соответствующие 3GPP файловому формату или другим таким файловым форматам, не обязательно содержат боксы 162 SIDX. В соответствии с примером 3GPP файлового формата, бокс SIDX может использоваться для идентификации подсегмента сегмента (например, сегмента, содержащегося в видеофайле 150). 3GPP файловый формат определяет подсегмент как ʺавтономный набор из одного или нескольких последовательных боксов фрагментов фильма с соответствующим(и) боксом(ами) мультимедийных данных, и бокс мультимедийных данных, содержащих данные, на которые ссылается бокс фрагмента фильма, должен следовать за этим боксом фрагмента фильма и предшествовать следующему боксу фрагмента фильма, содержащему информацию о том же трекеʺ. 3GPP файловый формат также указывает, что бокс SIDX ʺсодержит последовательность ссылок на подсегменты (под)сегмента, документированного этим боксом. Упомянутые посредством ссылки подсегменты являются смежными во время представления. Аналогично, байты, на которые ссылается бокс индекса сегмента, всегда являются смежными в пределах сегмента. Указанный ссылкой размер дает отсчет количества байтов в материале, на который дается ссылкаʺ.
[0094] Боксы 162 SIDX обычно предоставляют информацию, представляющую один или несколько подсегментов сегмента, включенного в видеофайл 150. Например, такая информация может включать в себя времена воспроизведения, в которые подсегменты начинаются и/или заканчиваются, байтовые смещения для подсегментов, включают ли подсегменты точку (например, начинаются с точки) доступа к потоку (SAP), тип для SAP (например, является ли SAP картинкой мгновенного обновления декодера (IDR), картинкой чисто случайного доступа (CRA), картинкой доступа нарушенной связи (BLA) и т.п.), положение SAP (с точки зрения времени воспроизведения и/или байтового смещения) в подсегменте и т.п.
[0095] Фрагменты 164 фильма могут включать в себя одну или несколько картинок кодированного видео. В некоторых примерах, фрагменты 164 фильма могут включать в себя одну или несколько групп картинок (GOP), каждая из которых может включать в себя ряд картинок кодированного видео, например, кадров или картинок. Кроме того, как описано выше, фрагменты 164 фильма могут включать в себя наборы данных последовательности в некоторых примерах. Каждый из фрагментов 164 фильма может включать в себя бокс заголовка фрагмента фильма (MFHD, не показанный на фиг.4). Бокс MFHD может описывать характеристики соответствующего фрагмента фильма, такие как порядковый номер для фрагмента фильма. Фрагменты 164 фильма могут быть включены в очередности порядкового номера в видеофайл 150.
[0096] Бокс 166 MFRA может описывать точки произвольного доступа во фрагментах 164 фильма видеофайла 150. Это может способствовать выполнению специальных режимов, таких как выполнение поисков для конкретных временных местоположений (то есть времен воспроизведения) в сегменте, инкапсулированном видеофайлом 150. Бокс 166 MFRA, как правило, является опциональным и не должен обязательно включаться в видеофайлы в некоторых примерах. Аналогично, клиентское устройство, такое как клиентское устройство 40, не обязательно должно ссылаться на бокс 166 MFRA, чтобы корректно декодировать и отображать видеоданные видеофайла 150. Бокс 166 MFRA может включать в себя количество боксов произвольного доступа фрагмента трека (TFRA) (не показано), равное количеству треков видеофайла 150 или, в некоторых примерах, равное количеству треков мультимедиа (например, не-хинт треков) видеофайла 150.
[0097] В некоторых примерах, фрагменты 164 фильма могут включать в себя одну или несколько точек доступа к потоку (SAP), таких как картинки IDR. Аналогично, бокс 166 MFRA может предоставлять указания местоположений в видеофайле 150 SAP. Соответственно, временная подпоследовательность видеофайла 150 может быть сформирована из SAP видеофайла 150. Временная подпоследовательность может также включать в себя другие картинки, такие как P-кадры и/или B-кадры, которые зависят от SAP. Кадры и/или вырезки временной подпоследовательности могут быть расположены в сегментах таким образом, что кадры/вырезки временной подпоследовательности, которые зависят от других кадров/вырезок подпоследовательности, могут быть надлежащим образом декодированы. Например, в иерархической компоновке данных, данные, используемые для предсказания для других данных, также могут быть включены во временную подпоследовательность.
[0098] На фиг. 5 показана блок-схема, иллюстрирующая примерную систему 180 инфраструктуры широковещательной передачи DASH. Система 180 включает в себя модуль 198 системного управления, буфер 182 мультимедиа длительности GOP, кодер 184 мультимедиа, сегментатор 186, отправитель 188, планировщик 190, модуль 192 кадрирования и возбудитель/усилитель 194. Система 180 и, следовательно, каждый из этих компонентов системы 180 может быть включен в устройство-источник, такое как серверное устройство 60 согласно фиг. 1 или устройство 20 подготовки контента согласно фиг. 1. Вновь, серверное устройство и устройство подготовки контента могут быть функционально интегрированы в одно устройство.
[0099] В примере системы 180, буфер 182 мультимедиа длительности GOP принимает и буферизует мультимедийные данные, подлежащие кодированию. Кодер 184 мультимедиа (который может фактически представлять множество кодеров мультимедиа, таких как аудиокодер 26 согласно фиг. 1 и видеокодер 28 согласно фиг. 1) кодирует мультимедийные данные (например, аудиоданные, видеоданные и/или временные текстовые данные), инкапсулирует мультимедийные данные в единицы уровня сетевой абстракции (NAL) и предоставляет кодированные мультимедийные данные, в форме 202 единицы NAL, на сегментатор 186. Кроме того, кодер 184 мультимедиа отправляет данные, представляющие явные идентификаторы 200 MDE, на сегментатор 186.
[0100] Сегментатор 186 инкапсулирует принятые единицы NAL в соответствующие сегменты. Таким образом, как правило, сегментатор 186 не предоставляет явной информации, указывающей расположение MDE в сегментах. Фактически, однако, сегментатор 186 предоставляет MDE на отправитель 188 в форме байтовых диапазонов в сегментах (206). Кроме того, сегментатор 186 также определяет требования 204 к времени передачи для MDE и отправляет данные, представляющие требования 204 к времени передачи, на отправитель 188.
[0101] Отправитель 188 представляет пример модуля отправки протокола на основе файла в соответствии с методами настоящего раскрытия. В этом примере, отправитель 188 отправляет данные принятых сегментов в соответствии с ROUTE. В других примерах, отправитель 188 может отправлять данные полученных сегментов в соответствии с FLUTE или другими такими протоколами на основе файла. В соответствии с методами настоящего раскрытия, отправитель 188 отправляет как данные 210 MDE (инкапсулированные в единицы данных на основе сети, например, IP, UDP, ROUTE, ALP и т.п.), так и требования 208 к времени передачи на планировщик 190 и формирователь 192 кадров. Формирователь 192 кадров формирует сетевые кадры, которые инкапсулируют сетевые данные в возбудитель/усилитель 194 в соответствии с данными расписания, определенными планировщиком 190, причем сетевые кадры дополнительно включают в себя описание базовой полосы событий 212 доставки данных (DDE) физического уровня. Возбудитель/усилитель 194 активно передает данные, например, через физический сетевой уровень, например, посредством вещания ATSC OTA, Ethernet или т.п.
[0102] Система вещания, такая как система Комитета по усовершенствованным телевизионным системам (ATSC), может поддерживать использование байтового диапазона с медиа-поддержкой, реализованное с помощью MDE в рамках протокола ROUTE или других протоколов доставки объектов, включающих в себя байтовые диапазоны с медиа-поддержкой (на медиа-основе). Идентификация (определение) индивидуальных MDE для системы может быть требуемым поведением, поэтому система может доставлять MDE. То есть, система должна быть в состоянии определить, какие байтовые диапазоны с медиа-поддержкой представляют MDE (или аналогичный объект данных), чтобы компоновать и отправлять MDE в планировщик с соответствующей временной маркировкой.
[0103] Примерное определение MDE представляет собой байтовый диапазон с медиа-поддержкой мультимедиа, который имеет смысл для принимающего кодека мультимедиа. Ввиду структуры кадра кодека, MDE может или не может быть несколькими выборками в контексте ISO BMMF в терминах выборки. Аудиокадр в высокоэффективном расширенном кодировании аудио (HE-AAC) (ISO/IEC JTC1/SC29/WG11/N7016 (Jan., 11, 2005)), который содержит несколько выборок аудио, сам по себе является одной выборкой в контексте ISO BMFF. Выборка ISO BMFF в контексте HEVC может быть единственным кадром видеоданных. MDE может включать в себя одну или несколько выборок ISO BMFF. Эта возможность существует из-за взаимозависимости между последовательными видеокадрами. Существует минимально возможное MDE, но для удобства или в других целях, эти атомные MDE, т.е. наименьшие возможные MDE, могут быть объединены в более крупное MDE. MDE в общем не перекрываются.
[0104] Элементы системы 180 на фиг. 5, которые могут быть первыми оповещены о MDE, являются кодером 184 мультимедиа, сегментатором 186 и отправителем 188. Функциональные объекты на фиг. 5 являются концептуальными. Эта логическая конструкция каскада удобна при рассмотрении системы и не является необходимой. Функции могут быть функционально интегрированы в единый объект или, возможно, разделены между дополнительными или альтернативными модулями иным образом. Логическое местоположение формирования MDE входит в объем кодера 184 мультимедиа, сегментатора 186 или секции ввода отправителя 188.
[0105] Объем и определение MDE определяются в соответствии с типом мультимедиа, которое обрабатывается. Например, аудио может быть скомпоновано в отдельные сегменты или мультиплексировано в сегментах, то есть в файлы/объекты ISO BMFF. MPEG DASH (INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01 Information Technology-Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formats), например, определяет как мультиплексированные, так и не мультиплексированные сегменты. Это всего лишь один аспект конфигурации. Как показано выше на фиг. 5, может иметься функция конфигурации системы, которая обеспечивает конфигурацию для различных функций.
[0106] Примеры некоторых потенциально конфигурируемых аспектов включают в себя:
Для DASH:
- длительность сегмента;
- композицию сегмента, т.е. типы мультимедиа, содержащиеся в конкретном мультимедийном объекте;
- каденцию типа сегмента, например, определенный сегмент мультимедиа содержит точку доступа к потоку (SAP) или нет.
Для видеокодера:
- длительность GoP (наименование конкретного кодека варьируется для таких структур);
- типы GoP, например, открытая или закрытая;
- каденцию типа кадра, например, I, B, B, P, B, B, P…;
- частоту кадров, разрешение, прогрессивное или чересстрочное и т.д.;
- границы MDE через согласованность с шаблоном или из разрешенных структур мультимедиа, например:
- аудиокадр является выборкой атомного MDE и ISO BMFF,
- индивидуальный I (IDR) кадр является атомным MDE,
- группы видеокадров являются атомными MDE, как показано на фиг. 3;
- такое определение может быть сделано или известно в кодере или определено сегментатором.
Для аудиокодера:
- частоту выборки;
- выбор инструментов кодирования;
- детали конструкции аудиокадра в соответствии с конкретным кодеком.
[0107] В той степени, в которой эти аспекты являются статическими конфигурациями, ассоциированные определения MDE могут предоставляться как статические определения, то есть конфигурация кодера известна сегментатору и/или отправителю, поскольку это статически сконфигурированный набор параметров. Предполагая, что видео запускает одну определенную каденцию типов видеокадра, границы MDE могут определяться конфигурацией. См. фиг. 7 ниже для примера конкретной каденции видео и ее атомных MDE. Следует отметить, что этот чертеж изображает порядок отображения видеокадров.
[0108] Фиг. 6 представляет концептуальную диаграмму, иллюстрирующую примерную композицию высокого уровня MDE.
[0109] Фиг. 7 представляет концептуальную диаграмму, иллюстрирующую примерную каденцию типов кадров и соответствующие определенные MDE. В частности, фиг. 7 иллюстрирует видеокадры 250-296. Различные видеокадры помечены как I, P или B, чтобы представлять, являются ли кадры интра-предсказанными (I), однонаправленно интер-предсказанными (P) или двунаправленно интер-предсказанными (B).
[0110] Видеокадры, изображенные на фиг. 7, показаны в порядке отображения. Если бы фигура была изображена в порядке доставки, группировки кадров появлялись бы как смежные байтовые диапазоны в исходном потоке из видеокодера и в контейнере ISO BMFF, то есть в сегменте мультимедиа для DASH.
[0111] Идентификация границ MDE для такой определенной каденции может быть выполнена посредством таблиц, которые, например, определяют, что первые N видеокадров GoP должны быть MDE 1, следующие M-кадров должны быть MDE 2 и т.д., или конкретной каденцией типов кадра, например, соответствовать шаблону, что распознается в синтаксисе кодека. Использование табличного метода является простым и удобным, если каденция типов кадра является статической на основе по каждому сегменту. Это потенциально удобный способ для медиа типа аудио, для которого может иметься фиксированное количество кадров аудиокодека на каждое MDE и на каждый кодек. (Это также является примером тривиального правила.) Эти таблицы, которые могут содержать явное описание шаблона или правил, могут быть выражены как XML. Фиг. 7 показывает, что некоторые атомные MDE могут быть объединены для формирования более крупного MDE. Это может быть определено посредством сопоставления с правилом или шаблоном или их комбинации. Эти способы могут реализовываться в кодере мультимедиа и пересылаться в качестве явного описания на сегментатор и отправитель, например, ROUTE или MMT.
[0112] Как кратко сказано выше, таблица конфигурации может быть сформирована в соответствии с правилом. Логика такого правила может позволить адаптивную операцию функции идентификации MDE (байтового диапазона с медиа-поддержкой). Это удобно, например, если сегмент (объект BMML ISO) мультиплексирован, то есть содержит несколько типов медиа. Функция идентификации MDE сегментатора может анализировать, например, скрытые титры, аудио и видео. Кроме того, каденция, например, типов видеокадров, может быть адаптивной.
[0113] Примеры адаптивных аспектов видео с точки зрения MDE включают в себя:
- каденцию типов кадра для включения открытых и закрытых GoP в последовательности сегментов;
- отсчет и каденцию типов видеокадров на основе по каждому сегменту или по каждому периоду;
- например, вкрапленные рекламные ролики 24 кадра в секунду и контент 30 кадров в секунду,
- такое изменение частоты кадров может вызвать изменение каденции типа кадра и, как следствие, каденции MDE.
[0114] Описаны методы для поддержки идентификации MDE в сегментах, т.е. байтовых диапазонах с медиа-поддержкой, которые контекстуально релевантны ассоциированному кодеку мультимедиа в поддержке протокола с учетом байтового диапазона, например, ROUTE или MMT.
[0115] Примеры методов поддержки такого определения MDE, то байтовых диапазонов с учетом кодека мультимедиа, могут включать в себя:
Табличные методы, описывающие конкретные последовательности, такие как:
- тип видео кадра видео,
- последовательности типов видеокадров,
- количество, например, видео или аудиокадров,
- комбинации описанных структур,
- сопоставление с шаблоном конкретной последовательности, например, типов видеокадров,
- эти способы реализованы в кодере мультимедиа, сегментаторе или отправителе.
Основанное на правилах обнаружение на основе MDE:
- например, конкретная конфигурация кодека HEVC может допускать эти логические конструкции последовательностей типов кадров:
- начало последовательности кадров (MDE) удовлетворяет этому первому набору условий,
- конец последовательности кадров (MDE) удовлетворяет второму набору условий,
- последовательность типов кадров удовлетворяет третьему набору условий.
Описанные методы шаблонов и правил могут быть объединены, например:
- обнаружен данный шаблон,
- затем должно быть применено данное правило.
Кодер мультимедиа может иметь библиотеку определенных операционных режимов с конкретными конструкциями MDE.
- Кодер мультимедиа передает упомянутый операционный режим в реальном времени с кодированным мультимедиа, передаваемым в сегментатор
См. Приложение A, например, XML или логику на основе файлового правила и логику на основе шаблона.
[0116] Каждое MDE может быть определено с самым ранним и/или самым последним временем передачи. Это полезно для планировщика, задачей которого является назначить мультимедиа временным интервалам доставки, например, конкретным кадрам FEC в ATSC 3.0 на физическом уровне. Эти самые ранние и самые последние атрибуты могут быть ограничены различными аспектами, такими как:
- Самое раннее время передачи: это буквально тот момент, когда может испускаться первый бит данного MDE (или сегмента). Этот испускаемый самым ранним бит включает весь связанный протокол инкапсуляции.
- Самое последнее время передачи: это буквально последний момент, когда должен испускаться последний бит MDE (или сегмент). Этот последний бит включает весь связанный протокол инкапсуляции.
[0117] Самое раннее время передачи может быть ограничено конфигурацией системы. Например, каденция кадров физического уровня могла бы иметь кадры, которые начинаются на границах целой секунды времени физического уровня ATSC (48b TAI секунд, 10b мс или, возможно, другая часть секунды). Эта каденция кадров физического уровня может быть или может не быть напрямую связана с длительностью (длительностями) сегмента мультимедиа. Например, данный период программы мог бы доставляться целиком до конца целой секунды, предшествующей рекламе, которая является замещающей рекламой. Концевая замещающая реклама, например, не должна начинать доставку до тех пор, пока не начнется по меньшей мере следующая целая секунда. Для моментов времени, смещенных от границ периода, самое раннее время передачи может быть, например, в предшествующей целой секунде.
[0118] Самое последнее время передачи может быть связано с временем декодирования последнего декодируемого мультимедиа, содержащегося в маркированном MDE. Маркировка, применяемая для доставки уровня сегмента мультимедиа, может определяться номинальной временной шкалой доступности DASH/сегмента. Самое последнее время передачи может соответствовать конечному сроку доставки сегмента. Требование к самому последнему времени передачи для последнего MDE (байтового диапазона с медиа-поддержкой) сегмента может быть таким же, как и для завершенного сегмента.
[0119] Фиг. 8 представляет собой концептуальную диаграмму, представляющую простое представление системного времени. То есть, фиг. 8 изображает представление верхнего уровня системного времени. Это относится как к воспроизведению на уровне сегмента, так и к воспроизведению на основе байтового диапазона. Одно различие для воспроизведения MDE заключается в том, что статическая задержка приемника может быть заметно короче, чем для воспроизведения сегмента. Физическое время станции может быть доставлено в приемник через физический уровень и поддерживаемый протокол. Физическое время приемника в любой момент после синхронизации является текущим физическим временем станции за вычетом текущего времени прохождения сигнала от доминирующего передатчика до приемника.
[0120] Фиг. 9 является блок-схемой, представляющей систему 300, которая представляет инфраструктуру передачи, которая сконфигурирована с временным соотношением. То есть, на фиг. 9 представлено концептуальное представление того, как временные задержки могут влиять на процесс передачи системы 300. В этом примере, система 300 включает в себя буфер 306 мультимедиа длительности GOP, кодер 308 мультимедиа, сегментатор 310, управление 304 скоростью, модуль 302 управления системой, отправитель 312, планировщик 314 и возбудитель/усилитель 316.
[0121] В этом примере, буфер 306 мультимедиа длительности GоP хранит (то есть буферизует) необработанные медиаданные, подлежащие кодированию. Кодер 308 мультимедиа извлекает мультимедийные данные, которые должны быть закодированы, из буфера 306 мультимедиа длительности GоP, кодирует мультимедийные данные, инкапсулирует закодированные мультимедийные данные в форме единицы NAL и доставляет единицы 320 NAL сегментатору 310. Следует понимать, что закодированные мультимедийные данные также включают в себя MDE, например, как показано на фиг. 7. Кроме того, как объяснялось выше, каждое из MDE может иметь требования к времени передачи, такие как требования к самому раннему времени передачи и/или к самому последнему времени передачи.
[0122] Сегментатор 310 принимает единицы 320 NAL из кодера 308 мультимедиа и инкапсулирует одно или несколько MDE (то есть одну или несколько единиц NAL) в соответствующие сегменты. Вновь, сегменты могут соответствовать независимо доставляемым файлам, ассоциированным с соответствующими URL, где URL могут однозначно идентифицировать соответствующий сегмент. MDE могут соответствовать соответствующим байтовым диапазонам сегментов. Кроме того, сегментатор 310 может определять требования к времени передачи для каждого из MDE и передавать как требования 322 к времени передачи, так и MDE (в форме байтовых диапазонов сегментов) 324 к отправителю 312.
[0123] Отправитель 312 может работать в соответствии с протоколом доставки на основе файла, таким как ROUTE. Таким образом, отправитель 312 может инкапсулировать соответствующие части сегментов (например, MDE) в соответствующие модули 328 доставки на основе сети, такие как пакеты или кадры, в планировщик 314 для передачи. Кроме того, отправитель 312 предоставляет требования 326 к времени передачи на планировщик 314, так что планировщик 314 может доставлять единицы доставки на основе сети на клиентское устройство (не показано на фиг. 9) в соответствии с требованиями к времени передачи. Более конкретно, планировщик 314 формирует описание базовой полосы событий 330 доставки данных физического уровня (DDE) и передает описание базовой полосы DDE 330 физического уровня на возбудитель/усилитель 316. Затем возбудитель/усилитель 316 передает данные на физическом уровне, например, на клиентское устройство.
[0124] Фиг. 9 также представляет различные задержки, вводимые системой 300 при отправке мультимедийных данных на клиентское устройство. Например, время между буферизацией мультимедийных данных и планированием мультимедийных данных для передачи, упоминается как задержка 332 на длительность анализа. Задержка на длительность анализа, в частности, включает в себя задержку одного прохода для конкретной выборки 334, которая является временем между кодированием кодером 308 мультимедийной выборки и инкапсулированием выборки в единицу NAL и предоставлением единицы NAL на сегментатор 310, как показано на фиг. 9. Кроме того, время между планированием данных для передачи и фактической передачей данных упоминается как задержка 336 передатчика и STL.
[0125] Определение времени для мультимедийных данных является вопросом рассмотрения того, как долго до времени излучения должны функционировать различные функциональные блоки передающей инфраструктуры системы 300, и как долго после приема мультимедиа будет передаваться на декодер(ы) мультимедиа. Это обсуждение, соответственно, разделено на ʺдо излученияʺ и ʺпосле приемаʺ. Фактическое время излучения является существенным, чтобы реализовать потенциально синхронное переключение между исходными потоками для приложения, например, персонализированной вставки рекламы. Фактическое время, которое ограничивает передачу мультимедиа, может быть ограниченным. Время доставки в приемник синхронизируется с временем излучения элементов самозагрузки физического уровня. Временной интервал, когда конкретный период присутствует на физическом уровне, должен быть понятным и контролируемым. MDE или сегмент мультимедиа маркируется диапазоном времени, в течение которого он может быть излучен, так что весь процесс до фактического излучения смещается во времени обычно на постоянную задержку, ассоциированную с конкретным блоком или функцией. Фиг. 9 изображает вероятную организацию временных областей в инфраструктуре передачи. Такое разделение не является требованием, оно просто удобно с концептуальной точки зрения. Ниже приведен список некоторых возможных временных областей и их вероятных длительностей.
[0126] Задержка 336 в передатчике и в линии студийного передатчика (STL): определенная задержка на этих блоках достаточно велика, чтобы данный кадр физического уровня, который только начинает поступать в STL, мог начать выводиться передатчиком, когда этот период истек. Эта задержка номинально включает в себя по меньшей мере длительность кадра физического уровня, длительность перемежителя и самую длинную задержку передачи в сети распределения SFN. Можно было бы попытаться сократить эту задержку, например, на основе подкадра. Поддержка подкадров потенциально может привести к увеличению пиковой скорости на студии на линии студийного передатчика, т.е. линия студийного передатчика должна поддерживать максимально допустимую пропускную способность физического уровня по меньшей мере для длительности подкадра. Ограничением на реализацию полного кадра является распределение разрешенной пиковой скорости, измеренное на основе полного кадра, которое может быть ниже, чем на подкадр, хотя оно может быть одинаковым, если все активные PLP имеют одинаковую емкость.
[0127] Задержка 332 на длительность анализа: Одна из задач планировщика 314 заключается в назначении мультимедиа физическому уровню способом, который удовлетворяет его определенным конечным срокам и удовлетворяет ограничениям емкости в соответствии с текущими определениями PLP физического уровня. Для этого планировщик 314 должен анализировать по меньшей мере самую длинную продолжительность значимости мультимедиа в кадре физического уровня. Планировщик 314 может в конечном счете потерпеть неудачу, если он не может успешно спланировать по меньшей мере одно время кадра физического уровня кодированного мультимедиа за истекшее время кадра физического уровня. Это является кумулятивной задачей. Кадр физического уровня с меньшим, чем его длительность, временем мультимедиа может быть уравновешен кадром физического уровня, который представляет больше времени мультимедиа.
[0128] Длительность кадра физического уровня может быть короче, чем длительность самого длинного сегмента мультимедиа или длительность GоP. В таком случае предельная граница связана с по меньшей мере самой длинной длительностью сегмента мультимедиа или длительностью GoP, поскольку GoP состоит из нескольких сегментов мультимедиа. Планировщик 314 может гарантировать, что наибольшая длительность сегмента медиа/GoP будет успешно планироваться. Планировщик 314 может дополнительно генерировать по меньшей мере одну секунду закодированного сегмента медиа/GoP на секунду мультимедиа. Как описано здесь, задержка 332 на длительность анализа не является постоянной, так как планировщик 314 обладает гибкостью в самом последнем времени излучения/самом раннем времени излучения в планировании фактического времени излучения.
[0129] Задержка 334 на один проход: если входное мультимедиа передавались потоком непосредственно на кодер 308 мультимедиа и сегментатор 310, то имелась бы задержка декодирования, которая является статической для данной конфигурации от ввода первого кадра GoP до времени декодирования первого декодируемого кадра, как описано в полученном первом сегменте. Это является концептуальной конструкцией.
[0130] Может иметь место случай, когда кодер 308 мультимедиа (который может представлять несколько кодеров) может, весьма вероятно, формировать более одного времени мультимедиа закодированного контента на каждое время сегмента мультимедиа. Фактические ограничения, вероятно, определяются количеством ʺпроходовʺ, используемых схемой кодирования. В этом контексте ʺпроходʺ является одним экземпляром кодирования мультимедиа. Если бы кодер 308 мультимедиа мог удовлетворить всем целям на одном проходе кодирования, тогда потребовалась бы по меньшей мере одна длительность сегмента мультимедиа на каждое истекшее время сегмента мультимедиа. Достаточно сложно получить желательный размер данных на первом проходе, поэтому планировщик может попытаться ограничить проходы до двух проходов кодирования. В двухпроходном кодировании, первый проход может обеспечивать калибровку сложности мультимедийных данных, которые должны быть закодированы, и второй проход может использоваться для корректировки решений, принятых во время первого прохода, для удовлетворения пропускной способности физического уровня. Если начальный проход кодирования приводит к размерам данных, которые существенно отличаются от конечного желательного/требуемого размера данных, то может быть выполнен третий проход или другая корректировка скорости передачи данных. Следует отметить, что планировщик должен работать с фактическим размером данных, подлежащих доставке на физическом уровне, включая все инкапсуляции.
[0131] Предполагая, что мультимедиа передается потоком в кодер 308 мультимедиа в реальном времени, и это является схемой кодирования с несколькими проходами, потенциально имеется полная задержка GoP, требуемая для захвата потокового мультимедиа реального времени перед кодером(ами) мультимедиа. Времена декодирования, предоставляемые с кодированным мультимедиа в приемнике, должны отражать всю задержку инфраструктуры и приемника. Ожидается, что они основаны на воспроизведении сегмента мультимедиа. Времена MDE могут быть вычислены из начальной точки MDE RAP относительно того, что могло бы произойти для воспроизведения уровня сегмента.
[0132] Фиг. 10 представляет собой концептуальную диаграмму, иллюстрирующую множество сегментов на каждую GOP со ступенчатым местоположением RAP. Ступенчатое время сегмента RAP, как показано на фиг. 10 (т.е. множество длительностей анализа на каждую GoP) может сократить минимальное требуемое время захвата до планирования мультимедиа и, следовательно, снизить общую задержку. Это несколько ограничивает выгоды немедленного мультиплексирования, поскольку, как показано, скорость передачи данных для данного кадра физического уровня определяется одним размером данных сегмента RAP. Временная маркировка мультимедиа захватывается вместе с мультимедиа.
[0133] Как описано выше, задержка передачи или задержка до излучения может быть выражена как:
Длительность задержки анализа - задержка одного прохода до конкретной выборки + задержка STL и передатчика
(Время кадра + глубина перемежителя + распределение SFN)
[0134] Фиг. 11 является концептуальной диаграммой, иллюстрирующей минимальную задержку до времени декодирования для воспроизведения мультимедиа. То есть, фиг. 11 изображает минимальные задержки, которые влияют на время декодирования мультимедиа для воспроизведения сегмента мультимедиа и MDE. Одно различие между воспроизведением сегмента мультимедиа и MDE заключается в том, что время начала для воспроизведения MDE при задержке уровня сегмента должно учитывать самую длинную задержку стека плюс предполагаемую задержку представления, в то время как воспроизведение уровня MDE является фактической задержкой отдельного устройства статически плюс задержка для обеспечения достаточности заполнения буфера ROUTE. Общее значение задержки MDE может быть меньше, чем время сегмента.
[0135] Общая задержка сквозного декодирования сегмента может быть выражена как:
Длительность задержки анализа - задержка одного прохода до конкретной выборки+задержка STL и передатчика
(Время кадра + глубина перемежителя+распределение SFN) + время распространения + задержка до времени начала доступности + MPD@suggestPresentationDelay + задержка в сегменте до конкретной выборки.
[0136] Общая задержка сквозного декодирования MDE может быть выражена как:
Длительность задержки анализа - задержка одного прохода до конкретной выборки + задержка STL и передатчика
(Время кадра + глубина перемежителя + распределение SFN) + время распространения + задержка прихода в ROUTE или аналогичный приемник MMT + время отсрочки потоковой передачи байтового диапазона + задержка в сегменте до конкретной выборки.
[0137] Некоторые подробности о способах временных метаданных для планирования были обсуждены выше. Дополнительные детали способов временных метаданных для планирования обсуждаются ниже. Конструкция временных метаданных для MDE может быть основана на точке привязки, определенной самым последним требуемым временем передачи, соответствующим началу сегмента. Требуемое самое последнее время для MDE может быть линейным в порядке первого времени декодирования каждого соответствующего MDE после начала сегмента. Последнее время может быть ограничено временем декодирования текущей подлежащей декодированию выборки в MDE относительно первой декодированной выборки сегмента, которая также является первым декодированным MDE сегмента. Такой тип способа является линейным во времени декодирования, что является лишь одним из подходов к определению метаданных самого последнего времени передачи.
[0138] Существуют дополнительные аспекты, которые нуждаются в рассмотрении, например, возможно, опережающей загрузки таких компонентов мультимедиа, как аудио и титры. Так как эти компоненты мультимедиа малы по отношении к видео, но законченное представление не может воспроизводиться без них, проще всего, возможно, будет отправить их перед RAP видео, но после, возможно, таких объектов требуемых метаданных, как MPD или IS. Это является, в общем, способом, который может быть использован, чтобы гарантировать первоочередную доставку всех требуемых малых объектов данных.
[0139] Фиг. 12 является концептуальной диаграммой, иллюстрирующей опциональную синхронизацию физического уровня и связанных метаданных. Отношение кадров физического уровня к T-RAP является релевантным аспектом по отношению к самой ранней передаче. Например, рассмотрим пример фиг. 12, показывающий возможность смещения самого раннего времени перед началом номинального физического кадра. Это может повлиять на время смены канала, если только не имеется полной последовательности начальных метаданных на всех уровнях.
[0140] Структура физического уровня может быть или может не быть способной обеспечивать точную синхронизацию на основе границ GoP, как показано выше. Определение положения синхронизации может быть ограничено до других местоположений по нумерологии физического уровня. Приемлемым способом является использование местоположение, близкое к длительности GоP. Близким может быть, например, следующее доступное время, т.е. перед номинальной границей предшествующего преобразования, несущего трафик, или после него. Временной масштаб для минимального преобразования может быть в масштабе 1 мс, тогда как максимальное может быть в пределах 10 мс.
[0141] Функция планирования может номинально рассматривать фиксированный блок времени, возможно, относящийся к длительности мультимедийной GоP или длительности сегмента, как показано выше. Для более эффективной схемы длительности GоP, возможно, что все мультимедиа полностью распланировано, и некоторая существенная емкость может быть оставлена доступной в (N) для потенциального использования в следующем интервале анализа (N+1). При таком условии, планировщик может попытаться заполнить эту емкость в (N) посредством мультимедиа из следующего интервала анализа (N+1). Это может быть обеспеченно временными метаданными, позволяя передачу в более раннем интервале посредством параметра самой ранней передачи. Как только заполненная часть последующего интервала становится известной, компонент физического уровня может вставить опциональный элемент синхронизации кадра, предусмотренный в целях обнаружения мультимедийных услуг раньше, чем это было бы возможно при использовании квази-фиксированного периодического кадрирования, например, начальной загрузки и преамбулы в ATSC 3.0.
[0142] Фиг. 13 изображает один пример способа, включающего в себя последовательность этапов, соответствующих потенциальным системным событиям, чтобы обеспечить обнаружение услуги для нескольких уровней мультимедийных данных. То есть, фиг. 13 является блок-схемой последовательности операций, иллюстрирующей примерную последовательность событий обнаружения. Способ на фиг. 13 может быть выполнен различными устройствами и системами, показанными здесь, такими как устройство 20 подготовки контента и устройство-источник 60 на фиг. 1, система 180 на фиг. 5 или система 300 на фиг. 9. В целях примера и пояснения, способ согласно фиг. 13 объяснен по отношению к системе 180 на фиг. 5.
[0143] Система 180 доставляет последовательность данных, которая обеспечивает начало линейной услуги или линейной основанной на приложении услуги (350). Фиг. 13 изображает типичную последовательность событий в приемнике и порядок доставки системой (180) связанных метаданных, других объектов и мультимедийных файлов, относящиеся к типичному началу приема услуги. Начало услуги типично инициируется (350) вводом номера канала, вводом кнопки переключения вверх/вниз канала или выбором услуги из инструкции. Обнаружение физического уровня начинается приемом начальной загрузки или шаблона синхронизации системы (352). Получение системных метаданных, относящихся к физическому уровню, и дополнительных системных метаданных выполняется через преамбулу или аналогичным получением метаданных описания физического уровня (354). После идентификации местоположения желательных PLP или аналогичных потоков пакетов физического уровня в сигналах, принимаются желательные потоки пакетов, содержащие ALP или другие аналогичные протоколы инкапсуляции, содержащие отображение (перекрестную ссылку) ID потоков пакетов (PLP ID) на содержащиеся IP или другие аналогичные ID пакетов потоков или адреса (356). Преамбула или подобное (354) содержит флаг, который идентифицирует присутствие системных метаданных (LLS), идентифицирующих детали услуги, такие как системное время, композиция услуги (SLT), возможная информация оповещения (AEAT) (358). SLT, сделанный доступным в LLS (358), содержит детализацию местоположения по каждой услуге в SLS (360). PLP, переносящие услугу, также могут содержать приложение, которое может включать в себя приложение времени выполнения (362), которое может позволить телевизионной услуге работать в интерфейсе на основе браузера. Если присутствует, приложение может запускаться перед и после начала услуги. Когда эти этапы, обусловленные приемом соответствующих данных, выполнены, воспроизведение мультимедиа может быть инициировано путем приема и декодирования IS (364) и связанного сегмента мультимедиа (366). Затем, линейная услуга или линейная услуга на основе приложения может быть начата (368).
[0144] Задержка сквозного декодирования MDE представляет собой статическое время, предшествующее декодированию уровня сегмента. Это статическое смещение может быть реализовано посредством существующих в MPD метаданных или перезаписью MPD, изменяющей значение метаданных, чтобы позволить воспроизведение MPD для MDE. Значение смещения может быть определено из первого воспроизведения RAP посредством MDE относительно времени, когда первая RAP была бы воспроизведена на уровне сегмента.
[0145] Функции, относящиеся к планированию MDE, могут включать в себя следующее:
Временная организация типов мультимедиа и метаданных для уменьшения времени обнаружения.
- Предоставляется меньше типов мультимедийных данных с более ранним последним временем для обеспечения полной доставки и как упрощение относительно попыток перемежения с другими мультимедиа посредством множества меньших запланированных объектов. Этот способ приводит к большей гибкости в планировании, т.е. несколько объектов большего размера с большей широтой по времени вместо множества меньших объектов со строгими требованиями. Увеличенная гибкость планирования обычно приводит к лучшим результатам с точки зрения общей эффективности.
- Если же для аудио и важных метаданных требуется более надежный результат, они могут быть запланированы вместе в более надежном канале физического уровня.
- В случае, когда желательно конкретное перемежение типов мультимедиа в общем канале доставки, использование мультиплексированного сегмента может оказаться проще в реализации. Выборки внутри мультиплексированного объекта мультимедиа предоставляются в порядке доставки/декодирования.
Способы для сохранения быстрого обнаружения посредством опциональных местоположений синхронизации физического уровня.
- Распознавание доставки T-RAP перед номинальным местоположением, т.е. концевой номинальной синхронизацией физического уровня или связанным номинальным интервалом анализа.
- Адаптация, основанная том, что текущий цикл планирования удовлетворяет всем запросам на доставку, т.е. если все запросы данных с последним в номинальном кадре периоде физического уровня были удовлетворены.
Средства для адаптации неточной временной длительности кадра физического уровня к выровненному по мультимедийной GoP интервалу анализа с использованием правила, что передатчик должен запускаться в известную целую секунду и миллисекунду. (Режим синхронизации будет всегда выполняться по четным секундам и миллисекундам по определению.) Режим символов всегда будет поддерживать истекшее время целого числа символов, начиная с секунды и миллисекунды времени ATSC. (Скорости символов могут изменяться среди предопределенных значений, указанных или определенных в информации о конфигурации.)
- Назначение синхронизации кадров на ближайшее доступное местоположение символа во времени, отстающее от номинальной позиции относительно интервала анализа.
- Назначение синхронизации кадров на ближайшее доступное местоположение в символе, опережающем номинальную позицию интервала анализа.
- Любая другая основанная на правиле схема на основе синхронизации физического уровня относительно определенного интервала анализа.
- Определенный интервал анализа, связанный с мультимедийной GoP или аналогичной структурой.
Возможный способ с низкой задержкой, основанный на интервалах анализа, основанных на длительности сегмента вместо GoP.
- Первичное управление скоростью на основе сегментов RAP.
- Корректировка концевых не-RAP сегментов для компенсации безуспешного PSNR или аналогичного показателя качества.
[0146] Настоящее раскрытие в общих чертах описывает разные методы, которые могут быть использованы по отдельности или в любой комбинации, для определения местоположений MDE, байтовых диапазонов с медиа-поддержкой в рамках протоколов транспортировки файлов, таких как ROUTE или MMT. Эти методы могут быть основаны на явном описании и сопоставлении действительных шаблонов или определении действительных шаблонов по правилу(ам). Эти методы могут комбинироваться. Не имеется ограничений на порядок комбинирования. Аналогичным образом, настоящее раскрытие также описывает временные аспекты в качестве предпосылок к обсуждению методов для организации синхронизации физического уровня и других аспектов доставки. Эти методы могут обеспечить быстрое обнаружение в системах с переменными или неточными местоположениями синхронизации по отношению к интервалам анализа, связанным с мультимедиа.
[147] Фиг. 14 является блок-схемой последовательности операций, иллюстрирующей другой примерный способ в соответствии с методами настоящего раскрытия. Способ согласно фиг. 14 поясняется как выполняемый модулем отправки протокола на основе файла, таким как отправитель 188 на фиг. 5 или отправитель 312 на фиг. 9. В целях пояснения, способ согласно фиг. 14 поясняется по отношению к системе 312 согласно фиг. 9, но следует понимать, что другие модули могут быть сконфигурированы, чтобы выполнять данный или подобный способ. Как описано выше, отправитель 312 представляет собой пример модуля отправки протокола на основе файла, например модуль, отправляющий данные в соответствии с протоколом ROUTE или протоколом FLUTE, или другими протоколами передачи на основе файла.
[0148] Первоначально, в примере согласно фиг. 14, отправитель 312 принимает один и несколько сегментов, включающих в себя одно и несколько MDE (380). Например, MDE может соответствовать байтовым диапазонам сегментов, которые могут быть доставлены. Отправитель 312 определяет местоположения MDE (382). В общем, отправитель 312 не принимает явной информации, сигнализирующей местоположения MDE, но вместо этого использует один или несколько методов настоящего раскрытия, чтобы обрабатывать данные сегментов для определения местоположений MDE. Например, отправитель 312 может выполнять методы сопоставления шаблонов или правила, определяющие то, как могут быть идентифицированы MDE, как обсуждено выше. Отправитель 312, соответственно, может использовать метод сопоставления шаблонов, правила или другие такие методы для идентификации MDE внутри сегментов.
[0149] Отправитель 312 может дополнительно определить требования к времени передачи для MDE (384). Например, отправитель 312 может анализировать данные файла манифеста, соответствующего сегментам, и определять требования к времени передачи из файла манифеста. Файл манифеста может содержать, например, MPD в соответствии с DASH. Требования к времени передачи могут представлять одно или оба из самого раннего времени передачи и самого последнего времени передачи для одного или нескольких MDE, как обсуждено выше.
[0150] В конечном счете, отправитель 312 может предоставить MDE и данные, представляющие требования к времени передачи для MDE, на модуль отправки физического уровня (386), такой как планировщик 314 и возбудитель/усилитель 316. Таким образом, планировщик 314 может планировать передачу MDE в соответствии с требованиями к времени передачи, так что возбудитель/усилитель 316 может передать данные MDE не раньше, чем самое раннее время передачи, и/или не позже, чем самое последнее время передачи.
[0151] Таким образом, способ согласно фиг. 14 представляет пример способа, включающего в себя, выполняемое модулем отправки протокола на основе файла устройства-источника, приема потока данных, содержащих сегменты мультимедийных данных от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI), определение местоположений событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные по меньшей мере для части одного из сегментов, определение одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и предоставление MDE и данных, представляющих требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
[0152] В одном или нескольких примерах, описанные функции могут быть реализованы в аппаратных средствах, программном обеспечении, встроенном программном обеспечении или любой их комбинации. При реализации в программном обеспечении, функции могут храниться или передаваться в виде одной или нескольких инструкций или кода на считываемом компьютером носителе и исполняться аппаратным процессором. Считываемые компьютером носители могут включать в себя считываемые компьютером носители хранения данных, которые соответствуют материальному носителю, такому как носители хранения данных, или среды связи, включая любой носитель, который облегчает перенос компьютерной программы из одного места в другое, например, согласно протоколу связи. Таким образом, считываемые компьютером носители, в общем, могут соответствовать (1) материальному считываемому компьютером носителю хранения данных, который является не-временным, или (2) среде связи, такой как сигнал или несущая волна. Носителями хранения данных могут быть любые доступные носители, к которым может получить доступ один или несколько компьютеров или один или несколько процессоров для извлечения инструкций, кода и/или структур данных для реализации методов, описанных в настоящем раскрытии. Компьютерный программный продукт может включать в себя считываемый компьютером носитель.
[0153] В качестве примера, а не ограничения, такие считываемые компьютером носители хранения данных могут содержать RAM, ROM, EEPROM, CD-ROM или другое хранилище на оптических дисках, хранилище на магнитных дисках или другие магнитные запоминающие устройства, флэш-память или любой другой носитель, который можно использовать для хранения желательного программного кода в виде инструкций или структур данных, и к которому может получать доступ компьютер. Кроме того, любое соединение может надлежащим образом определяться как считываемый компьютером носитель. Например, если инструкции передаются с веб-сайта, сервера или другого удаленного источника с использованием коаксиального кабеля, волоконно-оптического кабеля, витой пары, цифровой абонентской линии (DSL) или беспроводных технологий, таких как инфракрасная, радио и микроволновая, то коаксиальный кабель, волоконно-оптический кабель, витая пара, DSL или беспроводные технологии, такие как инфракрасная, радио и микроволновая, включаются в определение носителя. Однако следует понимать, что считываемые компьютером носители хранения и носители хранения данных не включают в себя соединения, несущие волны, сигналы или другие временные (переходные) носители, но вместо этого ориентированы на не-временные, материальные носители хранения. Магнитный диск (disk) и оптический диск (disc), как используется здесь, включают в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой многофункциональный диск (DVD), гибкий диск и Blu-ray диск, где магнитные диски (disks) обычно воспроизводят данные магнитным способом, в то время как оптические диски (discs) воспроизводят данные оптически, с помощью лазеров. Комбинации вышеизложенного также должны быть включены в объем считываемых компьютером носителей.
[0154] Инструкции могут исполняться одним или несколькими процессорами, такими как один или несколько процессоров цифровых сигналов (DSP), микропроцессоры общего назначения, специализированные интегральные схемы (ASIC), программируемые вентильные матрицы (FPGA) или другие эквивалентные интегральные или дискретные логические схемы. Соответственно, термин ʺпроцессорʺ, как используется здесь, может относиться к любой из вышеперечисленных структур или любой другой структуре, подходящей для реализации описанных здесь методов. Кроме того, в некоторых аспектах, функциональность, описанная здесь, может быть предоставлена в рамках специализированных аппаратных средств и/или программных модулей, сконфигурированных для кодирования и декодирования или интегрированных в объединенный кодек. Кроме того, методы могут быть полностью реализованы в одной или нескольких схемах или логических элементах.
[0155] Методы настоящего раскрытия могут быть реализованы в самых разных приборах или устройствах, включая беспроводную трубку, интегральную схему (IC) или набор IC (например, чипсет). Различные компоненты, модули или блоки описаны в настоящем раскрытии, чтобы подчеркнуть функциональные аспекты устройств, сконфигурированных для выполнения раскрытых методов, но не обязательно требуют реализации различными аппаратными модулями. Скорее, как описано выше, различные модули могут быть объединены в аппаратный модуль кодека или обеспечены набором взаимодействующих аппаратных модулей, включая один или несколько процессоров, как описано выше, в сочетании с подходящим программным обеспечением и/или встроенным программным обеспечением.
[0156] Выше были описаны различные примеры. Эти и другие примеры находятся в пределах объема следующей формулы изобретения.

Claims (85)

1. Способ транспортировки мультимедийных данных, причем способ содержит, посредством модуля отправки протокола на основе файла устройства-источника:
прием потока данных, содержащих сегменты мультимедийных данных, от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI);
определение местоположений событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов;
определение одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство; и
предоставление MDE и данных, представляющих требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
2. Способ по п. 1, в котором определение местоположений MDE содержит определение местоположений MDE с использованием сопоставления шаблонов.
3. Способ по п. 2, в котором мультимедийные данные содержат видеоданные, и в котором определение местоположений MDE с использованием сопоставления шаблонов содержит:
получение данных, определяющих каденцию для видеокадров потока, причем определенная каденция представляет порядок, в котором отправляются типы для видеокадров, причем типы для видеокадров включают в себя интра-предсказанные видеокадры и интер-предсказанные видеокадры; и
определение, по меньшей мере, некоторых из MDE на основе определенной каденции так, что MDE находятся между соответствующими границами видеокадров.
4. Способ по п. 2, в котором мультимедийные данные содержат аудиоданные, и в котором определение местоположений MDE с использованием сопоставления шаблонов содержит:
определение фиксированного количества аудиокадров потока для включения в каждое из MDE; и
определение, по меньшей мере, некоторых из MDE так, чтобы каждое включало в себя фиксированное количество аудиокадров из потока.
5. Способ по п. 1, в котором определение местоположений MDE содержит определение местоположений MDE с использованием правил, содержащее:
прием данных, представляющих одно или несколько правил, определяющих один или несколько из аудиокадров, видеокадров и синхронизированных текстовых экземпляров;
определение местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра на основе правил; и
определение MDE на основе местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра.
6. Способ по п. 1, в котором определение местоположений MDE содержит определение местоположений MDE на основе информации о времени для синхронизации физического уровня модуля отправки физического уровня.
7. Способ по п. 1, в котором определение местоположений MDE содержит анализ хинт-трека, включающего в себя метаданные, представляющие местоположения воспроизводимых данных в потоке.
8. Способ по п. 1, в котором определение требований к времени передачи содержит определение самого раннего времени передачи для одного из MDE на основе системной конфигурации для устройства-источника.
9. Способ по п. 1, в котором определение требований к времени передачи содержит определение самого последнего времени передачи для одного из MDE на основе времени доступности сегмента для сегмента, данные для которого включены в одно из MDE, причем способ дополнительно содержит определение времени доступности сегмента из файла манифеста для потока данных.
10. Устройство-источник для транспортировки мультимедийных данных, причем устройство-источник содержит:
сегментатор, сконфигурированный, чтобы формировать поток данных, содержащих сегменты мультимедийных данных, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI);
модуль отправки физического уровня, сконфигурированный, чтобы доставлять события доставки мультимедиа (MDE) на клиентское устройство в соответствии с требованиями к времени передачи для MDE, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, причем модуль отправки физического уровня сконфигурирован с доступными временными интервалами доставки для приема данных, подлежащих доставке; и
модуль отправки протокола на основе файла, сконфигурированный, чтобы:
принимать поток данных, содержащий сегменты мультимедийных данных, от сегментатора;
определять местоположения MDE в потоке медиаданных;
определять одно или несколько требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство, и
предоставлять MDE и данные, представляющие требования к времени передачи, на модуль отправки физического уровня в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
11. Устройство-источник по п. 10, в котором модуль отправки протокола на основе файла сконфигурирован для определения местоположений MDE с использованием сопоставления шаблонов.
12. Устройство-источник по п. 11, в котором мультимедийные данные содержат видеоданные, и в котором, для определения местоположений MDE с использованием сопоставления шаблонов, модуль отправки протокола на основе файла сконфигурирован, чтобы:
получать данные, определяющие каденцию для видеокадров потока, причем определенная каденция представляет порядок, в котором отправляются типы для видеокадров, причем типы для видеокадров включают в себя интра-предсказанные видеокадры и интер-предсказанные видеокадры; и
определять, по меньшей мере, некоторые из MDE на основе определенной каденции так, что MDE находятся между соответствующими границами видеокадров.
13. Устройство-источник по п. 11, в котором мультимедийные данные содержат аудиоданные, и в котором, для определения местоположений MDE с использованием сопоставления шаблонов, модуль отправки протокола на основе файла сконфигурирован, чтобы:
определять фиксированное количество аудиокадров потока для включения в каждое из MDE; и
определять, по меньшей мере, некоторые из MDE так, чтобы каждое включало в себя фиксированное количество аудиокадров из потока.
14. Устройство-источник по п. 10, в котором модуль отправки протокола на основе файла сконфигурирован, чтобы использовать правила для определения местоположений MDE, и в котором, для использования правил, модуль отправки протокола на основе файла сконфигурирован, чтобы:
принимать данные, представляющие одно или несколько правил, определяющих один или несколько из аудиокадров, видеокадров и синхронизированных текстовых экземпляров;
определять местоположения по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра на основе правил; и
определять MDE на основе местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра.
15. Устройство-источник по п. 10, в котором модуль отправки протокола на основе файла сконфигурирован для определения местоположений MDE на основе информации о времени для синхронизации физического уровня модуля отправки физического уровня.
16. Устройство-источник по п. 10, в котором, для определения местоположений MDE, модуль отправки протокола на основе файла сконфигурирован для анализа хинт-трека, включающего в себя метаданные, представляющие местоположения воспроизводимых данных в потоке.
17. Устройство-источник по п. 10, в котором, для определения требований к времени передачи, модуль отправки протокола на основе файла сконфигурирован для определения самого раннего времени передачи для одного из MDE на основе системной конфигурации для устройства-источника.
18. Устройство-источник по п. 10, в котором, для определения требований к времени передачи, модуль отправки протокола на основе файла сконфигурирован для определения последнего времени передачи для одного из MDE на основе времени доступности сегмента для сегмента, данные для которого включены в одно из MDE, и в котором модуль отправки протокола на основе файла дополнительно сконфигурирован для определения времени доступности сегмента из файла манифеста для потока данных.
19.Устройство-источник для транспортировки мультимедийных данных, причем устройство-источник содержит:
сегментатор, сконфигурированный, чтобы формировать поток данных, содержащих сегменты мультимедийных данных, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI);
модуль отправки физического уровня, сконфигурированный, чтобы доставлять события доставки мультимедиа (MDE) на клиентское устройство в соответствии с требованиями к времени передачи для MDE, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов, причем модуль отправки физического уровня сконфигурирован с доступными временными интервалами доставки для приема данных, подлежащих доставке;
средство для приема потока данных, содержащих сегменты мультимедийных данных от сегментатора;
средство для определения местоположений MDE в потоке мультимедийных данных;
средство для определения одного или нескольких требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство; и
средство для предоставления MDE и данных, представляющих требования к времени передачи, на модуль отправки физического уровня в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
20. Устройство-источник по п. 19, в котором средство для определения местоположений MDE содержит средство для определения местоположений MDE с использованием сопоставления шаблонов.
21. Устройство-источник по п. 20, в котором мультимедийные данные содержат видеоданные, и в котором средство для определения местоположений MDE с использованием сопоставления шаблонов содержит:
средство для получения данных, определяющих каденцию для видеокадров потока, причем определенная каденция представляет порядок, в котором отправляются типы для видеокадров, причем типы для видеокадров включают в себя интра-предсказанные видеокадры и интер-предсказанные видеокадры; и
средство для определения, по меньшей мере, некоторых MDE на основе определенной каденции так, что MDE находятся между соответствующими границами видеокадров.
22. Устройство-источник по п. 20, в котором мультимедийные данные содержат аудиоданные, и в котором средство для определения местоположений MDE с использованием сопоставления шаблонов содержит:
средство для определения фиксированного количества аудиокадров потока для включения в каждое из MDE; и
средство для определения, по меньшей мере, некоторых из MDE так, чтобы каждое включало в себя фиксированное количество аудиокадров из потока.
23. Устройство-источник по п. 19, в котором средство для определения местоположений MDE содержит средство для определения местоположений MDE с использованием правил, содержащее:
средство для приема данных, представляющих одно или несколько правил, определяющих одно или несколько из аудиокадров, видеокадров и синхронизированных текстовых экземпляров;
средство для определения местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра на основе правил; и
средство для определения MDE на основе местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра.
24. Устройство-источник по п. 19, в котором средство для определения местоположений MDE содержит средство для определения местоположений MDE на основе информации о времени для синхронизации физического уровня модуля отправки физического уровня.
25. Устройство-источник по п. 19, в котором средство для определения местоположений MDE содержит средство для анализа хинт-трека, включающего в себя метаданные, представляющие местоположения воспроизводимых данных в потоке.
26. Устройство-источник по п. 19, в котором средство для определения требований к времени передачи содержит средство для определения самого раннего времени передачи для одного из MDE на основе системной конфигурации для устройства-источника.
27. Устройство-источник по п. 19, в котором средство для определения требований к времени передачи содержит средство для определения самого последнего времени передачи для одного из MDE на основе времени доступности сегмента для сегмента, данные для которого включены в одно из MDE, причем способ дополнительно содержит определение времени доступности сегмента из файла манифеста для потока данных.
28. Считываемый компьютером носитель данных, содержащий сохраненные на нем инструкции, которые, при исполнении, побуждают модуль отправки протокола на основе файла устройства-источника:
принимать поток данных, содержащих сегменты мультимедийных данных, от сегментатора устройства-источника, который формирует сегменты, причем каждый из сегментов содержит соответствующий индивидуально извлекаемый файл, ассоциированный с уникальным унифицированным указателем ресурса (URL) или унифицированным идентификатором ресурса (URI);
определять местоположения событий доставки мультимедиа (MDE) в потоке мультимедийных данных, причем MDE включают в себя данные для, по меньшей мере, части одного из сегментов;
определять одно или несколько требований к времени передачи для MDE, представляющих моменты времени, в которые MDE должны быть отправлены на клиентское устройство; и
предоставлять MDE и данные, представляющие требования к времени передачи, на модуль отправки физического уровня устройства-источника в соответствии с доступными временными интервалами доставки для модуля отправки физического уровня.
29. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять местоположения MDE, содержат инструкции, которые побуждают процессор определять местоположения MDE с использованием сопоставления шаблонов.
30. Считываемый компьютером носитель данных по п. 29, в котором мультимедийные данные содержат видеоданные, и в котором инструкции, которые побуждают процессор определять местоположения MDE с использованием сопоставления шаблонов, содержат инструкции, которые побуждают процессор:
получать данные, определяющие каденцию для видеокадров потока, причем определенная каденция представляет порядок, в котором отправляются типы для видеокадров, причем типы для видеокадров включают в себя интра-предсказанные видеокадры и интер-предсказанные видеокадры; и
определять, по меньшей мере, некоторые из MDE на основе определенной каденции так, что MDE находятся между соответствующими границами видеокадров.
31. Считываемый компьютером носитель данных по п. 29, в котором мультимедийные данные содержат аудиоданные, и в котором инструкции, которые побуждают процессор определять местоположения MDE с использованием сопоставления шаблонов, содержат инструкции, которые побуждают процессор:
определять фиксированное количество аудиокадров потока для включения в каждое из MDE; и
определять, по меньшей мере, некоторые из MDE так, чтобы каждое включало в себя фиксированное количество аудиокадров из потока.
32. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять местоположения MDE, содержат инструкции, которые побуждают процессор определять местоположения MDE с использованием правил, содержащие инструкции, которые побуждают процессор:
принимать данные, представляющие одно или несколько правил, определяющих одно или несколько из аудиокадров, видеокадров и синхронизированных текстовых экземпляров;
определять местоположения по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра на основе правил; и
определять MDE на основе местоположений по меньшей мере одного аудиокадра, видеокадра или синхронизированного текстового экземпляра.
33. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять местоположения MDE, содержат инструкции, которые побуждают процессор определять местоположения MDE на основе информации о времени для синхронизации физического уровня модуля отправки физического уровня.
34. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять местоположения MDE, содержат инструкции, которые побуждают процессор анализировать хинт-трек, включающий в себя метаданные, представляющие местоположения воспроизводимых данных в потоке.
35. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять требования к времени передачи, содержат инструкции, которые побуждают процессор определять самое раннее время передачи для одного из MDE на основе системной конфигурации устройства-источника.
36. Считываемый компьютером носитель данных по п. 28, в котором инструкции, которые побуждают процессор определять требования к времени передачи, содержат инструкции, которые побуждают процессор определять самое последнее время передачи для одного из MDE на основе времени доступности сегмента для сегмента, данные для которого включены в одно из MDE, причем способ дополнительно содержит определение времени доступности сегмента из файла манифеста для потока данных.
RU2018124449A 2016-01-08 2017-01-06 Определение местоположений событий доставки мультимедиа для транспортировки мультимедиа RU2718170C2 (ru)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201662276674P 2016-01-08 2016-01-08
US62/276,674 2016-01-08
US15/399,381 US10666961B2 (en) 2016-01-08 2017-01-05 Determining media delivery event locations for media transport
US15/399,381 2017-01-05
PCT/US2017/012551 WO2017120482A1 (en) 2016-01-08 2017-01-06 Determining media delivery event locations for media transport

Publications (3)

Publication Number Publication Date
RU2018124449A3 RU2018124449A3 (ru) 2020-02-10
RU2018124449A RU2018124449A (ru) 2020-02-10
RU2718170C2 true RU2718170C2 (ru) 2020-03-30

Family

ID=57882176

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2018124449A RU2718170C2 (ru) 2016-01-08 2017-01-06 Определение местоположений событий доставки мультимедиа для транспортировки мультимедиа

Country Status (20)

Country Link
US (1) US10666961B2 (ru)
EP (1) EP3400712B1 (ru)
JP (1) JP6893930B2 (ru)
KR (1) KR20180101371A (ru)
CN (1) CN108432261B (ru)
AU (1) AU2017205187B2 (ru)
CA (1) CA3007318C (ru)
CL (1) CL2018001833A1 (ru)
CO (1) CO2018006980A2 (ru)
ES (1) ES2864645T3 (ru)
HK (1) HK1257973A1 (ru)
HU (1) HUE052430T2 (ru)
MX (1) MX2018008372A (ru)
MY (1) MY192795A (ru)
NZ (1) NZ743019A (ru)
RU (1) RU2718170C2 (ru)
SA (1) SA518391872B1 (ru)
SG (1) SG11201804448QA (ru)
TW (1) TWI740878B (ru)
WO (1) WO2017120482A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU203858U1 (ru) * 2020-08-05 2021-04-23 Общество с ограниченной ответственностью "Витрина ТВ" Устройство отображения и воспроизведения аудиовизуального контента

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10129358B2 (en) * 2016-01-15 2018-11-13 Verizon Digital Media Services Inc. Partitioned serialized caching and delivery of large files
WO2017152178A1 (en) * 2016-03-04 2017-09-08 Bladelogic, Inc. Provisioning of containers for virtualized applications
JP7011586B2 (ja) * 2016-06-30 2022-01-26 ソニーセミコンダクタソリューションズ株式会社 受信装置
BR112019000571A2 (pt) * 2016-07-20 2019-07-02 Sony Corp dispositivo de recepção e método de processamento de dados.
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US11412312B2 (en) * 2016-09-28 2022-08-09 Idomoo Ltd System and method for generating customizable encapsulated media files
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
US10904313B2 (en) * 2017-06-20 2021-01-26 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses, methods, computer programs, and computer program products for live uplink adaptive streaming
US11146608B2 (en) * 2017-07-20 2021-10-12 Disney Enterprises, Inc. Frame-accurate video seeking via web browsers
US10750220B2 (en) * 2018-04-06 2020-08-18 Enensys Technologies Method for generating a STL stream, local adapter and corresponding computer program
CN108737845B (zh) * 2018-05-22 2019-09-10 北京百度网讯科技有限公司 直播处理方法、装置、设备以及存储介质
US10652849B2 (en) * 2018-07-16 2020-05-12 Sinclair Broadcast Group, Inc. Using broadcast physical layer for one-way time transfer of universal coordinated time to receivers
CN109471736A (zh) * 2018-09-14 2019-03-15 叮联信息技术有限公司 事件信息不间断随机传递及实时共享方法
WO2020060990A1 (en) 2018-09-17 2020-03-26 Google Llc Methods, systems, and media for delivering manifestless streaming media content
KR102124194B1 (ko) * 2018-12-19 2020-06-23 포디리플레이코리아 주식회사 영상분석을 위한 다채널 영상 전송 시스템 및 이의 제어 방법
US10700798B1 (en) * 2019-03-01 2020-06-30 GM Global Technology Operations LLC System and method to receive and deliver audio content
US12101526B2 (en) * 2019-12-11 2024-09-24 Saturn Licensing Llc Reducing latency during service change and improving robustness in advanced television systems committee (ATSC) 3.0 system
EP4085642A4 (en) * 2020-01-03 2024-01-03 Nokia Technologies Oy REAL-TIME TEXTURE ADAPTATION METHOD
CN113141514B (zh) * 2020-01-17 2022-07-22 北京达佳互联信息技术有限公司 媒体流传输方法、系统、装置、设备及存储介质
WO2021251886A1 (en) * 2020-06-09 2021-12-16 Telefonaktiebolaget Lm Ericsson (Publ) Providing semantic information with encoded image data
CN114598756B (zh) * 2020-12-01 2024-03-12 深圳Tcl数字技术有限公司 一种alp数据包的处理方法、存储介质及电子设备
US11882170B2 (en) * 2021-04-19 2024-01-23 Tencent America LLC Extended W3C media extensions for processing dash and CMAF inband events

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080037956A1 (en) * 2006-06-30 2008-02-14 Scientific-Atlanta, Inc. Systems and Methods of Generating Encapsulated MPEG Program Streams
US20120259994A1 (en) * 2011-04-05 2012-10-11 Gillies Donald W Ip broadcast streaming services distribution using file delivery methods
US20140375894A1 (en) * 2013-06-24 2014-12-25 Broadcom Corporation Video channel change system
RU2598992C2 (ru) * 2012-06-07 2016-10-10 Хуавэй Текнолоджиз Ко., Лтд. Способ, устройство и система для отправки сигнала физического уровня

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4392880B2 (ja) * 1998-06-29 2010-01-06 キヤノン株式会社 認証装置及びその制御方法並びに記憶媒体
US7146429B2 (en) * 2001-03-16 2006-12-05 The Aerospace Corporation Cooperative adaptive web caching routing and forwarding web content data requesting method
JP2007213772A (ja) * 2006-01-11 2007-08-23 Sony Corp 記録転送プログラム、記録転送装置及び記録転送方法
JP2008257592A (ja) * 2007-04-06 2008-10-23 Iwate Broadcasting Co Ltd クライアント端末、コンテンツ再生方法及びコンテンツ再生プログラム
JP4427567B2 (ja) * 2007-07-03 2010-03-10 株式会社東芝 無線通信装置及び無線通信方法
EP2235642A4 (en) 2007-12-13 2016-08-03 Highwinds Holdings Inc CONTENT DELIVERY NETWORK
CN101222509B (zh) * 2008-01-22 2011-10-26 中兴通讯股份有限公司 一种点对点网络的数据保护传输方法
CN101616009B (zh) * 2008-06-27 2011-07-06 中国移动通信集团公司 数据业务的传输方法及其设备
MX2011006973A (es) 2008-12-31 2011-12-06 Apple Inc Transmision de flujos de datos en tiempo real o en tiempo casi real.
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US9032451B2 (en) 2011-09-01 2015-05-12 The Directv Group, Inc. Method and system for using a second screen device for interacting with a set top box to enhance a user experience
US9591361B2 (en) * 2011-09-07 2017-03-07 Qualcomm Incorporated Streaming of multimedia data from multiple sources
GB2506911B (en) * 2012-10-12 2015-12-09 Canon Kk Method and correponding device for streaming video data
EP2939420B1 (en) 2013-01-15 2018-03-14 Huawei Technologies Co., Ltd. Using quality information for adaptive streaming of media content
MX2015014412A (es) 2013-04-16 2016-02-16 Lg Electronics Inc Dispositivo de transmision de radiodifusion, dispositivo de recepcion de radiodifusion, metodo de operacion del dispositivo de transmision de radiodifusion y metodo de operacion de dispositivo de recepcion de radiodifusion.
CN104283849A (zh) * 2013-07-04 2015-01-14 深圳市天趣网络科技有限公司 弹窗数据推送、展示方法及装置、系统
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
CN105100015B (zh) 2014-05-16 2018-07-03 林琳 一种采集互联网访问数据的方法及装置
US20170055046A1 (en) 2014-05-21 2017-02-23 Lg Electronics Inc. Broadcast signal transmitting/receiving method and device
WO2016129973A1 (ko) 2015-02-15 2016-08-18 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080037956A1 (en) * 2006-06-30 2008-02-14 Scientific-Atlanta, Inc. Systems and Methods of Generating Encapsulated MPEG Program Streams
US20120259994A1 (en) * 2011-04-05 2012-10-11 Gillies Donald W Ip broadcast streaming services distribution using file delivery methods
RU2598992C2 (ru) * 2012-06-07 2016-10-10 Хуавэй Текнолоджиз Ко., Лтд. Способ, устройство и система для отправки сигнала физического уровня
US20140375894A1 (en) * 2013-06-24 2014-12-25 Broadcom Corporation Video channel change system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU203858U1 (ru) * 2020-08-05 2021-04-23 Общество с ограниченной ответственностью "Витрина ТВ" Устройство отображения и воспроизведения аудиовизуального контента

Also Published As

Publication number Publication date
EP3400712A1 (en) 2018-11-14
AU2017205187B2 (en) 2020-09-10
HUE052430T2 (hu) 2021-04-28
TWI740878B (zh) 2021-10-01
MY192795A (en) 2022-09-09
CL2018001833A1 (es) 2018-10-12
WO2017120482A1 (en) 2017-07-13
CO2018006980A2 (es) 2018-07-19
MX2018008372A (es) 2018-09-21
RU2018124449A3 (ru) 2020-02-10
AU2017205187A1 (en) 2018-06-21
JP2019506059A (ja) 2019-02-28
TW201725911A (zh) 2017-07-16
CN108432261B (zh) 2021-01-05
US10666961B2 (en) 2020-05-26
RU2018124449A (ru) 2020-02-10
CA3007318A1 (en) 2017-07-13
JP6893930B2 (ja) 2021-06-23
KR20180101371A (ko) 2018-09-12
EP3400712B1 (en) 2020-12-23
CN108432261A (zh) 2018-08-21
US20170201761A1 (en) 2017-07-13
NZ743019A (en) 2024-07-05
ES2864645T3 (es) 2021-10-14
SA518391872B1 (ar) 2022-01-24
CA3007318C (en) 2023-08-15
HK1257973A1 (zh) 2019-11-01
BR112018013750A2 (pt) 2018-12-11
SG11201804448QA (en) 2018-07-30

Similar Documents

Publication Publication Date Title
RU2718170C2 (ru) Определение местоположений событий доставки мультимедиа для транспортировки мультимедиа
CN107409234B (zh) 基于lct利用dash格式的基于文件格式的流式传输
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
CN107113460B (zh) 针对空中广播媒体数据的会话描述信息
KR102168596B1 (ko) 저 레이턴시 비디오 스트리밍
US9591361B2 (en) Streaming of multimedia data from multiple sources
RU2558615C2 (ru) Обновление файла манифеста для сетевой потоковой передачи кодированных видеоданных
US20160164943A1 (en) Transport interface for multimedia and file transport
US10887645B2 (en) Processing media data using file tracks for web content
US20180316740A1 (en) Deadline signaling for streaming of media data
US20170331666A1 (en) Real-time control interface for broadcast object streaming
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
BR112018013750B1 (pt) Método de transporte de dados de mídia por uma unidade de envio de protocolo baseado em arquivo de um dispositivo de origem, dispositivo de origem para transporte de dados de mídia e memória legível por computador