Несколько лет назад мне пришлось по работе познакомиться с UPnP A/V-протоколом. Это продолжение UPnP-спецификаций, которые используют многие так называемые аудио/видео проигрыватели/сервера (в основном телеприставки), чтобы обеспечить простой способ обмениваться потоками мультимедийного контента. Поработав с ним, я решил написать небольшой UPnP A/V медиа-сервер с запилом под встроенные решения, так появился uShare (произносится you-share). Удивительно uShare быстро стал одним из наиболее часто используемых UPnP A/V медиа-серверов на UNIX. Теперь он является частью дистрибутива Ubuntu, равно как и включен во множество микро-дистрибутивов, такие как OpenWRT или FreeNAS, которые используются на маршрутизаторах или NAS.
UPnP A/V протокол никогда не был действительно хорошо описан (куча широковещательных сообщений, производящих массовое использование SOAP-запросов через HTTP для передачи информации в XML), но все это могло быть и хуже. Это, вероятно, было путем, по которому инженеры начали идти, когда они разрабатывали DLNA спецификации. UPnP A/V опирается на UPnP протокол обмена информации о сессии. Он также требует до 3 сервисов для диалога между клиентом/плеером и сервером: сервис Content Directory Service (CDS) который предоставляет ваши шары, a Connection Manager Service (CMS), который заведует соединениями между конечными точками и опциональный AV Transport Service (AVTS), который бог его знает что делает. Наконец, все, для чего нужен протокол — предоставить клиенту HTTP-ссылку, дабы тот знал откуда открывать поток… Да, это кажется несколько переусложненным, дабы всего лишь сделать такую простую вещь, но такова жизнь.
Но, тем не менее, это все работало и работало неплохо и uShare становился все более и более известным и используемым. Как ни странно, хотя я и являюсь автором uShare, я сам использовал этот протокол, так как не имею совместимых с UPnP A/V устройств. Это не очень помогает в тестировании, это уж точно ;-). Но потом появилась Microsoft Xbox 360. Как обычно бывает с MS, они сделали много дерьма и добавили дополнительный сервис UPnP, просто дабы быть несовместимыми со спецификациями, которые они сами и сделали (UPnP был разработан Microsoft в начале 2000-х годов). Давайте назовем этот новый сервис Microsoft Registrar (MSR). На самом деле, он был разработан так, что только Windows Media Connect (WMC) может быть использован в качестве сервера для Xbox 360. В результате, uShare вынужден был мимикрировать под WMC, дабы обслуживать Xbox 360. Кроме того, они решили не использовать обычную реализацию CDS, которая, опять же, еще одна вещь, чтобы свести меня с ума. Тот факт, что у меня нет интереса к Xbox 360, ни доступа к этой гадости (и я до сих пор не имею ее) был не самый лучший путь добавления поддержки в uShare. Хотя, благодаря помощи многих тестеров на протяжении многих лет, мне удалось заставить ее работать. И это, кажется, используется массово по всему миру, в основном с Xbox. Я все еще не понимаю, почему, но мне даже пришлось ответить на несколько интервью, о моих планах на uShare и о поддержке Xbox 360. Это было очень смешно 🙂
Но давайте вернемся к DLNA. DLNA расшифровывается как Digital Living Network Alliance. Это консорциум промышленников, которые сосредоточив внимание на рынок встраиваемых решений и приставок, и которые хотели, чтобы какой-то протокол обмена медиа-контента между различными устройствами (NAS, телевизоры, A/V-плееров и так далее …). Они решили использовать UPnP A/V протокол, но этот путь слишком простой, поэтому решили усложить его, так что это звучит более профессионально. Говоря простыми словами, DLNA может быть определена как «UPnP A/V с ограничениями». Используя простые UPnP A/V, сервер может расшарить любой файл (являющийся двоичным, аудио файлом, видео файлом, текстовым файлом, т.е. субтитры, или даже документ Word или PowerPoint презентации, независимо от …). Все это в конце концов, простой обмен файлов через HTTP с соответствующим MIME-типом, это делает любой сервер HTTP (Apache …). Тип нужен, дабы клиенту/плееру понять, сможет ли он осилить поток. Но это было показалось слишком простым для DLNA-пацанчиков. Они решили, что только многочисленнымы файлами следует делать общий доступ. В результате, они решили ограничить протокол, так что только некоторые конкретные расширения файлов, а также комбинации аудио/видео контейнеров/кодеков могут быть использованы. Это только звучит как очень хорошая идея. Даже 16-летний пьяный болельщик мог бы понять это было чистейшим дерьмом!
А вот ниже представлены поддерживаемые характеристики потоков:
Кодеки изображений: JPEG, PNG
Аудио кодеки: AC3, AMR, ATRAC3, LPCM, MP3, MPEG4, WMA
Видео кодеки: MPEG 1, MPEG 2, MPEG 4 Part 2 (ака DivX), MPEG-4 Part 10 (он же H.264), WMV9.
Контейнеры: MPEG PS / TS, MP4, ASF для видео-файлов…
Как вы можете видеть, многие медиа-форматы просто начисто выброшены, потому что никто не использует их в промышленности, так что это довольно просто понять. Как вы, возможно заметили, нет ни поддержки свободных аудио кодеков (Ogg/Vorbis, FLAC, …), ни WMV10 (ака VC-1), который стремится заменить WMV9 все больше и больше, но, что более интересно, ни AVI, ни Matroska (MKV) контейнеров не поддерживаются. Это просто означает, что 99% видео-файлов не являются DLNA-совместимыми и, как следствие, не могут быть переданы как есть. Это просто замечательно! Но если закончить прямо здесь, протокол может выглядеть просто «плохо». Давайте рассмотрим более сложную часть. Предположим, у вас есть мультимедийный файл, который соответствует этим ограничениям (скажем, вы скачали HDTV трейлер на Apple.com, где видео в формате H.264, с AAC аудио, инкапсулированные в MOV/MP4 контейнер). Это выглядит как поддерживаемый файл. Но вообще-то, это не так 🙂 Да, я забыл рассказать вам о DLNA профилях! DLNA спецификация определяет довольно много A/V-профилей (что-то вроде 250-300 я бы сказал), и файл, чтобы быть совместимым с DLNA, должен соответствовать одному из этих профилей. Как уже было сказано, это зависит от аудио/видео кодеков и контейнеров, но еще и от разрешения, битрейта и тому подобного. Если мы будем возьмем предыдущий пример, в файле кодеки/контейнер могут совпадать. Хотя, когда разрешение превышает 720×576, MP4 контейнера уже недостаточно, таким образом, только содержимое в контейнере MPEG TS может передаваться. Это худшее, что можно было бы себе представить.
Очень хорошо с этим сломанным дизайном является то, что почти 99% из видео файлов не являются DLNA-совместимыми (немного проще с аудио-файлами, MP3 и AAC должны играть нормально, например). Как передать файлы тогда? Это довольно просто в теории: вам нужно просто сделать их совместимыми с протоколом, вот и все ;-). Как это сделать тогда? Ну, для каждого файла, DLNA сервер должен сначала демукснуть (разобрать на потоки) дабы определить информацию, подходит ли оно к имеющемуся профилю. Если подходити вы еще хотите передачи, затем сервер должен пересобрать поток на лету (в лучшем случае) если этого достаточно, или перекодировать на лету к валидному профилю и уже потом собрать (худший вариант), дабы плеер смог это прочитать. Конечно, проделывание этого на лету потребляет много ресурсов процессора, который, по определению, не доступен, что делает невозможным использование на встроенных устройствах, которые были целью DLNA-изобретателей. Кроме того, каждому файлу, как только он demuxed, должен быть присвоен идентификатор DLNA профиля. Хорошо, когда файл _ЯВЛЯЕТСЯ_ DLNA совместимым и может быть декодирован плеером, но сервер сообщил, что у него неправильный идентификатор, поэтому вы не можете в итоге его проиграть.
Как мы уже видели, DLNA действительно сломан на уровне дизайна. Хотя, это отраслевые стандарты и все больше и больше устройств будет только DLNA совместимыми и не будут поддерживать UPnP A/V более. Первая сделала это было Sony Playstation 3 (да-да, им удается сделать хуже, чем это делает Microsoft …). К счастью для меня, мне предоставили PS3, чтобы uShare работы с ним. Я также был спонсирован Consumer Embedded Linux Forum (CELF), который предоставил мне DLNA спецификаций бесплатно (в противном случае, идиотское объяснение стоило бы 5000 долларов…), которые помогли мне разработать первую и единственную реализации DLNA спецификаций на С для Linux через libdlna. libdlna реализует все DLNA профили и теперь позволяет создавать полностью совместимые DLNA (или UPnP A/V) Media Server с помощью нескольких строк кода. Следующая цель будет заключаться в предоставлении возможностей медиа-плееров, а также поддержка ремукса/перекодирования на лету для сервера, которая запрашивается пользователями уже очень давно. Кроме того, разрабатываемая версия uShare теперь полностью зависит от libdlna и является не более чем из интерфейсом командной строки к нему.
В настоящее время, у меня нет даты следующего libdlna и uShare релиза. Многие вещи до сих пор должны быть исправлены в обоих, особенно сейчас, когда они тесно переплетены. Весь uShare UPnP CDS/CMS код теперь переехал в libdlna и Xbox 360 Поддержка сломана еще раз. Если кто-то хочет спонсировать меня, вы знаете где найти меня. Вот и все на сегодня, больше новостей о libdlna/uShare будет на следующих неделях, если я найду время и мотивацию для них 😉
ссылка на оригинал статьи http://habrahabr.ru/post/166227/
Добавить комментарий