Оптимальный торрент стример - обсуждение

[HAL9000]

Сообщение от Roman_V_M

Тут ведь в чем фигня. API плагинов Коди допускает 3 типа вызовов: вируальная папка (isFolder=True), проигрываемый файл ('IsPlayable'='true' и isFolder=False) и прочее (isFolder=False). Тип вызова элемента задается заранее при формировании списка, и в рантайме его менять нельзя.
В идеале схема должна была бы быть такая: мы открываем торрент, получаем список файлов, а дальше, если файл один, начинаем воспроизведение. Если же их несколько, формируем список для выбора.
Либо можно формировать список всегда, независимо от количества файлов, но тогда усложняется навигация.

Да. Все верно. И я абсолютно не вижу проблем. Сейчас так и сделано (у меня в RuTracker):

• Выставляю isFolder=False.
• Скачиваю торрент-раздачу.
• Вывожу ее пользователю и на выводе снова выставляю isFolder=False
• Пользователь жмет и я уже запускаю ему видео с помощью экземпляра xbmc.Player

При этом, не нужно пытаться использовать isPlayable=True и setResolvedUrl. Эта схема после таймаута будет выдавать ошибку.

В вашем варианте нужно делать так:

• Выставляем isFolder=False.
• Пользователь жмет на строку.
• Если у нас магнит, то отдаем его нашему "libtorrent-плеер" (условно написанному в будущем), а пользователю начинаем показывать прогресс-бар "Please wait". В результате получаем список файлов.
• Если у нас торрент, то также гоним его в наш "libtorrent-плеер" (или локально парсим) и получаем список файлов (без прогресс-бара - там все быстро).
• Далее - анализируем. Если можем выбрать файл самостоятельно, то переходим к следующему пункту. Если не можем выбрать файл самостоятельно (например, это - сериал и их много), то выводим пользователю список файлов. При этом ОПЯТЬ выставляем isFolder=False. Пользователь жмет на нужный файл и...
• Создаем экземпляр класса xbmc.Player и вперед...

Сообщение от Roman_V_M

Насколько я понимаю, полноценной перемотки при стриминге торрента всё равно не будет, разве что файл будет скачиваться быстрее, чем скорость перемотки. Теоретически, можно реализовать прыжки, но только если всё управление будет завязано на плагин, т. к. класс xbmc.Player не предоставляет достаточно контроля. А свое управление будет сложно сделать так, чтобы оно не конфликтовало с управлением Коди. Но, возможно, я в этом плане что-то упускаю.

Так точно. Именно так дело и обстоит.
Я постоянно пытаюсь объяснить на форуме, что bittorrent-протокол ну ваще ни разу не подходит для стриминга, а костыли мы пишем только потому, что контента на торрентах "как грязи". Но все время получаю в ответ - мол "а в ACE Stream все в порядке с перемоткой...".
ACE Stream добились нормальной перемотки с помощью того, что пожертвовали кое-чем другим. Они могут проигрывать только потоковое видео. Kodi при потоке по HTTP умеет перепрыгивать сразу через большие куски. А вот при чтение локального файла - вроде как нет (пишу вроде, так как сам до конца еще не разобрался и мне это интересно).
Как только Kodi запрашивает у ACE Stream кусок из "будущего", то оно также сообщает об этом ACE и тот начинает приоритезировать новые куски в раздаче. В это время (если этих кусков нет) в Kodi включается сообщение "буферизация". Другими словами - это частный случай реализации в Kodi (просмотр через HTTP).

Но в целом, я считаю, что перемотка не такая уж и большая засада. Нужно просто отлавливать немного заранее момент, когда заканчиваются скаченные куски и принудительно ставить на паузу. Чем выше скорость перемотки пользователь врубил, тем больше должно быть кусков, входящих в это самое "заранее".

[HAL9000]

Сообщение от DiMartino

А я думаю, если плагин будет понимать с какого куска файла какая секунда начинается и сможет проверить наличие этого куска, то плагин сам будет ставить паузу и возобновлять воспроизведение, без xbmc.Player, от которого нужно будет только подчиниться и дать секунду куда перемотали.

Не прочитал сразу твое сообщение. Именно это я и имел в виду в предыдущем своем сообщение.

Сообщение от Roman_V_M

Я со своей реализацией торрент-стримера копаюсь достаточно давно, и в одном из вариантов такой функционал был. Но не работал. В ближних пределах от точки воспроизведения картину портит кэш Коди, который норовит захватить в себя недокачанные фрагменты. А при прыжке на дальние расстояния плеер Коди не может надежно стать на паузу на битом участке и, опять таки, пытается захватить этот участок в кэш.

