Когато решите да създавате video addon за Kodi е добре да обмислите предварително нещата: дали е целесъобразно и добре ли ще се получи или само половинчато... В тази тема ще разгледам някои фактори, които е хубаво да вземете под внимание.

ЛЕГЕНДА НА ПОНЯТИЯТА

видео хостинг -> сайт за споделяне на видео клипове за вграждане в други сайтове (например YouTube. При него по подразбиране видеата са публично достъпни за търсене чрез търсачка и в каталози, а при повечето други хостинги са частни и достъпни, само ако разполагате с директен линк до страницата им);

IA -> Inputstream Adaptive addon за Kodi (да не се бърка с AI). Поддържа допълнителни формати субтитри, манифести, DRM и други екстри, като адаптивен стрийминг (които вградения плейър в Kodi не поддържа);

API -> Application Programming Interface (да не се бърка с Агенция Пътна Инфраструктура). Обезпечава правила на форматирани заявки между клиент и сървър и гарантира конкретен формат и съдържание на отговора на конкретна заявка къмто съответен възел (ендпойнт). Най често, форматът на отговорите е JSON или XML, а заявките съдържат някакъв API Key за достъп (статичен или динамичен).

URL resolver -> скрипт за извличане на директни "пускаеми" линкове. Използва се за резолфване на Obfuscation code, Minified code, криптиран код с някакъв шифър или просто изкуствено усложнен до някакъв математически израз на Javascript, който би отказал почти всекиго да го подхване... Такива резолфвъри са yt-dlp, Universal URL Resolver, ResolveURL и др. (аз използвам последния, понеже лесно се вгражда в Kodi и активно се поддържа).

Ако си избирате сайт за който да напишете addon за Kodi е препоръчително той да разполага с API, защото резултата ще е надежден, стабилен и ще продължава да работи без значение на козметичните промени в сорс кода на фронтенда (сайта). С API разполагат само големите стрийминг услуги. Малките любителски проекти от типа Wordpress с някакъв Movie скин отгоре не разполагат с нищо подобно, освен вграденото в Wordpress REST API. По принцип, дори и да го използвате, резултата от заявките до него пак ще изискват регулярни изрази, така, че малко се обезмисля използването му, но в някои случаи е наистина полезно - когато сайта е зад Cloudflare! И така... 

Когато трябва да скрейпнете заглавието на филма, линка към неговата страница в сайта, обложката му и евентуално други елементи като описание, времетраене и т.н., не се опитвайте да го направите наведнъж с един регулярен израз: С една заявка прочетете цялата страница и запишете отговора й в една променлива и с отделни регулярни изрази скрейпвайте поотделно каквото потрябва от този отговор! По този начин правите само една заявка към самата страница и можете да прочитате разхвърляни из нея тагове с метаданни  (както е в повечето от случаите). Изпращайте оригиналните хедъри при заявката ви, същите, които и вашия собствен браузър би изпращал при отварянето на тази страница. По този начин трафикът от заявките на потребителите (на вашия addon) ще бъде неразличим от "органичния" трафик на web browser-а на потребителите на сайта.

Сорс кода на сайта се променя прекалено често: ако няма стабилен API за достъп до услугата, то не си правете труда изобщо да се захващате, защото е уморителна игра на котка и мишка.

Видео хостинг: В идеалния случай, ще се използва вътрешен видео хостинг т.е. видеата винаги ще са работещи (ще се отварят), няма да бъдат свалени от хостинга поради неактивност или предявени претенции за нарушени авторски права. В сравнително оптимистичните случаи, се използва само един външен хостинг т.е. има да имплементирате кода за извличане на стриймовете от едно място. Хубаво е, ако кода на страница за вграждане (iframe) използва открит кода на стриймовете, лесен за скрейпване с регулярни изрази. В повечето случаи обаче, имаме Obfuscation code и се налага да разчитате на чужд URL resolver. Трябва да помислите, как/откъде потребителите ви да получават редовни ъпдейти на URL resolver-а, защото той е измежду най-важните компоненти на вашия addon, въпреки, че не го разработвате вие. Ако той е ъпдейтнат има голяма вероятност да разполага с актуален resolver за външния хостинг, който ви тормози. Например, може да предвидите инсталация на хранилище откъдето URL resolver-а да се ъпдейтва автоматично.

