Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту
Запропоновано реалізацію концепції адаптивного мовлення за допомогою сервера потокового медіа для вирішення проблеми «Останньої милі» – забезпечення достатньої швидкості передачі даних користувачу при використанні сервісів онлайн медіа трансляції....
Saved in:
| Date: | 2013 |
|---|---|
| Main Authors: | , , , , |
| Language: | Ukrainian |
| Published: |
Інститут програмних систем НАН України
2013
|
| Series: | Проблеми програмування |
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/86654 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту / О.І. Провотар, А.А. Заміховський, О.В. Галкін, М.М. Верес, Л.О. Катеринич // Проблеми програмування. — 2013. — № 1. — С. 78-84. — Бібліогр.: 5 назв. — укр. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
nasplib_isofts_kiev_ua-123456789-86654 |
|---|---|
| record_format |
dspace |
| spelling |
nasplib_isofts_kiev_ua-123456789-866542025-02-09T22:03:08Z Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту Провотар, О.І. Заміховський, А.А. Галкін, О.В. Верес, М.М. Катеринич, Л.О. Експертні та інтелектуальні інформаційні системи Запропоновано реалізацію концепції адаптивного мовлення за допомогою сервера потокового медіа для вирішення проблеми «Останньої милі» – забезпечення достатньої швидкості передачі даних користувачу при використанні сервісів онлайн медіа трансляції. 2013 Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту / О.І. Провотар, А.А. Заміховський, О.В. Галкін, М.М. Верес, Л.О. Катеринич // Проблеми програмування. — 2013. — № 1. — С. 78-84. — Бібліогр.: 5 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/86654 004.7 uk Проблеми програмування application/pdf Інститут програмних систем НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Ukrainian |
| topic |
Експертні та інтелектуальні інформаційні системи Експертні та інтелектуальні інформаційні системи |
| spellingShingle |
Експертні та інтелектуальні інформаційні системи Експертні та інтелектуальні інформаційні системи Провотар, О.І. Заміховський, А.А. Галкін, О.В. Верес, М.М. Катеринич, Л.О. Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту Проблеми програмування |
| description |
Запропоновано реалізацію концепції адаптивного мовлення за допомогою сервера потокового медіа для вирішення проблеми «Останньої милі» – забезпечення достатньої швидкості передачі даних користувачу при використанні сервісів онлайн медіа трансляції. |
| author |
Провотар, О.І. Заміховський, А.А. Галкін, О.В. Верес, М.М. Катеринич, Л.О. |
| author_facet |
Провотар, О.І. Заміховський, А.А. Галкін, О.В. Верес, М.М. Катеринич, Л.О. |
| author_sort |
Провотар, О.І. |
| title |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| title_short |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| title_full |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| title_fullStr |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| title_full_unstemmed |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| title_sort |
реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2013 |
| topic_facet |
Експертні та інтелектуальні інформаційні системи |
| url |
https://nasplib.isofts.kiev.ua/handle/123456789/86654 |
| citation_txt |
Реалізація концепції адаптивного мовлення та системи автоматичної підготовки контенту / О.І. Провотар, А.А. Заміховський, О.В. Галкін, М.М. Верес, Л.О. Катеринич // Проблеми програмування. — 2013. — № 1. — С. 78-84. — Бібліогр.: 5 назв. — укр. |
| series |
Проблеми програмування |
| work_keys_str_mv |
AT provotaroí realízacíâkoncepcííadaptivnogomovlennâtasistemiavtomatičnoípídgotovkikontentu AT zamíhovsʹkiiaa realízacíâkoncepcííadaptivnogomovlennâtasistemiavtomatičnoípídgotovkikontentu AT galkínov realízacíâkoncepcííadaptivnogomovlennâtasistemiavtomatičnoípídgotovkikontentu AT veresmm realízacíâkoncepcííadaptivnogomovlennâtasistemiavtomatičnoípídgotovkikontentu AT kateriničlo realízacíâkoncepcííadaptivnogomovlennâtasistemiavtomatičnoípídgotovkikontentu |
| first_indexed |
2025-12-01T07:08:47Z |
| last_indexed |
2025-12-01T07:08:47Z |
| _version_ |
1850288838625198080 |
| fulltext |
Експертні та інтелектуальні інформаційні системи
© О.І. Провотар, А.А. Заміховський, О.В. Галкін, М.М. Верес, Л.О. Катеринич, 2013
78 ISSN 1727-4907. Проблеми програмування. 2013. № 1
УДК 004.7
О.І. Провотар, А.А. Заміховський, О.В. Галкін, М.М. Верес, Л.О. Катеринич
РЕАЛІЗАЦІЯ КОНЦЕПЦІЇ АДАПТИВНОГО МОВЛЕННЯ ТА
СИСТЕМИ АВТОМАТИЧНОЇ ПІДГОТОВКИ КОНТЕНТУ
Запропоновано реалізацію концепції адаптивного мовлення за допомогою сервера потокового медіа для
вирішення проблеми «Останньої милі» – забезпечення достатньої швидкості передачі даних користува-
чу при використанні сервісів он-лайн медіа трансляції.
Вступ
Загальновідомим є той факт, що бі-
льшість користувачів мережі Інтернет
знають і користуються сервісами он-лайн
медіа трансляції. До найбільш популярних
можна віднести такі проекти: як YouTube
та російський аналог RuTube. Але не один
із них не враховує проблему «Останньої
милі», тобто швидкість передачі каналу
користувача фізично не дозволяє програ-
вачу відтворювати та завантажувати медіа
контент високої якості, який представле-
ний на сторінках відео сервісів. Варіанти
вирішення даної проблеми викладені в
концепції адаптивного мовлення. На від-
міну від традиційного мовлення, в процесі
відтворення контенту враховуються умови
в яких знаходиться кінцевий користувач,
тобто його поточна пропускна швидкість
мережі. Якщо швидкість з’єднання недо-
статня, то якість зображення зменшується і
навпаки, якщо є можливість перегляду
медіа кращої якості, то відбувається пере-
хід на вищу якість даних.
Існує багато варіантів реалізації те-
хнології адаптивного мовлення, однією з
цікавих є трансляція на сервері потокового
медіа двох потоків певного контенту з різ-
ними показниками якості та використання
кадрів з потоку вищої якості та нижчої у
залежності від умов на стороні клієнта [1].
Не менш цікавим є варіант трансляції кон-
тенту використовуючи кодування в реаль-
ному часі де зміна показників якості конт-
ролюється ключовим кадром, за допомо-
гою якого можливо здійснювати кодуван-
ня з будь-якої частини медіа контенту [2].
Але така можливість потребує надто бага-
то ресурсів сервера.
Існує також варіант використання
специфічного контейнера для зберігання
відеоданих у декількох потоках з можли-
востями компресії. Даний контейнер має
назву MVC (Multiview Video Coding), який
входить до набору алгоритмів H.264/AVC,
що запатентовані та не доступні для широ-
кого використання [3].
Найвідомішою реалізацією даної
ідеї є технологія IIS Smooth Streaming від
компанії Microsoft [4]. В основі даної тех-
нології використовується сервер Microsoft
IIS, а як протокол передачі між клієнтом
та сервером використовується протокол
HTTP. Для можливості організовувати
адаптивне мовлення на сервері заздалегідь
підготовляються відеоролики з різними
показниками якості, такими як бітрейт та
роздільна здатність. За допомогою даної
технології вирішена початкова проблема
швидкого відтворення. На початку клієнту
передається фрагмент найнижчої якості,
який швидко доставляється і починається
його відтворення, потім, якщо дозволяє
пропускна швидкість каналу, якість збіль-
шується відповідно до апаратних можли-
востей користувача. Взаємодія між серве-
ром і клієнтом проходить у такій послідо-
вності:
програвач проводить запит до сервера
за протоколом HTTP, і запитує відео-
фрагмент певної довжини (в більшості
випадків це фрагмент довжиною в 2 секу-
нди);
на початку відтворення запитується
фрагмент найнижчої якості, який швидко
доставляється до програвача і починається
його відтворення;
Експертні та інтелектуальні інформаційні системи
79
на основі даних отриманих при пере-
дачі першого фрагмента визначаються
можливості користувача та наступний
фрагмент запитується з урахуванням да-
них, які отримані при доставці поперед-
нього фрагмента.
Цей процес повторюється постійно
поки не буде припинено відтворення ме-
діа-контенту на стороні користувача. Та-
ким чином медіа-контент може відтворю-
ватися в різні моменти часу з різними по-
казниками якості, які залежать від поточ-
них можливостей користувача.
Для даної технології використову-
ється специфічна підготовка медіа-кон-
тенту. В результаті кодування отриму-
ється набір підготовлених медіа-потоків
з різною роздільною здатністю, які упа-
ковані в файл з розширенням «.ismv».
Також підготовлюється файл маніфесту
(.ism). У якому зберігається інформація
про медіа-контент, а також список дос-
тупних відео-потоків. На початку відт-
ворення проводиться запит до файлу
маніфесту, який і надає інформацію
про доступні ресурси. Щоб отримати
інформацію про наявні ресурси необхід-
но провести запит до .ism файлу з па-
раметром «Manifest» тобто вигляду:
«http://../media.ism/Manifest», у відповідь
отримаємо XML-файл з описом доступних
відео потоків та їх показників якості, саме
на основі цих даних програвач приймає
рішення щодо зміни якості зображення в
залежності від умов відтворення. Також у
файлі маніфесту задається шаблон URL
для запиту фрагмента відео-файлу, в біль-
шості випадків використовується даний
шаблон
«QualityLevels({bitrate})/Fragments(video=
={start time})». У секції {bitrate} задається
показник якості відео-фрагмента, а у секції
{start time} позиція відтворення фрагмента.
Таким чином клієнт і сервер знахо-
дяться в постійному зв’язку між собою, що
дає можливість реагувати на зміни умов
клієнта, а також проводити збір певної
статистичної інформації.
На сьогодні відомі декілька варіан-
тів реалізації технології адаптивного мов-
лення, це вищезгадані Microsoft Smooth
Streaming for Silverlight, Apple HTTP
Adaptive Streaming for iPhone/iPad та Adobe
Dynamic Streaming for Flash. Всі вони ма-
ють певну особливість, для їх функціону-
вання необхідно мати спеціалізований сер-
вер для проведення трансляції за протоко-
лом HTTP. Запропонований далі підхід,
дозволяє реалізувати технологію адаптив-
ного мовлення без використання спеціалі-
зованих серверів відповідних компаній. У
його основі лежить принцип використання
технології передачі відео за протоколом
RTMP та зміна характеристик відео потоку
в залежності від умов користувача, а в
подальшому перенесення проміжної об-
робки на клієнтську сторону за допомо-
гою технології псевдо потоків (англ.
pseudo streaming). Окрім того, запропоно-
вана система також включає програмне
забезпечення для автоматичної обробки
відео контенту на основі статистичних
даних, отриманих від користувачів даного
ресурсу.
Опис системи
Основна ідея системи полягає в то-
му щоб надати користувачеві якісно підго-
товлений контент для перегляду в режимі
он-лайн, зважаючи на пропускну можли-
вість його мережі. Одним із можливих ва-
ріантів реалізації даної ідеї є підготовка
відеоматеріалів з різними показниками
якості, щоб можливо було передавати кон-
тент по мережі без затримок. Зважаючи на
проблему «останньої милі» також необхід-
но контролювати процес відтворення для
оперативного реагування на зміну пропус-
кної швидкості каналу мережі.
Система складається з двох частин.
Перша частина відповідає за доставку
контенту кінцевому користувачеві, конт-
роль за зміною пропускної швидкості
мережі та відповідне реагування на ці
зміни. Друга частина являє собою програ-
мний комплекс, який створений для поле-
гшення процесу додавання нового контен-
ту на сервер та його попередню обробку,
також він відповідає за обробку статисти-
чних даних та автоматичну підготовку
відеоматеріалів у залежності від потреб
користувачів.
Серверна частина написана у ви-
гляді Java Enterprise проекту, з’єднання з
Експертні та інтелектуальні інформаційні системи
80
базою даних забезпечується за допомогою
технології EJB. Під час входу на початкову
сторінку проекту відбувається вимірюван-
ня пропускної швидкості мережі клієнта.
На основі отриманих даних генеруються
посилання на контент, який у даний мо-
мент знаходиться на сервері. Вибір опти-
мального варіанта відео файлу проводить-
ся на стороні сервера, servlet на основі
отриманих даних проводить підбір розміру
файлу, який в даний момент наявний у
системі. Якщо не знайдено жодного відео
файлу, який задовольнив би потреби кори-
стувача, то обирається найближчий, із ная-
вних даних, до отриманого запиту зі сто-
рони користувача. Дані про пропускну
спроможність та дату відвідання сайту
заносяться до бази даних для подальшої
обробки та підготовки відповідних матері-
алів. Під час перегляду наданого контенту
може виникнути ситуація коли швидкість
мережі може змінитись і користувачеві
буде некомфортно переглядати обраний
матеріал, саме на цю ситуацію орієнтова-
ний набір коду, який виконується на сто-
роні користувача і відслідковує такого ро-
ду зміни. В даній реалізації присутня сис-
тема перевірки в основі якої лежить відс-
лідковування часу прогнозованого відтво-
рення в порівнянні з фактичним часом,
впродовж якого відбувалося відтворення.
Якщо фактичні й прогнозовані результати
не збігаються, користувачеві автоматично
проводиться зміна контенту на один із тих,
що на даний момент наявні в системі. Як-
що такий матеріал відсутній то зміна не
проводиться, а в базу даних додаються
дані про необхідність підготовки відео з
відповідними показниками якості. Зміна
відеороликів «на льоту» є однією із основ-
них проблем відтворення контенту, тому
що необхідно приховати сам факт зміни
від користувача. Дану проблему можна
вирішити лише за рахунок медіа сервера,
додавши до нього можливість попередньо-
го завантаження фрагментів даних до по-
чатку їх відтворення. У разі використання
комерційного варіанта WOWZA Media
Server, то тут лише присутня можливість
створити додаток до сервера, використо-
вуючи відкрите API для розробників. У
випадку Open Source проектів, таких як
Red5 Media Server, залишається лише мо-
жливість редагування вихідних кодів та
ручного збирання проекту. Технологія
Microsoft IIS Smooth Streaming [4] вирішує
дану проблему за рахунок протоколу пере-
дачі даних, кожен фрагмент відеоряду від-
правляється сервером та одночасно відт-
ворюється програвачем на стороні клієнта,
у разі отримання інформації про зміну
пропускної спроможності просто зміню-
ється наступний пакет на інший у залеж-
ності від необхідних показників якості.
Отже, повертаючись до аспектів реалізації
проекту, слід відмітити не останню роль
програмного забезпечення та його викори-
стання. Для збереження інформації про
наявний контент необхідно використову-
вати високоефективну базу даних, виходя-
чи з міркувань загальнодоступності ін-
струментарію обрано СУБД MySQL, яка
на даний момент є найдоступнішою та ві-
дносно стабільною серед інших Open
Source проектів. Далі показана на рисунку
структура бази даних (БД), яка використо-
вується в системі.
Рисунок
Як видно із структури БД, основ-
ною є таблиця, яка містить інформацію
про наявні в системі ролики в оригіналь-
ному (незжатому) вигляді під назвою
Експертні та інтелектуальні інформаційні системи
81
“vidorig”. Саме звідси веб інтерфейс
отримує інформацію про наявний контент.
Таблиця“vidcoded” містить інформацію
про кодовані відео ролики, одне з полів
яких зв’язане з ключовим полем таблиці
оригінальних даних, що дозволяє контро-
люючим частинам на стороні сервера
отримувати достовірну інформацію про
наявні розміри та бітрейти варіантів осно-
вного відео ролика.
Не менш важливою є таблиця
“lowreq”, в якій розміщуються запити на
зміну якості відео у процесі його перегля-
ду. Дана таблиця містить у собі ключове
поле за яким відбувається зв'язок з даними
про оригінальні відео ролики, також при-
сутнє поле, що відповідає за кількість та-
ких запитів та поле зі значенням найниж-
чого бітрейту загалом за певним роликом.
Під час роботи системи автоматичної під-
готовки матеріалів, дані відсортовуються
за кількістю запитів і контент з більшим
рейтингом обробляється в першу чергу.
Для ведення певних статистичних спосте-
режень, а в подальшому і прогнозування
певних дій спирається на таблиці
“topvideos” та “stats”. Перша з них вико-
ристовується для аналізу популярності
певних відео роликів та в подальшому збі-
льшення їх пріоритету при попередній
обробці, в іншій накопичується інфор-
мація про пропускну спроможність кана-
лу користувачів ресурсу. На основі цих
даних планується проводити аналіз опти-
мального розміру відео файлу для його
комфортного перегляду. В подальшому
планується відмовитися від збереження
інформації про кодовані відео ролики у
базі даних, більш ефективним та зручним
буде створення файлу метаданих, що й
буде містити всю необхідну інформацію
про наявність інформації у системі, також
це дозволить зменшити навантаження на
сервер бази даних.
Як згадувалося раніше, друга час-
тина проекту відповідає за автоматичну
підготовку необхідних матеріалів. Для ви-
конання цих та інших функцій необхідно
мати програмний продукт, який має мож-
ливість перекодування відео файлів з од-
ного формату в інший з використанням
необхідних кодеків (англ. CODEC – Coder
Decoder). Всім цим вимогам задовольняє
безкоштовна Open Source утиліта під на-
звою FFMpeg (http://ffmpeg.org) , даний
програмний продукт надає користувачеві
інтерфейс командного рядка для виконан-
ня всіх задач кодування та підтримує ті
формати відео, які використовуються для
трансляції по мережі.
Під час розробки даної частини
проекту реалізовано програмний інтер-
фейс до командного рядка FFMpeg, його
основна задача полягає у підготовці
командного рядка в залежності від зада-
них параметрів якості відповідного кон-
тенту. В процесі розробки виникла необ-
хідність зчитування метаданих (довжина
ролика, бітрейт, розмір файлу, роздільна
здатність), для вирішення цієї проблеми
використано також FFMpeg, але в режимі
зчитування інформації про файл. Щоб
отримати ці дані використовується пере-
направлення потоків стандартного вво-
ду/виводу (stdin/stdout) та подальший роз-
бір отриманих даних. Інформація про
новий підготовлений контент заноситься
до бази даних і стає доступною для вико-
ристання. У даній частині проекту реалізо-
ваний прямий доступ до бази даних, що
спрощує передачу інформації між серве-
ром бази даних та даної програми. Про-
грама виконується постійно і з заданим
інтервалом перевіряє базу даних на наяв-
ність нових запитів, якщо такі присутні, то
вона починає підготовку і кодування від-
повідних відео файлів. Паралельно з пото-
ком в якому проводиться аналіз та оброб-
ка, працює потік який обробляє команди
користувача. Завдяки цим командам кори-
стувачеві надана можливість керування
обробкою інформації. Для задоволення
потреб користувачів система дозволяє ав-
томатично готувати необхідний матеріал
на основі аналізу отриманої статистики.
В процесі активності користувача збира-
ється інформація про переглянуті ним
відеоролики, пропускну швидкість його
Інтернет з’єднання та кількість запитів на
зміну якості матеріалу. Отримані дані со-
ртуються за спаданням від найпопулярні-
шого контенту до менш популярного,
таким чином готується в першу чергу
матеріал який найбільш затребуваний
http://ffmpeg.org/
Експертні та інтелектуальні інформаційні системи
82
користувачами. Процес підготовки почи-
нається відразу після перевірки наявнос-
ті необхідної інформації в системі, інте-
рвал перевірки задається адміністратором
системи в залежності від навантаження.
Доцільно також зупинитися більш
детально на функціоналі програми підго-
товки контенту. Як згадувалося раніше
користувачеві надана можливість змінюва-
ти параметри виконання під час роботи.
Основні операції керування здійснюються
за допомогою командного рядка та мають
певний синтаксис. Детальний опис команд
наведено далі:
/bwp – виведення інформації про міс-
цезнаходження файлів основного контен-
ту, тобто папки в яких знаходиться відео-
матеріал як кодований, так і оригінальний;
/dbh – виведення Інтернет адреси сер-
вера бази даних у вигляді “host:port/”;
/dbu – відображення назви активного
профілю користувача бази даних;
/newdb – за допомогою даної ко-
манди користувачеві надається можли-
вість змінювати параметри з’єднання з
сервером баз даних. Команда відпрацьо-
вує у діалоговому режимі та пропонує
заповнити поля необхідні для успішного
з’єднання, у разі якщо введені дані не
відповідають дійсності неможливо вста-
новити зв'язок, то повертаються параме-
три попереднього успішного з’єднання.
Відповідна процедура повторюється та-
кож під час першого запуску програми
і не дозволяє запуск основного циклу
обробки без успішного під’єднання до
бази даних. Саме на етапі роботи з ба-
зою даних виникла основна проблема
безкоштовного програмного забезпечен-
ня, неякісні допоміжні бібліотеки. Спра-
ва в тому, що драйвер з’єднання з БД,
який розповсюджується у комплекті з
СУБД MySQL, абсолютно неможливо ви-
користовувати при розробці. Окрім того,
що некоректно встановлюється з’єдна-
ння, яке може бути розірвано без види-
мих на те причин, відтік оперативної
пам’яті є більш ніж помітним, після
завершення одного процесу комунікації
з базою даних, кількість оперативної
пам’яті збільшується на 1 Mb, що у
будь-якому випадку є неприпустимим.
Після недовгих пошуків з’ясувалося, що
дана проблема саме у драйвері, тому
знайдено більш функціональну та стабі-
льну заміну в проекті MySQL++, озна-
йомитися можна за посиланням
http://tangentsoft.net/mysql++/;
/currint – виведення інтервалу затрим-
ки при повторній перевірці та підготовці
відеоматеріалів;
/chint <interval> – команда для зміни
інтервалу перевірки. Значення інтервалу
вводиться у форматі “seconds-minutes-
hours-days”, що допускає введення лише
необхідного значення, але в строгому по-
рядку зліва направо;
/exit – завершення роботи основної
програми;
/addv – команда використовується для
додання нових відео файлів у систему.
Основне її призначення максимально зме-
ншити кількість дій зі сторони користу-
вача. Отже у діалоговому режимі кори-
стувачеві пропонуються ввести інформа-
цію про місцезнаходження відео файлу
та ім’я яке буде відображатися у веб
інтерфейсі системи. В автоматичному
режимі проводиться внесення відповідної
інформації у базу даних та розпочина-
ється позачерговий процес підготовки
кодованого відео у найвищій якості, яка
доступна в налаштуваннях програми. Для
отримання всієї інформації використову-
ється декілька допоміжних засобів для по-
передньої обробки, використовуються такі
засоби: отримання інформації з метаданих
вихідного відео файлу та внесення її у ко-
довані файли.
Отримання метаданих з файлу про-
водиться шляхом запуску утиліти FFmpeg
у режимі зчитування, щоб провести всі
необхідні маніпуляції відбувається захоп-
лення вихідного потоку утиліти та його
подальший розбір з перетворенням отри-
маної інформації у необхідну форму. Пе-
рекодування проходить за допомогою ути-
літи FFmpeg, на вхід якої подається підго-
товлений командний рядок, який генеру-
ється в автоматичному режимі та включає
всю необхідну інформацію як про вхідні
дані, так і про вихідні.
http://tangentsoft.net/mysql++/
Експертні та інтелектуальні інформаційні системи
83
Приклад реалізації головного циклу
перевірки та підготовки контенту можна
побачити далі.
DWORD WINAPI Statistical_Analyzer(LPVOID
lp)
{
vector <int> mygrid;
mygrid.push_back(100);
mygrid.push_back(300);
mygrid.push_back(500);
BitrateGrid * btg = new BitrateGrid(mygrid);
vector<Encoder*> encvec;
vector<vidcoded*> codvec;
vector<stats*> mystat;
vector<topVideos*> tpv;
vector<lowReq*> lrw ;
while(true){
system("cls");
Connector * cnt = new
Connector(DBHost,DBUser,DBPass);
mystat = cnt->GetStatistic();
tpv = cnt->GetTop();
lrw = cnt->GetRequests();
if(lrw.size()==0){goto endpoint;}
sort(tpv.begin(),tpv.end(),sortForTop);
//prepare encoding tasks
for(UINT i=0;i<tpv.size();i++){
int k= FindInByID(lrw,tpv[i]->VIDID);
if(k!=-1){
int z = btg->lowerThan(lrw[k]->
lowestBitrate);
if(z!=0){
ExifTool * einfo = new ExifTool();
encvec.push_back(new Encoder());
vidorig vd = cnt->
getOrigVideoByID(tpv[i]->VIDID);
MetaData * mtd = new MetaData();
mtd=einfo->
GetInfoForFile(basePath+vd.fpath);
encvec[encvec.size()-1]->
SetSourceVideoFile(basePath+vd.fpath);
encvec[encvec.size()-1]-
>SetBitrate(z);
encvec[encvec.size()-1]->
SetDimensions(mtd->width,mtd->height);
string prep =
BitrateGrid::split(vd.fpath,"/")[1];
prep =
BitrateGrid::split(prep,".")[0];
prep+="_"+BitrateGrid::toString(z)+"."+"flv";
encvec[encvec.size()-1]->
SetDestinationVideoFile(basePath+"codedvid/"+p
rep);
vidcoded * vdcd = new vidcoded();
vdcd->bitrate=z;
vdcd->fpath="codedvid/"+prep;
vdcd->PID=tpv[i]->VIDID;
codvec.push_back(vdcd);
delete mtd;
delete einfo;
}
}
}
for(UINT i=0;i<encvec.size();i++)
{
encvec[i]->encode();
}
for(UINT i=0;i<codvec.size();i++)
{
ExifTool * einfo = new ExifTool();
MetaData * mtdt = new MetaData();
mtdt = einfo->
GetInfoForFile(basePath+codvec[i]->fpath);
codvec[i]->fsize=mtdt->file_size;
cnt->InsertCodedVideo(*codvec[i]);
delete einfo;
}
encvec.clear();
codvec.clear();
cnt->DeleteStatisticalTables();
endpoint: delete cnt;
cout<<endl<<"new iter"<<endl;
CListener((LPVOID)false);
Sleep(timeInterval);
}
delete btg;
return 0;
}
Як бачимо вище зв'язок з базою
даних встановлюється за допомогою кла-
су Connector в якому реалізовано всі
необхідні методи для роботи з БД, а та-
кож присутні методи які відповідають
за отримання необхідної інформації і
її представлення у вигляді придатному
для подальшого використання. Також
одним із основних класів, що відповідає
за обробку відео контенту, – ExifTool,
який є по суті обгорткою (wrapper) навко-
ло утиліти FFMpeg і за допомогою якої
отримується вся необхідна інформація
для подальшого використання. Вся отри-
мана з файлу інформація зберігається
в структурі MetaData для подальшого
використання в процесі підготовки. А
клас, який відповідає безпосередньо
за конвертацію носить назву Encoder,
Експертні та інтелектуальні інформаційні системи
84
котрий також являє собою обгортку
навколо FFMpeg. Інші вищепредставлені
класи й методи є допоміжними у
процесі підготовки й конвертації та ви-
користовуються для проміжного збере-
ження інформації.
Висновок
У даній роботі продемонстровано
один із варіантів реалізації концепції адап-
тивного мовлення за допомогою сервера
потокового медіа. Ключовою відмінністю
даного підходу є те, що для організації
адаптивного мовлення не потрібно вико-
ристовувати спеціалізовані Web-сервери,
використання та обслуговування яких пот-
ребує значних капіталовкладень.
Запропоновано варіант системи
автоматичного адміністрування та підго-
товки медіа контенту на основі аналізу
статистичних даних зібраних іншою час-
тиною проекту, яка спрощує адміністру-
вання та дозволяє раціонально використо-
вувати простір носіїв зберігання інфор-
мації. Проте в подальшому планується
взагалі відмовитися від використання
серверів потокового медіа на користь сис-
теми псевдо потоків (англ. Pseudo
streaming). Дана технологія дозволяє, ли-
ше доданням до Web-сервера спеціалізо-
ваного обробника запитів, реалізувати си-
стему відтворення відео з довільної пози-
ції. Завдяки цьому з’являється можливість
реалізації концепції адаптивного мовлен-
ня без використання допоміжного про-
грамного забезпечення для потокового
мовлення.
1. Xiaoyan Sun, Feng Wu, Shipeng Li, Wen Gao,
Ya-Qin Zhang. “Seamless switching of
scalable video bitstreams for efficient
streaming” IEEE Transaction on multimedia,
Vol. 6, no 2, 291-303, 2004.
2. Xiaoyan Sun, Feng Wu, Shipeng Li, Guobin
Shen, Wen Gao. “Drift-Free Switching of
Compressed Video Bitstreams at Predictive
Frames”, IEEE Transaction on multimedia,
Vol. 16, no 5, 565-576, 2006.
3. Xun Guo, Yan Lu, Feng Wu, Wen Gao,
Shipeng Li. “Free Viewpoint Switching in
Multi-view Video Streaming Using Wyner-
Ziv Video Coding”, SPIE Visual
Communications and Image Processing, VCIP
2006, San Jose, CA, USA, Jan. 2006.
4. Microsoft IIS Smooth Streaming technology,
5. http://www.iis.net/download/SmoothStreamin
g
Одержано 30.03.2012
Про авторів:
Провотар Олександр Іванович,
доктор фізико-математичних наук,
професор, завідувач кафедри інформацій-
них систем факультету кібернетики,
Заміховський Андрій Андрійович,
студент кафедри інформаційних систем
факультету кібернетики, 5 курс.
Галкін Олександр Володимирович,
кандидат фізико-математичних наук,
доцент кафедри інформаційних систем
факультету кібернетики,
Верес Максим Миколайович,
кандидат фізико-математичних наук,
доцент кафедри інформаційних систем
факультету кібернетики,
Катеринич Лариса Олександрівна,
кандидат фізико-математичних наук,
асистент кафедри інформаційних систем
факультету кібернетики.
Місце роботи авторів:
Київський національний університет
імені Тараса Шевченка,
03680, м. Київ,
Проспект Академіка Глушкова, 4Д.
Тел.: (044) 259 0511,
e-mail: islab@unicyb.kiev.ua
http://www.iis.net/download/SmoothStreaming
http://www.iis.net/download/SmoothStreaming
|