Модифікуючі командні послідовності

Реферат: Спосіб модифікування послідовності команд, яка включає множину команд, команди мають розклад, за яким вони повинні виконуватись, включаючи такі кроки: перетворення (202) команд у вчасні субкоманди, які повинні виконуватись згідно розкладу, та підготовчі субкоманди, які не обмежені виконанням за розкладом; і налаштування (204, 206) порядку субкоманд так, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекривалися з періодами, під час яких виконуються субкомандні компоненти першого типу. UA 104034 C2 (12) UA 104034 C2 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 Цей винахід стосується модифікуючих командних послідовностей. Частково, але не повністю, він має відношення до оптимізації командних послідовностей, які використовуються для презентації медіа контенту на користувацьких термінальних пристроях. Він можне використовуватися для потокової передачі насиченого медіа контенту на мобільні термінальні пристрої. Насичений медіа контент, зазвичай, є контентом, який насичений графічно, і часто містить декілька типів складних медіа даних, таких як текст, графічні дані, анімація, аудіо або відео. Взагалі, насичені медіа дані є динамічними у сенсі того, що вони можуть змінюватися в часі та у деяких випадках можуть реагувати на інтерактивні дії користувача. Все більше насиченого медіа контенту стає доступним у мережі Інтернет, через що вимоги до його доставки зростають. Тому стає доцільним надання засобів забезпечення можливості пристроям з обмеженим ресурсом, таким як мобільні телефони або вбудовані пристрої, бути здатними приймати і обробляти насичений медіа контент. Система насичених медіа даних у формі системи клієнт-сервер 100 показана на фіг. 1. Вона включає сервер насичених медіа даних 102, клієнта насичених медіа даних 104 та механізм транспортування 106. Сервер насичених медіа даних 102 сконфігурований для прийому та зберігання насичених медіа даних у формі контейнера насичених медіа даних 108, який включає дискретні медіа дані (нерухомі зображення), неперервні медіа дані (відео- або аудіопотоки) 110 та команди дескрипторів кадрів 112. Команди дескрипторів кадрів 112 визначають порядок, у якому насичений медіа контент повинен монтуватись, презентуватись та змінюватися в часі. Такі зміни є наслідком дії команд оновлення кадрів, які використовуються для оновлення кадрів у часі. Сервер насичених медіа даних 102 також містить блок сервісу віддаленої взаємодії 114, який сконфігурований для прийому віддаленої взаємодії від користувача та її використання для модифікації кадру, як показано на термінальному пристрої, який містить у собі та запускає клієнта насичених медіа даних 104. Клієнт насичених медіа даних 104 має блок рендерингу насичених медіа даних 116, блок локальної взаємодії 118 та блок віддаленої взаємодії 120. Блок рендерингу насичених медіа даних 116 отримує команди кадрового дескриптора від сервера насичених медіа даних 102 через механізм транспортування 106 та обробляє їх для візуальної та звукової презентації на термінальному пристрої. Блок локальної взаємодії 118 отримує команди користувача, які визначають, як повинен презентуватися кадр на термінальному пристрої. Блок віддаленої взаємодії 120 приймає віддалені команди користувача і/або зворотній зв'язок від користувача та доставляє їх на блок сервісу віддаленої взаємодії 114 через механізм транспортування 106. Ці команди і/або зворотній зв'язок від користувача можуть бути прямими запитами на новий контент або непрямими запитами, при яких дії користувача спонукають систему намагатись доставити новий контент. Транспортний механізм 106 здатний використовувати прямий канал 122 для потокової передачі, завантаження і/або поетапного завантаження насичених медіа даних індивідуальним користувачам у режимі доставки один-до-одного або у режимі один-до-багатьох, або доставки у режимі мовлення. Зворотній зв'язок, надаваний блоком віддаленої взаємодії 120 клієнту насичених медіа даних 104, доставляється на сервер насичених медіа даних 102 по каналу зворотного зв'язку 124. При потоковій передачі насичених медіа даних сервером насичених медіа даних клієнтам насичених медіа даних під час сесії потокової передачі відбувається або передача нарізно, наприклад, аудіо, відео та кадровий дескриптор передаються як окремі доріжки, наприклад, у випадку використання потокового протоколу реального часу (ППРС) (Real Time Streaming Protocol, RTSP) та протоколу транспортування в реальному часі (ПТРТ) (Real-time transport Protocol, RTP), або всі ці елементи мультиплексуються разом, наприклад, у випадку використання транспортного потоку MPEG. Кадровий дескриптор, відправлений у модуль потокової передачі, являє собою або повний (новий) кадровий дескриптор або оновлену команду. Оновлена команда може бути декларативною (як вставка, видалення, заміна і т.д.) або скриптом. Типовий клієнт насичених медіа даних запускається на термінальному пристрої користувача такому як ПК, нетбук, КПК, або стільниковому пристрої безпроводового зв'язку, такому як мобільний телефон. У деяких випадках потоку насиченого медіа контенту може знадобитися значна кількість обробок, і при обробці персональним мобільним пристроєм з обмеженим ресурсом це може зайняти багато часу для роботи з командами потоку. Клієнт насичених медіа даних 104 здатен до рендерингу контенту. Як тільки насичений медіа контент пройшов рендеринг і, відповідно, став доступним для користувача, клієнт 1 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 насичених медіа даних 104 може взаємодіяти з контентом як локально, так і віддалено. У першому випадку, користувач вносить зміни у рендеринг насиченого медіа контенту на термінальному пристрої. У другому випадку введені дані користувача спонукають клієнта насичених медіа даних 104 до запиту насиченого медіа контенту з сервера насичених медіа даних 102 таким чином, що контент, який міститься у клієнті насичених медіа даних 104 змінюється і піддається рендерингу, через що може змінитися презентація на термінальному пристрої. Приклади таких систем насичених медіа даних включають MPEG-BIFS, LASeR та 3GPPDIMS. BIFS є презентаційним механізмом для MPEG за замовчуванням, а наступні два є стандартами кадрових дескрипторів, спеціально розроблених для додатків з обмеженим ресурсом. У багатьох випадках доступна транспортна полоса пропускання між сервером насичених медіа даних 102 та клієнтом насичених медіа даних 104 є обмеженою. Навіть у високошвидкісній мережі бажано мати рівномірно розподілений трафік та уникати сплесків трафіку. Для цього рекомендується використовувати постійну (максимальну) бітову швидкість передачі аудіо або відео потоків. Одначе, дескрипція кадрів та команди оновлення кадрів можуть у деяких випадках стати причиною значних сплесків трафіку, особливо, якщо вони містять вбудовані графічні дані, фонти та скрипти. Також проблемою, особливо для пристроїв з обмеженим ресурсом, може стати те, що виконання команд оновлення кадрів може зайняти довгий час, оскільки рендеринг взагалі є ресурсномісткою операцією. Якщо декілька команд кадрового оновлення розташовані близько одна від одної у часі, то це може викликати затримки або помилки рендерингу і, можливо, може стати причиною проблем внутрішньої обробки в термінальному пристрої користувача. Для запобігання перебоїв трафіку через кадрові дескриптори та команди оновлення можна використовувати буферизацію. Наприклад, модель декодера MPEG-LASeR пропонує буферизацію медіа потоків перед та після декодування. Взагалі, для клієнта насичених медіа даних 104 є проблемою визначення необхідного розміру буфера, який загалом залежить від самого контенту. Є можливість встановити розмір буфера між сервером насичених медіа даних 102 та клієнтом насичених медіа даних 104 під час початку сесії передачі медіа контенту, але у випадку потокової передачі наживо сам сервер насичених медіа даних 102 не може завчасно точно визначити необхідний розмір буфера, а зміна його під час потокової сесії неможлива без впливу на якість рендерингу. У будь-якому випадку, буферизація не вирішить проблеми великого часу для обробки команд, який необхідний для терміналів користувача з обмеженими ресурсами. Відповідно до першого аспекту винаходу пропонується спосіб модифікування командної послідовності, яка включає множину команд, команди мають розклад, за яким вони мають виконуватись, який включає такі кроки: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватись відповідно до розкладу, та у субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; і налаштування порядку субкомандних компонентів так, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекривалися з періодами, під час яких виконуються субкомандні компоненти першого типу. Переважно команди відносяться до дескрипції кадрів. Ними можуть бути команди дескриптора кадрів та команда оновлення для кадрової дескрипції. Винахід переважно стосується потокової передачі таких команд. Бажано, щоб розклад визначав відрізки часу, у які повинні виконуватися оригінальні команди. Це можуть бути моменти часу, у які повинне починатись виконання команд. Після модифікації, розкладом можуть бути моменти часу, в які починається виконання субкомандних компонентів першого типу. Оригінальна команда трансформується у субкомандний компонент першого типу і субкомандний компонент другого типу так, щоб вона мала відповідний субкомандний компонент першого типу та відповідний субкомандний компонент другого типу. Одначе, в інших варіантах реалізації винаходу може бути більше, ніж два субкомандних компоненти. Субкомандні компоненти першого типу, мають аспект строгого виконання у часі, в який виконання відповідно до розкладу стосується події, поява якої сприймається користувачем термінального пристрою або може мати істотний вплив на спостерігача. Такий субкомандний компонент може бути віднесена до вчасного субкомандного компонента. Бажано, щоб підкоманди другого типу мали аспект, не критичний по часу, в який виконання відповідно до розкладу стосується події, яка не сприймається користувачем приймального 2 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 пристрою. Це може бути фоновою обробкою, щоб дозволити реалізацію події, помітної для користувача. Такий субкомандний компонент може відноситись до підготовчого субкомандного компонента. Бажано, щоб субкомандний компонент другого типу міг бути виконаний раніше розкладу, за яким повинен виконуватися відповідний йому субкомандний компонент першого типу. Субкомандний компонент другого типу може бути виконаний раніше розкладу, за яким повинен виконуватися інший субкомандний компонент першого типу, який передує відповідному субкомандному компоненту першого типу так, що, щонайменше, один проміжний субкомандний компонент за розкладом виконується між субкомандним компонентом другого типу і відповідним йому субкомандним компонентом першого типу. Бажано, щоб субкомандні компоненти другого типу впорядковувались навколо субкомандних компонентів першого типу. В одному варіанті реалізації винаходу оцінюються відповідні витрати на виконання субкомандних компонентів першого типу і визначається чи є доступні інтервали у загальному ресурсі, який зайнятий субкомандними компонентами першого типу, у яких можуть виконуватися підкоманди другого типу. Термін "доступний ресурс" у деяких варіантах може стосуватися загального періоду часу, у який повинні бути виконані всі субкомандні компоненти, або загального ресурсу в байтах, який відповідає сумарній кількості обробок для передачі або виконання всіх субкомандних компонентів. Витрати оцінюються на основі можливих параметрів швидкості. Загалом, метод стосується вибору випадкового параметру швидкості та намагання розподілити за розкладом субкомандні компоненти відповідно до підпрограми впорядкування розкладу для вибраного параметра швидкості. Параметри швидкості можуть відображати можливість обробки приймального пристрою або ширину смуги пропускання. Винахід може стосуватись оцінки затрат субкомандних компонентів. У багатьох варіантах реалізації винаходу ця оцінка затрат може розглядатися як приблизна оцінка передавального розміру субкомандного компонента, потужності для обробки, необхідної для виконання субкомандного компонента або комбінація цих параметрів. Якщо виконується оптимізація за множиною параметрів, то для генерування оцінки затрат може використовуватися зважений максимум. Оцінка затрат може використовуватися для генерації часового періоду необхідного для обробки субкомандного компонента. Наприклад, часовий період передавання і/або обробки субкомандного компонента може бути розрахований діленням оцінки затрат субкомандного компонента на параметр швидкості, зазвичай, на число або кількість одиниць, призначених для обробки, наприклад, виражений у байтах на одиницю часу. У іншому аспекті, винахід може включати планування розкладу виконання субкомандних компонентів з різними значеннями параметра швидкості так, щоб робочий параметр швидкості в якості максимально низького значення мав значення, при якому субкомандні компоненти обробляються коректно. Для того, щоб забезпечити ефективне планування виконання для пристроїв з обмеженим ресурсом, у винаході є можливість оцінити періоди часу, які необхідні для виконання субкомандних компонентів. Це може стосуватися оцінювання затрат виходячи з ресурсів пристрою і/або системних ресурсів виконання команд оновлення кадрів. У цьому варіанті винаходу, така оцінка затрат є оцінкою, або, можливо, прямим вимірюванням розміру передачі команди оновлення. Як тільки оцінка затрат субкомандного компонента отримана, вона може використовуватися для оцінки необхідного для виконання субкомандного компонента часового періоду, наприклад, шляхом ділення оцінки затрат субкомандного компонента на припустиму швидкість обробки, на якій зможе працювати приймальний пристрій, який приймає субкомандні компоненти. Оскільки ця швидкість обробки невідома, то генерується випадкове значення, після чого буде проведено ряд операцій по плануванню розкладу для визначення тієї, при якій необхідна швидкість обробки мінімальна. В іншому варіанті винаходу, планування розкладу може базуватися на розмірі субкомандних компонентів краще, ніж на оцінці необхідного часу для їх виконання. Загалом, розклад є попередньо визначеним розкладом. Взагалі, метод включає генерування додаткового розкладу, за яким виконуються субкомандні компоненти другого типу. В результаті методу можуть бути два розклади: попередньо визначений розклад, за яким мають виконуватися субкомандні компоненти першого типу та додатковий розклад, за яким мають виконуватися субкомандні компоненти другого типу. Загалом, метод відноситься до оптимізації розкладу множини команд. Взагалі, метод включає ітераційну частину, яка використовує підпрограму налаштування розкладу для визначення порядку, в якому мають виконуватися субкомандні компоненти. 3 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 Ітераційна частина може виконувати оптимізацію планування з різними параметрами швидкості доти, поки не буде визначений ефективний параметр швидкості. Взагалі, якщо підпрограма налаштування розкладу видає у розкладі субкомандні компоненти, що підходять для виконання вчасно з обраним параметром швидкості, то параметр швидкості знижується, і субкомандні компоненти після цього знову плануються у розкладі відповідно до підпрограми налаштування розкладу. Це може відбуватися багато разів, поки підпрограма налаштування розкладу не відмітить, що вчасне виконання недосяжне. Взагалі, якщо підпрограма налаштування розкладу видає у розкладі субкомандних компонентів, які не можуть бути виконані з вибраним параметром швидкості вчасно, параметр швидкості збільшується, і потім субкомандні компоненти плануються у розкладі знову відповідно до підпрограми налаштування розкладу. Це може відбуватися багато разів, поки підпрограма налаштування розкладу не відмітить, що часове виконання досяжне. Використовувана підпрограма налаштування розкладу може видавати результат у діапазоні між верхньою та нижньою межами параметра швидкості. Підпрограма налаштування розкладу може застосовуватися до параметрів швидкості між верхньою та нижньою межами параметрів швидкості з успішними результатами, які визначають нову верхню межу, та неуспішними результатами, які визначають нижню межу. Цей крок може повторюватися ітераційно, поки різниця між двома межами не буде меншою, ніж попередньо визначене значення. Останній параметр швидкості верхньої межі може використовуватись в якості мінімального параметра швидкості, при якому субкомандні компоненти плануються відповідно до підпрограми налаштування розкладу і можуть успішно запускатись. Загалом, підпрограма налаштування розкладу планує субкомандні компоненти першого типу, а потім субкомандні компоненти другого типу. Взагалі, субкомандні компоненти першого типу плануються у порядку починаючи з того, який повинен виконуватися першим до того, який повинен виконуватися останнім. Взагалі, субкомандні компоненти другого типу плануються у зворотному порядку починаючи з того, який повинен виконуватися останнім до того, який повинен виконуватися першим. Вони можуть плануватися у порядку з проміжками починаючи з останнього і закінчуючи найпершим виходячи з актуальної хронології (або обробки). Загалом, у кінці ітеративної частини при успішній обробці всіх субкомандних компонентів, результатом є доступність наступних типів інформації: (і) субкомандним компонентам першого типу призначається їх час виконання відповідно до попередньо визначеного розкладу; (іі) субкомандним компонентам другого типу призначається новий час виконання відповідно до додаткового розкладу; та (ііі) параметр швидкості, при якому субкомандні компоненти були сплановані успішно. Взагалі, розміри субкомандних компонентів оцінюються для надання оцінок субкомандних затрат. Оцінки субкомандних затрат потім можуть ділитися на параметр швидкості для оцінки часових періодів, необхідних для виконання кожного субкомандного компонента. Одна окремий субкомандний компонент першого типу може перевірятись для того, щоб з'ясувати, чи необхідний часовий період для його виконання, який починається зі старту його виконання, перекривається з часом старту виконання безпосередньо наступного субкомандного компонента першого типу. Якщо так, то підпрограма налаштування розкладу вважається виконаною невдало, а параметр швидкості вважається "неуспішним". У цьому випадку, ітераційна частина може обрати більший параметр швидкості, який використовується підпрограмою налаштування розкладу у плануванні розкладу субкомандних компонентів першого типу. Взагалі, якщо період часу субкомандного компонента другого типу дуже довгий для того, щоб вміститися у будь-який проміжок між субкомандними компонентами першого типу, підпрограма налаштування розкладу вважається виконаною невдало, а параметр швидкості вважається "неуспішним". У цьому випадку, ітераційна частина може обрати більший параметр швидкості, який використовується підпрограмою налаштування розкладу у плануванні розкладу субкомандних компонентів другого типу. Загалом, параметр швидкості є значенням швидкості. Це може бути значення швидкості обробки приймального пристрою або це може бути значення швидкості передачі, наприклад у показниках смуги пропускання або бітовій швидкості між передавальним пристроєм, таким як сервер, та приймальним пристроєм. Один субкомандний компонент другого типу може бути розміщений в тому ж проміжку, що і один або більше інших субкомандних компонентів другого типу, якщо є місце для розміщення їх обох або всіх. Взагалі, розмір n-го субкомандного компонента другого типу може порівнюватися 4 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 з доступним розміром проміжку між послідовними субкомандними компонентами першого типу, з якими попередньо був розміщений n+1-a субкомандний компонент другого типу. Доступний розмір проміжку може бути визначений як розмір проміжку між послідовними субкомандними компонентами першого типу мінус розмір n+1-го субкомандного компонента другого типу. У варіанті реалізації винаходу, де проміжки можуть вмістити множину субкомандних компонентів другого типу, вони розміщені у проміжку у порядку, в якому вони повинні виконуватися так, що розмір n-й субкомандний компонент другого типу передує n+1-му субкомандному компоненту другого типу. Взагалі, якщо підпрограма налаштування розкладу не може розташувати субкомандний компонент другого типу у n-й проміжок між послідовними субкомандними компонентами першого типу, вона потім намагається розмістити субкомандний компонент другого типу у n-1-й проміжок між послідовними підкомандами першого типу. В цьому випадку спосіб може розмістити субкомандний компонент другого типу у проміжок, який знаходиться найближче до відповідних йому субкомандних компонентів першого типу. Взагалі, спосіб модифікування командної послідовності виконується для підготовки їх до передачі. Загалом, це стосується передачі на приймальний пристрій. Це може бути термінальний пристрій, наприклад мобільний термінальний пристрій. Загалом, команди та субкомандні компоненти виконуються приймальним пристроєм для рендерингу мультимедійних даних у приймальному пристрої. Це може стосуватися презентації картинок і/або відео на дисплеї приймального пристрою, програвання аудіо приймальним пристроєм, або і того, і того. Взагалі, у варіанті винаходу, де немає залежності між субкомандними компонентами другого типу, може виникнути ситуація, в якій в наборі субкомандних компонентів, які мають оптимізований розклад, субкомандні компоненти другого типу закінчуються в оптимізованому порядку, який відрізняється від їхнього оригінального порядку. Одначе, вони можуть досі бути розміщені у проміжках, які передують їх субкомандним компонентам першого типу. Команди можуть бути декларативними оновленнями. Крок перетворення може бути перетворенням декларативних команд оновлення у недекларативні команди, наприклад, скрипти. В одному варіанті винаходу це може бути генерація субкоманди, здатної викликати анімаційний ефект. В іншому варіанті винаходу, крок перетворення може стосуватися злиття разом субкоманд, які відносяться до різних оригінальних команд, наприклад, створення загальної підготовки і/або вчасної субкоманди з більше, ніж однієї оригінальної команди. Відповідно до другого аспекту винаходу, надається система для модифікування та передачі командної послідовності, яка включає множину команд, команди мають розклад, за яким вони повинні виконуватися, система містить сервер та приймальний пристрій, сервер може: перетворювати команди у субкомандні компоненти першого типу, які мають виконуватись згідно розкладу, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; налаштовувати порядок субкомандних компонентів так, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу не перекривались з періодами, під час яких виконуються субкомандні компоненти першого типу; та передавати субкомандні компоненти першого та другого типів, і приймальний пристрій може: приймати компонент підкоманди першого та другого типів; та виконувати субкомандні компоненти першого та другого типів без, щонайменше, одного перекривання між виконанням субкомандних компонентів першого та другого типів. Відповідно до третього аспекту винаходу, надається сервер для модифікування командної послідовності, яка містить множину команд, команди мають розклад, за яким вони мають виконуватися, сервер може: перетворювати команди у субкомандні компоненти першого типу, які мають виконуватися відповідно до розкладу, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; та налаштовувати порядок субкомандні компоненти так, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу не перекривались з періодами, під час яких виконуються субкомандні компоненти першого типу. Взагалі, сервер є сервером насичених медіа даних. Відповідно до четвертого аспекту винаходу, надається термінальний пристрій, який може: 5 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 приймати модифіковану командну послідовність, яка містить множину субкомандних компонентів, субкомандні компоненти представляють оригінальні команди, які мають розклад, за яким вони повинні виконуватися, які перетворені на субкомандні компоненти першого типу, які повинні виконуватися відповідно до розкладу та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом, порядок субкомандних компонентів налаштовується так, що очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекриваються з періодами, під час яких виконуються субкомандні компоненти першого типу; та виконувати субкомандні компоненти першого та другого типів без, щонайменше, одного перекривання між виконаннями субкомандних компонентів першого та другого типів. Взагалі, термінальний пристрій містить клієнт насичених медіа даних. Відповідно до п'ятого аспекту винаходу надається комп'ютерний програмний продукт, який включає програмний код, який при виконанні на комп'ютерній системі реалізує спосіб модифікування командної послідовності, яка включає множину команд, команди мають розклад, за яким вони виконуються, включаючи такі кроки: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватися відповідно до розкладу та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; та налаштування порядку субкомандних компонентів так, що очікувані періоди, під час яких виконуються субкомандні компоненти другого типу не перекривались з періодами, під час яких виконуються субкомандні компоненти першого типу. Взагалі, комп'ютерний програмний продукт зберігається на машиночитаному носії. Відповідно до шостого аспекту винаходу, надається командна послідовність, яка містить множину субкомандних компонентів, підкоманди представляють оригінальні команди, які мають розклад, за яким вони повинні виконуватися, які перетворені на субкомандні компоненти першого типу, які мають виконуватися відповідно до розкладу та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом, порядок субкомандних компонентів повинен налаштовуватися так, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекривалися з періодами, під час яких виконуються субкомандні компоненти першого типу. В одному варіанті реалізації винаходу винахід включає обробку набору команд для відділення, щонайменше, деяких фонових обробок, які включені у підготовку елемента контента для презентації та обробки, задіяної у його презентації, наприклад через інтерфейс користувача приймального пристрою. У цьому випадку, може бути визначена мінімальна продуктивність приймального пристрою, при якій слоти часу або проміжки між періодами часу, під час яких забезпечується обробка презентації елемента контенту, досить довгі, щоб дозволити виконувати в них фонову обробку. Це можливо тому, що аспекти, що пов'язані з оригінальними командами виконання фонової обробки, можуть бути зміщені у часі відносно до обробки, яка забезпечує презентацію елемента контенту. Відповідно до сьомого аспекту винаходу, надається спосіб перетворення оригінальної командної послідовності у оптимізовану командну послідовність, який включає наступні кроки: вибір можливого параметра швидкості; оцінювання розміру індивідуальних командних компонент для можливого параметра швидкості; спроба розподілити індивідуальні командні компоненти в об'ємі командної послідовності таким чином, щоб частини об'єму командної послідовності, які очікуються для виконання індивідуальних компонент завантаження оптимізованої командної послідовності не перекривались; та позначення можливого параметра швидкості як вдалого параметра швидкості, якщо індивідуальні командні компоненти можна розподілити в об'ємі командні послідовності без перекриття. Взагалі, розмір це оцінка часу, необхідного для виконання командних компонентів. Або це об'єм пам'яті, який займуть компоненти команди, наприклад, у байтах. Загалом, вдалий параметр швидкості може бути попереднім параметром швидкості, який буде замінений іншим параметром швидкості, визначеним пізніше. Взагалі, розподіл індивідуальних командних компонентів означає визначення порядку і/або розкладу індивідуальних командних компонентів. Загалом, об'єм командної послідовності знаходиться у часовій області. Або це може бути в області довжини команди. 6 UA 104034 C2 5 10 15 20 25 30 Зараз буде описано варіант винаходу, тільки як приклад, з посиланнями на супровідні рисунки, на яких: Фіг. 1 відображує систему клієнт-сервер; та Фіг. 2 відображає сервер насичених мультимедійних даних. Фіг. 1 описана вище. У реалізації винаходу, сервер насичених медіа даних 102 та клієнт насичених медіа даних 104 модифіковані відповідно до винаходу, як описано далі. Відповідно, на фіг. 2 показаний сервер насичених медіа даних 200, який містить блок перетворення 202, який приймає оригінальні команди, блок оптимізації 203, який має ітераційний суб-блок оптимізації 204, суб-блок оцінки затрат 205, та суб-блок підпрограми 206, а також сховище 208 для зберігання оптимізованих субкоманд. Зараз буде описаний спосіб оптимізації планування відповідно до варіанту винаходу. Для того, щоб виконати оптимізацію відповідно до цього винаходу, необхідно розділити (або перетворити) команду оригінального кадрового дескриптора на субчастини за допомогою блоку перетворення 202: - Підготовча субкоманда, яка має виконуватися перед моментом, вказаним у розкладі, у який починається виконання оригінальної команди. Це не суворо обмежена у часі субкоманда, через це її час виконання можна переміщувати (у відповідних обмеженнях, які будуть пояснені далі). - Вчасна субкоманда, яка повинна виконуватись у зазначений розкладом час, у який має починатися виконання оригінальної команди. Це суворо обмежена у часі субкоманда, у якої час початку виконання фіксований, вона обмежена конкретним часом розкладу, наприклад, тому, що вона створює візуальний або звуковий ефект, який може спостерігати користувач пристрою, і затримку такого ефекту можна помітити. Взагалі, відповідні підготовчі субкоманди, пов'язані з двома оригінальними командами, повинні виконуватись у такому ж порядку, як і дві оригінальні команди через те, що у деяких випадках виконання однієї підготовчої субкоманди потребує результату виконання більш ранньої підготовчої субкоманди. Підготовчі підкоманди загалом потребують більше часу для виконання, ніж вчасні субкоманди. Приклади оригінальних команд та субкоманд, у які вони можуть бути перетворені, показані у таблиці, наведеній нижче. Таблиця Оригінальні команди Вставка Заміна (елемента) Підготовчі підкоманди Вставити такий самий елемент у () елемент SVG групи. Він повинен мати автоматично згенерований унікальний ідентифікатор та його атрибут видимості має бути "схований". Вставити заміщуючий елемент (дочірній елемент оригінальної команди) у елемент SVG групи, як новий дочірній елемент від батьківського заміненого вузла. Елемент SVG групи має бути схованим та мати згенерований ідентифікатор, так само як і у випадку команди Вставити (Insert). Вчасні команди Коментарі Замінити атрибут видимості SVG групи, доданої під час підготовки на "видимий". 1) Видалити замінений елемент. 2) Замінити атрибут видимості SVG групи, доданої під час підготовки, на "видимий". 7 Підготовча команда потребує посилання на батьківський елемент заміненого вузла. Один шлях отримання його полягає у додаванні елемента SVG групи над кожним елементом з атрибутом ідентифікатора в кожній кадровій команді. Інший шлях полягає у вставці скрипта, у якому батьківський вузол є доступним за допомогою стандартної функції АРІ. UA 104034 C2 Продовження таблиці Новий Кадр Всі інші кадрові команди (за винятком Відновлення Кадру, (RefreshScen)) 5 10 15 20 25 30 35 40 1) Тільки для першої команди Новий Кадр (New Scene): установити пустий кореневий елемент (SVG групи) як Новий Кадр. 2) Вставити новий кадр у схований елемент SVG групи у кореневий SVG вузол. 1) Видалити стару кадрову групу, якщо існує. 2) Замінити атрибут видимості нової кадрової SVG групи на "видимий". Нові кадри можуть розглядатися як команда Заміна (Replace) для всього кадру. Оригінальна команда Інші кадрові команди не перетворюються. Вони не мають дочірніх вузлів (які можуть містити вкладені графічні дані), тому вони відносно малі. Вони можуть виконуватися відносно швидко. Взагалі під час оптимізації субкоманди перевіряються у суб-блоці оцінки затрат 205 для того, щоб визначити їх затрати у показниках ресурсів пристрою, який буде їх виконувати. Ця командна оцінка витрат використовує функцію витрат, яка базується на багатьох факторах, таких як розмір команди у байтах, тип команди і т.д. Це, фактично, є вимірюванням складності команд. В одному варіанті винаходу функція затрат береться як максимальне значення, яке базується на зважених значеннях розміру команди у байтах та очікуваного часового періоду виконання, розрахованого на основі типу команди та складності дочірніх вузлів (якщо вони є). Вагові коефіцієнти застосовуються в залежності від відносної важливості для управління системою виходячи з розміру команди та можливості обробки. Приймаючи до облікового запису затрату команди, та обмеження, обумовлені часовими інтервалами згідно розкладу команд, які мають бути виконані, сервер насичених медіа даних 102 виконує пошук швидкісної характеристики для визначення її рівня (або більш точно смуги), при якому (в якій) набору субкоманд надаються уточнені часові інтервали згідно розкладу та потенційна зміна порядку для вдалого виконання, це все, що може виконатись для набору субкоманд в оригінальному розкладі. Швидкісна характеристика може бути швидкістю роботи процесора ЦПБ або смугою пропускання при завантаженні (або бітовою швидкістю) пристрою, який буде виконувати набір команд. У широкому сенсі, для кожної команди, командна оцінка затрат ділиться на швидкісну характеристику для надання часового інтервалу, який використовується сервером для планування команди. Це загальне визначення буде пояснене у показниках варіанту винаходу, у якому працює спосіб оптимізації планування команд кадрового дескриптора команд працює відповідно до ітераційного способу (кроки і - iv). Підпрограма налаштування розкладу використовується для визначення порядку, у якому мають виконуватися субкоманди. Підпрограма налаштування розкладу описується після описання ітераційного способу. Ітераційний спосіб включає наступні ітераційні кроки: і. Обирається довільне початкове значення швидкості. Це може бути встановлено алгоритмом оцінювання, який виконує, наприклад, ділення загальних затрат всіх оцінок затрат субкоманд на загальну довжину оптимізованого часового періоду, який відповідає загальній тривалості медіа даних. У випадку потоку в реальному масштабі часу оптимізація може бути застосована до частин потоку, у цьому випадку оптимізованим часовим періодом є довжина будь-якої однієї окремої частини. Результат, отриманий після виконання алгоритму оцінювання, потім множиться на емпіричну константу (що була згенерована базуючись на попередній статистиці, наприклад, при виконанні тестових запусків способу оптимізації). У цілях пояснення винаходу, у цьому варіанті, значення швидкості представлене як здатність швидкості обробки процесора приймального пристрою. Потім субкоманди плануються відповідно до підпрограми налаштування розкладу, яка описана далі, для вибраного значення швидкості. Результатом застосування підпрограми налаштування розкладу можуть бути два альтернативні результати (далі А та В): іі (а). (Результат А) Якщо підпрограма налаштування розкладу визначає у розкладі субкоманд, що вони можуть виконатися своєчасно при обраному значенні швидкості (значення 8 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 швидкості відмічається як "успішне"), то значення швидкості ділиться навпіл і після цього субкоманди знову плануються підпрограмою налаштування розкладу, і знову перевіряється, чи можуть субкоманди бути виконані своєчасно. Після перевірки кожного "успішного" значення швидкості ділення навпіл відбувається доти, доки підпрограма налаштування розкладу не відмітить, що своєчасне виконання недоступне (значення швидкості відмічається як "неуспішне"). У цьому випадку останнє "успішне" значення швидкості та "неуспішне" значення швидкості беруться для визначення верхньої та нижньої межі значення швидкості. іі (b). (Результат В) Якщо підпрограма налаштування розкладу визначає у розкладі субкоманд, що вони не можуть бути виконані своєчасно при вибраному значенні швидкості (значення швидкості відмічається як "неуспішне"), то значення швидкості подвоюється і після цього субкоманди знову плануються підпрограмою налаштування розкладу, і знову перевіряється, чи можуть субкоманди бути виконані своєчасно. Якщо подвоєне значення швидкості також "неуспішне", це позначується у розкладі субкоманд, які не можуть бути виконані своєчасно при обраному значенні швидкості, значення швидкості знову подвоюється та виконується перевірка стільки разів, скільки потрібно, поки підпрограма налаштування розкладу не відмітить, що своєчасне виконання можливе (значення швидкості відмічається як "успішне"). У цьому випадку останнє "неуспішне" значення швидкості та "успішне" значення швидкості беруться для визначення нижньої та верхньої межі значення швидкості. ііі. Цей крок застосовується до нижньої і верхньої меж, отриманих на кроці іі (а) або кроці іі (b). Підпрограма налаштування розкладу використовується для планування розкладу команд з середніми значеннями швидкості між нижньою та верхньою межами. Якщо все пройшло успішно, то це середнє значення обирається як нова верхня межа. Якщо все пройшло неуспішно, то це середнє значення обирається як нова нижня межа. Цей крок повторюється ітераційно, поки різниця між двома межами не стане меншою, ніж попередньо визначене значення (наприклад, в одному варіанті реалізації у абсолютних показниках або в іншому варіанті реалізації винаходу у відсотках). iv. Ці ітераційні кроки визначають останню верхню межу значення швидкості, яке розглядається як мінімальне значення швидкості, при якому субкоманди, заплановані підпрограмою налаштування розкладу, можуть бути виконані успішно. Таким чином, планування, яке було визначене для цієї останньої верхньої межі значення швидкості використовується для забезпечення кінцевого розміщення команд у часі (складання розкладу) субкоманд кадрового дескриптора та їх передачі разом з цим розкладом за допомогою сервера насичених медіа даних 102 на термінальний пристрій, в який інкорпорований клієнт насичених медіа даних 104. Зараз буде описана підпрограма налаштування розкладу. Вона включає в себе дві основні частини - складання розкладу вчасних субкоманд та складання розкладу підготовчих субкоманд. Як буде зрозуміло з описання ітераційного способу, підпрограма налаштування розкладу використовується декілька разів у кроках іі (а) / (b) та ііі для того, щоб визначити останню верхню межу значення швидкості, яка використовується для забезпечення кінцевого розкладу субкоманд кадрового дескриптора, який працює з багатьма різними значеннями швидкості. Підкоманди плануються для заданого значення швидкості: або для вибраного випадкового вихідного значення швидкості, або для одного із послідовних значень швидкості отриманих ітераційним методом, описаним вище. Планування вчасних субкоманд Першим кроком є планування вчасних субкоманд у порядку від однієї, яка повинна виконуватися першою до тієї, яка повинна виконуватися останньою. Необхідно відмітити, що ці вчасні субкоманди мають часові моменти у розкладі, у які повинні починатися їх виконання (час початку виконання), які відповідають моментам початку виконання оригінальних команд. Через це, часовий період, необхідний для виконання попередньої вчасної субкоманди, не повинен бути настільки довгими, щоб її виконання перекривалося у часі з часом початку виконання наступної вчасної субкоманди. Це накладає обмеження на планування вчасних субкоманд. Одначе, підготовчі субкоманди не настільки обмежені і можуть плануватися у будь-який зручний спосіб, щоб потрапити у доступні часові періоди, у які вони можуть виконуватись так довго, щоб не переривати підготовку кадру для презентації. Вчасні субкоманди можуть розглядатися як каркас набору субкоманд, які виконуються разом для генерації кадру. Зараз буде описаний приклад, у якому є чотири команди, які, як описано вище, перетворюються на чотири підготовчі субкоманди та чотири вчасні субкоманди. Розміри всіх вчасних субкоманд оцінюють для визначення відповідних оцінок затрат субкоманди, які потім ділять на задане значення швидкості для оцінки часових періодів, необхідних для виконання кожної з вчасних підкоманд, вказаних як періоди виконання, після 9 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 чого ці періоди виконання зберігаються. Потім визначають, чи період виконання, необхідний для виконання першої вчасної субкоманди, який триває від старту виконання першої вчасної субкоманди перекриває час старту виконання другої вчасної субкоманди. Якщо період виконання настільки короткий, що перекривання відсутнє (це значить, що це так званий "позитивний часовий період"), підпрограма налаштування розкладу може продовжувати. Якщо ж період виконання дуже довгий і присутнє перекривання (це значить, що це так званий "негативний часовий період"), підпрограма налаштування розкладу вважається невдалою, і значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод у кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається. У випадку, коли підпрограма налаштування розкладу не вважається невдалою при плануванні першої вчасної субкоманди, то потім визначається, чи період виконання необхідний для виконання другої вчасної субкоманди, який триває від старту виконання другої вчасної субкоманди перекриває час старту виконання третьої вчасної субкоманди. Якщо період виконання настільки короткий, що перекривання відсутнє, підпрограма налаштування розкладу може продовжувати. Якщо ж період виконання дуже довгий і присутнє перекривання, підпрограма налаштування розкладу вважається невдалою, і значення швидкості вважається "неуспішним". У цьому випадку ітераційний метод у кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається. Якщо підпрограма налаштування розкладу була вдалою при плануванні другої вчасної субкоманди, то потім визначається, чи період виконання, необхідний для виконання третьої вчасної субкоманди, який триває від старту виконання третьої вчасної субкоманди, перекриває час старту виконання четвертої вчасної субкоманди. Якщо період виконання настільки короткий, що перекривання відсутнє, підпрограма налаштування розкладу може продовжувати. Якщо ж період виконання дуже довгий і присутнє перекривання, підпрограма налаштування розкладу вважається невдалою, і значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод у кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається. Щодо планування четвертої вчасної субкоманди: якщо визначений момент часу, у який вона має виконуватися, то вона може бути спланована у такий самий спосіб, який використовувався для попередніх вчасних субкоманд. Якщо ж немає такого визначеного моменту часу, то у цьому випадку вона має бути спланована відповідно до оригінальних команд. Якщо в результаті підпрограми налаштування розкладу були вдало оброблені всі вчасні субкоманди, то цим субкомандам призначаються оригінальні сплановані моменти часу, періоди виконання для виконання кожної з них і значення швидкості, при якому вчасні субкоманди можуть бути вдало сплановані. Планування підготовчих субкоманд Спланувавши вчасні субкоманди, підпрограма налаштування розкладу тепер починає планування підготовчих субкоманд. У цьому місці підпрограми налаштування розкладу є значення швидкості (або вибране випадкове вихідне значення, або ж значення, обране ітераційно за допомогою ітераційного методу). Позитивні часові періоди між оцінюваним закінченням вчасної субкоманди та початком наступної вчасної субкоманди ідентифіковані. Кожен з цих позитивних часових періодів називається "інтервал" або "слот". Таким чином, у цьому прикладі є чотири вчасні субкоманди і відповідно чотири інтервали: другий, третій та четвертий, між першою та другою, другою та третьою, і третьою та четвертою вчасними субкомандами відповідно; перший інтервал розташований між вихідним нульовим значенням часу та першою вчасною субкомандою. Необхідно відмітити, що підготовчі субкоманди починаються при наявності оригінального порядку, який відповідає порядку відповідних їм вчасних субкоманд (це послідовність першої підготовчої субкоманди, другої підготовчої субкоманди, третьої підготовчої субкоманди та четвертої підготовчої субкоманди). Очікується, що у деяких випадках буде виникати залежність між n-ю та n+1-ю підготовчими субкомандами, наприклад, якщо обробка n-ї підготовчої субкоманди випереджає результат обробки, наприклад, графічного елемента, який необхідний для використання у n+1-й підготовчій n субкоманді. У цьому випадку, підпрограма налаштування розкладу конфігурується для підтримки порядку підготовчих субкоманд. У бажаному варіанті реалізацій винаходу спочатку призначають підготовчі субкоманди інтервалам, у зворотному порядку починаючи з тієї, яка має виконуватися найпізніше у часі, і закінчуючи тією, яка має виконуватися найпершою у часі, на основі оригінального спланованого порядку, а потім у порядку інтервалів: від найпізнішого до найбільш раннього на основі актуального хронологічного порядку. У цьому випадку, підготовчі субкоманди настільки близькі 10 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 до відповідних їм вчасних субкоманд, наскільки це можливо (якщо є декілька можливих розкладів), що надає кращу підтримку для випадкового доступу. Для того, щоб зробити це, оцінюють розміри всіх підготовчих субкоманд для визначення відповідних оцінок затрат субкоманд, які потім ділять на задане значення швидкості для оцінки періодів виконання, необхідних для виконання кожної з підготовчих субкоманд, після чого ці періоди виконання зберігаються. Потім період виконання, необхідний для виконання останньої підготовчої субкоманди, порівнюється з розміром останнього (четвертого) інтервалу між третьою та четвертою вчасною субкомандами. Якщо інтервал достатньо великий для забезпечення підготовчої субкоманди, то вона розміщується в цьому інтервалі. Якщо ні, то період виконання, необхідний для виконання останньої підготовчої субкоманди, порівнюється з розміром третього інтервалу. Якщо інтервал достатньо великий для забезпечення підготовчої субкоманди, то вона розміщується в цьому інтервалі. Якщо ні, то період виконання, необхідний для виконання останньої підготовчої субкоманди, порівнюється з розміром другого інтервалу. Якщо інтервал достатньо великий для забезпечення підготовчої субкоманди, то вона розміщується в цьому інтервалі. Якщо ні, то період виконання, необхідний для виконання останньої підготовчої субкоманди порівнюється з розміром першого інтервалу. Це час, доступний перед початком першої команди. Інакше кажучи, це період виконання від вихідного нульового значення часу (початку потоку або оптимізованого періоду) до часу старту виконання першої вчасної команди. Якщо остання підготовча субкоманда може розміститися в одному з інтервалів, то підпрограма налаштування розкладу вважається вдалою відносно цієї підготовчої субкоманди, і починається планування безпосередньо попередньої підготовчої субкоманди. Якщо ж остання підготовча субкоманда була занадто великою для того, щоб вміститися у будь-який інтервал, підпрограма налаштування розкладу вважається невдалою, а значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод на кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається з початку, намагаючись запланувати першу з вчасних субкоманд. Якщо планування останньої підготовчої субкоманди було успішним, період виконання необхідний для обробки третьої підготовчої субкоманди порівнюється з розміром третього інтервалу або, якщо остання підготовча субкоманда була розміщена у більш ранньому інтервалі, з цим більш раннім інтервалом. В іншому випадку, якщо розміщення третьої підготовчої субкоманди прийняте в інтервал, який вже зайнятий останньою підготовчою субкомандою, то період виконання, необхідний для обробки третьої підготовчої субкоманди, порівнюється з розміром доступного часу в інтервалі, який дорівнює розміру інтервалу мінус час виконання останньої підготовчої субкоманди. Якщо остання підготовча субкоманда фактично була розміщена в четвертому інтервалі, то період виконання третьої підготовчої субкоманди просто порівнюється з розміром третього інтервалу. Якщо доступний час інтервалу (чи це незайнятий останньою підготовчою субкомандою третій інтервал, чи третій інтервал зайнятий останньою підготовчою субкомандою, або більш ранній інтервал, зайнятий останньою підготовчою субкомандою) достатньо великий для розміщення третьої підготовчої субкоманди, то вона розміщується в цьому інтервалі. Якщо ж ні, то період виконання, необхідний для обробки третьої підготовчої субкоманди порівнюється, у свою чергу, з розміром (розмірами) будь-якого попереднього інтервалу (інтервалів), поки не знайдеться такий, що достатньо великий для розміщення третьої підготовчої субкоманди. Якщо такий інтервал знайдено, то третя підготовча субкоманда розміщується у цьому інтервалі і підпрограма налаштування розкладу вважається вдалою відносно третої підготовчої субкоманди, і починається планування безпосередньо попередньої підготовчої субкоманди. Якщо ж третя підготовча субкоманда була достатньо великою для того, щоб вміститися у будь-який інтервал, підпрограма налаштування розкладу вважається невдалою, а значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод у кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається з початку, намагаючись запланувати першу з вчасних субкоманд. Якщо планування третьої підготовчої субкоманди було успішним, період виконання, необхідний для обробки другої підготовчої субкоманди порівнюється з розміром другого інтервалу або з першим інтервалом, якщо третя підготовча субкоманда розміщена у цьому інтервалі. В іншому випадку, якщо була спроба розміщення другої підготовчої субкоманди у інтервал, вже зайнятий третьою підготовчою субкомандою, то період виконання, необхідний для обробки другої підготовчої субкоманди порівнюється з розміром доступного місця в інтервалі, який дорівнює розміру інтервалу мінус час виконання третьої підготовчої субкоманди. Може статись так, що третя та остання підготовчі субкоманди розміщені в одному інтервалі, тоді 11 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 доступне місце в інтервалі дорівнює розміру інтервалу мінус час виконання третьої підготовчої субкоманди і мінус час виконання останньої підготовчої субкоманди. Якщо третя підготовча субкоманда фактично була розміщена у третьому інтервалі, то період виконання другої підготовчої субкоманди просто порівнюється з розміром другого інтервалу. Якщо доступне місце інтервалу, у який планується третя підготовча субкоманда, (чи це другий інтервал, не зайнятий третьою підготовчою субкомандою, другий інтервал, зайнятий третьою підготовчою субкомандою, але не останньою підготовчою субкомандою, другий інтервал, зайнятий третьою та останньою підготовчими субкомандами, перший інтервал, зайнятий третьою підготовчою субкомандою, але не останньою підготовчою субкомандою, або перший інтервал, зайнятий третьою та останньою підготовчими субкомандами) достатньо велике для розміщення другої підготовчої субкоманди, то вона розміщується в цьому інтервалі. Якщо ж ні і/або, якщо перший інтервал не зайнятий будь-якою підготовчою субкомандою, то період виконання, необхідний для обробки другої підготовчої субкоманди, порівнюється з розміром першого інтервалу, не зайнятого третьою підготовчою субкомандою. Якщо доступне місце першого інтервалу достатньо велике, щоб вмістити другу підготовчу субкоманду, вона розміщується в цьому інтервалі. Якщо ж друга підготовча субкоманда була достатньо великою для того, щоб вміститися у будь-який інтервал, виконання підпрограми налаштування розкладу вважається невдалим, а значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод у кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається з початку, намагаючись запланувати вчасні субкоманди. Якщо планування другої підготовчої субкоманди було вдалим, то період виконання, необхідний для обробки першої підготовчої субкоманди порівнюється з розміром першого інтервалу. Може статись так, що друга та наступна або наступні підготовчі субкоманди розміщуються у першому інтервалі, у цьому випадку, період виконання, необхідний для обробки першої підготовчої субкоманди порівнюється з розміром доступного місця у інтервалі, який визначається як розмір першого інтервалу мінус час (часи) виконання другої та будь-яких іншої (інших) підготовчої субкоманди (субкоманд). Якщо у першому інтервалі достатньо місця, щоб вмістити першу підготовчу субкоманду, то вона розміщується у цьому інтервалі, тоді підпрограма налаштування розкладу вдало розміщує всі субкоманди і ітераційний метод продовжується. Якщо ж у першому інтервалі немає достатньо місця, щоб вмістити першу підготовчу субкоманду, підпрограма налаштування розкладу вважається завершеною невдало, а значення швидкості вважається "неуспішним". У цьому випадку, ітераційний метод на кроці іі (b) обирає більше значення швидкості, а підпрограма налаштування розкладу перезапускається з початку, намагаючись запланувати вчасні субкоманди. Для кожної вдало розміщеної підготовчої субкоманди, розраховується відповідний запланований час старту виконання, який базується на запланованому часі старту попередньої вчасної субкоманди та на періоді виконання цієї вчасної субкоманди, і цей час старту виконання зберігається. У випадку, коли багато підготовчих субкоманд розміщуються у одному інтервалі, розрахунок часів старту виконання також має враховувати будь-які попередні підготовчі субкоманди у цьому інтервалі. Винятком для розрахунку часів старту виконання є перша підготовча субкоманда, якій задається нульовий час старту виконання. Якщо в результаті роботи підпрограми налаштування розкладу всі підготовчі субкоманди оброблені вдало, то цим субкомандам присвоюються нові часи планування старту виконання, періоди виконання, необхідні для обробки кожної з них, та значення швидкості, при якій можуть бути успішно сплановані вчасні субкоманди. Необхідно відмітити, що часовий період від очікуваного закінчення однієї вчасної субкоманди і до часу старту виконання наступної субкоманди також може бути нульовим або практично нульовим, у розумінні, що це дуже малий часовий період для виконання будь-якої підготовчої субкоманди, яка має виконуватись. Для того, щоб попередити виконання непотрібної обробки, не робляться спроби спланувати підготовчі субкоманди в інтервали, які мають менший розмір, ніж мінімальний поріг. Таким чином, буде зрозуміло, що підготовчі субкоманди розміщуються відповідно до наступних принципів: (і) підготовча субкоманда передує відповідній їй вчасній субкоманді; (іі) підготовчій субкоманді не потрібне безпосереднє пере дування відповідній їй вчасній субкоманді; (ііі) один і той же інтервал може займати більше, ніж одна підготовча субкоманда; та (iv) не всі інтервали мають бути зайнятими. 12 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 Для цього варіанту реалізації винаходу, є додатковий принцип (v), який полягає у тому, що підтримується порядок підготовчих субкоманд. Як тільки виконана оптимізація субкоманд, надлишкові випадкові точки доступу (наприклад, команди Відновлення Кадру, RefreshScene) перераховуються/оновлюються. Також встановлено, що першим кроком у їх плануванні є автоматичне порівняння періоду виконання, необхідного для обробки n-ї підготовчої субкоманди, з розміром n-го інтервалу (або більш раннього інтервалу, якщо пізніша підготовча субкоманда уже розміщена в ньому), це застосовується у випадку, коли є залежність між підготовчими субкомандами. У випадку, коли немає залежності між підготовчими субкомандами, підготовчі субкоманди можуть оптимізуватися так, що результатом буде оптимізований порядок, який відрізняється від початкового порядку підготовчих субкоманд (або порядку відповідних їм вчасних субкоманд). У цьому випадку, розміщення підготовчих субкоманд у інтервалах досі проводиться у зворотному порядку підготовчих субкоманд починаючи з тієї, яка має бути виконана останньою за часом, до тієї, яка має бути виконана найраніше за часом згідно початкового порядку. Одначе, вони можуть бути вільно розміщені у інтервалах так, щоб всі вони вмістились при найнижчому значенні швидкості за умови, що всі підготовчі субкоманди розміщені в інтервалах, які передують їх відповідним вчасним субкомандам. Як вказано вище, порівняння підготовчих субкоманд та інтервалів здійснюється в часовій області, порівнянням періоду часу, необхідного для обробки підготовчої субкоманди, з розміром інтервалу на основі її тривалості у часі або періоду часу. Одначе, є можливість виконувати такі порівняння в інших областях, наприклад, у області, для якої затрати оцінюються на основі розміру підготовчих субкоманд та інтервалів на основі байтів. Це може бути зроблено з метою зручності обробки. Якщо такий альтернативний підхід прийнятий, то підготовчі субкоманди та інтервали конвертуються у відповідну область будь-яким способом, який наведений тут або є загальновідомим. Під час виконання способу оптимізації можуть виконуватись різні розрахунки та порівняння у різних областях. Не є необхідним використання однієї і тієї ж області протягом усього способу. Замість розрахунку періодів виконання, необхідних для обробки всіх субкоманд на початку планування для такого типу субкоманд, такі розрахунки можуть бути виконані окремо для надання періодів виконання, необхідних для обробки окремої підготовчої субкоманди безпосередньо перед виконанням її планування. Потім, згідно застосування способу оптимізації, команди посилаються з сервера насичених медіа даних 102 на клієнт насичених медіа даних 104, наприклад, запуск на термінальному пристрої, на якому команди виконуються для того, щоб відобразити контент за допомогою інтерфейсу користувача термінального пристрою. (Необхідно розуміти, що термін відображення означає як візуальну так і звукову презентацію). Оптимізація розкладу означає, що команди мають покращену можливість бути обробленими на приймальному пристрої так, щоб результатом виконання команд у кадрі було візуальне і/або звукове відтворення на пристрої з обмеженими ресурсами. Клієнт насичених медіа даних 104 модифікується так, що він має здатність розпізнавати та обробляти вчасні та підготовчі субкоманди. Одначе, в іншому варіанті реалізації винаходу, якщо оптимізація відбувалася на сервері, а відомий клієнт насичених медіа даних 104 працює з субкомандами, які він вже здатний обробляти, то його не потрібно модифікувати. Також були описані варіанти реалізації винаходу, в яких команди трансформуються у субкоманди першого типу, які мають виконуватися відповідно до оригінального командного розкладу, але це не обов'язково означає, що виконання субкоманди першого типу повинне починатися у однаковий час з відповідною оригінальною командою. Наприклад, якщо команда заміни перетворена на анімаційну команду з двома станами, у якій у певний момент часу перший графічний елемент змінюється другим графічним елементом, відповідність до оригінального розкладу пов'язана зі змінами першого графічного елемента на другий графічний елемент, а не з точкою старту виконання анімаційної команди. Крім того, це показує іншу властивість винаходу - субкоманда другого типу відповідає вставці анімаційної команди, а субкоманда першого типу відповідає її активації. У цьому сенсі субкоманди не є окремими і чітко вираженими командами, але одна, фактично, є операцією, що виконується над іншою. Спосіб, описаний для застосування для планування команд кадрового дескриптора на сервері насичених медіа даних, також може застосовуватись у будь-якій ситуації, де необхідно виконати послідовності команд у рамках часового розкладу. У варіанті реалізації винаходу, описаному вище, кадровими командами є ті, що визначаються специфікацією MPEG-LASeR. Одначе винахід не обмежується кадровими командами саме такого типу. 13 UA 104034 C2 5 10 15 20 25 30 35 Хоч є посилання на сервер, який виконує різні кроки способу, винахід не обмежений такою властивістю і деякі або всі кроки способу можуть виконуватися іншим пристроєм, а не сервером. Може бути такий випадок, коли кроки способу виконуються в іншому місці, а сервер лише отримує команди, які мають оптимізований розклад, так, що він може посилати їх на приймальний пристрій. Наприклад, оптимізація може застосовуватися на будь-якому кроці обробки насиченого медіа контенту, включаючи: - вбудовану у засоби розробки, які генерують вхідні дані для сервера насичених медіа даних; та - автономний інструмент оптимізації для обробки насиченого медіа контенту. В іншому варіанті реалізації винаходу оптимізація виконується здатністю вбудування у клієнт насичених медіа даних. У цьому випадку оптимізація використовується тільки для часових періодів, які обробляються, а не для запобігання сплескам трафіку. Це може виконуватись з використанням відомих технологій, наприклад, буферизації. Цей винахід має можливість трансформувати описання кадрів у модифіковане описання кадрів у такий спосіб, що: - Ефекти контенту (візуальні і/або звукові) з результуючим описанням кадрів це теж саме, що і з оригінальним описанням кадрів (що може розглядатися як "оптимізація без втрат"), або різниця між ефектами результуючого кадрового описання та оригінальними кадровими описаннями менша, ніж визначена границя (що може відноситись до "оптимізації з втратами"); та - Трафік, згенерований потоковою передачею і/або здатністю обробки, необхідної для виконання результуючого описання кадрів краще розподіляється у часі. У випадку "оптимізації з втратами" вчасні субкоманди можуть плануватися для відтворення відповідно до розкладу, який незначно відрізняється від розкладу оригінальних команд, але не відхиляється настільки, щоб це спричиняло незручності для користувача. Використання такої незначної зміни розкладу може надати змогу оптимізувати субкоманди для меншого значення швидкості, ніж в іншому випадку. В доповнення винаходу, у випадку, коли багато підготовчих субкоманд займають один і той самий інтервал, частини інтервалу, присвоєні відповідним підготовчим субкомандам, визначаються їх відповідними оцінками затрат. Підготовчим субкомандам з великими оцінками затрат призначається більша частина інтервалу. Звичайно, кожна підготовча субкоманда повинна мати в інтервалі період часу, який, як мінімум, дорівнює періоду її виконання. Субкоманди, розглянуті вище, наведені лише з метою ілюстрації винаходу. Інші команди є під командами, які можуть використовуватися, наприклад, команда видалення трансформується у приховану вчасну субкоманду та пост-обробну субкоманду видалення. Наведені вище варіанти реалізації винаходу були показані та описані тільки для прикладу. Численні варіанти, зміни та заміни можуть виникати у спеціалістів в даній області без виходу за рамки цього винаходу. Відповідно, наступна формула винаходу призначена для врахування всіх таких варіантів або еквівалентів, які знаходяться в межах змісту та рамок винаходу. 40 ФОРМУЛА ВИНАХОДУ 45 50 55 60 1. Спосіб модифікування командної послідовності, яка включає множину команд, команди мають розклад, за яким вони мають виконуватись, який включає такі кроки: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватись відповідно до розкладу, та у субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; і налаштування порядку субкомандних компонент так, щоб очікувані періоди, під час яких виконують субкомандні компоненти другого типу, не перекривались з періодами, під час яких виконують субкомандні компоненти першого типу, крім того, при налаштуванні вибирають випадковий можливий параметр швидкості та здійснюють спробу запланувати за розкладом субкомандні компоненти відповідно до підпрограми налаштування розкладу для вибраного параметра швидкості, причому планування субкомандних компонентів здійснюють з різними значеннями параметра швидкості для того, щоб визначити параметр робочої швидкості, який має найнижче можливе значення, при якому очікується, що субкомандні компоненти будуть оброблені коректно. 2. Спосіб за п. 1, за яким субкомандні компоненти другого типу планують до виконання раніше розкладу, за яким відповідний їм субкомандний компонент першого типу повинен виконуватися. 3. Спосіб за п. 1 чи п. 2, за яким субкомандний компонент другого типу планують до виконання раніше розкладу, за яким повинен виконуватися інший субкомандний компонент першого типу, 14 UA 104034 C2 5 10 15 20 25 30 35 40 45 50 55 60 який передує відповідному субкомандному компоненту першого типу так, що планують щонайменше один проміжний субкомандний компонент, запланований до виконання між субкомандним компонентом другого типу та відповідним йому субкомандним компонентом першого типу. 4. Спосіб за будь-яким попереднім пунктом, за яким субкомандні компоненти першого типу мають обмеження у часі, у якому виконання відповідно до розкладу співвідносять до події, поява якої є помітною користувачеві термінального пристрою або має матеріальний ефект для спостерігача. 5. Спосіб за будь-яким попереднім пунктом, за яким оцінюють відповідні витрати на виконання субкомандних компонент і визначають, чи є доступні інтервали в загальному ресурсі, зайнятому субкомандними компонентами першого типу, які є достатньо великими з тим, щоб субкомандні компоненти другого типу мали можливість виконуватися в них. 6. Спосіб за п. 5, за яким субкомандний компонент другого типу розміщують у тому ж інтервалі, що і один або більше інших субкомандних компонентів другого типу, якщо є місце для розміщення їх обох або всіх. 7. Спосіб за будь-яким попереднім пунктом, за яким відповідні витрати на виконання субкомандних компонентів використовують для генерування часових періодів, що базуються на можливих параметрах швидкості. 8. Спосіб за будь-яким попереднім пунктом, за яким спочатку планують субкомандні компоненти першого типу, після чого планують субкомандні компоненти другого типу. 9. Спосіб за будь-яким попереднім пунктом, за яким субкомандні компоненти першого типу планують у порядку, починаючи з того, який повинен виконуватися першим, і закінчуючи тим, який має виконуватися останнім. 10. Спосіб за будь-яким попереднім пунктом, за яким субкомандні компоненти другого типу планують у зворотному порядку, починаючи з того, який має виконуватися останнім, і закінчуючи тим, який має виконуватися першим. 11. Спосіб за будь-яким попереднім пунктом, який включає генерування додаткового розкладу, за яким повинні виконуватись субкомандні компоненти другого типу. 12. Спосіб, за будь-яким попереднім пунктом, у якому команди відносять до опису кадрів. 13. Спосіб за будь-яким попереднім пунктом, за яким субкоманди оптимізують для їх підготовки з потокової передачі з передавального пристрою до приймального пристрою. 14. Система для модифікування та передачі командної послідовності, яка містить множину команд, що мають розклад, за яким вони повинні виконуватися, система включає сервер та приймальний пристрій, причому сервер виконаний з можливістю: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватися за розкладом, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; налаштування порядку субкомандних компонентів таким чином, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекривались з періодами, під час яких виконуються субкомандні компоненти першого типу; крім того, налаштування включає вибір випадкового можливого параметра швидкості та спробу запланувати за розкладом субкомандні компоненти відповідно до підпрограми налаштування розкладу для вибраного параметра швидкості, а планування субкомандних компонентів здійснено з різними значеннями параметра швидкості для того, щоб визначити параметр робочої швидкості, який має найнижче можливе значення, при якому очікується, що субкомандні компоненти будуть обробленими коректно; та передавання субкомандних компонентів першого та другого типів, а приймальний пристрій виконаний з можливістю: прийому субкомандних компонентів першого та другого типів; та виконання субкомандних компонентів першого та другого типів без щонайменш одного перекривання між виконанням субкомандних компонентів першого та другого типів. 15. Сервер для модифікування командної послідовності, яка містить множину команд, що мають розклад, за яким вони повинні виконуватися, причому сервер виконаний з можливістю: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватися відповідно до розкладу, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; і налаштування порядку субкомандних компонентів таким чином, щоб очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекривались з періодами, під час яких виконують субкомандні компоненти першого типу, крім того, налаштування включає вибір випадкового можливого параметра швидкості та спробу запланувати за розкладом субкомандні компоненти відповідно до субпрограми налаштування розкладу для вибраного параметра 15 UA 104034 C2 5 10 15 20 25 30 швидкості, а планування субкомандних компонентів здійснено з різними значеннями параметра швидкості для того, щоб визначити параметр робочої швидкості, який має найнижче можливе значення, при якому очікується, що субкомандні компоненти будуть обробленими коректно. 16. Термінальний пристрій, який виконаний з можливістю: прийому модифікованої командної послідовності, яка містить множину субкомандних компонентів, які, будучи представлені як оригінальні команди, що мають розклад, за яким вони повинні виконуватися, перетворені на субкомандні компоненти першого типу, що повинні виконуватися відповідно до розкладу, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом, причому порядок субкомандних компонентів налаштовано так, що очікувані періоди, під час яких виконуються субкомандні компоненти другого типу, не перекриваються з періодами, під час яких виконуються субкомандні компоненти першого типу, крім того, налаштування містить вибір випадкового можливого параметра швидкості та спробу запланувати за розкладом субкомандні компоненти відповідно до підпрограми налаштування розкладу для вибраного параметра швидкості, а планування субкомандних компонентів здійснено з різними значеннями параметра швидкості для того, щоб визначити параметр робочої швидкості, який має найнижче можливе значення, при якому очікується, що субкомандні компоненти будуть обробленими коректно; та виконання субкомандних компонентів першого та другого типів без щонайменше одного перекривання між виконаннями субкомандних компонентів субкоманд першого та другого типів. 17. Машиночитаний носій інформації, який містить код програмного забезпечення, розміщений в ньому, для модифікування командної послідовності і виконання наступних операцій: перетворення команд у субкомандні компоненти першого типу, які повинні виконуватися відповідно до розкладу, та субкомандні компоненти другого типу, які не обмежені виконанням за розкладом; та налаштування порядку субкомандних компонентів таким чином, щоб очікувані періоди, під час яких виконують субкомандні компоненти другого типу, не перекривалися з періодами, під час яких виконуються субкомандні компоненти першого типу, крім того, таке налаштування містить вибір випадкового можливого параметра швидкості та спробу запланувати за розкладом субкомандні компоненти відповідно до підпрограми налаштування розкладу для вибраного параметра швидкості, а планування субкомандних компонентів здійснено з різними значеннями параметра швидкості для того, щоб визначити параметр робочої швидкості, який має найнижче можливе значення, при якому очікується, що субкомандні компоненти будуть обробленими коректно. 16 UA 104034 C2 Комп’ютерна верстка Л. Литвиненко Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 17