Субтитри и DRM: При перфектни обстоятелства, в кода на страницата с iframe-а ще има директен линк до файл със субтитри, какъвто Kodi поддържа. Чрез съответните python команди, ще можете да ги зареждате след стартиране на видеото. Такъв късмет се случва сравнително рядко. Също много добър вариант е да намерите сайт, където субтитрите се вграждат като hardsub в самите кадри на видео файловете. В повечето случаи имаме "манджа" от множество различни видео хостинги в които заедно с видео файла е ъплоуднат и файл за субтитри. При някои от тях, файла си стои външен и плейъра им го зарежда, ако е наличен и съвпадне като език с този на web browser-а. При останалите случаи, субтитрите се вграждат в манифеста HLS/MPD на видео файла. Вградения плейър в Kodi ffplay (ffmpeg) не поддържа MPEG DASH манифести, но поддържа HLS и при това, само половинчато и не поддържа субтитрови стриймове в HLS, както и AES криптиране на чънковете (DRM). На помощ в такъв случай, може да разчитате само на IA, защото той поддържа както различни формати субтитри от Kodi (като например WebVTT), така и вградени субтитри в манифестите, така и допълнителни манифести като MPD и ISM. Също така поддържа и Google Widevine DRM, а в недалечното бъдеще и на ClearKey и Microsoft PlayReady. Накрая, ще бъде добавена поддръжка и на Apple FairPlay (според "пътната им карта"). За добавки, ориентирани към родна аудитория е несериозно да очаквате хората да търсят ръчно субтитри, чрез добавки за субтитри, при условие, че в самия сайт автоматично си зареждат!

Защити: Ако сайта е изградил някаква форма на защита за скриване на самите iframe-ове или чрез Javascript инжектира съдържанието в себе си, ще се наложи да възпроизведете въпросната функционалност чрез python, иначе добавката ви няма да достигне до съдържанието, което очаквате да зарежда! Използването на специални хедъри, потребителски ключове, потребителски сесии (изискват login в сайта с валиден акаунт), Obfuscation code, anti-adbloker-и, anti-developer-tools, Cloudflare и т.н. други мизерии се срещат под една или друга форма, понякога самостоятелно, а друг път като комбинации между тях. Това не бива да ви отказва. Дайте си достатъчно време да експериментирате, да изпробвате различни варианти, докато намерите работещо решение и да го приложите.

Целта на проекта е създаването на Audio Addon за четене на книги, през Коди на български език.

В интернет пространството се намират аудио книги на български език, но предимно стари, които да са със свободен достъп. Също така количествено са съвсем малко, че да представляват интерес. Затова пренасочваме архитектурата към изчитане на глас на подадени в текстов формат книги - ще използваме TTS (Text to Speech).

1. Ще ни трябва някакъв python модул, който да прави интеграцията между Kodi addon-а и TTS модула. Може да използваме например voicebox: https://pypi.org/project/voicebox-tts/ Измежду всички TTS енджини, които той поддържа: ElevenLabs, eSpeak NG, Google Cloud Text-to-Speech и gTTS "говорят" на български език, а: Amazon Polly и Pico TTS не "говорят" на нашия език.