К такой же проблеме пришел и я в DelugeStream. Я даже до не давнего времени не оставлял мысли что-нибудь придумать с этим буфером или таймаутом.
Пришел к выводу, что ни фига там ничего не выйдет.
Думаю надо копать в сторону обратной связи от Player к плагину (как ACE). Без штатных средств Коди (без HTTP Range и все такое...).

Сообщение от Roman_V_M

В идеале команду на прыжок нужно перехватывать до самого прыжка, чтобы поставить плеер на паузу, проверить место прыжка, докачать, если нужно, и перекинуть плеер на нужный уже скачанный участок. Однако в API такого события, которое можно перехватить до прыжка, нет.

А вот тут, кстати, можно и покопать еще...
Я сейчас у себя эксперементирую со следующей хренью... Есть у меня в RuTracker инфо-окошко, которое встраивается в слой контрлов плеера и при паузе показывает статус работы libtorrent`а. Такой же есть у Pulsar, у Torrenter и т.д.
Так вот. Сейчас это окошко отрисовывается не правильно, так как заранее не известно разрешение экрана у пользователя и приходится все размеры высчитывать в реал-тайме. Все это потому, что встраивается это инфо-окошко в уже существующий слой.
Если же отрисовывать его в новом слое, то можно самостоятельно задать разрешение слоя и рисовать уже со "знанием дела". Kodi потом сам сконвертит изображение в разрешение пользователя.
Я решил попробовать следующую схему:
Попробовать рисовать все поверх некого прокси-окна. Которое будет выше, чем окно с контролами плеера. При этом все нажатия пульта ловить нашим окном и перекидывать в нижнее.
Если этот мега-костыль заработает, то также можно сделать и с отловом перемотки. Ловить нажатие пульта своим окном и если мы уверены, что перематывать "рановато", то не проксировать этот клик ниже (в окно контролов).
Вот такая вот идейка...

Update: правда пользователь может нажимать перемотку не через отрисованные контролы, а просто с пульта (вернее так и происходит чаще всего). Может прозрачный прокси-слой попробовать отрисовывать поверх видео?...

[Roman_V_M]

Сообщение от HAL9000

Д
Как только Kodi запрашивает у ACE Stream кусок из "будущего", то оно также сообщает об этом ACE и тот начинает приоритезировать новые куски в раздаче. В это время (если этих кусков нет) в Kodi включается сообщение "буферизация".

Очень интересно. А как именно Коди сообщает, куда он собирается прыгнуть?

Сообщение от HAL9000

Если же отрисовывать его в новом слое, то можно самостоятельно задать разрешение слоя и рисовать уже со "знанием дела". Kodi потом сам сконвертит изображение в разрешение пользователя.
Я решил попробовать следующую схему:
Попробовать рисовать все поверх некого прокси-окна. Которое будет выше, чем окно с контролами плеера. При этом все нажатия пульта ловить нашим окном и перекидывать в нижнее.
Если этот мега-костыль заработает, то также можно сделать и с отловом перемотки. Ловить нажатие пульта своим окном и если мы уверены, что перематывать "рановато", то не проксировать этот клик ниже (в окно контролов).
Вот такая вот идейка...

Update: правда пользователь может нажимать перемотку не через отрисованные контролы, а просто с пульта (вернее так и происходит чаще всего). Может прозрачный прокси-слой попробовать отрисовывать поверх видео?...

Теоретически, класс xbmcgui.WindowDialog умеет перехватывать события управления. У меня когда-то (до смены API закачки субтитров) работал плагин субтитров на базе моего же микро-фреймворка PyXBMCt, который запускался поверх видео и вполне себе нормально управлялся с пульта, пока не закроешь окно. Кстати, экземпляр WindowDialog всегда рисуется в координатной сетке 1280х720 независимо от фактического разрешения экрана и текущего скина. По крайней мере, геометрия элементов окна в PyXBMCt рассчитывается именно в таком разрешении, и пока никто не жаловался.

[Roman_V_M]

Сообщение от Roman_V_M

Очень интересно. А как именно Коди сообщает, куда он собирается прыгнуть?

Провел некоторые поверхностные исследования. Вопрос снимается. Я в общих чертах понял принцип и смысл вашего вопроса в другом разделе.

[Roman_V_M]

Сообщение от HAL9000

При этом, не нужно пытаться использовать isPlayable=True и setResolvedUrl. Эта схема после таймаута будет выдавать ошибку.

Схема с setResolvedUrl мне нравится двумя моментами.
1. ListItem, передаваемый в setResolvedUrl, автоматически наследует все свойства (инфо-лейблы, картинки) ListItem, из которого он был вызван.
2. Автозакладки и отметки просмотренного (теоретически). Последнее у меня не очень выходит, хотя все свойства вроде бы правильные. Т. е. отметок никаких нет, хотя автозакладки через раз срабатывают.

Недостаток только один, но существенный - setResolvedUrl прерывает выполнение текущего скрипта аналогично sys.exit().

[Roman_V_M]

Кстати, если интересно, при получении контента по http Коди отправляет 3 запроса: HEAD, GET с начала файла и GET с конечной позиции файла.

13:08:57 T:744  NOTICE: Creating InputStream
13:08:57 T:6020  NOTICE: plugin.video.yatp: HEAD
13:08:57 T:6020  NOTICE: plugin.video.yatp: [('Content-Length', ''), ('Accept-Charset', 'UTF-8,*;q=0.8'), ('User-Agent', 'Kodi/15.0 (Windows NT 6.1; WOW64) App_Bitness/32 Version/15.0-Git:20150721-2f34a0c'), ('Accept', '*/*'), ('Host', 'localhost:8668'), ('Content-Type', 'text/plain')]
13:08:57 T:6020  NOTICE: plugin.video.yatp: Playing media: Zoo.S01E05.HDTV.x264-LOL[rarbg]/zoo.105.hdtv-lol.mp4
13:08:57 T:744   DEBUG: CCurlFile::GetMimeType - http://localhost:8668/media/Zoo.S01E05.HDTV.x264-LOL%5Brarbg%5D/zoo.105.hdtv-lol.mp4 -> video/mp4
13:08:57 T:744   DEBUG: CFileCache::Open - opening <media/Zoo.S01E05.HDTV.x264-LOL%5Brarbg%5D/zoo.105.hdtv-lol.mp4> using cache
13:08:57 T:744   DEBUG: CurlFile::Open(0B8F7C88) http://localhost:8668/media/Zoo.S01E05.HDTV.x264-LOL%5Brarbg%5D/zoo.105.hdtv-lol.mp4
13:08:58 T:3288  NOTICE: plugin.video.yatp: GET
13:08:58 T:3288  NOTICE: plugin.video.yatp: [('Content-Length', ''), ('Accept-Charset', 'UTF-8,*;q=0.8'), ('User-Agent', 'Kodi/15.0 (Windows NT 6.1; WOW64) App_Bitness/32 Version/15.0-Git:20150721-2f34a0c'), ('Accept', '*/*'), ('Range', 'bytes=0-'), ('Host', 'localhost:8668'), ('Content-Type', 'text/plain')]
13:08:58 T:3288  NOTICE: plugin.video.yatp: Playing media: Zoo.S01E05.HDTV.x264-LOL[rarbg]/zoo.105.hdtv-lol.mp4
13:08:58 T:744  NOTICE: Creating Demuxer
13:08:58 T:6680  NOTICE: Thread FileCache start, auto delete: false
13:08:58 T:744   DEBUG: CDVDDemuxFFmpeg::Open - probing detected format [mov,mp4,m4a,3gp,3g2,mj2]
13:08:58 T:6680    INFO: XCURL::DllLibCurlGlobal::easy_aquire - Created session to http://localhost
13:08:58 T:6680   DEBUG: CurlFile::CReadState::Connect - Resume from position 324296002
13:08:58 T:7052   DEBUG: ------ Window Init (DialogBusy.xml) ------
13:08:58 T:7052   DEBUG: ------ Window Deinit (DialogProgress.xml) ------
13:08:58 T:6060  NOTICE: plugin.video.yatp: GET
13:08:58 T:6060  NOTICE: plugin.video.yatp: [('Content-Length', ''), ('Accept-Charset', 'UTF-8,*;q=0.8'), ('User-Agent', 'Kodi/15.0 (Windows NT 6.1; WOW64) App_Bitness/32 Version/15.0-Git:20150721-2f34a0c'), ('Accept', '*/*'), ('Range', 'bytes=324296002-'), ('Host', 'localhost:8668'), ('Content-Type', 'text/plain')]
13:08:58 T:6060  NOTICE: plugin.video.yatp: Playing media: Zoo.S01E05.HDTV.x264-LOL[rarbg]/zoo.105.hdtv-lol.mp4
13:08:58 T:744   DEBUG: XFILE::CFileCache::Seek - waiting for position 324361487.
13:08:58 T:6680    INFO: CFileCache::Process - Hit eof.

Как я понимаю, последний запрос выполняется, чтобы проверить, соответствует ли заявленный Content-length реальному.
При прыжках выдается http-запрос с заголовком 'Range' с нужной позиции в байтах. При перемотке никаких запросов не выдается.
Т. е. при реализации выдачи контента по http на сервере прыжки отлавливать можно, но перемотку - никак.

[HAL9000]

В общем, убил я сутки на попытку сделать некое прокси-окно (о чем писал выше). Не вышло у меня в итоге. Событие отлавливаю через "onAction". Пробую послать в слой с контролами плеера (через внутреннюю функцию "Action(id,window)". Не видят они этих экшенов. Может я не правильно определяю слой, в котором висят контролы плеера? Не знаю. Позже еще поковыряю немного в эту сторону. Может что получится.

Сообщение от Roman_V_M

Схема с setResolvedUrl мне нравится двумя моментами.
1. ListItem, передаваемый в setResolvedUrl, автоматически наследует все свойства (инфо-лейблы, картинки) ListItem, из которого он был вызван.
2. Автозакладки и отметки просмотренного (теоретически). Последнее у меня не очень выходит, хотя все свойства вроде бы правильные. Т. е. отметок никаких нет, хотя автозакладки через раз срабатывают.

Если запускать плеер как сторонний плагин (а так в идеале это и надо), то его вызов будет идти через ссылку вида (примерно): plugin://script.module.player/play/какой-то-любой-конетен-в-формате-json
Такими ссылками можно сразу убить двух зайцев (два верхних пункта):
1. В ссылке мы передадим всю инфу по лейбам и картинкам (и плеер уже самостоятельно сварганит ItemInfo).
2. Такие ссылки очень хорошо сохраняются в закладках.

Оффтоп:
Надо вообще уходит от колекционирования фильмов в виде реальной их записи на диск. Мне кажеться, надо просто сохранять такие вот ссылки на торрент-стримы и прилеплять рядом файлы NFO для наведения всякой красоты.
Плюс еще все это брахло синхронизировать с другими своими Коди через какой-нибудь Яндекс.Диск (тут еще и бэкап автоматом нарисовывается). И все. Коллекция ссылок на винте будет занимать пару мегабайт (от силы) а де-факто мы имеем коллекцию FullHD на сотни терабайт. Всякие домашние файло-помойки можно выкидывать на свалку...

[HAL9000]

Сообщение от Roman_V_M

Как я понимаю, последний запрос выполняется, чтобы проверить, соответствует ли заявленный Content-length реальному.

Думаю, что не из-за этого. Некоторые форматы файлов держат информацию по индексам в конце своего файла. Это вкратце обсуждалось в ветке по DelugeStream, начиная вот с этого сообщения.

Сообщение от Roman_V_M

При прыжках выдается http-запрос с заголовком 'Range' с нужной позиции в байтах. При перемотке никаких запросов не выдается.

В том же DelugeStream я так же ориентировался именно на Range из HTTP-запросов. Проблема при прыжках в том, что у Коди срабатывает таймаут пока Deluge пытается быстренько вытащить новые куски. В начале-то фильма мы заставляем пользователя немного подождать, пока загрузится буфер, и потом уже включаем проигрывание видео. А тут он уже стоит на проигрывание и просит "срочно" качнуть ему мегабайт 50-100. Срабатывает таймаут.

Если можно было бы увеличивать программно этот таймаут, то и проблем не было бы. Перед началом фильма увеличил, после окончания вернул старое значение. Но Коди не поддерживает программное изменение этого параметра.

[yevgenb]

Сообщение от HAL9000

Это не страшно. На самом деле там процесс не такой уж и долгий. Тот же Pulsar, прежде чем запустить просмотр, полностью разруливает магнит. То есть у него на руках уже фактически уже есть торрент-файл. Просто steeve по каким-то причинам не стал добавлять выбор конкретного файла, хотя ему оставалось добавить буквально пару строк (может у него концепт такой).

Ему просто не нужно было, я с ним на эту тему переписывался пару лет назад еще на заре xbmctorrent - так и лежит открытый тикет на гитхабе с этого времени. По его словам установка приоритета чанков в либторренте не работала нормально и он забил

[TDW1980]

Оффтоп:
Надо вообще уходит от колекционирования фильмов в виде реальной их записи на диск. Мне кажеться, надо просто сохранять такие вот ссылки на торрент-стримы и прилеплять рядом файлы NFO для наведения всякой красоты.

Я такие ссылки реализовал в своем плагине к Кинопоиску. Получилось вполне сносно.