Оновлення файла маніфесту для мережевої потокової передачі кодованих відеоданих
Формула / Реферат
1. Спосіб отримання мультимедійних даних, причому спосіб включає етапи, на яких:
отримують дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого клієнтським пристроєм, при цьому дані першого сегмента відповідають періоду мультимедійного контенту;
отримують частину другого сегмента представлення відповідно до файлу маніфесту, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента, при цьому другий сегмент має місце після першого сегмента в згаданому представленні, і при цьому згадана частина другого сегмента вказує, що файл маніфесту повинен бути оновлений;
оновлюють копію файлу маніфесту, збереженого клієнтським пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений; і
отримують медіадані другого сегмента відповідно до оновленого файлу маніфесту.
2. Спосіб за п. 1, в якому оновлення файлу маніфесту включає етап, на якому оновлюють файл маніфесту з використанням даних згаданої частини другого сегмента.
3. Спосіб за п. 1, в якому оновлення файлу маніфесту включає етап, на якому отримують дані для оновлення файлу маніфесту з місцеположення, вказаного в згаданій частині другого сегмента.
4. Спосіб за п. 1, в якому оновлення файлу маніфесту включає етапи, на яких: визначають один або більше елементів файлу маніфесту, які повинні бути оновлені; і
оновлюють тільки визначений один або більше елементів файлу маніфесту.
5. Спосіб за п. 1, який додатково включає етапи, на яких:
отримують медіадані з другого, іншого представлення мультимедійного контенту;і
відправляють інформацію, що вказує дані, отримані з першого представлення і другого представлення.
6. Спосіб за п. 5, який додатково включає етап, на якому:
створюють електронний документ, форматований за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, у тому числі перше і друге представлення, з яких були отримані медіадані,
при цьому відправка інформації, що вказує отримані дані, включає етап, на якому відправляють створений документ серверу, від якого були отримані медіадані.
7. Пристрій для отримання мультимедійних даних, причому пристрій містить один або більше процесорів, сконфігурованих, щоб отримувати дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм, при цьому дані першого сегмента відповідають періоду мультимедійного контенту, отримувати частину другого сегмента представлення відповідно до файлу маніфесту, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента, при цьому другий сегмент має місце після першого сегмента в згаданому представленні, і при цьому згадана частина другого сегмента вказує, що файл маніфесту повинен бути оновлений, оновлювати копію файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений, і отримувати медіадані другого сегмента відповідно до оновленого файлу маніфесту.
8. Пристрій за п. 7, в якому для оновлення файлу маніфесту один або більше процесорів сконфігуровані, щоб оновлювати файл маніфесту, використовуючи дані згаданої частини другого сегмента.
9. Пристрій за п. 7, в якому для оновлення файлу маніфесту один або більше процесорів сконфігуровані, щоб отримувати дані для оновлення файлу маніфесту з місцеположення, вказаного в згаданій частині другого сегмента.
10. Пристрій за п. 7, в якому для оновлення файлу маніфесту один або більше процесорів сконфігуровані, щоб визначати один або більше елементів файлу маніфесту, які повинні бути оновлені, і оновлювати тільки визначені один або більше елементів файлу маніфесту.
11. Пристрій за п. 7, в якому один або більше процесорів додатково сконфігуровані, щоб отримувати медіадані з другого, іншого представлення мультимедійного контенту і відправляти інформацію, що вказує дані, отримані з першого представлення і другого представлення.
12. Пристрій за п. 11, в якому один або більше процесорів додатково сконфігуровані, щоб створювати електронний документ, форматований за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, у тому числі перше і друге представлення, з яких були отримані медіадані, і при цьому, щоб відправити інформацію, що вказує отримані дані, один або більше процесорів сконфігуровані відправляти створений документ серверу, від якого були отримані медіадані.
13. Пристрій за п. 7, причому пристрій містить щонайменше одне з:
інтегральної схеми;
мікропроцесора; і
пристрою бездротового зв'язку, який включає в себе один або більше процесорів.
14. Пристрій для отримання мультимедійних даних, причому пристрій містить:
засіб для отримання даних першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм, при цьому дані першого сегмента відповідають періоду мультимедійного контенту;
засіб для отримання частини другого сегмента представлення відповідно до файлу маніфесту, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента, при цьому другий сегмент має місце після першого сегмента в згаданому представленні, і при цьому згадана частина другого сегмента вказує, що файл маніфесту повинен бути оновлений;
засіб для оновлення копії файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений; і
засіб для отримання медіаданих другого сегмента відповідно до оновленого файлу маніфесту.
15. Пристрій за п. 14, в якому оновлення файлу маніфесту містить оновлення файлу маніфесту з використанням даних згаданої частини другого сегмента.
16. Пристрій за п. 14, в якому оновлення файлу маніфесту містить отримання даних для оновлення файлу маніфесту з місцеположення, вказаного в згаданій частині другого сегмента.
17. Пристрій за п. 14, в якому засіб для оновлення файлу маніфесту містить:
засіб для визначення одного або більше елементів файлу маніфесту, які повинні бути оновлені; і
засіб для оновлення тільки визначених одного або більше елементів файлу маніфесту.
18. Пристрій за п. 14, який додатково містить:
засіб для отримання медіаданих з другого, іншого представлення мультимедійного контенту; і
засіб для відправки інформації, що вказує дані, отримані з першого представлення і другого представлення.
19. Пристрій за п. 18, який додатково містить:
засіб для створення електронного документа, форматованого за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, у тому числі перше і друге представлення, з яких були отримані медіадані,
при цьому засіб для відправки інформації, що вказує отримані дані, містить засіб для відправки створеного документа серверу, від якого були отримані медіадані.
20. Комп'ютерно-читаний носій, що містить збережені на ньому інструкції, які при виконанні приписують процесору пристрою для отримання мультимедійних даних:
отримувати дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм, при цьому дані першого сегмента відповідають періоду мультимедійного контенту;
отримувати частину другого сегмента представлення відповідно до файлу маніфесту, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента, при цьому другий сегмент має місце після першого сегмента в згаданому представленні, і при цьому згадана частина другого сегмента вказує, що файл маніфесту повинен бути оновлений;
оновлювати копію файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений; і
отримувати медіадані другого сегмента відповідно до оновленого файлу маніфесту.
21. Комп'ютерно-читаний носій за п. 20, в якому інструкції, які приписують процесору оновлювати файл маніфесту, містять інструкції, які приписують процесору оновлювати файл маніфесту, використовуючи дані згаданої частини другого сегмента.
22. Комп'ютерно-читаний носій за п. 20, в якому інструкції, які приписують процесору оновлювати файл маніфесту, містять інструкції, які приписують процесору отримувати дані, щоб оновити файл маніфесту з місцеположення, вказаного в згаданій частині другого сегмента.
23. Комп'ютерно-читаний носій за п. 20, в якому інструкції, які приписують процесору оновлювати файл маніфесту, містять інструкції, які приписують процесору:
визначати один або більше елементів файлу маніфесту, які повинні бути оновлені; і
оновлювати тільки визначені один або більше елементів файлу маніфесту.
24. Комп'ютерно-читаний носій за п. 20, який додатково містить інструкції, які приписують процесору:
отримувати медіадані з другого, іншого представлення мультимедійного контенту; і
відправляти інформацію, що вказує дані, отримані з першого представлення і другого представлення.
25. Комп'ютерно-читаний носій за п. 24, який додатково містить інструкції, які приписують процесору:
створювати електронний документ, форматований за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, у тому числі перше і друге представлення, з яких були отримані медіадані,
при цьому інструкції, які приписують процесору відправляти інформацію, що вказує отримані дані, містять інструкції, які приписують процесору відправляти створений документ серверу, від якого були отримані медіадані.
26. Спосіб відправки інформації для мультимедійних даних, причому спосіб включає етапи, на яких:
відправляють дані файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, що вказує перший сегмент представлення мультимедійного контенту, при цьому дані першого сегмента відповідають періоду мультимедійного контенту;
відправляють щонайменше частину першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому згадана частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, що вказує другий, інший сегмент представлення, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента; і
відправляють у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, дані другого сегмента клієнтському пристрою.
27. Спосіб за п. 26, в якому згадана частина першого сегмента включає в себе інформацію, що вказує оновлення до файлу маніфесту.
28. Спосіб за п. 26, в якому згадана частина першого сегмента включає в себе інформацію, що вказує місцеположення даних, що вказують оновлення до файлу маніфесту.
29. Спосіб за п. 26, який додатково включає етап, на якому приймають інформацію, що вказує дані мультимедійного контенту, отримані клієнтським пристроєм.
30. Спосіб за п. 29, в якому прийом інформації, що вказує дані, отримані клієнтським пристроєм, включає етап, на якому приймають електронний документ, форматований за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, з яких клієнтський пристрій отримав медіадані мультимедійного контенту.
31. Пристрій для відправки інформації для мультимедійних даних, причому пристрій містить один або більше процесорів, сконфігурованих, щоб відправляти дані файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, що вказує перший сегмент представлення мультимедійного контенту, при цьому дані першого сегмента відповідають періоду мультимедійного контенту, відправляти щонайменше частину першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому згадана частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, що вказує другий, інший сегмент представлення, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента, і відправляти у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, дані другого сегмента клієнтському пристрою.
32. Пристрій за п. 31, в якому згадана частина першого сегмента включає в себе інформацію, що вказує оновлення до файлу маніфесту.
33. Пристрій за п. 31, в якому згадана частина першого сегмента включає в себе інформацію, що вказує місцеположення даних, що вказують оновлення до файлу маніфесту.
34. Пристрій за п. 31, в якому один або більше процесорів сконфігуровані, щоб приймати інформацію, що вказує дані мультимедійного контенту, отримані клієнтським пристроєм.
35. Пристрій за п. 34, в якому інформація, що вказує дані, отримані клієнтським пристроєм, містить прийом електронного документа, форматованого за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, з яких клієнтський пристрій отримав медіадані мультимедійного контенту.
36. Пристрій за п. 31, причому пристрій містить щонайменше одне з:
інтегральної схеми;
мікропроцесора; і
пристрою бездротового зв'язку, який включає в себе один або більше процесорів.
37. Пристрій для відправки інформації для мультимедійних даних, причому пристрій містить:
засіб для відправки даних файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, що вказує перший сегмент представлення мультимедійного контенту, при цьому дані першого сегмента відповідають періоду мультимедійного контенту;
засіб для відправки щонайменше частини першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому згадана частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, що вказує другий, інший сегмент представлення, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента; і
засіб для відправки у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, даних другого сегмента клієнтському пристрою.
38. Пристрій за п. 37, в якому згадана частина першого сегмента включає в себе інформацію, що вказує оновлення до файлу маніфесту.
39. Пристрій за п. 37, в якому згадана частина першого сегмента включає в себе інформацію, що вказує місцеположення даних, що вказують оновлення до файлу маніфесту.
40. Пристрій за п. 37, який додатково містить засіб для прийому інформації, що вказує дані мультимедійного контенту, отримані клієнтським пристроєм.
41. Пристрій за п. 40, в якому засіб для прийому інформації, що вказує дані, отримані клієнтським пристроєм, містить засіб для прийому електронного документа, форматованого за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, з яких клієнтський пристрій отримав медіадані мультимедійного контенту.
42. Комп'ютерно-читаний носій, що містить збережені на ньому інструкції, які при виконанні приписують процесору пристрою для відправки інформації для мультимедійних даних:
відправляти дані файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, що вказує перший сегмент представлення мультимедійного контенту, при цьому дані першого сегмента відповідають періоду мультимедійного контенту,
відправляти щонайменше частину першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому згадана частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, що вказує другий, інший сегмент представлення, при цьому дані другого сегмента відповідають періоду, якому відповідають дані першого сегмента; і
відправляти у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, дані другого сегмента клієнтському пристрою.
43. Комп'ютерно-читаний носій за п. 42, в якому згадана частина першого сегмента включає в себе інформацію, що вказує оновлення до файлу маніфесту.
44. Комп'ютерно-читаний носій за п. 42, в якому згадана частина першого сегмента включає в себе інформацію, що вказує місцеположення даних, що вказують оновлення до файлу маніфесту.
45. Комп'ютерно-читаний носій за п. 42, який додатково містить інструкції, які приписують процесору приймати інформацію, що вказує дані мультимедійного контенту, отримані клієнтським пристроєм.
46. Комп'ютерно-читаний носій за п. 45, в якому інструкції, які приписують процесору приймати інформацію, що вказує дані, отримані клієнтським пристроєм, містять інструкції, які приписують процесору приймати електронний документ, форматований за допомогою розширюваної мови розмітки, що включає в себе інформацію, що вказує представлення мультимедійного контенту, з яких клієнтський пристрій отримав медіадані мультимедійного контенту.
Текст
Реферат: В одному прикладі розкритий пристрій для отримання мультимедійних даних, причому пристрій містить один або більше процесорів, сконфігурованих отримувати дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм; отримувати частину другого сегмента представлення відповідно до файлу маніфесту, при цьому другий сегмент має місце після першого сегмента в згаданому представленні, і при цьому згадана частина другого сегмента вказує, що файл маніфесту повинен бути оновлений; оновлювати копію файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений; і отримувати медіадані другого сегмента відповідно до оновленого файлу маніфесту. UA 107394 C2 (12) UA 107394 C2 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 Галузь техніки, до якої належить винахід Це розкриття належить до зберігання і транспортування закодованих мультимедійних даних. Рівень техніки Можливості цифрового відео можуть бути вбудовані в широкий спектр пристроїв, включаючи цифрові телевізори, системи прямого цифрового мовлення, системи бездротового мовлення, кишенькові персональні комп'ютери (PDA), ноутбуки або настільні комп'ютери, цифрові фотоапарати, пристрої цифрового запису, цифрові медіапрогравачі, відеоігрові пристрої, ігрові приставки, стільникові або супутникові радіотелефони, пристрої відеоконференцзв'язку і т.п. Цифрові відеопристрої реалізовують методи стиснення відео, наприклад, описані в стандартах, визначених в MPEG-2, MPEG-4, ITU-T H.263 або ITU-T H.264/MPEG-4, Частина 10, Вдосконалене кодування відео (AVC), і розширеннях таких стандартів, для більш ефективної передачі і прийому цифрової відеоінформації. Методи стиснення відео виконують просторовий прогноз і/або часовий прогноз для зменшення або усунення надмірності, властивої послідовностям відеокадрів. При блоковому відеокодуванні відеокадр або секція можуть бути розділені на макроблоки. Кожний макроблок може бути додатково розділений. Макроблоки в кадрі або секції з внутрішнім кодуванням (I) кодуються з використанням просторового прогнозу по відношенню до сусідніх макроблоків. Макроблоки в кадрі або секції з міжкадровим кодуванням (Р або В) можуть використовувати просторовий прогноз по відношенню до сусідніх макроблоків в тому ж самому кадрі або секції або часовий прогноз по відношенню до інших опорних кадрів. Після того як відеодані були закодовані, відеодані можуть бути пакетовані для передачі або зберігання. Відеодані можуть бути зібрані у відеофайл, відповідний будь-якому з множини стандартів, таких як основний формат медіафайла Міжнародної організації по стандартизації (ISO) і його розширення, такий як ITU-T H.264/AVC. Такі пакетовані відеодані можуть транспортуватися множиною шляхів, наприклад, за допомогою передачі по комп'ютерній мережі за допомогою мережевої потокової передачі. СУТЬ ВИНАХОДУ Загалом, це розкриття описує методи для поліпшення потокової передачі медіаданих по мережі. Ці методи включають в себе підтримку для нестандартних режимів, таких як прискорене перемотування уперед, перемотування назад і пошук в межах медіаконтенту, що передається по мережі. Ці методи також включають в себе підтримку для груп представлень, наприклад, інформування про загальні характеристики для групи представлень, а також індивідуальних характеристик представлень. Крім того, методи включають в себе надання інформації для оновлення файлів маніфесту для медіаконтенту, що передається. Методи також включають в себе забезпечення медіаданих для адресної реклами у вигляді зовнішніх періодів для медіаконтенту. Ці методи додатково включають в себе надання і інтерпретацію звітів про якість сприйняття від клієнтського пристрою постачальнику послуг. Крім того, ці методи включають в себе повідомлення даних профілю, яким відповідає файл маніфесту медіаконтенту. В одному прикладі спосіб отримання відеоданих включає в себе аналіз щонайменше частини файлу маніфесту для мультимедійного контенту, при цьому частина файлу маніфесту включає в себе інформацію, яка вказує набори представлень мультимедійного контенту, і інформацію, яка вказує загальні характеристики для кожного з наборів представлень, вибір одного з наборів представлень на основі загальних характеристик для одного з наборів представлень, вибір одного з представлень вибраного одного з наборів представлень на основі однієї або більше характеристик кодування одного з представлень одного з наборів, і створення запиту на дані одного з представлень на основі вибору. В іншому прикладі пристрій для прийому інформації для відеоданих включає в себе один або більш процесорів, сконфігурованих, щоб аналізувати щонайменше частину файлу маніфесту для мультимедійного контенту, при цьому частина файлу маніфесту включає в себе інформацію, яка вказує набори представлень мультимедійного контенту, і інформацію, яка вказує загальні характеристики для кожного з наборів представлень, вибирати один з наборів представлень на основі загальних характеристик для одного з наборів представлень, вибирати одне з представлень вибраного одного з наборів представлень на основі однієї або більше характеристик кодування одного з представлень одного з наборів, і створювати запит на дані одного з представлень на основі вибору. В іншому прикладі пристрій для прийому інформації для відеоданих включає в себе засіб для аналізу щонайменше частини файлу маніфесту для мультимедійного контенту, при цьому частина файлу маніфесту включає в себе інформацію, яка вказує набори представлень мультимедійного контенту, і інформацію, яка вказує загальні характеристики для кожного з наборів представлень, засіб для вибору одного з наборів представлень на основі загальних 1 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 характеристик для одного з наборів представлень, засіб для вибору одного з представлень вибраного одного з наборів представлень на основі однієї або більше характеристик кодування одного з представлень одного з наборів, і засіб для створення запиту на дані одного з представлень на основі вибору. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій даних, що містить інструкції, які при виконанні приписують процесору пристрою отримувати відеодані для аналізу щонайменше частини файлу маніфесту для мультимедійного контенту, при цьому частина файлу маніфесту включає в себе інформацію, яка вказує набори представлень мультимедійного контенту, і інформацію, яка вказує загальні характеристики для кожного з наборів представлень, вибирати один з наборів представлень на основі загальних характеристик для одного з наборів представлень, вибирати одне з представлень вибраного одного з наборів представлень на основі однієї або більше характеристик кодування одного з представлень одного з наборів, і створювати запит на дані одного з представлень на основі вибору. В іншому прикладі спосіб відправки інформації для відеоданих включає в себе отримання набору представлень мультимедійного контенту, що має одну або більше загальних характеристик, при цьому кожне з представлень в наборі має одну або більше індивідуальних характеристик кодування, окремих від загальних характеристик, отримання файлу маніфесту для мультимедійного контенту, при цьому файл маніфесту включає в себе інформацію, яка вказує представлення в наборі, інформацію, яка вказує загальні характеристики для набору представлень, і інформацію, яка вказує характеристики кодування для кожного з представлень в наборі, і відправку щонайменше частини файлу маніфесту клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих містить один або більше процесорів, сконфігурованих, щоб отримувати набір представлень мультимедійного контенту, що має одну або більше загальних характеристик, при цьому кожне з представлень в наборі має одну або більше індивідуальних характеристик кодування, окремих від загальних характеристик, отримувати файл маніфесту для мультимедійного контенту, при цьому файл маніфесту включає в себе інформацію, яка вказує представлення в наборі, інформацію, яка вказує загальні характеристики для набору представлень, і інформацію, яка вказує характеристики кодування для кожного з представлень в наборі, і відправляти щонайменше частину файлу маніфесту клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих включає в себе засіб для отримання набору представлень мультимедійного контенту, що має одну або більше загальних характеристик, при цьому кожне з представлень в наборі має одну або більше індивідуальних характеристик кодування, окремих від загальних характеристик, засіб для отримання файлу маніфесту для мультимедійного контенту, при цьому файл маніфесту включає в себе інформацію, яка вказує представлення в наборі, інформацію, яка вказує загальні характеристики для набору представлень, і інформацію, яка вказує характеристики кодування для кожного з представлень в наборі, і засіб відправки щонайменше частини файлу маніфесту клієнтському пристрою. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій даних, що містить інструкції, які приписують процесору пристрою для забезпечення відеоданих отримувати набір представлень мультимедійного контенту, що має одну або більше загальних характеристик, при цьому кожне з представлень в наборі має одну або більше індивідуальних характеристик кодування, окремих від загальних характеристик, отримувати файл маніфесту для мультимедійного контенту, при цьому файл маніфесту включає в себе інформацію, яка вказує представлення в наборі, інформацію, яка вказує загальні характеристики для набору представлень, і інформацію, яка вказує характеристики кодування для кожного з представлень в наборі, і відправляти щонайменше частину файлу маніфесту клієнтському пристрою. В іншому прикладі спосіб отримання відеоданих включає в себе аналіз інформації файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, визначення одного або більше місцеположення даних для часової підпослідовності і подачу одного або більше запитів на дані для часової підпослідовності. В іншому прикладі пристрій для отримання відеоданих включає в себе один або більше процесорів, сконфігурованих аналізувати інформацію файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, визначати одне або більше 2 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 місцеположення даних для часової підпослідовності і подавати один або більше запитів на дані для часової підпослідовності. В іншому прикладі пристрій для отримання відеоданих включає в себе засіб для аналізу інформації файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, засіб для визначення одного або більше місцеположення даних для часової підпослідовності і засіб для подачі одного або більше запитів на дані для часової підпослідовності. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій, що містить інструкції, які зберігаються на ньому, які при виконанні приписують процесору пристрою для отримання відеоданих аналізувати інформацію файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, визначати одне або більше місцеположення даних для часової підпослідовності і подавати один або більше запитів на дані для часової підпослідовності. В іншому прикладі спосіб відправки інформації для відеоданих включає в себе отримання даних щонайменше для одного представлення мультимедійного контенту, яке включає в себе часову підпослідовність, отримання даних для файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, і відправку щонайменше частини файлу маніфесту клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих включає в себе один або більше процесорів, сконфігурованих, щоб отримувати дані щонайменше для одного представлення мультимедійного контенту, яке включає в себе часову підпослідовність, отримувати дані для файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, і відправляти щонайменше частину файлу маніфесту клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих включає в себе засіб для отримання даних щонайменше для одного представлення мультимедійного контенту, яке включає в себе часову підпослідовність, засіб для отримання даних для файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, і засіб для відправки щонайменше частини файлу маніфесту клієнтському пристрою. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій, що містить інструкції, які зберігаються на ньому, які при виконанні приписують процесору пристрою для відправки інформації для відеоданих отримувати дані щонайменше для одного представлення мультимедійного контенту, яке включає в себе часову підпослідовність, отримувати дані для файлу маніфесту для мультимедійного контенту, при цьому інформація файлу маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність, і відправляти щонайменше частину файлу маніфесту клієнтському пристрою. В іншому прикладі спосіб отримання відеоданих включає в себе отримання даних першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого клієнтським пристроєм, отримання частини другого сегмента представлення відповідно до файлу маніфесту, при цьому другий сегмент має місце після першого сегмента в представленні, і при цьому частина другого сегмента вказує, що файл маніфесту повинен бути оновлений, оновлення копії файлу маніфесту, збереженого клієнтським пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений, і отримання медіаданих другого сегмента відповідно до оновленого файлу маніфесту. В іншому прикладі пристрій для отримання відеоданих включає в себе один або більше процесорів, сконфігурованих, щоб отримувати дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм, отримувати частину другого сегмента представлення відповідно до файлу маніфесту, при цьому другий сегмент має місце після першого сегмента в представленні, і при цьому частина другого сегмента вказує, що файл маніфесту повинен бути оновлений, оновлювати копію файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений, і отримувати медіадані другого сегмента відповідно до оновленого файлу маніфесту. 3 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 В іншому прикладі пристрій для отримання відеоданих включає в себе засіб для отримання даних першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого клієнтським пристроєм, засіб отримання частини другого сегмента представлення відповідно до файлу маніфесту, при цьому другий сегмент має місце після першого сегмента в представленні, і при цьому частина другого сегмента вказує, що файл маніфесту повинен бути оновлений, засіб для оновлення копії файлу маніфесту, збереженого клієнтським пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений, і засіб отримання медіаданих другого сегмента відповідно до оновленого файлу маніфесту. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій, що містить інструкції, які зберігаються на ньому, які при виконанні приписують процесору пристрою для отримання відеоданих отримувати дані першого сегмента представлення мультимедійного контенту відповідно до даних копії файлу маніфесту, збереженого пристроєм, отримувати частину другого сегмента представлення відповідно до файлу маніфесту, при цьому другий сегмент має місце після першого сегмента в представленні, і при цьому частина другого сегмента вказує, що файл маніфесту повинен бути оновлений, оновлювати копію файлу маніфесту, збереженого пристроєм, на основі вказівки, що файл маніфесту повинен бути оновлений, і отримувати медіадані другого сегмента відповідно до оновленого файлу маніфесту. В іншому прикладі спосіб відправки інформації для відеоданих включає в себе відправку даних файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, яка вказує перший сегмент представлення мультимедійного контенту, відправку щонайменше частини першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, яка вказує другий інший сегмент представлення, і відправку у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, даних другого сегмента клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих включає в себе один або більше процесорів, сконфігурованих, щоб відправляти дані файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, яка вказує перший сегмент представлення мультимедійного контенту, відправляти щонайменше частину першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, яка вказує на другий, інший сегмент представлення, і відправляти у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, дані другого сегмента клієнтському пристрою. В іншому прикладі пристрій для відправки інформації для відеоданих включає в себе засіб для відправки даних файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, яка вказує перший сегмент представлення мультимедійного контенту, засіб для відправки щонайменше частини першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, яка вказує другий інший сегмент представлення, і засіб відправки у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, даних другого сегмента клієнтському пристрою. В іншому прикладі комп'ютерний програмний продукт включає в себе комп'ютерно-читаний носій, що містить інструкції, які зберігаються на ньому, які при виконанні приписують процесору пристрою для відправки інформації для відеоданих відправляти дані файлу маніфесту мультимедійного контенту клієнтському пристрою, при цьому файл маніфесту включає в себе інформацію, яка вказує перший сегмент представлення мультимедійного контенту, відправляти щонайменше частину першого сегмента представлення клієнтському пристрою у відповідь на запит від клієнтського пристрою, при цьому частина першого сегмента вказує, що файл маніфесту повинен бути оновлений, при цьому оновлена версія файлу маніфесту включає в себе інформацію, яка вказує на другий, інший сегмент представлення, і відправляти у відповідь на запит, прийнятий від клієнтського пристрою і сформований згідно з оновленим файлом маніфесту, дані другого сегмента клієнтському пристрою. Короткий опис креслень 4 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 Фіг. 1 є блок-схемою, що зображає зразкову систему, яка реалізовує методи потокової передачі медіаданих по мережі. Фіг. 2 є концептуальною схемою, що зображає елементи зразкового мультимедійного контенту. Фіг. 3 є блок-схемою, що зображає елементи зразкового відеофайлу, які можуть відповідати сегменту представлення мультимедійного контенту. Фіг. 4 є концептуальною схемою, що зображає зразковий мультимедійний контент, що включає в себе опис медіапрезентації (MPD) і різні групи представлень. Фіг. 5 є концептуальною схемою, що зображає інший зразковий мультимедійний контент, в якому дані MPD розділені на різні частини для різних груп представлень. Фіг. 6 є концептуальною схемою, що зображає інший зразковий мультимедійний контент, який може використовуватися для підтримки нестандартних режимів. Фіг. 7 є концептуальною схемою, що зображає інший зразковий мультимедійний контент, в якому сегменти можуть включати в себе поля оновлення MPD для вказівки, що MPD мультимедійного контенту повинен бути оновлений. Фіг. 8 є блок-схемою послідовності операцій, що зображає зразковий спосіб для надання вказівок відносно груп представлень серверним пристроєм, і для вибору груп представлень клієнтським пристроєм, а також окремого представлення у вибраній групі представлень. Фіг. 9 є блок-схемою послідовності операцій, що зображає зразковий спосіб для надання даних, характерних для нестандартного режиму, серверним пристроєм і для використання даних клієнтським пристроєм для отримання і відтворення даних нестандартного режиму мультимедійного контенту. Фіг. 10 є блок-схемою послідовності операцій, що зображає зразковий спосіб для забезпечення серверним пристроєм вказівок, що файл маніфесту, наприклад MPD, повинен бути оновлений, і для оновлення MPD клієнтським пристроєм. Фіг. 11 є блок-схемою послідовності операцій, що зображає зразковий спосіб для створення і використання даних звітного документа про якість сприйняття (QoE). Докладний опис Загалом, це розкриття описує методи для потокової передачі мультимедійних даних, таких як аудіодані і відеодані, по мережі. Методи цього розкриття можуть використовуватися в поєднанні з динамічною адаптивною потоковою передачею по HTTP (DASH). Це розкриття описує різні методи, які можуть виконуватися в поєднанні з потоковою передачею по мережі, будь-який або всі з яких можуть бути реалізовані по окремості або в будь-якій комбінації. Як описується більш детально нижче, різні пристрої, що виконують потокову передачу по мережі, можуть бути сконфігуровані для реалізації методів цього розкриття. Згідно з DASH і аналогічними методами для потокової передачі даних по мережі мультимедійний контент (наприклад, фільм або інший аудіо/відео-контент, який може також включати в себе текстове накладення або інші дані) може бути закодований множиною шляхів і з множиною характеристик. Пристрій підготовки контенту може сформувати множину представлень одного і того ж мультимедійного контенту. Кожне представлення може відповідати певному набору характеристик, наприклад характеристик кодування і відтворення, для забезпечення даних, які можуть використати множину різних клієнтських пристроїв з різними можливостями для кодування і відтворення. Крім того, представлення, що мають різні бітові швидкості, можуть дозволити здійснювати адаптацію під пропускну спроможність. Тобто клієнтський пристрій може визначити величину пропускної спроможності, яка в даний момент доступна, і вибрати представлення на основі величини доступної пропускної спроможності, а також можливостей для кодування і відтворення клієнтського пристрою. В деяких прикладах пристрій підготовки контенту може указати, що набір представлень має ряд загальних характеристик. Пристрій підготовки контенту може тоді указати, що представлення в наборі формують групу представлень, і представлення в наборі можуть використовуватися для адаптації під пропускну спроможність. Тобто представлення в наборі можуть відрізнятися по бітовій швидкості, але в іншому мати значною мірою однакові характеристики. Таким чином, клієнтський пристрій може визначити різні набори загальних характеристик для груп представлень мультимедійного контенту і вибрати групу представлень на основі можливостей для кодування і відтворення клієнтського пристрою. Потім клієнтський пристрій може адаптивно перемикатися між представленнями у вибраній групі представлень на основі доступної пропускної спроможності. Пристрій підготовки контенту може також забезпечувати окремі місцеположення в мережі для різних частин файлу маніфесту, наприклад файлу опису медіапрезентації (MPD) в форматі, приписаному 3GPP (Проектом партнерства третього покоління). Тобто різні частини файлу 5 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 маніфесту можуть бути незалежно такі, що адресуються з допомогою, наприклад, різних уніфікованих ідентифікаторів ресурсу (URI), таких як уніфіковані покажчики ресурсів (URL). Початкова частина файлу маніфесту може включати в себе URI, URL або інший ідентифікатор місцеположення іншої частини файлу маніфесту. Наприклад, перша частина файлу маніфесту може включати в себе описи загальних характеристик груп представлень, як обговорювалася вище. Кожній з груп представлень можуть відповідати відповідні різні частини файлу маніфесту, який може включати в себе дані, які вказують місцеположення медіаданих представлень у відповідній групі представлень. Таким чином, клієнтський пристрій може прийняти першу частину файлу маніфесту, вибрати відповідну групу представлень, отримати іншу частину файлу маніфесту для вибраної групи представлень, вибрати представлення вибраної групи і використати іншу частину файлу маніфесту, щоб отримати дані вибраного представлення. Крім того, клієнтський пристрій може пристосуватися до зміни пропускної спроможності мережі шляхом використання іншої частини файлу маніфесту, тобто частини, відповідної вибраній групі представлень. Додатково або альтернативно, частина файлу маніфесту може посилатися на інші частини файлу маніфесту для інших цілей. Тобто частина файлу маніфесту може направити клієнтський пристрій до іншої частини файлу маніфесту для того, щоб вставити медіадані винесеного періоду в фільм під час відтворення. У деяких прикладах винесений період може відповідати рекламі. У деяких прикладах ці методи можуть використовуватися для системи адресної реклами. Клієнтський пристрій може забезпечувати інформацію користувача, таку як ідентифікатор користувача, налаштування користувача для реклами і/або демографічні дані про користувача серверному пристрою, який може вибрати частину файлу маніфесту на основі призначеної для користувача інформації. Таким чином, при отриманні об'єкта посилання зовнішня частина файлу маніфесту може бути включена в початковий файл маніфесту, наприклад, клієнтським пристроєм. Серверний пристрій може забезпечити місцеположення частини файлу маніфесту, пов'язаного з адресним рекламним медіаконтентом, клієнтському пристрою. Клієнтський пристрій може потім отримати і представити дані адресного рекламного медіаконтенту перед отриманням даних конкретного представлення періоду мультимедійного контенту, що запитується. Таким чином, перша частина файлу маніфесту для мультимедійного контенту може звертатися до другої частини файлу маніфесту. У деяких випадках користувач може побажати відтворити відеодані іншим чином, не від початку до кінця. Наприклад, користувач може побажати відтворити відеодані в режимі прискореного перемотування уперед або перемотування назад, або починаючи з конкретної точки відтворення. Такі режими відтворення відео, які є режимами, відмінними від відтворення від початку до кінця, можуть згадуватися як "нестандартні режими". У нестандартних режимах, оскільки не всі відеодані будуть, зрештою, відтворені, немає необхідності отримувати всі відеодані. Це розкриття також забезпечує методи для підтримки нестандартних режимів. Наприклад, пристрій підготовки контенту може забезпечити вказівки відносно місцеположення діапазонів байтів кадрів у відеоданих, що використовуються для нестандартних режимів, наприклад, зображень миттєвого оновлення декодера (IDR). Загалом, зображення IDR можуть декодуватися незалежно від даних будь-яких кадрів, що є зовнішніми по відношенню до самих зображень IDR. Кадри або секції зображень IDR, як правило, кодуються в режимі внутрішнього прогнозу, щоб уникнути залежності від інших кадрів або секцій. Таким чином, клієнтський пристрій може отримати інформацію, яка вказує місцеположення зображень IDR для завантаження тільки даних для зображень IDR для використання у відображенні відеоданих в нестандартному режимі, наприклад прискореному перемотуванню вперед. У часовій підпослідовності також можуть бути включені інші дані. Дані можуть бути розташовані в порядку кодування, так що дані, що використовуються для посилання, мають місце раніше, ніж (і в безперервній послідовності байтів) дані, що посилаються. Наприклад, I-кадр може передувати Р-кадру, за яким може йти один або більше В-кадрів, будь-який або всі з яких можуть передувати іншим В-кадрам, які можуть посилатися на більш ранні В-кадри в ієрархічному порядку. У деяких прикладах файл маніфесту, наприклад MPD, час від часу може вимагати оновлень. Це розкриття також забезпечує методи для подачі сигналів і прийому вказівок, що MPD вимагає оновлення. Зокрема, пристрій підготовки контенту може включати в себе дані в сегментах представлень, які вказують, що відповідний MPD вимагає оновлення. Ці дані можуть відповідати початковому елементу сегмента, який може вказувати оновлення для застосування до MPD і/або місцеположення, з яких клієнтський пристрій може отримати оновлення до MPD. 6 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 Оновлення можуть містити повністю новий MPD або інкрементні оновлення відносно попереднього MPD для мультимедійного контенту. Це розкриття додатково включає в себе методи для забезпечення зворотного зв'язку клієнтських пристроїв з серверним пристроєм і/або пристроєм підготовки контенту. Зворотний зв'язок може відповідати, наприклад, інформації про дані, які були отримані як мультимедійний контент. Адміністратор або інший користувач пристрою підготовки контенту і/або сервера можуть використати таку інформацію різними шляхами. Наприклад, користувач може сконфігурувати мережу доставки контенту (CDN) для кешування даних що найчастіше використовуються представлень, в проксі-пристроях CDN, таких як маршрутизатори або інші пристрої. Як інший приклад, користувач може визначити найчастіше використовувані представлення, щоб визначити, чи повинні деякі представлення бути додані або прибрані до або з поточного мультимедійного контенту, і/або як закодувати представлення майбутнього мультимедійного контенту. Відеофайли, наприклад сегменти представлень медіаконтенту, можуть відповідати відеоданим, інкапсульованим згідно з будь-яким базовим форматом ISO мультимедійних файлів, форматом файлів відеокодування (SVC), що масштабується, форматом файлів вдосконаленого відеокодування (AVC), форматом файлів Проекту партнерства третього покоління (3GPP) і/або форматом файлів багатовидового відеокодування (MVC) або іншими подібними форматами відеофайлів. Базовий формат ISO мультимедійних файлів призначений для зберігання синхронізованої медіаінформації для презентації в гнучкому, форматі, що розширюється, який робить можливими обмін, керування, редагування і презентація медіа-інформації. Базовий формат ISO мультимедійних файлів (ISO/IEC 14496-12:2004) вказаний в MPEG-4 Частину-12, яка визначає загальну структуру для синхронізованих медіафайлів. Базовий формат ISO мультимедійних файлів використовується як базис для інших форматів файлів в сімействі, наприклад формату файлів AVC (ISO/IEC 14496-15), що визначає підтримку для H.264/MPEG-4 AVC стиснення відео, формату файлів 3GPP, формату файлів SVC і формату файлів MVC. Формат файлів 3GPP і формат файлів MVC є розширеннями формату файлів AVC. Базовий формат ISO мультимедійних файлів містить синхронізацію, структуру і медіаінформацію для синхронізованих послідовностей медіаданих, таких як аудіовізуальні презентації. Файлова структура може бути об'єктно-орієнтованою. Файл може бути дуже просто розділений на базові об'єкти, і структура об'єктів витікає з їх типу. Файли, відповідні базовому формату ISO мультимедійних файлів (і його розширенням), можуть бути сформовані як послідовності об'єктів, які називаються "полями". Дані в базовому форматі ISO мультимедійних файлів можуть зберігатися в полях, так що немає необхідності зберігати які-небудь інші дані в файлі і немає необхідності мати дані за межами полів в файлі. Це стосується і будь-якого початкового підпису, необхідного конкретним форматом файлу. "Поле" може бути об'єктно-орієнтованим структурним елементом, що визначається унікальним ідентифікатором типу і довжиною. Як правило, презентація міститься в одному файлі, і медіапрезентація є самодостатньою. Контейнер фільму (поле фільму) може містити метадані медіаінформації, а відео і аудіо кадри можуть міститися в контейнері медіаданих і можуть бути в інших файлах. Зображення (послідовність кадрів) може міститися в декількох файлах, які іноді називають сегментами. Інформація про синхронізацію і розкадрування (положення і розмір) знаходиться, як правило, в базовому медіафайлі ISO, а допоміжні файли можуть, по суті, використовувати будь-який формат. Ця презентація може бути 'локальною' для системи, що містить презентацію, або може бути забезпечена через мережу або інший потоковий механізм доставки. Може використовуватися додаткова доріжка метаданих для тегування кожної доріжки, які "цікаві характеристики" вона має, для яких її значення може відрізнятися від інших членів групи (наприклад, її бітова швидкість, розмір екрана або мова). Деякі фрагменти даних в доріжці можуть мати спеціальні характеристики або можуть бути індивідуально ідентифіковані. Одним прикладом характеристики є точка синхронізації (часто I-кадр відео). Ці точки можуть бути ідентифіковані в спеціальній таблиці в кожній доріжці. Загалом, природа залежності між фрагментами даних доріжок може також бути задокументована з допомогою метаданих. Метадані можуть бути структуровані у вигляді послідовності фрагментів даних формату файлу, точно так само як відеодоріжка. Така доріжка може називатися доріжкою метаданих. Кожний фрагмент даних метаданих може бути структурований у вигляді повідомлення метаданих. Є різні види повідомлень, відповідні різним питанням, які можуть бути задані про відповідний фрагмент даних формату файлу або складаючі його фрагменти дані. 7 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 Коли медіадані передаються по протоколу потокової передачі, можливо, що медіадані повинні бути перетворені з того способу, як вони представлені в файлі. Одним прикладом цього є випадок, коли медіадані передаються по транспортному протоколу реального часу (RTP). У файлі, наприклад, всі кадри відео зберігаються один за одним у вигляді фрагментів даних формату файлу. У RTP повинні задовольнятися конкретні для кожного кодеку правила пакетування при розміщенні цих кадрів в пакетах RTP. Сервер потокової передачі може бути сконфігурований для обчислення такого пакетування під час роботи. Проте, є підтримка для допомоги серверам потокової передачі. Методи цього розкриття можуть бути застосовні до мережевих протоколів потокової передачі, такими як потокова передача по HTTP, наприклад, відповідно до динамічної адаптивної потокової передачі по HTTP (DASH). У потоковій передачі по HTTP часто використовувані операції включають в себе операції GET і partial (частковий) GET. Операція GET повертає цілий файл, відповідний даному уніфікованому покажчику ресурсів (URL) або іншому ідентифікатору, наприклад, URI. Операція partial GET приймає діапазон байтів як вхідний параметр і повертає безперервне число байтів файлу, відповідне прийнятому діапазону байтів. Таким чином, фрагменти фільму можуть бути забезпечені для потокової передачі по HTTP, тому що операція partial GET може отримати один або більше окремих фрагментів фільму. Потрібно зазначити, що у фрагменті фільму може бути декілька фрагментів різних доріжок. При потоковій передачі по HTTP представлення медіаданих може бути структурованим набором даних, які доступні для клієнта. Клієнт може запитати і завантажити інформацію про медіадані, щоб надати службу потокової передачі користувачеві. У прикладі потокової передачі даних 3GPP за допомогою потокової передачі по HTTP може бути множина представлень для відео- і/або аудіоданих мультимедійного контенту. Маніфест таких представлень може бути визначений в структурі даних Опису медіапрезентації (MPD). Представлення медіаданих може відповідати структурованому набору даних, які доступні для клієнтського пристрою, що веде потокову передачу по HTTP. Клієнтський пристрій, що веде потокову передачу по HTTP може запитати і завантажити інформацію про медіадані, щоб надати службу потокової передачі користувачеві клієнтського пристрою. Представлення медіаданих може бути описане в структурі даних MPD, яка може включати в себе оновлення MPD. Мультимедійний контент може містити послідовність з одного або більше періодів. Періоди можуть бути визначені елементом Period (Період) в MPD. Кожний період може мати атрибут start (початок) в MPD. MPD може включати в себе атрибут start і атрибут availableStartTime (можливийЧасПочатку)} для кожного періоду. Для послуг прямої трансляції сума атрибута start періоду і атрибута MPD availableStartTime може вказувати час доступності періоду в форматі UTC, зокрема перший Сегмент медіаданих кожного представлення у відповідний період. Для послуг на вимогу атрибут start першого періоду може бути 0. Для будь-яких інших періодів атрибут start може вказувати зміщення часу між часом початку відповідного Періоду відносно часу початку першого Періоду. Кожний період може тягнутися до початку наступного Періоду або до кінця медіапрезентації у випадку останнього періоду. Час початку Періодів може бути точним. Він може відображати фактичний момент, що виходить з відтворення медіаданих всіх попередніх періодів. Кожний період може містити одне або більше представлення для одного і того ж медіаконтенту. Представлення може бути однією з багатьох альтернативних закодованих версій аудіо- або відео-даних. Представлення можуть відрізнятися різними характеристиками, такими як типи кодування, наприклад, бітовою швидкістю, дозволом і/або кодеком для відеоданих і бітовою швидкістю, мовою і/або кодеком для аудіоданих. Термін представлення може використовуватися для назви секції закодованих аудіо- або відео-даних, відповідних конкретному періоду мультимедійного контенту і закодованих певним чином. Представлення конкретного періоду можуть бути віднесені до групи, яка може бути вказана атрибутом group (група) в MPD. Представлення в одній і тій же групі, як правило, розглядаються як альтернативи одне одному. Наприклад, кожне представлення відеоданих для конкретного періоду може бути віднесене до однієї і тієї ж групи, так що будь-яке з представлень може бути вибране для декодування, щоб відобразити на екрані відеодані мультимедійного контенту для відповідного періоду. Медіаконтент в межах одного періоду може бути представлений в деяких прикладах або одним представленням з групи 0, якщо вона присутня, або комбінацією не більше одного представлення з кожної ненульової групи. Дані синхронізації для кожного представлення періоду можуть бути виражені по відношенню до часу початку періоду. Представлення може включати в себе один або більше сегментів. Кожне представлення може включати в себе ініціалізаційний сегмент, або кожний сегмент представлення може бути 8 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 таким, що ініціалізується самостійно. Якщо присутній, ініціалізаційний сегмент може містити інформацію про ініціалізацію для доступу до представлення. Загалом, ініціалізаційний сегмент не містить медіадані. На сегмент можна однозначним чином послатися за допомогою ідентифікатора, наприклад, уніфікованого покажчика ресурсів (URL). MPD може забезпечувати ідентифікатори для кожного сегмента. У деяких прикладах MPD може також забезпечувати діапазони байт у вигляді атрибута range (діапазон), який може відповідати даним для сегмента в файлі, доступним з допомогою URL або URI. Кожне представлення може також включати в себе один або більше медіакомпонентів, де кожний медіакомпонент може відповідати закодованій версії одного окремого типу медіаданих, такого як аудіо, відео і/або синхронізований текст (наприклад, для субтитрів). Медіакомпоненти можуть бути безперервними у часі через границі послідовних ділянок медіаданих в межах одного представлення. Фіг. 1 є блок-схемою, що зображає зразкову систему 10, яка реалізовує методи для потокової передачі медіаданих по мережі. У цьому прикладі система 10 включає в себе пристрій 20 підготовки контенту, серверний пристрій 60 і клієнтський пристрій 40. Клієнтський пристрій 40 і серверний пристрій 60 комунікативно пов'язані мережею 74, яка може включати в себе Інтернет. У деяких прикладах пристрій 20 підготовки контенту і серверний пристрій 60 можуть також бути пов'язані мережею 74 або іншою мережею, або можуть бути комунікативно сполучені напряму. У деяких прикладах пристрій 20 підготовки контенту і серверний пристрій 60 можуть включати в себе один і той же пристрій. Пристрій 20 підготовки контенту в прикладі на фіг. 1 містить аудіоджерело 22 і відеоджерело 24. Аудіоджерело 22 може містити, наприклад, мікрофон, який створює електричні сигнали, що являють собою захоплені аудіодані для кодування аудіокодером 26. Альтернативно, аудіоджерело 22 може містити носій даних, що зберігає раніше записані аудіодані, генератор аудіоданих, такий як комп'ютеризований синтезатор, або будь-яке інше джерело аудіоданих. Відеоджерело 24 може містити відеокамеру, яка створює відеодані для кодування відеокодером 28, носій даних, закодований з раніше записаними відеоданими, блок генерування відеоданих, такий як джерело комп'ютерної графіки, або будь-яке інше джерело відеоданих. Пристрій 20 підготовки контенту не обов'язково комунікативно пов'язаний з серверним пристроєм 60 у всіх прикладах, а може зберігати мультимедійний контент на окремий носій, який зчитується серверним пристроєм 60. Необроблені аудіо- і відеодані можуть містити аналогові або цифрові дані. Аналогові дані можуть бути оцифровані перед кодуванням аудіокодером 26 і/або відеокодером 28. Аудіоджерело 22 може отримувати аудіодані від учасника, що говорить, поки учасник говорить, а джерело відеосигналу 24 може одночасно отримувати відеодані учасника, що говорить. В інших прикладах аудіоджерело 22 може містити комп'ютерно-читаний носій даних, що містить збережені аудіодані, а відеоджерело 24 може містити комп'ютерно-читаний носій даних, що містить збережені відеодані. Таким чином, методи, описані в цьому розкритті, можуть бути застосовані до аудіо- і відеоданих в режимі прямої трансляції, потокової передачі або в режимі реального часу або до заархівованих, попередньо записаних аудіо- і відеоданих. Аудіокадри, які відповідають відеокадрам, є, як правило, аудіо кадрами, що містять аудіодані, які були захоплені аудіоджерелом 22 одночасно з відеоданими, захопленими відеоджерелом 24, які містяться у відеокадрах. Наприклад, поки учасник, що говорить, як правило, виробляє аудіодані вимовляючи слова, аудіоджерело 22 захоплює аудіодані, а відеоджерело 24 одночасно захоплює відеодані учасника, що говорить, тобто в той же час, як аудіоджерело 22 захоплює аудіодані. Отже, аудіокадр може за часом відповідати одному або більше конкретним відеокадрам. Відповідно, аудіокадр, відповідний відеокадру, як правило, відповідає ситуації, в якій аудіодані і відеодані були захоплені в один і той же час, і для якої аудіокадр і відеокадр містять, відповідно, аудіодані і відеодані, які були захоплені в один і той же час. У деяких прикладах аудіокодер 26 може закодувати мітку часу в кожному закодованому аудіокадрі, яка представляє час, в який були записані аудіодані для закодованого аудіокадра, і, аналогічно, відеокодер 28 може закодувати мітку часу в кожному закодованому відеокадрі, яка являє собою час, в який були записані відеодані для закодованого відеокадру. У таких прикладах аудіокадр, відповідний відеокадру, може містити аудіокадр, що містить мітку часу, і відеокадру, що містить ту ж саму мітку часу. Пристрій 20 підготовки контенту може включати в себе внутрішній годинник, з яких аудіокодер 26 і/або відеокодер 28 можуть генерувати мітки часу, або якій аудіоджерело 22 і відеоджерело 24 можуть використати для зв'язку аудіоданих і відеоданих, відповідно, з міткою часу. 9 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 У деяких прикладах аудіоджерело 22 може відправити дані в аудіокодер 26, відповідні часу, в який були записані аудіодані, а відеоджерело 24 може відправити дані у відеокодер 28, відповідні часу, в який були записані відеодані. У деяких прикладах аудіокодер 26 може закодувати ідентифікатор послідовності в закодованих аудіоданих, щоб вказати відносне часове впорядкування закодованих аудіоданих, але не обов'язково вказуючи абсолютний час, в який були записані аудіодані, і точно так само відеокодер 28 може також використати ідентифікатори послідовності, щоб указати відносне часове впорядкування закодованих відеоданих. Точно так само в деяких прикладах ідентифікатор послідовності може бути відображений на або іншим чином пов'язаний з міткою часу. Аудіокодер 26, як правило, виробляє потік закодованих аудіоданих, в той час як відеокодер 28 виробляє потік закодованих відеоданих. Кожний окремий потік даних (аудіо або відео) може називатися елементарним потоком. Елементарний потік - це один закодований в цифровій формі (можливо стиснений) компонент представлення. Наприклад, закодована відео або аудіо частина представлення може бути елементарним потоком. Елементарний потік може бути перетворений в пакетований елементарний потік (PES) перед інкапсулюванням у відеофайл. У межах одного і того ж представлення ідентифікатор (ID) потоку може використовуватися для того, щоб відрізняти PES-пакети, що належать одному елементарному потоку, від інших пакетів. Основною одиницею даних елементарного потоку є пакет пакетованого елементарного потоку (PES). Таким чином, кодовані відеодані, як правило, відповідають елементарним відеопотокам. Точно так само аудіодані відповідають одному або більше відповідним елементарним потокам. Як і багато які стандарти відеокодування, H.264/AVC визначає синтаксис, семантику і процес декодування для бітових потоків без помилок, будь-який з яких відповідає деякому профілю або рівню. H.264/AVC не конкретизує кодер, але кодер повинен гарантувати, що генеровані бітові потоки сумісні зі стандартами для декодера. У контексті стандарту відеокодування "профіль" відповідає підмножині алгоритмів, можливостей або інструментів і обмежень, які застосовуються до них. Наприклад, як визначено стандартом H.264, "профіль" - це підмножина всього синтаксису бітового потоку, який визначений стандартом H.264. "Рівень" відповідає обмеженням споживання ресурсів декодером, таких як, наприклад, пам'ять декодера і обчислення, які пов'язані з розрізненням зображень, бітова швидкість і швидкість обробки макроблоків (MB). Про профіль можна повідомити за допомогою значення profile_idc (індикатор профілю), а про рівень можна повідомити за допомогою значення level_idc (індикатор рівня). Стандарт H.264, наприклад, бере до уваги, що в межах границь, накладених синтаксисом даного профілю, все ще можливо, що буде вимагатися істотно різна продуктивність кодерів і декодерів в залежності від значень, прийнятих елементами синтаксису в бітовому потоку, такими як вказаний розмір декодованих зображень. Стандарт H.264 додатково бере до уваги, що в багатьох додатках реалізація декодера, здатного справитися з всіма гіпотетичними використаннями синтаксису в межах конкретного профілю, не є ні практичною, ні економічно доцільною. Відповідно, стандарт H.264 визначає "рівень" як вказаний набір обмежень, накладених на значення елементів синтаксису в бітовому потоці. Ці обмеження можуть бути простими обмеженнями на значеннях. Альтернативно, ці обмеження можуть приймати вигляд обмежень на арифметичні комбінації значень (наприклад, ширину зображення, помножену на висоту зображення, помножену на число зображень, декодованих за секунду). Стандарт H.264 додатково забезпечує те, що окремі реалізації можуть підтримувати різний рівень для кожного профілю, що підтримується. Декодер, відповідний профілю, звичайно підтримує всі можливості, визначені в профілі. Наприклад, як можливість кодування, кодування з В-зображеннями не підтримується в базовому профілі H.264/AVC, але підтримується в інших профілях H.264/AVC. Декодер, відповідний рівню, повинен бути здатний декодувати будь-який бітовий потік, який не вимагає ресурсів поза обмеженнями, визначеними в рівні. Визначення профілів і рівнів можуть бути корисними для інтерпретованості. Наприклад, під час передачі відео пара визначень профілю і рівня може узгоджуватися і бути узгодженою для всього сеансу передачі. Зокрема, в H.264/AVC рівень може визначати, наприклад, обмеження на число макроблоків, які повинні бути оброблені, розмір буфера декодованих зображень (DPB), розмір буферу кодованих зображень (СРВ), діапазон вектора вертикального руху, максимальне число векторів руху на два послідовних MB і чи може В-блок мати області підмакроблоків менше, ніж 8×8 пікселів. Таким чином, декодер може визначити, чи здатний декодер належно декодувати бітовий потік. Стандарти стиснення відео, такі як ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 частина 10 і майбутній стандарт Високоефективного відеокодування (HEVC), використовують часовий прогноз з компенсацією руху для зменшення часової надмірності. Кодер, такий як відеокодер 28, може використати прогноз з компенсацією руху від деяких 10 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 раніше закодованих зображень (які також називаються тут кадрами) для прогнозу поточних кодованих зображень згідно з векторами руху. Є три основних типи зображень в типовому відеокодуванні. Це зображення з внутрішнім кодуванням ("I-зображення" або "I-кадри"), зображення з прогнозом ("Р-зображення" або "Р-кадри") і зображення з прогнозом вперед/назад ("В-зображення" або "В-кадри"). Р-зображення можуть використати опорне зображення перед поточним зображенням у часовій послідовності. У В-зображенні кожний блок В-зображення може бути передбачений по одному або двом опорним зображенням. Ці опорні зображення можуть бути розташовані до або після поточного зображення у часовій послідовності. Набори параметрів, як правило, містять інформацію заголовка на рівні послідовності в наборах параметрів послідовності (SPS) і нечасто змінювану інформацію заголовка на рівні зображення в наборах параметрів зображення (PPS). З наборами параметрів немає необхідності повторювати цю нечасто змінювану інформацію для кожної послідовності або зображення; отже, ефективність кодування може бути поліпшена. Крім того, використання наборів параметра може дозволити здійснювати позасмугову передачу інформації заголовка, уникаючи потреби в надмірних передачах для досягнення стійкості до помилок. У позасмуговій передачі блоки NAL наборів параметрів передаються по іншому каналу, чим інші блоки NAL. У прикладі на фіг. 1 блок 30 інкапсуляції пристрою 20 підготовки контенту приймає елементарні потоки, що містять кодовані відеодані, від відеокодеру 28 і елементарні потоки, що містять кодовані аудіодані, від аудіокодеру 26. У деяких прикладах відеокодер 28 і аудіокодер 26 можуть кожний включати в себе пакетизатори для формування пакетів PES з кодованих даних. В інших прикладах і відеокодер 28 і аудіокодер 26 можуть взаємодіяти через інтерфейс з відповідними пакетизаторами для формування пакетів PES з кодованих даних. В інших прикладах блок 30 інкапсуляції може включати в себе пакетизатори для формування пакетів PES з кодованих аудіо- і відеоданих. Відеокодер 28 може закодувати відеодані мультимедійного контенту множиною шляхів для створення різних представлень мультимедійного контенту з різними бітовими швидкостями і з різними характеристиками, такими як розрізнення в пікселях, частота кадрів, відповідність різним стандартам кодування, відповідність різним профілям і/або рівням профілів для різних стандартів кодування, представлень, що мають один або декілька ракурсів (наприклад, для двомірного або тривимірного відтворення) або іншими подібними характеристиками. Представлення, як цей термін використовується в даному розкритті, може містити комбінацію аудіоданих і відеоданих, наприклад, один або більше елементарних аудіопотоків і один або більше елементарних відеопотоків. Кожний пакет PES може включати в себе stream_id (ідентифікатор потоку), який ідентифікує елементарний потік, якому належить пакет PES. Блок 30 інкапсуляції відповідає за збирання елементарних потоків у відеофайли різних представлень. Блок 30 інкапсуляції приймає пакети PES для елементарних потоків представлення від аудіокодера 26 і відеокодер 28 і формує відповідні блоки мережевого рівня абстракції (NAL) з пакетів PES. У прикладі H.264/AVC (вдосконалене кодування відео) кодовані відеосегменти організуються в блоки NAL, які забезпечують "орієнтоване на мережі" представлення відеоданих, призначене для таких застосувань, як відеотелефонія, зберігання, мовлення або потокова передача. Блоки NAL можуть поділятися на блоки NAL шару відеокодування (VCL) і блоки NAL не-VCL. Блоки VCL можуть містити основний механізм стиснення і можуть включати в себе блок, макроблок і/або дані рівня секції. Інші блоки NAL можуть бути блоками NAL не-VCL. У деяких прикладах кодоване зображення в один момент часу, що звичайно представляється як основне кодоване зображення, може міститися в пристрої доступу, який може включати в себе один або більше блоків NAL. Блоки NAL не-VCL можуть включати в себе, серед інших, блоки NAL наборів параметрів і блоки NAL SEI. Набори параметрів можуть містити інформацію заголовка на рівні послідовності (в наборах параметрів послідовності (SPS)) і нечасто змінювану інформацію заголовка на рівні зображення (в наборах параметрів зображення (PPS)). З наборами параметрів (наприклад, PPS і SPS) немає необхідності повторювати нечасто змінювану інформацію для кожної послідовності або зображення, отже, ефективність кодування може бути поліпшена. Крім того, використання наборів параметрів може дозволити здійснювати позасмугову передачу інформації заголовка, уникаючи необхідності в надмірних передачах, для стійкості до помилок. У прикладах позасмугової передачі блоки NAL наборів параметрів можуть передаватися на іншому каналі, ніж інші блоки NAL, такі як блоки NAL SEI. Додаткова розширююча інформація (SEI) може містити інформацію, яка не є необхідною для декодування кодованих фрагментів даних зображень з блоків NAL VCL, але може допомогти в процесах, пов'язаних з декодуванням, відображенням, стійкістю до помилок і 11 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 іншими цілями. Повідомлення SEI можуть міститися в блоках NAL не-VCL. Повідомлення SEI є нормативною частиною специфікацій деяких стандартів, і таким чином не завжди є обов'язковими для сумісної зі стандартом реалізації декодера. Повідомлення SEI можуть бути повідомленнями SEI на рівні послідовності або повідомленнями SEI на рівні зображення. Деяка інформація на рівні послідовності може міститися в повідомленнях SEI, таких як повідомлення SEI з інформацією про масштабованість в прикладі SVC і повідомлення SEI з інформацією про масштабованість ракурсу в MVC. Ці приклади повідомлень SEI можуть передавати інформацію, наприклад, про витягання робочих точок і характеристики робочих точок. Крім того, блок 30 інкапсуляції може сформувати файл маніфесту, такий як дескриптор медіапрезентації (MPD), який описує характеристики представлень. Блок 30 інкапсуляції може форматувати MPD відповідно до розширюваної мови розмітки (XML). Блок 30 інкапсуляції може надати дані для одного або більше представлення мультимедійного контенту нарівні з файлом маніфесту (наприклад, MPD) на вихідний інтерфейс 32. Вихідний інтерфейс 32 може містити мережевий інтерфейс або інтерфейс для запису на носій даних, такий як інтерфейс універсальної послідовної шини (USB), пристрою запису CD або DVD, інтерфейс до магнітного або флеш-носія даних або інші інтерфейси для зберігання або передачі медіаданих. Блок 30 інкапсуляції може надати дані кожного з представлень мультимедійного контенту на вихідний інтерфейс 32, який може відправити дані серверному пристрою 60 за допомогою мережевої передачі або носієві даних. У прикладі на фіг. 1 серверний пристрій 60 включає в себе носій 62 даних, який зберігає різні мультимедійні контенти 64, кожний з яких включає в себе відповідний файл 66 маніфесту і одне або більше представлення 68A-68N (представлення 68). Відповідно до методів цього розкриття частини файлу 66 маніфесту можуть бути збережені в окремих місцях, наприклад, місцях носія 62 даних або іншого носія даних, потенційно іншого пристрою мережі 74, такого як проксі-пристрій. У деяких прикладах представлення 68 можуть бути розділені на групи представлень. Тобто різні підмножини представлень 68 можуть включати в себе відповідні загальні набори характеристик, такі як кодек, профіль і рівень, розрізнення, число ракурсів, файловий формат для сегментів, інформацію про тип тексту, яка може вказувати мову або інші характеристики тексту для відображення з представленням і/або аудіоданими для декодування і представлення, наприклад, за допомогою гучномовців, інформацію про ракурс камери, яка може описувати ракурс камери або реальний вид, знятий камерою, об'єкта зйомки для представлень в групі представлень, рейтингову інформацію, яка описує відповідність контенту вимогам конкретних аудиторій і т.п. Файл 66 маніфесту може включати в себе дані, які вказують підмножини представлень 68, відповідні конкретним групам представлень, а також загальні характеристики для груп представлень. Файл 66 маніфесту може також включати в себе дані, які показують окремі характеристики, такі як бітові швидкості, для окремих представлень груп представлень. Таким чином, група представлень може забезпечувати спрощену адаптацію під пропускну спроможність мережі. Представлення в групі представлень можуть бути вказані за допомогою дочірніх елементів елемента групи представлень файлу 66 маніфесту. Файл 66 маніфесту може також (тобто, додатково або альтернативно) повідомляти інформацію про нестандартний режим для одного або більше представлення 68. У деяких прикладах одне або більше представлення 68 може включати в себе відповідну часову підпослідовність для підтримки нестандартного режиму. Нестандартний режим, як правило, відповідає режиму відтворення для представлення, в якому дані представлення відтворюються не від початку до кінця, а замість цього можуть починатися з вказаного місця у часі (наприклад, щоб дозволити перехід на конкретне місце у часі), або пропускати один або більше кадрів в прямому або зворотному напрямі за часом (наприклад, прискорене перемотування уперед або назад). Для забезпечення нестандартних режимів мультимедійний контент 64 може включати в себе інформацію, яка вказує місцеположення даних для часових підпослідовностей відповідних представлень 68. У деяких прикладах файл 66 маніфесту може включати в себе інформацію, яка вказує місцеположення даних для часових підпослідовностей. В інших прикладах представлення 68 самі можуть включати в себе інформацію, яка вказує місцеположення даних для часових підпослідовностей. В інших прикладах і представлення 68 і файл 66 маніфесту можуть включати в себе інформацію, яка вказує місцеположення даних для часових підпослідовностей. У деяких прикладах пристрій 20 підготовки контенту може готувати медіаконтент по мірі того, як він записується, наприклад, для служб прямої трансляції. У деяких випадках може бути необхідно, щоб блок 30 інкапсуляції періодично оновлював файл маніфесту для медіаконтенту. 12 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 Блок 30 інкапсуляції може навіть оновити файл маніфесту в межах конкретного періоду медіаконтенту. Відповідно до методів цього розкриття блок 30 інкапсуляції може сформувати сегменти представлення, які включають дані, які вказують, що файл маніфесту повинен бути оновлений. Блок 30 інкапсуляції може надати оновлення в самих сегментах або в окремому місці, з якого клієнтські пристрої, такі як клієнтський пристрій 40, можуть отримати оновлення до файлу маніфесту. Таким чином, коли необхідно оновити файл 66 маніфесту в межах конкретного періоду мультимедійного контенту 64, блок 30 інкапсуляції може сформувати сегмент одного або більше представлення 68, який вказує, що файл 66 маніфесту повинен бути оновлений. У деяких прикладах файл 66 маніфесту може включати в себе дані для вставки даних винесеного періоду в мультимедійний контент 64 під час відтворення. Наприклад, замість кодування реклами в мультимедійному контенті 64 пристрій 20 підготовки контенту може підготувати один або більше окремих рекламних медіаконтентів, які будуть включені в мультимедійний контент 64 під час відтворення. Клієнтський пристрій 40 може в деяких прикладах надавати інформацію, що залежить від користувача, так що реклама може бути адресована користувачеві клієнтського пристрою 40, так що користувач клієнтського пристрою 40 приймає рекламні оголошення, які є найбільш переважними і інформативними для користувача. У відповідь на набір призначеної для користувача інформації серверний пристрій 60 може надати адресну рекламну частину файлу маніфесту клієнтському пристрою 40, що може привести до того, що клієнтський пристрій 40 буде отримувати дані адресного рекламного мультимедійного контенту. Таким чином, два або більше глядача одного і того ж мультимедійного контенту 64, можуть приймати різну адресну рекламу, так що рекламні оголошення є найбільш актуальними і корисними для користувачів. Серверний пристрій 60 включає в себе блок обробки запитів 70 і мережевий інтерфейс 72. У деяких прикладах серверний пристрій 60 може включати в себе множину мережевих інтерфейсів. Крім того, будь-які або всі з функцій серверного пристрою 60 можуть бути реалізовані в інших пристроях мережі доставки контенту, таких як маршрутизатори, мости, проксі-пристрої, комутатори або інші пристрої. У деяких прикладах проміжні пристрої мережі доставки контенту можуть кешувати дані мультимедійного контенту 64 і включати в себе компоненти, які відповідають значною мірою таким з серверного пристрою 60. Загалом, мережевий інтерфейс 72 сконфігурований відправляти і приймати дані через мережу 74. Блок 70 обробки запитів сконфігурований приймати мережеві запити від клієнтських пристроїв, таких як клієнтський пристрій 40, на дані носія 72 даних. Наприклад, блок 70 обробки запитів може реалізовувати протокол передачі гіпертексту (HTTP) версія 1.1, як описано в RFC 2616, "Hypertext Transfer Protocol HTTP/1.1," by R. Fielding et al, Network Working Group, IETF, June 1999. Тобто блок 70 обробки запитів може бути сконфігурований приймати запити HTTP GET або partial GET і надавати дані мультимедійного контенту 64 у відповідь на запити. Запити можуть вказувати сегмент одного з представлень 68, наприклад, за допомогою URL сегмента. У деяких прикладах запити можуть також вказувати один або більше діапазонів байтів сегмента, таким чином, включаючи в себе запити partial GET. Блок 70 обробки запитів додатково може бути сконфігурований обслуговувати запити HTTP HEAD для надання даних заголовка сегмента одного з представлень 68. У будь-якому випадку, блок 70 обробки запитів може бути сконфігурований обробляти запити для надання даних, що запитуються, запитуючому пристрою, такому як клієнтський пристрій 40. Як зображено в прикладі на фіг. 1, мультимедійний контент 64 включає в себе файл 66 маніфесту, який може відповідати опису медіапрезентації (MPD). Файл 66 маніфесту може містити описи різних альтернативних представлень 68 (наприклад, відеопослуг з різною якістю), і опис може включати в себе, наприклад, інформацію про кодек, значення профілю, значення рівня, бітову швидкість і інші описові характеристики представлень 68. Клієнтський пристрій 40 може отримати MPD медіапрезентації, щоб визначити, як отримати доступ до сегментів представлень 68. Зокрема веб-додаток 52 може отримати дані (не показані) конфігурації клієнтського пристрою 40, щоб визначити можливості з декодування відеодекодера 48 і можливості по відтворенню відеовиводу 44. Дані конфігурації можуть також включати в себе будь-які або всі з переваг мови, вибраної користувачем клієнтського пристрою 40, одну або більше перспектив камери, відповідні настройкам глибини, встановленим користувачем клієнтського пристрою 40, і/або рейтингові оцінки, вибрані користувачем клієнтського пристрою 40. Веб-додаток 52 може містити, наприклад, веб-браузер або медіаклієнт, сконфігурований, щоб подавати запити HTTP GET і partial GET. Веб-додаток 52 може відповідати інструкціям програмного забезпечення, що виконуються одним або більше процесорами або блоками обробки (не показані) клієнтського 13 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 пристрою 40. У деяких прикладах вся або частина функціональності, описаної відносно вебдодатку 52, може бути реалізована в апаратних засобах або комбінації апаратних засобів, програмного забезпечення і/або вбудованого мікропрограмного забезпечення, де необхідні апаратні засоби можуть бути забезпечені для виконання інструкцій програмного забезпечення або вбудованого мікропрограмного забезпечення. Веб-додаток 52 може порівнювати можливості з декодування і відтворення клієнтського пристрою 40 з характеристиками представлень 68, вказаними за допомогою інформації файлу 66 маніфесту. Веб-додаток 52 може спочатку отримати щонайменше частину файлу 66 маніфесту, щоб визначити характеристики представлень 68. Наприклад, веб-додаток 52 може запитати частину файлу 66 маніфесту, який описує характеристики однієї або більше групи представлень, відповідно до методів цього розкриття. Веб-додаток 52 може вибрати підмножину представлень 68 (наприклад, групу представлень), що має характеристики, які відповідають можливостями по кодуванню і відтворенню клієнтського пристрою 40. Веб-додаток 52 може потім визначити бітові швидкості для представлень в групі представлень, визначити доступну в даний момент величину пропускної спроможності мережі і отримати сегменти з одного з представлень, що мають бітову швидкість, яка відповідає пропускній спроможності мережі. Загалом, представлення з більш високою бітовою швидкістю можуть дати більш високу якість відтворення відео, в той час як представлення з більш низькою бітовою швидкістю можуть забезпечити досить якісне відтворення відео, коли доступна пропускна спроможність мережі меншає. Відповідно, коли доступна пропускна спроможність мережі відносно висока, веб-додаток 52 може отримати дані з представлень з відносно високою бітовою швидкістю, тоді як коли доступна пропускна спроможність мережі низька, веб-додаток 52 може отримати дані з представлень з відносно низькою бітовою швидкістю. Таким чином, клієнтський пристрій 40 може передавати мультимедійні дані по мережі 74, в той же час пристосовуючись до доступності пропускної спроможності мережі, що змінюється 74. Як відзначалося вище, в деяких прикладах клієнтський пристрій 40 може забезпечувати інформацію користувача, наприклад, для серверного пристрою 60 або інших пристроїв мережі доставки контенту. Веб-додаток 52, наприклад, може зібрати ідентифікатор користувача, налаштування користувача і/або демографічні дані про користувача і надати таку інформацію користувача серверному пристрою 60. Веб-додаток 52 може потім прийняти файл маніфесту, пов'язаний з адресним рекламним медіаконтентом, і використати його, щоб вставити дані з адресного рекламного медіаконтенту в медіадані запитаного медіаконтенту під час відтворення. Час від часу користувач клієнтського пристрою 40 може взаємодіяти з веб-браузером 52 за допомогою призначеного для користувача інтерфейсу клієнтського пристрою 40, такого як клавіатура, миша, стилус, інтерфейс із застосуванням сенсорного екрана, кнопки або інші інтерфейси для запиту, щоб вибране представлення з представлень 68 було відтворене в нестандартному режимі. Наприклад, користувач може вибрати конкретне місце у часі, з якого треба почати відтворення, або перемотувати або шукати конкретне місце у часі. Як інший приклад користувач може вибрати прискорене перемотування представлення уперед або назад. У відповідь на такі запити від користувача веб-додаток 52 може визначити, чи включає одне з представлень 68 часову підпослідовність для виконання запитаного нестандартного режиму. Як приклад, користувач може вибрати відтворення відеоданих в режимі прискореного перемотування уперед. Замість отримання всіх даних сегментів представлення веб-додаток 52 може визначити місцеположення даних представлення, відповідні часовій підпослідовності представлення. Дані часової підпослідовності можуть відповідати, наприклад, ряду зображень миттєвого оновлення декодера (IDR) представлення. Приблизна тривалість часу між зображеннями IDR представлення може дорівнювати, наприклад, 2 секундам, 10 секундам або іншій приблизній тривалості часу. Крім того, зображення IDR можуть бути закодовані в режимі внутрішнього прогнозу, і, таким чином, вебдодаток 52 не потребує отримання даних крім зображень IDR. Веб-додаток 52 може наказувати відображення зображення IDR з тією ж частотою кадрів, з якою б відображалися дані в іншому випадку. Однак, оскільки між зображеннями IDR може бути пропущено багато кадрів даних, результуючі відеодані можуть відтворюватися із збільшеною частотою кадрів, таким чином, дозволяючи здійснити бажаний нестандартний режим. Веб-додаток 52 може визначити місцеположення даних для часової підпослідовності, використовуючи різні методи. У деяких прикладах веб-додаток 52 може проаналізувати дані файлу 66 маніфесту, щоб визначити місцеположення зображень IDR. Місцеположення зображень IDR можуть бути вказані за допомогою діапазонів байтів в сегментах конкретного 14 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 представлення. В інших прикладах конкретне поле сегментів представлень, таке як поле переліку підфрагментів (яке також називається полем переліку підсегментів), може забезпечувати вказівки відносно місцеположень даних для часової підпослідовності. Наприклад, поле переліку підфрагментів може включати в себе дані, які вказують діапазони байтів для зображень IDR в межах відповідного сегмента. В інших прикладах і файл 66 маніфесту і представлення 68 можуть включати в себе інформацію, що використовується вебдодатком 52 для отримання даних для часової підпослідовності. У будь-якому випадку, вебдодаток 52 може визначити діапазони байтів зображень IDR в сегментах для створення запитів partial GET на зображення IDR, щоб уникнути отримання даних, які не будуть використовуватися для декодування або відображення. У деяких прикладах блок 30 інкапсуляції може сформувати сегменти так, що зображення IDR йдуть одне за одним в межах сегментів. Тобто, блок 30 інкапсуляції може потурбуватися про те, щоб байти сегментів, відповідних зображенням IDR, йшли один за одним, не перемежаючись з байтами для інших типів зображень. Таким чином, веб-додаток 52 має вказати тільки один діапазон байтів сегментів представлення, щоб отримати дані для часової підпослідовності представлення. У деяких прикладах зображення відкритого оновлення декодера (ODR) можуть також використовуватися для здійснення нестандартних режимів. У деяких прикладах веб-додаток 52 може визначити, що частина прийнятого сегмента вказує, що файл маніфесту повинен бути оновлений. Веб-додаток 52 може бути сконфігурований аналізувати конкретну частину кожного сегмента, таку як частину заголовка або іншу початкову частину сегмента, щоб визначити, чи вказує сегмент, що файл маніфесту повинен бути оновлений. Коли сегмент вказує, що файл маніфесту повинен бути оновлений, веб-додаток 52 може оновити локально збережену копію файлу маніфесту, використовуючи або дані сегмента або отримуючи дані для оновлення файлу маніфесту з видаленого місця, наприклад, від сервера 60. Після оновлення файлу маніфесту веб-додаток 52 може подавати майбутні запити на дані представлень 68 на основі даних оновленого файлу маніфесту. Як приклад, пристрій 20 підготовки контенту може закодувати медіадані для прямої трансляції, наприклад, пряму трансляцію спортивного заходу, політичної події або іншої події, що заслуговує освітлення, яка звичайно транслюється в прямому ефірі або майже в прямому ефірі, а не в записі. У таких випадках сегменти, відповідні медіаданим, до певного часу можуть бути призначеними ідентифікаторами, такими як URL, включеними в початковий файл маніфесту. Однак після того як період часу закінчився, сегменти, наступні після певного часу можуть бути закодовані, і ним привласнені ідентифікатори, такі як URL. Блок 30 інкапсуляції пристрою 20 підготовки контенту може забезпечити URL для сегментів після певного часу в оновленому файлі маніфесту. Відповідно, щоб визначити, як отримати сегменти після певного часу, клієнтський пристрій 40 може прийняти інформацію, яка вказує на оновлений файл маніфесту, для створення запитів на отримання сегментів після певного часу. У деяких прикладах сегмент може вказувати, чи є він останнім сегментом представлення. Коли сегмент є останнім сегментом представлення, може бути необхідність отримати новий файл маніфесту, щоб визначити представлення подальшого періоду відповідного мультимедійного контенту. Відповідно, коли веб-додаток 52 визначає, що сегмент є останнім сегментом представлення в періоді мультимедійного контенту, веб-додаток 52 може отримати оновлений файл маніфесту для мультимедійного контенту, наприклад, оновлену версію файлу 66 маніфесту мультимедійного контенту 64. У деяких прикладах клієнтський пристрій 40 може зберігати структуру даних, яка вказує на конкретні представлення 68, з яких клієнтський пристрій 40 запитав дані для мультимедійного контенту 64. Клієнтський пристрій 40 може також зберігати вказівки відносно того, що саме було відтворено і в який час. Тобто структура даних може забезпечувати інформацію, яка вказує час початку і кінця і в реальному (або "фізичному") часі і часі презентації. Структура даних може додатково забезпечувати інформацію, яка вказує час початкового запуску і початки відтворення. Після завершення відтворення мультимедійного контенту 64 клієнтський пристрій 40 може відправити структуру даних серверному пристрою 60 і/або пристрою 20 підготовки контенту. Серверний пристрій 60 і/або пристрій 20 підготовки контенту може використати інформацію, прийняту від клієнтського пристрою 40, для визначення більш оптимальних шляхів поліпшення якості сприйняття, наприклад, зменшення пауз при відтворенні. Мережевий інтерфейс 54 може прийняти і надати дані сегментів вибраного представлення веб-додатку 52, який може в свою чергу забезпечити сегменти для блоку 50 декапсуляції. Блок 50 декапсуляції може декапсулювати елементи відеофайлу в складові потоки PES, депакетизувати потоки PES для отримання кодованих даних і відправити кодовані дані або аудіодекодеру 46 або відеодекодеру 48, в залежності від того, чи є кодовані дані частиною 15 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 аудіопотоку або відеопотоку, наприклад, як вказано в заголовках пакетів PES потоку. Аудіодекодер 46 декодує закодовані аудіодані і відправляє декодований аудіодані на аудіовихід 42, в той час як відеодекодер 48 декодує закодовані відеодані і відправляє декодовані відеодані, які можуть включати в себе множину ракурсів потоку, на відеовихід 44. Відеокодер 28, відеодекодер 48, аудіокодер 26, аудіодекодер 46, блок 30 інкапсуляції, вебдодаток 52 і блок 50 декапсуляції, кожний з них може бути реалізований як будь-яка множина відповідних електронних схем обробки, в залежності від обставин, таких як один або більше мікропроцесорів, цифрові сигнальні процесори (DSP), спеціалізовані інтегральні схеми (ASIC), програмовані користувачем вентильні матриці (FPGA), дискретні логічні схеми, програмного забезпечення, апаратних засобів, вбудованого мікропрограмного забезпечення або будь-яких їх комбінацій. І відеокодер 28, і відеодекодер 48 можуть бути включені в один або декілька кодерів або декодери, будь-який з яких може бути інтегрований як частина комбінованого відеокодеру/декодеру (CODEC). Аналогічно, і аудіокодер 26, і аудіодекодер 46 можуть бути включені в один або більше кодерів або декодери, будь-який з яких може бути інтегрований як частина комбінованого CODEC. Пристрій, що включає в себе відеокодер 28, відеодекодер 48, аудіокодер 26, аудіодекодер 46, блок 30 інкапсуляції, веб-додаток 52 і/або блок 50 декапсуляції, може містити інтегральну схему, мікропроцесор і/або пристрій бездротового зв'язку, такий як стільниковий телефон. Фіг. 2 є концептуальною схемою, що зображає елементи зразкового мультимедійного контенту 100. Мультимедійний контент 100 може відповідати мультимедійному контенту 64 (фіг. 1) або іншому мультимедійному контенту, збереженому в пам'яті 62. У прикладі на фіг. 2 мультимедійний контент 100 включає в себе опис медіапрезентації (MPD) 102 і множину представлень 110-120. Представлення 110 включає в себе додаткові дані 112 заголовка і сегменти 114A-114N (сегменти 114), в той час як представлення 120 включає в себе додаткові дані 122 заголовка і сегменти 124A-124N (сегменти 124). Для зручності буква N використовується для позначення останнього фрагмента фільму в кожному з представлень 110, 120. У деяких прикладах у представлень 110, 120 може бути різне число фрагментів фільму. MPD 102 може містити структуру даних, окрему від представлень 110-120. MPD 102 може відповідати файлу 66 маніфесту на фіг 1. Аналогічно, представлення 110-120 можуть відповідати представленням 68 на фіг. 1. Загалом, MPD 102 може включати в себе дані, які, як правило, описують характеристики представлень 110-120, такі як характеристики кодування і відтворення, групи представлень, профіль, якому відповідає MPD 102, інформацію про тип тексту, інформацію про ракурс, рейтингову інформацію, інформацію про нестандартний режим (наприклад, інформацію, яка вказує представлення, які включають часові підпослідовності) і/або інформацію для отримання винесених періодів (наприклад, для вставки адресної реклами в медіаконтент під час відтворення). Винесені періоди можуть також називатися зовнішніми періодами. Фіг. 4-7, що обговорюються більш детально нижче, зображають різні приклади мультимедійного контенту з різними елементами, що входять в одне з або в обидва: MPD і/або представлення (наприклад, в сегменти представлень або дані заголовків представлень). Будьякі або всі з MPD на фіг. 4-7 можуть відповідати значною мірою MPD 102 на фіг. 2. Дані 112 заголовка, якщо вони присутні, можуть описувати характеристики сегментів 114, наприклад, положення під часі точок довільного доступу, який з сегментів 114 включає точки довільного доступу, байтові зміщення до точок довільного доступу в сегментах 114, уніфіковані покажчики ресурсів (URL) сегментів 114 або інші аспекти сегментів 114. Дані 122 заголовки, якщо вони присутні, можуть описувати аналогічні характеристики сегментів 124. Додатково або альтернативно, такі характеристики можуть бути повністю включені в MPD 102. Сегменти 114 включають в себе один або більше кодованих фрагментів відеоданих, кожний з яких може включати в себе кадри або секції відеоданих. Кожний з кодованих фрагментів відеоданих сегментів 114 може мати аналогічні характеристики, наприклад, висоту, ширину і вимоги до пропускної спроможності. Такі характеристики можуть бути описані даними MPD 102, хоча такі дані не показані в прикладі на фіг. 2. MPD 102 може включати в себе характеристики, як описане в Специфікації 3GPP, з доданням всієї або частини інформації, що передається, описаної в цьому розкритті. Кожний з сегментів 114, 124 може бути пов'язаний з унікальним уніфікованим ідентифікатором ресурсів (URI), наприклад, уніфікованим покажчиком ресурсів (URL). Таким чином, кожний з сегментів 114, 124 може бути отриманий незалежно з використанням мережевого протоколу потокової передачі, такого як DASH. Таким чином, приймальний пристрій, наприклад, клієнтський пристрій 40, може використати запит HTTP Get для отримання сегментів 114 або 124. У деяких прикладах клієнтський пристрій 40 може використати запити HTTP partial Get для отримання конкретних діапазонів байтів сегментів 114 або 124. 16 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 Як відмічалося вище, MPD 102 може відповідати конкретному профілю MPD. MPD 102 може включати в себе інформацію, яка вказує тип Багатоцільового розширення пошти в Інтернеті (MIME) для MPD 102 і/або мультимедійного контенту 100. Однак типи MIME, як правило, не вказують, який кодек необхідний для представлення мультимедійного контенту. Загалом передбачається, що якщо пристрій може отримати MPD для мультимедійного контенту, наприклад, MPD 102, то пристрій може відтворити дані мультимедійного контенту, відповідного MPD. Однак, це допущення не завжди безпечне. Тому в деяких прикладах MPD 102 може включати в себе інформацію, яка вказує профіль, якому відповідає MPD 102. Може бути відносно невелика кількість профілів, яким можуть відповідати MPD. Профілі можуть доповнюватися рівнями для розв'язання питань, пов'язаних з можливостями, аналогічно тому, яким чином H.264/AVC включає в себе профілі і рівні для відеокодування. Профілі MPD можуть мати цибулинну структуру, тобто профіль більш високого рівня може включати в себе всі елементи всіх профілів більш низького рівня. Може бути процес реєстрації з реєструючим органом для реєстрації різних профілів. У деяких прикладах клієнтський пристрій, такий як клієнтський пристрій 40, може бути сконфігурований отримувати інформацію, яка вказує профіль для MPD, такого як MPD 102, до отримання інших даних MPD, таких як характеристики представлень 110-120, що повідомляються MPD 102. Таким чином, до надання доступу до MPD 102 може бути повідомлений профіль для MPD 102. Ідентифікатор профілю може бути забезпечений у вигляді простого тексту (наприклад, як проста назва) або зворотного доменного імені. Прості назви можуть бути зарезервовані реєструючим органом, таким як 3GPP або інший реєструючий орган. Профіль може розглядатися як вимога і дозвіл, в тому значенні, що профіль може вимагати, щоб відповідний мультимедійний контент відповідав профілю, і дає дозвіл засобу читання (наприклад, клієнтському пристрою), який реалізовує цей профіль, прочитувати MPD, інтерпретувати те, що він розпізнав, і ігнорувати матеріал, який він не розуміє. Профілі можуть описувати характеристики такі як, наприклад, особливості MPD 102, використання мережі, формат(и) медіаданих, що використовується кодек(і), формати захисту і/або кількісні показники, такі як бітові швидкості, розміри екрана і т.п. Таким чином, профіль MPD 102 може забезпечувати інформацію, яка вказує, які кодеки повинні підтримуватися для того, щоб отримати дані MPD 102 і/або мультимедійний контент 100. Профілі можуть також бути описані як "точки відповідності". Профілі, яким відповідає MPD, можуть бути вказані в атрибуті "Профілі" опису MPD. Таким чином, клієнтський пристрій може бути сконфігурований отримувати частину MPD 102, що включає інформацію, що стосується атрибута "Профілі" перед отриманням додаткових даних MPD 102. Альтернативно, профілі можуть бути вказані як параметр в типі MIME опису MPD. Наприклад, про профілі "X, Y і Z" може бути повідомлено таким чином: video/vnd.mpeg.mpd;profiles="Х, Y, Z". У деяких прикладах MPD 102 може посилатися на дані зовнішніх періодів (які також називаються винесеними періодами). Період, як правило, відповідає конкретній часовій секції мультимедійного контенту. Кожний період може включати в себе одне або більше представлення, таких як представлення 110-120. Зовнішній період, однак, може бути вставлений в або між періодами мультимедійного контенту 100. Зовнішній період може включати в себе мультимедійні дані в доповнення до мультимедійних даних мультимедійного контенту. Наприклад, зовнішні періоди можуть включати в себе дані реклами. Періоди можуть бути визначені їх тривалістю, тобто час початку Періоду може залежати від тривалості попереднього періоду. Клієнтський пристрій може відобразити зовнішні періоди на структуру MPD. Для послуг прямої трансляції конкатенація описів MPD може бути досягнута шляхом динамічного створення MPD на сервері, такому як серверний пристрій 60, за допомогою відповідних процедур оновлення. Також можуть використовуватися інші веб-технології. URL для зовнішнім чином визначених періодів можуть оброблятися в режимі реального часу для генерування нового періоду, що містить рекламу, призначену для користувача клієнтського пристрою 40. Клієнтський пристрій 40 може надати із запитом додаткову інформацію, яка може використовуватися для створення адресної реклами, наприклад, ідентифікатор користувача, налаштування користувача, демографічні дані про користувача або іншу інформацію. Таблиця 1 нижче зображає зразковий набір інформації, яка може бути надана в MPD 102 для опису одного або більше Періодів мультимедійного контенту і вказівку наявності зовнішніх періодів: 17 UA 107394 C2 Таблиця 1 Інформація про періоди в MPD Period PeriodAitributes Е Список 1… N М М periodDuration 20 25 30 35 40 О Е periodListURI 15 А RepresentationGroups 10 О representationGroupListURI 5 А А 0… N M Забезпечує інформацію Періоду Вже існуючі атрибути періоду Забезпечує тривалість періоду, може використовуватися як альтернатива атрибуту start (початок) наступного Періоду. URI, який вказує на документ, який містить список Представлень. Цей елемент містить опис Групи представлень URI, який вказує на документ, який містить один або декілька елементів Періоду. Таким чином, елемент Period опису MPD 102 може посилатися на зовнішні (або винесені) періоди, наприклад, з допомогою periodListURl. Для контенту по запиту вказівки відносно тривалості періодів можуть бути більш корисні для клієнтських пристроїв, такими як клієнтський пристрій 40, чим час початку, для підтримки зовнішніх періодів. MPD може включати в себе послідовність Періодів, де Періоди можуть бути внутрішніми або зовнішніми. Використання таких винесених Періодів, нарівні з призначеною для користувача інформацією, може дати можливість адресної реклами для користувача. Серверний пристрій 60 і/або пристрій 20 підготовки контенту може бути сконфігурований динамічно генерувати окремі MPD для кожного користувача або для кожного клієнтського пристрою. Клієнтський пристрій 40 або інший пристрій, може об'єднати відтворення адресної реклами і послуги прямої трансляції, наприклад, використовуючи MPD, що динамічно створюється. Таким чином, методи цього розкриття можуть підтримувати ситуації, в яких постачальник послуг пропонує контент на вимогу через 3GPP AHS. Контент може включати в себе декілька сцен, і між кожною сценою може бути додана реклама. Реклама може бути різною для кожного користувача. Тобто може бути додана адресна реклама. Крім того, кожна реклама може мати різну тривалість. Аналогічно, постачальник послуг може запропонувати конкретну послугу прямої трансляції (наприклад, безкоштовну послугу). При доступі до послуги прямої трансляції постачальник послуг може додати рекламу, яка можливо, а може і не бути адресована користувачеві. Тривалість реклами може відрізнятися в залежності від часу доступу, місця доступу, користувача і т.п. Серверний пристрій 60 може бути сконфігурований забезпечувати URL послуги прямої трансляції тільки після завершення реклами, щоб гарантувати, що реклама переглянута. Фіг. 3 є блок-схемою, що зображає елементи зразкового відеофайлу 150, який може відповідати сегменту представлення, такому як один з сегментів 114, 124 на фіг. 2. Кожний з сегментів 114, 124 може включати в себе дані, які значною мірою відповідають розташуванню даних, зображеному в прикладі на фіг. 3. Аналогічно, сегменти на фіг. 4-7, що обговорюються нижче, можуть також значною мірою відповідати структурі відеофайлу 150. Як описано вище, відеофайли відповідно до базового формату ISO мультимедійних файлів і його розширень зберігають дані в послідовностях об'єктів, які називаються "полями". У прикладі на фіг. 3 відеофайл 150 включає в себе поле 152 типу файлу (FTYP), поле 154 фільму (МООВ), поля 162 фрагментів фільму (MOOF) і поле 164 довільного доступу до фрагментів фільму (MFRA). Поле 152 типу файлу (FTYP), як правило, описує тип файлу для відеофайлу 150. Поле 152 типу файлу може включати в себе дані, які вказують специфікацію, яка описує найкраще використання для відеофайлу 150. Поле 152 типу файлу може розміщуватися перед полем 154 MOOV, полями 162 фрагментів фільму і полем 164 MFRA. У деяких прикладах сегмент, такий як відеофайл 150, може включати в себе поле оновлення MPD (не показано) перед полем 152 FTYP. Поле оновлення MPD може включати в себе інформацію, яка вказує, що MPD, відповідний представленню, що включає в себе відеофайл 150, повинен бути оновлений, нарівні з інформацією для оновлення MPD. Наприклад, поле оновлення MPD може забезпечити URI або URL для ресурсу, який повинен використовуватися 18 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 для оновлення MPD. Як інший приклад, поле оновлення MPD може включати в себе дані для оновлення MPD. У деяких прикладах поле оновлення MPD може йти відразу за полем типом сегмента (STYP) (не показано) відеофайлу 150, де поле STYP може визначати тип сегмента для відеофайлу 150. Фіг. 7, що обговорюється більш детально нижче, забезпечує додаткову інформацію відносно поля оновлення MPD. Поле 154 MOOV в прикладі на фіг. 3 включає в себе поле 156 заголовка фільму (MVHD), поле 158 доріжки (TRAK) і одне або більше полів 160 розширень фільму (MVEX). Загалом, поле 156 MVHD може описувати загальні характеристики відеофайлу 150. Наприклад, поле 156 MVHD може включати в себе дані, які описують, коли відеофайл 150 був спочатку створений, коли відеофайл 150 був останній раз змінений, часові рамки для відеофайлу 150, тривалість відтворення для відеофайлу 150 або інші дані, які, як правило, описують відеофайл 150. Поле 158 TRAK може включати в себе дані для доріжки відеофайлу 150. Поле 158 TRAK може включати в себе поле заголовка доріжки (TKHD), яке описує характеристики доріжки, відповідної полю 158 TRAK. У деяких прикладах поле 158 TRAK може включати в себе кодовані відеозображення, в той час як в інших прикладах кодовані відеозображення доріжки можуть міститися у фрагментах 162 фільму, на який можуть посилатися дані поля 158 TRAK. У деяких прикладах відеофайл 150 може включати в себе більше однієї доріжки. Відповідно, поле 154 MOOV може включати в себе число полів TRAK, рівне числу доріжок у відеофайлі 150. Поле 158 TRAK може описувати характеристики відповідної доріжки відеофайлу 150. Наприклад, поле 158 TRAK може описувати часову і/або просторову інформацію для відповідної доріжки. Поле TRAK, аналогічно полю 158 TRAK поля 154 MOOV, може описувати характеристики доріжки набору параметрів, коли блок 30 інкапсуляції (фіг. 1) додає доріжку набору параметрів у відеофайл, такий як відеофайл 150. Блок 30 інкапсуляції може повідомляти про наявність повідомлень SEI рівня послідовності в доріжці набору параметрів в полі TRAK, що описує доріжку набору параметра. Поля 160 MVEX можуть описувати характеристики відповідних фрагментів 162 фільму, наприклад, для вказівки, що відеофайл 150 включає в себе фрагменти 162 фільму, якщо такі є, в доповнення до відеоданих, що містяться в полі 154 MOOV. У контексті даних потокового відео кодовані відеозображення можуть міститися у фрагментах 162 фільму, а не в полі 154 MOOV. Відповідно, всі кодовані фрагменти відеоданих можуть міститися у фрагментах 162 фільму, а не в полі 154 MOOV. Поле 154 MOOV може включати в себе число полів 160 MVEX, рівне числу фрагментів 162 фільму у відеофайлі 150. Кожне з полів 160 MVEX може описувати характеристики відповідного одного з фрагментів 162 фільму. Наприклад, кожне поле MVEX може включати в себе поле заголовка розширень фільму (MEHD), яке описує тривалість за часом для відповідного одного з фрагментів фільму 162. Як відмічалося вище, блок 30 інкапсуляції може зберігати набір даних послідовності у фрагменті відеоданих, який не включає в себе фактичні кодовані відеодані. Фрагмент відеоданих може, як правило, відповідати блоку доступу, який є представленням кодованого зображення в конкретний момент часу. У контексті AVC кодоване зображення включає в себе один або більше блоків NAL VCL, які містять інформацію для створення всіх пікселів блоку доступу, і інші відповідні блоки NAL не-VCL, такі як повідомлення SEI. Відповідно, блок 30 інкапсуляції може включати в себе набір даних послідовності, який може включати в себе повідомлення SEI рівня послідовності, в одному з фрагментів 162 фільму. Блок 30 інкапсуляції може додатково повідомляти про наявність набору даних послідовності і/або наявність повідомлень SEI рівня послідовності в одному з фрагментів 162 фільму в одному з полів 160 MVEX, відповідних одному з фрагментів 162 фільму. Фрагменти 162 фільму можуть включати в себе одне або більше кодованих відеозображень. У деяких прикладах фрагменти 162 фільму можуть включати в себе одну або більше груп зображень (GOP), кожна з яких може включати в себе багато кодованих відеозображень, наприклад, кадрів або зображень. Крім того, як описано вище, в деяких прикладах фрагменти 162 фільму можуть включати в себе набори даних послідовності. Кожний з фрагментів 162 фільму може включати в себе поле заголовка фрагмента фільму (MFHD, не показано на фіг. 3). Поле MFHD може описувати характеристики відповідного фрагмента фільму, такі як порядковий номер для фрагмента фільму. Фрагменти 162 фільму можуть міститися у відеофайлі 150 в порядку порядкових номерів. Поле 164 MFRA може описувати точки довільного доступу у фрагментах 162 фільму відеофайлу 150. Це може допомогти з виконанням нестандартних режимів, таких як виконання пошуку конкретного місця за часом у відеофайлі 150. Поле 164 MFRA є, як правило, необов'язковим, і не повинне міститися у відеофайлах в деяких прикладах. Аналогічно, 19 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 клієнтський пристрій, такий як клієнтський пристрій 40, не обов'язково повинний посилатися на поле 164 MFRA для правильного декодування і відображення відеоданих відеофайлу 150. Поле 164 MFRA може включати в себе число полів (не показані) довільного доступу до фрагментів доріжки (TFRA), рівне числу доріжок відеофайлу 150 або, в деяких прикладах, рівне числу мультимедійних доріжок (наприклад, доріжок без підказок) відеофайлу 150. У деяких прикладах фрагменти 162 фільму можуть включати в себе одне або більше зображень IDR і/або ODR. Аналогічно, поле 164 MFRA може забезпечувати вказівки відносно місцеположення у відеофайлі 150 зображень IDR і ODR. Відповідно, часова підпослідовність відеофайлу 150 може бути сформована із зображень IDR і ODR відеофайлу 150. Часова підпослідовність може також включати в себе інші зображення, такі як Р-кадри і/або В-кадри, які залежать від зображень IDR і/або ODR. Кадри і/або секції часової підпослідовності можуть бути розташовані в сегментах так, що кадри/секції часової підпослідовності, які залежать від інших кадрів/секцій підпослідовності, можуть бути належно декодовані. Наприклад, в ієрархічній структурі даних дані, що використовуються для прогнозу інших даних, можуть також бути включені у часову підпослідовність. Крім того, дані можуть бути розташовані в безперервній підпослідовності, так що в запиті partial GET може бути вказаний один діапазон байтів для отримання всіх даних конкретного сегмента, що використовується для часової підпослідовності. Клієнтський пристрій, такий як клієнтський пристрій 40, може витягнути часову підпослідовність відеофайлу 150 шляхом визначення діапазонів байтів фрагментів 162 фільму (або частин фрагментів 162 фільму), відповідних зображенням IDR і/або ODR. Як обговорюється більш детально нижче, відеофайли, такі як відеофайл 150, можуть включати в себе поле переліку підфрагментів і/або поле фрагментів піддоріжки, будь-яке або обидва з яких можуть включати в себе дані для витягання часової підпослідовності відеофайлу 150. Фіг. 4 є концептуально схемою, що зображає зразковий мультимедійний контент 200, що включає в себе MPD 202 і групи представлень 210-220. Мультимедійний контент 200 може відповідати мультимедійному контенту 64 (фіг. 1) або іншому мультимедійному контенту, збереженому в пам'яті 62. У цьому прикладі представлення мультимедійного контенту 200 впорядковані по групах представлень. Тобто представлення із загальним набором характеристик можуть бути зібрані в групу представлень, яка забезпечує спрощену адаптацію до пропускної спроможності мережі. У цьому прикладі MPD 202 включає в себе загальні характеристики 204A представлень, які включають в себе інформацію, що описує загальні характеристики групи 210 представлень, і загальні характеристики 204B представлень, що описують загальні характеристики групи 220 представлень. Загальні характеристики можуть включати в себе характеристики кодування і/або відтворення представлень, такі як кодек, профіль і рівень кодеку, яким відповідають представлення в групі представлень, розрізнення в пікселях, частота кадрів або інші характеристики представлень. Відповідно до методів цього розкриття характеристики можуть включати в себе значення типу тексту, значення ракурсу камери і/або значення рейтингу в доповнення до характеристик, що обговорювалися вище. Значення типу тексту може описувати характеристики тексту, призначеного для відображення з відеоданими (наприклад, тексту субтитрів). Значення типу тексту може описувати, наприклад, мову тексту, місце на екрані, в якому треба відображати текст, шрифт і/або розмір тексту або інші характеристики тексту. Значення ракурсу камери може описувати реальне горизонтальне положення камери, що використовується (фізично або уявно) для генерування кодованих відеоданих відповідних представлень. Використовуючи ракурси камери, клієнтський пристрій може вибрати дані з двох або більше представлень для відображення практично одночасно, наприклад, для створення ефекту відтворення тривимірного відео. Реальні горизонтальні місцеположення камери можуть дозволити клієнтському пристрою вибрати представлення для збільшення або зменшення відносної величини глибини в тривимірному відтворенні відеоданих. Рейтинг може описувати придатність контенту для конкретних аудиторій. Наприклад, в Сполучених Штатах Америки Американська кіноасоціація визначає наступні рейтинги G, PG, PG-13, R і NC-17. Як інший приклад, в Великобританії Британське бюро класифікації кінофільмів визначає наступні рейтинги U, PG, 12A, 12, 15, 18 і R18. Як ще один приклад, в Китайській Республіці (Тайвань) категорії кінофільмів включають в себе категорію для широкої аудиторії, захищену категорію, категорію, що вимагає контролю з боку дорослих, і обмежену категорію. Шляхом забезпечення загальних характеристик 204 відповідних груп представлень, наприклад, груп 210-220 представлень, клієнтський пристрій (наприклад, клієнтський пристрій 40) може вибрати відповідну групу з груп 210-220 представлень щонайменше частково на основі відповідних загальних характеристик 204 представлень. У прикладі на фіг. 4 MPD 202 20 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 також включає в себе індивідуальні характеристики 206A, 206B, 208A і 208B представлень, відповідні, відповідно, представленням 212A, 212B, 222A, 222B. Індивідуальні характеристики 206A, 206В, 208A і 208B представлень можуть включати в себе інформацію, яка вказує характеристики представлень 212A, 212В, 222A, 222B, не вказані в загальних характеристиках 204 представлень. Наприклад, індивідуальні характеристики 206A, 206B, 208A і 208B представлень можуть включати в себе інформацію, яка вказує бітові швидкості для відповідних представлень 212A, 212B, 222A, 222B. Представлення групи представлень можна вважати взаємовиключаючими в тому значенні, що вони можуть представляти один і те ж контент (одне і те ж відео, одна і та ж мова аудіо і т.д.) з різним кодуванням або іншими параметрами. MPD 202 може забезпечувати інформацію для вибору однієї з груп 210-220 представлень, наприклад, загальні характеристики 204 представлення. Ця інформація може включати в себе інформацію, яка вказує, чи може клієнт декодувати і відтворити дане представлення. Таким чином, клієнтський пристрій може прибрати з розгляду представлення, які клієнтський пристрій не може декодувати і/або відтворити. Відповідно, клієнтський пристрій 40 може вибрати відповідну групу представлень, яка може бути декодована і відтворена, потім вибрати представлення з групи на основі, наприклад, доступності пропускної спроможності мережі. Клієнтський пристрій 40 може також бути сконфігурований з призначеними для користувача настройками для, наприклад, рейтингу, мови, і/або глибини. Відповідно, клієнтський пристрій 40 може також вибрати одну або більше груп представлень так, що вибрані групи відповідають призначеним для користувача налаштуванням. Клієнтський пристрій 40 може потім вибрати підмножину доступних груп представлень, які можуть бути відтворені одночасно. Коли клієнтський пристрій 40 здатний відображати тільки один ракурс, клієнтський пристрій 40 може вибрати отримувати дані тільки з одного представлення. З іншого боку, коли клієнтський пристрій 40 має можливості багатовидового або стерео-відображення, клієнтський пристрій 40 може отримувати дані з двох або більше представлень. Після вибору однієї або більше груп представлень, клієнтський пристрій 40 може вибрати представлення з груп представлень на основі, наприклад, доступної пропускної спроможності мережі. Оскільки доступна пропускна спроможність мережі змінюється (наприклад, збільшується або зменшується), клієнтський пристрій 40 може підстроювати вибір представлень з груп представлень для адаптації до умов пропускної спроможності мережі, що змінюються. Звичайно, клієнтський пристрій 40 може також змінити вибір представлень, якщо змінюються призначені для користувача налаштування або можливості пристрою (наприклад, можливості по декодування і відтворенню). У деяких прикладах загальні характеристики 204 представлень можуть відповідати XML елементам RepresentationGroup опису MPD 202. Індивідуальні характеристики представлень можуть відповідати, в деяких прикладах, піделементам відповідних елементів RepresentationGroup опису MPD 202. Групуючи загальні характеристики представлень разом, може бути досягнута різна оптимізація. Наприклад, багато які представлення можуть мати одні і ті ж значення для різних параметрів. Таким чином, індивідуальна вказівка характеристик в MPD може привести до істотного дублювання в MPD для вказівки характеристик індивідуально. Багато клієнтських пристроїв сконфігуровані так, щоб відкидати переважну частину прийнятого MPD. Тому в частині, яку приймає клієнтський пристрій, може бути проведена оптимізація. Крім того, якщо Група представлень відкинута, клієнтський пристрій може не мати необхідності доступу до інформації, що є в даний момент в MPD (покажчикам URL і т.д.) для відкинутого представлення або групи представлень. Клієнтський пристрій може також уникнути непотрібних оновлень URL, які мають тенденцію часто оновлюватися у час, наприклад, потокової передачі по мережі в реальному часі відеоданих для подій в прямому ефірі. Навіть якби надмірність в MPD була усунена, то клієнтський пристрій 40 повинен був би все ще проаналізувати весь MPD після отримання і реконструкції, на що може даремно витратитися істотна кількість машинного часу. Фіг. 5 є концептуальною схемою, що зображає інший зразковий мультимедійний контент 250, в якому дані MPD розділені на різні частини для різних груп представлень. Мультимедійний контент 250 може відповідати мультимедійному контенту 64 (фіг. 1) або іншому мультимедійному контенту, збереженому в пам'яті 62. Зокрема файл маніфесту для мультимедійного контенту 250 включає в себе частину 252 MPD, яка, як правило, включає дані, пов'язані з групами представлень. У цьому прикладі частина 252 MPD включає в себе дані 254A і 254B груп представлень (дані 254 груп представлень), які відповідає відповідним групам 270280 представлень, як зображене стрілками, які вказують від даних 254 груп представлень до відповідних груп 270-280 представлень. 21 UA 107394C2 5 10 15 20 25 30 35 У цьому прикладі дані 254A групи представлень включають в себе загальні характеристики 256A групи представлень і місцеположення частини MPD для групи 258A представлень. Тобто місцеположення частини MPD для групи 258A представлень вказує місцеположення частини MPD для групи 260A представлень. Місцеположення частини MPD для групи 258A представлень може відповідати, наприклад, URI або URL частини MPD для групи 260A представлень. Аналогічно, дані 254B групи представлень включають в себе загальні характеристики 256B групи представлень і місцеположення частини MPD для групи 258B представлень, відповідної частині MPD для групи 260B представлень. Частина MPD для групи 260A представлень включає в себе інформацію, яка вказує характеристики конкретних представлень 272A, 272B (представлення 272) групи 270 представлень. Аналогічно, частина MPD для групи 260B представлень включає в себе інформацію, яка вказує характеристики конкретних представлень 282A, 282B (представлення 282) групи 280 представлень. Таким чином, клієнтський пристрій, такий як клієнтський пристрій 40, може визначити відповідну групу представлень, з якої необхідно отримувати дані, не приймаючи дані, що залежать від представлення з інформацією для представлень, які клієнтський пристрій 40 не буде отримувати, декодувати і відображати. Відповідно, клієнтський пристрій 40 може уникнути отримання надмірних даних, які в іншому випадку були б просто відкинуті. Зокрема, після вибору однієї або більше групи представлень, що включають в себе представлення, які можуть бути декодовані і відтворені клієнтським пристроєм 40, клієнтський пристрій 40 може отримати тільки частини MPD для вибраних груп представлень, не отримуючи частини MPD для груп представлень, які не можуть бути належно декодовані і/або відтворені клієнтським пристроєм 40. Дані мультимедійного контенту 250 можуть, як правило, значною мірою відповідати відповідним елементам мультимедійного контенту 200. Однак мультимедійний контент 250 може спростити ієрархічне завантаження даних MPD для мультимедійного контенту 250 клієнтськими пристроями. Наприклад, замість отримання повного файлу маніфесту, який може включати в себе дані з інформацією для всіх представлень, клієнтський пристрій може просто визначити одну або більше груп представлень, потім отримати частини MPD, відповідні цим групам представлень, не отримуючи частини MPD, відповідні іншим групам представлень, які клієнтський пристрій не буде отримувати (наприклад, тому що клієнтський пристрій не підтримує процедури декодування і/або відтворення для декодування і відображення представлень). Таким чином, дані мультимедійного контенту 250 можуть зменшити неефективність непотрібного завантаження і синтаксичного аналізу. Таблиця 2 нижче забезпечує зразковий елемент, який може бути доданий до MPD, такому як MPD 202 на фіг. 4 і/або частини 252 MPD на фіг. 5, які описують характеристики груп представлень. Загальні характеристики 204 представлень (фіг. 4) і/або загальні характеристики 256 груп представлень можуть бути форматовані відповідно структурі Таблиці 2. Таблиця 2 RepresentationGroup Е 1… N RepresentationGroupAtiri Список Елементів і Атрибутів Representation Е RepresentationAttribut Список Елементів і Атрибутів representationListURI А M 0… N О 0,1 О 0… N О Цей елемент містить опис Групи представлень Описує значення за умовчанням для цієї групи, може включати в себе інформацію про профіль. Цей елемент містить опис Представлення. Описує атрибути Представлення, які належать до цього Представлення. URI, який вказує на документ, який містить список Представлень. 40 XML нижче наводить приклади елементів Групи представлень структури даних MPD: 22 UA 107394 C2 5 10 Таблиця 3 нижче забезпечує зразковий набір даних, які можуть бути включені для представлень. Ці дані можуть бути забезпечені для окремих представлень в деяких прикладах, в той час як в інших прикладах всі або частина даних можуть бути забезпечені для груп представлень згідно з, наприклад, Таблицею 2 вище. Таблиця 3 Representation bandwidth Е 1… N А M M Цей елемент містить опис Представлення. Мінімальна пропускна спроможність гіпотетичного каналу з постійною швидкістю передачі в бітах в секунду (біт/сек.), по якому представлення може бути доставлене так, що клієнт, після буферизації протягом точно minBufferTime (мінБуфернийЧас), може бути впевнений в наявності достатньої кількості даних для безперервного відтворення. … texttype А cameraangle А Rating Е 0…N Е 0,1 SchemeInformation schemeIdUri 15 20 25 30 35 вказує тип тексту. Можливі опції: підзаголовок субтитри забезпечує ракурс. Просте пояснення, наприклад, О основний, в середині, вигляд гравців забезпечує рейтингову інформацію Цей елемент дає інформацію про рейтингову схему, що використовується. Елемент може бути ПРО розширений, щоб забезпечувати більше інформації для конкретної схеми. Забезпечує абсолютний URL для ідентифікації схеми. Визначення цього елемента залежить від схеми, що використовується для визначення рейтингу. О У деяких прикладах дані для груп представлень і дані для окремих представлень в таких групах можуть бути представлені в MPD, такому як MPD 202, з ієрархічною залежністю. Тобто інформація про окремі представлення може повідомлятися у вигляді дочірніх елементів відповідного елемента групи представлень, наприклад, описи MPD 202. Аналогічно, для частини 252 MPD і частин MPD для груп 260 представлень індивідуальні характеристики 262, 264 представлень можуть відповідати дочірнім елементам загальних характеристик 256 груп представлень. Фіг. 6 є концептуальною схемою, що зображає інший зразковий мультимедійний контент 300, який може використовуватися для підтримки нестандартних режимів. Мультимедійний контент 300 може відповідати мультимедійному контенту 64 (фіг. 1) або іншому мультимедійному контенту, збереженому в пам'яті 62. У цьому прикладі MPD 302 включає в себе інформацію 304 про представлення, яка може включати в себе інформацію про часову підпослідовність 306. У цьому прикладі інформація про представлення 304 включає в себе характеристики представлення 310. Представлення 310 включає в себе сегменти 312A-312D (сегменти 312). У цьому прикладі кожний з сегментів 312 включає в себе відповідне поле 314 переліку підфрагментів і дані 316 про точки довільного доступу (RAP). В інших прикладах деякі сегменти можуть не включати в себе ніяких точок довільного доступу, в той час як деякі сегменти можуть включати в себе множину точок довільного доступу. Точки довільного доступу можуть включати в себе зображення IDR або ODR. Клієнтський пристрій 40 може витягнути часову підпослідовність з представлення 310. Наприклад, клієнтський пристрій 40 може витягнути кожну з точок RAP 316 для формування часової підпослідовності представлення 310. Альтернативно, клієнтський пристрій 40 може отримати підмножину точок RAP 316, таких як точки RAP 316A і 316C або 316A і 316D. 23 UA 107394 C2 5 Отримуючи і відтворюючи тільки точки 316 довільного доступу (або їх піднабори), клієнтський пристрій 40 може відтворити представлення 310 в нестандартному режимі, наприклад, прискореному перемотуванню уперед або назад. Аналогічно, клієнтський пристрій 40 може перейти або перемотати до однієї конкретної точки з точок 316 довільного доступу, щоб почати відтворення з необхідного часового положення. Мультимедійний контент може включати в себе будь-яку або обидві з: часову інформацію 306 про підпослідовність і/або поле 314 SFIX для вказівки інформації для нестандартних режимів. Інформація 306 про часову підпослідовність може включати в себе елемент "Нестандартний режим" опису MPD 302, такий як визначено в Таблиці 4 нижче: 10 Таблиця 4 TrickMode alternatePlayoutRate Е frameRate А bandwidth А altematePlayoutRate 20 А TemporalSubSequence 15 Е А Забезпечує інформацію для нестандартного режиму. Також вказує, що Представлення 0,1 О може використовуватися як Представлення нестандартного режиму. Вказує максимальну швидкість відтворення як число, кратне швидкості звичайного відтворення, яку це Представлення підтримує з О тим же самим профілем декодера і вимогами рівня, що і для нормальної швидкості відтворення. Вказує, що це Представлення містить часову підпослідовність, до якої можна легко отримати 0…N О доступ за допомогою діапазонів байтів, використовуючи інформацію Поля переліку підфрагментів (' sfix). M Вказує частоту кадрів часової підпослідовності. Вказує мінімальну пропускну спроможність гіпотетичного каналу з постійною швидкістю передачі в бітах в секунду (біт/сек.), по якому часова підпослідовність може бути доставлена ПРО так, що клієнт, після буферизації протягом точно minBufferTime (мінБуфернийЧас), може бути впевнений в наявності достатньої кількості даних для безперервного відтворення. Вказує максимальну швидкість відтворення як число, кратне звичайній швидкості відтворення, яку ця часова підпослідовність О підтримує з тим же самим профілем декодера і вимогами рівня, що і для нормальної швидкості відтворення. У прикладі Таблиці 4 елемент Нестандартного режиму включає в себе елемент Часової підпослідовності, який вказує, що відповідне представлення містить часову підпослідовність, до якої можна отримати доступ за допомогою діапазонів байтів, використовуючи інформацію полів 314 переліків підфрагментів. Точки RAP 316 можуть відповідати частинам фрагментів фільму, таким як фрагменти 162 фільму, зображені на фіг. 3. Поля 314 переліків підфрагментів можуть, як правило, описувати місцеположення діапазонів байтів точок 316 довільного доступу відповідних сегментів 312. Загалом, поля 314 переліків підфрагментів можуть знаходитися після поля переліку сегментів (SIDX) (не показано на фіг. 6) сегментів 312 і забезпечувати розміри префіксів фрагментів фільму для фрагментів фільму, на які посилається безпосередньо попереднє поле переліку сегментів. У таблиці 5 нижче наводяться властивості зразкового поля SFIX. 24 UA 107394 C2 Таблиця 5 Властивості поля переліку під фрагментів Тип поля Контейнер Обов'язкове Кількість 5 10 15 20 25 30 SFIX Немає Немає Одне на полі переліку сегментів Псевдокод нижче забезпечує зразковий синтаксис для полів 314 переліку підфрагментів: aligned(8) class SubFragmentlndexBox extends FullBox('strf',0,0) { unsigned int(32) fragment_count; unsigned int(8) sub_fragment_count; for (i=0; i< fragment_count; i++) for (j=0; j< sub_fragment_count-1; j++) unsigned int(32) prefix_size; } Опис нижче забезпечує зразковий набір семантики для синтаксису, описаного вище: fragment_count вказує число фрагментів, для яких інформація про підфрагмент вказана в цьому полі. Воно повинне бути таке, що дорівнює числу посилань на фрагменти в безпосередньо попередньому Полі переліку сегментів. sub_fragment_count вказує число підфрагментів на фрагмент prefix_size вказує розмір префікса фрагмента i, зайнятого підфрагментом j. У доповнення або як варіант поле фрагментів піддоріжки може бути включено в сегменти 312. У той час як поле переліку підфрагментів може надавати інформацію про синтаксис, яка може бути отримана клієнтським пристроєм 40 разом з полем переліку сегментів перед запитом медіаданих, поле переліку підфрагментів може надавати інформацію для клієнтського пристрою 40 для створення запитів діапазонів байтів, які націлені на підмножини даних фрагментів, наприклад, часові підшари. Поле фрагментів піддоріжки може вказувати переупорядкування вибіркових даних фрагмента доріжки, так що фрагменти даних кожного фрагмента піддоріжки передують всім фрагментам даних, які з'являються тільки в більш високих фрагментах піддоріжки. Фрагменти даних фрагмента піддоріжки, які не з'являються в жодному більш низькому фрагменті піддоріжки, можуть бути розміщені в файлі безперервно (наприклад, відповідний один з сегментів 312) в тому ж порядку, як вони з'являються в поле Відтворення Доріжки. Це може дозволити зберігати фрагменти даних в порядку шару з часовою масштабованістю у фрагменті доріжки. Коли це поле присутнє, може бути тільки одне поле Відтворення Доріжки. Таблиця 6 описує властивості поля фрагментів піддоріжки: ТАБЛИЦЯ 6 Властивості поля фрагментів під доріжки Тип поля Контейнер Обов'язкове Кількість 35 40 STRF Поле фрагмента доріжки ("TRAF") Немає Нуль або одне Псевдокод нижче показує зразковий синтаксис для поля фрагментів піддоріжки: aligned(8) class SubTrackFragBox extends FullBox(' strf', 0, 0) { unsigned int(8) sub_track_count; unsigned int(16) sample_count[sub_track_count-1]; for (i=0; i< sub_track_count; i++) { for (j=0; j< sample_count[i]; j++) bit(1) cur_sub_trak_flag; } 25 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 reserved_trailing_bits; } Опис нижче забезпечує зразкову семантику для зразкового синтаксису поля фрагментів піддоріжки, описаного вище: sub_track_count вказує число фрагментів піддоріжки; коли це поле присутнє, sub_track_count може бути рівним або більше 2. sample_count[i] вказує число фрагментів даних у фрагменті піддоріжки з індексом i+1. Фрагменти даних фрагмента піддоріжки вважаються елементами всіх фрагментів піддоріжки з меншими значеннями індексу. Число фрагментів даних у фрагменті 0 піддоріжки дорівнює числу нулів першого бітового рядка в подальшому циклі. Число фрагментів даних у фрагменті піддоріжки з індексом sub_track_count-1, тобто число sample_count[sub_track_count-1], дорівнює числу фрагментів даних у Фрагменті Доріжки. cur_sub_track_flag, рівний 1 в ітерації i зовнішнього циклу, вказує, що фрагмент даних належить фрагменту піддоріжки з індексом i+1. Ця величина, рівна 0 в ітерації зовнішнього циклу, вказує, що фрагмент даних належить фрагменту піддоріжки з індексом менше i+1. Примітка: Тобто перша ітерація циклу містить прапори sample_count[0], які вказують положення фрагментів даних у фрагменті 1 піддоріжки, які не знаходяться також у фрагменті 0 піддоріжки. Друга ітерація циклу містить прапори sample_count[1], які вказують положення фрагментів даних у фрагменті 2 піддоріжки і також не у фрагменті 1 піддоріжки і т.д. sample_count[sub_track_count-1] вважаються рівними числу фрагментів даних у Фрагменті Доріжки. Нестандартні режими можуть бути застосовані до множини різних сценаріїв. Наприклад, нестандартні режими можуть використовуватися для тимчасового припинення послуги, поновлення послуги після паузи, перемотування назад на певну кількість часу і/або прискореного перемотування уперед для переходу до бажаної позиції у часі (наприклад, після того, як відтворення було перерване або для пошуку конкретної бажаної позиції у часі). Підтримка нестандартних режимів з допомогою часових підпослідовностей може дати ряд переваг. Наприклад, часові підпослідовності можуть відносно легко підтримувати різні частоти кадрів. Аналогічно, представлення, що включає в себе часову підпослідовність, може використовуватися для звичайного відтворення, оскільки представлення не обмежується тільки часовою підпослідовністю. Крім того, кодування з часовими підпослідовностями може бути дуже ефективним. Часові підпослідовності також не вимагають ніяких нових профілів кодування або рівнів, можуть повторно використовувати звичайні представлення, уникають привнесення додаткової складності клієнтів, дозволяють здійснювати легке надання контенту, забезпечують ефективність пропускної спроможності, кешування і зберігання, забезпечують гнучкість реалізації клієнта для оптимізації сприйняття користувача, поширені в різних операціях нестандартних режимів, і можуть бути застосовні до широкого спектра реалізацій клієнтів, і можуть забезпечувати відносно хороше сприйняття користувача з точки зору початкової затримки після пошуку, а також хороші частоти кадрів, чуйність і інші подібні показники. Фіг. 7 є концептуальною схемою, що зображає інший зразковий мультимедійний контент 350, в якому сегменти 362A-362D можуть включати в себе поля 364 оновлення MPD для вказівки, що MPD 352 повинен бути оновлений. Мультимедійний контент 350 може відповідати мультимедійному контенту 64 (фіг. 1) або іншому мультимедійному контенту, збереженому в пам'яті 62. Загалом, MPD 352 включає в себе інформацію 354 про представлення для представлення 360, таку як характеристики представлення 360 і URI або URL сегментів 362 представлення 360. У деяких випадках представлення 360 може бути сформоване з контенту прямої трансляції, наприклад, спортивного заходу, і тому URI сегментів 362 не можуть бути визначені заздалегідь. Тому, коли сегменти представлення 360 сформовані, один або більше сегментів може включати в себе поля оновлення MPD для вказівки, що MPD 352 повинен бути оновлений. Наприклад, на фіг. 7 сегмент 362A включає в себе поле 364 оновлення MPD і дану 366A сегменти. Дані 366A сегменти, як правило, можуть бути сформовані згідно з відеофайлом 150 (фіг. 3). Однак сегмент 362A також включає в себе поле 364A оновлення MPD. Таким чином, клієнтський пристрій 40 може оновити MPD 352 на основі даних поля 364A оновлення MPD. Поле 364A оновлення MPD може включати в себе оновлення до MPD 352 або може включати в себе URI або URL оновлення для MPD 352. Потрібно розуміти, що дані полів 364 оновлення MPD не обов'язково містяться в явних полях. Наприклад, дані, які значною мірою відповідають даним полів 364 оновлення MPD, можуть міститися в інших полях сегментів 362 або в частині заголовка сегментів 362. Таким чином, "частина" сегментів 362, яка включає в себе інформацію про оновлення MPD, може відповідати частині заголовка, полю оновлення MPD, подібному 26 UA 107394 C2 5 10 15 полям 364 оновлення MPD, або даним, що містяться в одному або більше інших полях сегментів 362. Таким чином, після отримання даних сегмента 362A клієнтський пристрій 40 може проаналізувати поле 364A оновлення MPD для оновлення MPD 352. Клієнтський пристрій 40 може потім використати оновлену версію MPD 352 для отримання сегментів 362B і 362C. Сегменти 362B і 362C включають в себе дані сегментів 366B, 366C, які знову ж можуть бути форматовані згідно з відеофайлом 150 на фіг. 3. Клієнтський пристрій 40 може також отримати дані сегмента 362D. У цьому прикладі сегмент 362D включає в себе поле 364B оновлення MPD, яке клієнтський пристрій 40 може використати для виконання іншого оновлення MPD 352 способом, який значною мірою відповідає першому оновленню. Відповідно, щоб прийняти сегменти за сегментом 362D представлення 360, клієнтський пристрій 40 може використати оновлену версію MPD 352, основану на оновленнях, виконаних за даними поля 364B оновлення MPD. Поле оновлення MPD, таке як поля 364A, 364B оновлення MPD, можуть включати в себе властивості згідно з Таблицею 7 нижче: Таблиця 7 Властивості поля оновлення MPD Тип поля Контейнер Обов'язкове Кількість 20 25 30 35 40 45 50 MUPE Немає Немає Нуль або одне У деяких прикладах може використовуватися наступний синтаксис для визначення поля оновлення MPD: aligned(8) class MPDUpdateBox extends FullBox(' mupe') { unsigned int(3) mpd_information_flags; unsigned int(1) new_location_flag; unsigned int(28) latest_mpd_update_time; /// Наступні поля є необов'язковими string mpd_location } Зразковий набір семантики для зразкового синтаксису поля оновлення MPD представлений нижче: mpd_information_flags містить логічне АБО жодних або декількох елементів з нижченаведеного: 0 × 00 Оновити Опис медіапрезентації зараз 0 × 01 Оновити Опис медіапрезентації заздалегідь 0 × 02 Кінець презентації 0 × 03-0 × 07 Зарезервовані new_location_flag, якщо встановлений рівним 1, то новий Опис медіапрезентації доступний в новому місцеположенні, вказаному в mpd_location. latest_mpd_update_time вказує час в мілісекундах, до якого необхідно оновлення MPD, відносно часу публікації останнього MPD. Клієнт може вирішити оновити MPD в будь-який час між тепер і цим часом. mpd_location присутній, якщо і тільки якщо new_location_flag встановлений і забезпечує Уніфікований покажчик ресурсів для нового Опису медіапрезентації. Таким чином, може використовуватися передача сигналів в основній смузі пропущення на рівні сегмента для вказівки оновлень до MPD 302. У деяких прикладах оновлення можуть бути забезпечені на границях сегментів. Тобто в різних прикладах поля 364 оновлення MPD можуть мати місце тільки на початку або в кінці відповідних сегментів. У деяких прикладах, якщо смуга пропущення оновлень MPD являє собою проблему, серверний пристрій 60 (фіг. 1) може запропонувати описи MPD для деяких можливостей пристрою, так що тільки ці частини оновлюються. Крім того, елемент MPD опису MPD 302 може забезпечувати фізичний час публікації MPD 302. Він може забезпечувати унікальний час публікації MPD, який може забезпечувати унікальний ідентифікатор для MPD і те, коли MPD був випущений. Він може також забезпечувати прив'язку для процедур оновлення. Крім того, серверний пристрій 60 і/або 27 UA 107394 C2 5 10 15 20 25 30 35 40 45 50 55 60 пристрій 20 підготовки контенту може оптимізувати оновлення MPD, використовуючи ієрархічні структури, наприклад для оновлення тільки частин MPD 302, які вимагають оновлення, не змінюючи інші частини MPD 302, які не потребують оновлення. Вставка реклами, така як вставка адресної реклами, може також виконуватися за допомогою полів оновлення MPD, аналогічних таким на фіг. 7. Тобто, поле оновлення MPD може бути забезпечене для того, щоб спрямувати клієнтський пристрій 40 на отримання даних з рекламного мультимедійного контенту. Це може відбуватися під час тайму-аутів або інших дій на спортивних заходах, які затримують гру і, аналогічно, в таймі-аутах або затримках захоплюючої дії для повтору відео. Оскільки такі події можуть статися до деякої міри випадково, моменти часу, в які повинна бути вставлена реклама, можуть бути не відомі заздалегідь. Оновлення MPD 302 може здійснюватися асинхронним чином для доставки сегментів. Серверний пристрій 60 може надати гарантії клієнтському пристрою 40, що MPD не буде оновлюватися протягом конкретного періоду часу. Однак серверний пристрій 60 не потребує необхідності явно подавати сигнал, коли MPD оновлюється до мінімального періоду оновлення. Повністю синхронне відтворення навряд чи може бути досягнуте, оскільки клієнтські пристрої можуть працювати по різних копіях оновлення MPD. Тому клієнти можуть відчувати зміщення. Перегляд із зсувом за часом може бути передбачений серверним пристроєм 60 і/або пристроєм 20 підготовки контенту. Фіг. 8 є блок-схемою послідовності операцій, яка зображає зразковий спосіб для забезпечення вказівок відносно груп представлень серверним пристроєм і для вибору груп представлень клієнтським пристроєм, а також окремих представлень у вибраній групі представлень. Хоча спосіб на фіг. 8 описаний відносно серверного пристрою 60 і клієнтського пристрою 40, потрібно розуміти, що інші пристрої можуть реалізовувати методи, аналогічні таким з способу на фіг. 8. Наприклад, пристрій 20 підготовки контенту або один або більше мережевих пристроїв мережі доставки контенту можуть виконувати деякі або всі функції, віднесені до серверного пристрою 60. Серверний пристрій 60 може спочатку отримати (наприклад, створити або прийняти від пристрою 20 підготовки контенту), дані для набору представлень мультимедійного контенту, де представлення в наборі мають одну або більше загальних характеристик, а також файл маніфесту для мультимедійного контенту. Набір представлень може відповідати групі представлень. Серверний пристрій 60 може забезпечити вказівки відносно груп представлень клієнтському пристрою 40 (400). Наприклад, серверний пристрій 60 може надати MPD 202 (фіг. 4) або частину MPD 252 (фіг. 5) клієнтському пристрою 40. Інші зразкові MPD на фіг. 2, 6 і 7 можуть також включати в себе вказівки відносно груп представлень, такі як XML елементи груп представлень. У будь-якому випадку, клієнтський пристрій 40 може прийняти інформацію, що описує характеристики груп представлень (402), наприклад, з файлу MPD або частини файлу MPD, прийнятого від серверного пристрою 60. Клієнтський пристрій 40 може потім проаналізувати характеристики групи представлень, щоб виключити групи представлень, які клієнтський пристрій 40 не може або не буде вибирати для отримання, декодування або відтворення. Наприклад, клієнтський пристрій 40 може порівняти можливості для декодування і відтворення з характеристиками груп представлень, щоб визначити невідповідні групи представлень. Як інший приклад, клієнтський пристрій 40 може порівняти налаштування користувача для мови, рейтингу і величини глибини (наприклад, як забезпечено двома або більше конкретними ракурсами камери), щоб виключити небажані групи представлень. Клієнтський пристрій 40 може потім вибрати відповідну групу представлень на основі, щонайменше частково, можливостей для декодування і відтворення клієнтського пристрою 40 (404). Звичайно, потрібно розуміти, що цей вибір може також (додатково або альтернативно) бути зроблений на основі призначених для користувача налаштувань, як обговорювався вище. Таким чином, клієнтський пристрій 40 може вибрати набір представлень на основі загальних характеристик для набору представлень. Після вибору групи представлень клієнтський пристрій 40 може запитати дані для частини MPD, яка описує конкретно представлення групи представлень. У відповідь серверний пристрій 60 може надати клієнтському пристрою 40 вказівки відносно бітових швидкостей представлення, крім інших індивідуальних характеристик представлень, у вибраній групі представлень (406). Наприклад, серверний пристрій 60 може відправити клієнтському пристрою 40 дані для конкретної однієї з частин MPD для груп 260 представлень (фіг. 5). В інших прикладах клієнтський пристрій 40, можливо, вже прийняв повне MPD для мультимедійного контенту (наприклад, MPD 202 на фіг. 4), але він може детально аналізувати частини MPD, відповідні конкретно вибраній групі представлень. Таким чином, в деяких прикладах етап 406 на фіг. 8 може мати місце до етапу 402 і/або етапу 404. 28
ДивитисяДодаткова інформація
Назва патенту англійськоюManifest file updates for network streaming of coded video data
Автори англійськоюChen, Ying, Stockhammer, Thomas, Watson, Mark
Автори російськоюЧень Ин, Штокхаммер Томас, Уотсон Марк
МПК / Мітки
МПК: H04L 29/06
Мітки: файла, передачі, потокової, мережевої, відеоданих, маніфесту, оновлення, кодованих
Код посилання
<a href="https://ua.patents.su/46-107394-onovlennya-fajjla-manifestu-dlya-merezhevo-potokovo-peredachi-kodovanikh-videodanikh.html" target="_blank" rel="follow" title="База патентів України">Оновлення файла маніфесту для мережевої потокової передачі кодованих відеоданих</a>
Режими швидкого доступу до довільної точки для мережевої потокової передачі кодованих відеоданих
Номер патенту: 107125
Опубліковано: 25.11.2014
Автори: Уотсон Марк, Штокхаммер Томас, Чен Ін
МПК: H04L 29/06
Мітки: режимі, точки, відеоданих, мережевої, доступу, довільно, передачі, кодованих, потокової, швидкого
Формула / Реферат:
1. Спосіб витягання мультимедійних даних, причому спосіб включає:аналіз інформації файлу маніфесту для мультимедійного контенту, при цьому інформація файла маніфесту вказує, що щонайменше одне представлення мультимедійного контенту включає в себе часову підпослідовність;визначення одного або більше байтових діапазонів, що відповідають місцеположенням даних для часової підпослідовності в одному або більше відповідних сегментах...
Швидке перемикання каналу і захист потокової передачі високої якості по широкомовному каналу
Номер патенту: 95881
Опубліковано: 12.09.2011
Автори: Штокхаммер Томас, Лубі Майкл Дж., Шокроллахі Мохаммад Амін
МПК: H04N 7/015, H04N 7/64
Мітки: потокової, захист, високої, перемикання, каналу, передачі, якості, широкомовному, швидке
Формула / Реферат:
1. Система електронної доставки для доставки потоків даних по широкомовному каналу, при цьому широкомовний канал є каналом для передачі сигналів від одного або більше джерел у множині приймачів, при цьому кожен приймач намагається прийняти по суті той же самий сигнал, причому система електронної доставки містить:систему відправника, яка відправляє дані для потоку даних в пакетах фізичного рівня блоків фізичного рівня, причому...
Спосіб і пристрій для обробки даних для передачі та блок передавача в кодованих системах з множиною входів та множиною виходів з вибірковою інверсією каналів, що застосовується на кожній власній моді
Номер патенту: 84684
Опубліковано: 25.11.2008
Автори: Уолтон Джей Род, Мєдвєдєв Іріна, Кетчум Джон У.
МПК: H04B 7/005, H04L 1/02
Мітки: каналів, пристрій, застосовується, виходів, вибірковою, моди, входів, кожній, даних, власній, передачі, системах, множиною, інверсією, обробки, спосіб, кодованих, передавача, блок
Формула / Реферат:
1. Спосіб обробки даних для передачі у системі зв'язку з множиною входів, множиною виходів (МІМО), що включає етапи, на якихорганізовують множину наявних каналів передачі у множину груп; і для кожної групи каналів передачі, яка повинна використовуватися для передачі даних:вибирають один або більше каналів передачі у групі для використання і визначають масштабний коефіцієнт для кожного вибраного каналу передачі...
Спосіб налаштування мережевої навігації, система для налаштування мережевої навігації та машинозчитуваний носій
Номер патенту: 93477
Опубліковано: 10.02.2011
Автор: Новофастовський Костянтин Олександрович
МПК: G06F 17/30
Мітки: машинозчитуваний, мережевої, налаштування, спосіб, навігації, система, носій
Формула / Реферат:
1. Спосіб налаштування мережевої навігації, при якому прописують посилання, що забезпечує перехід з графічного зображення на сторінку сайту, який відрізняється тим, щопопередньо зберігають на сервері базу даних, причому елементи бази даних виконані з можливістю проводити пошук по них за допомогою робота в інформаційно-пошуковій системі,створюють графічне зображення, яке відповідає певним визначеним критеріям,прописують в...
Способи та системи передачі мультимедійного контенту з використанням існуючого протоколу передачі оцифрованого звуку
Номер патенту: 101630
Опубліковано: 25.04.2013
Автори: Шуракві Жан, Нгуєн Хунг
МПК: H04L 12/16, H04N 21/434, H04N 21/643, H04L 29/06, H04N 21/2368
Мітки: використанням, системі, контенту, існуючого, передачі, звуку, мультимедійного, способи, оцифрованого, протоколу
Формула / Реферат:
1. Система обробки мультимедійного контенту для передачі через одну або більше мереж, що включає:трансформаційний пристрій (211, 311), для конвертації мультимедійного файлу в звуковий файл для подальшої передачі через одну або більше мереж із використанням існуючого протоколу передачі оцифрованого звуку, де мультимедійний файл являє собою мультимедійний контент;та відновлюваний пристрій (251, 351), для відновлення...
Попередній патент: Парокомпресійна холодильна машина
Наступний патент: Спосіб гум кількісного визначення агрегації клітин периферичної крові методом поверхневого плазмонного резонансу
Випадковий патент: Спосіб діагностики полідорозису у вирощуваних у чорному морі двостулкових молюсків (устриць і мідій)