2. Трябва да изберем подходящ TTS енджин, който да притежава български глас. Някои от изброените в т.1 енджини са платени и за тях тарифата е твърда месечна такса и лимит на броя символи/знаци, обработени през онлайн API-то на платформата им. Други са безплатни за конкретна употреба, стига да не се нарушават правилата им на употреба. Интересен например е TTS енджинът на българската компания SkyCode, която беше известна с програмата за офлайн превод на текст към български език: WebTrance. Техния енджин поддържа мъжки и женски български гласове и има приложение за Андроид, което може да се ползва офлайн. То, ако става дума и в новите Андроид устройства си има вграден български глас, разработен от Google, който също може да си използвате офлайн. Въпросът е, какъв енджин да изберем, който да се използва офлайн (по възможност, предвид огромното количество текст, което ще му подаваме) и да бъде съвместим с всички или поне повечето системи, върху които работи Коди. Измежду поддържаните от voicebox-tts енджини се спрях на eSpeek NG. Той е напълно офлайн, поддържа един мъжки български глас, безплатен е и може да се инсталира в Linux, Windows, Mac OSX, BSD, Solaris (не представлява интерес) и евентуално в Андроид (когато е инсталиран в Андроид, не съм сигурен, как точно ще бъде стартиран???).

3. За осигуряване инсталацията на TTS енджина, той трябва да е е с малко зависимости, лесен за компилиране и разполагане. Аз работя под Линукс и затова ще го пробвам на x86_64 битов Ubuntu, както и на aarch64 LibreELEC. За по-лесен деплоинг, без нужда от рекомпилация, използвам скрипта tts_addon_bundler. Във файла tts_addon_bundler.sh посочих:

и деплойнах два пъти съответно за x86_64 и aarch64. Инсталационния пакет, може да се инсталира в Коди, като всяка една друга добавка. Може да тествате конкретен език/глас, през терминала на операционната система, например:

Гласът звучи много брутално и роботизирано. Не бих могъл да го изтърпя повече от 30 секунди! Можете да го тествате и онлайн през тази страница. По принцип, добрите гласове изискват повече хардуерни ресурси, натоварват повече, а най-съвременните са базирани на невронни мрежи. Това означава, че някой ден, когато всяко хардуерно устройство притежава и NPU чип, ще може да изпълнява локално такива AI гласове (с изкуствен интелект) или пък да превежда субтитри на филмите в Коди напълно локално/офлайн. При това доста качествено.

4. Принципът на действие измислих да е такъв: През интерфейсът на Коди се браузва сайтът на Читанката или друг сайт за електронни книги. Когато бъде избрана конкретна книга, тя се листва в Коди като директория. В нея всяка страница, ще се показва като отделен елемент за възпроизвеждане - в случая аудио съдържание. Потребителя избира "четвърта страница" и текстът от нея се изпраща през voicebox-tts към eSpeek NG, който в реално време, започва да го чете на глас. Звуковия файл няма да се съхранява локално, за да не пълни локалния сторидж на устройството. Когато бъде прочетена конкретната страница/аудио елемент, Коди автоматично преминава към следващия в директорията/книгата. Няма да подаваме цялата книга наведнъж, заради лимита в енджина и хардуерните ресурси на устройството.

В общи линии, това е идеята. Ако сте прочели проекта до края, вероятно сте разбрали, че не започвам да го правя, въпреки, че може, защото хубавите български гласове са платени (доста скъпа е употребата им през API) и за локално използване не намерих добър български глас, който да работи и под Линукс. Някой ден, да се надяваме докато сме живи, ще се промени ситуацията. Идват и други интересни приложения на AI, които ще намерят място в Kodi, но поне половината от тях ще бъдат свързани с обработка на текст:

- командване на Коди с гласови команди (има го тук, там);

- превеждане на субтитри офлайн от един език към друг, директно в Коди (има го, но онлайн за момента);

- четене на текстови файлове с книги; списания; вестници и др. сайтове през Коди;

- превеждане на дублажа на видеото в Коди напълно офлайн от един език към друг! При наличие на два български гласа М/Ж, на съответните герои/участници във видеото ще бъде избиран подходящ глас (измежду наличните) - разбира се от AI. Той ще прави всичко това.

Към момента, всичко това ни звучи като научна фантастика, но ако сте чели книгите на Жул Верн, вероятно усещате как духа вятъра на промяната