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

[Roman_V_M]

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

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

А может поступить проще? Перехватывать события управления, но плеером управлять штатными методами (xbmc.Player, JSON-RPC или built-ins).

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

Да, я понял уже эту засаду. А что если в ответ на запрос отсутствующего куска сервер, в свою очередь, поставит Коди на паузу, например по JSON-RPC, пока он будет докачивать куски? А по окончании снимет с паузы. Надо попробовать такой вариант.

Единственный момент - нужно организовать какой-то фидбек для юзера о состоянии буферизации. DialogProgress, используемый при буферизации, не подходит - он вешает Коди при попытке вывести его поверх видео. Можно выводить информацию прямо на экран или использовать вариант на базе WindowDialog/WindowDialogXML.

[TDW1980]

А вы не думали о воспроизведении с нужного момента
Пользователь перемотал на n%
Событие произошло % известен. Делаем СТОП
Буферизируем с этого участка.
И начаинаем воспроизведение с нужного фрагмента
Хотя это совсем криво конечно. Наверняка можно найти более элегантное решение.

[Roman_V_M]

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

А вы не думали о воспроизведении с нужного момента
Пользователь перемотал на n%
Событие произошло % известен. Делаем СТОП

Откуда известен? Если вы думаете использовать события xbmc.Player, то они работают криво.

[TDW1980]

а в чем криво? я год назад примерно пробовал с эйсом экспериментировал, когда там тоже перемотка не работала. Событие перемотки отлавливалось вроде нормально а вот команду эйсу передать не получалось.

[Roman_V_M]

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

а в чем криво?

События не всегда отлавливаются. Например, onPlaybackSeek срабатывает при длинном прыжке (клавиша вверх), но не срабатывает при коротком (клавиша вправо).

[TDW1980]

незнал. я когда с этим событием игрался мышкой по прогрессбару нажимал. и почти сразу понял что мне это не поможет, забросил.
А если в цикле запустить
getTime(self)
и мониторить позицию воспроизведения?
Хотя вы уже нашли гораздо лучшее решение

на запрос отсутствующего куска сервер, в свою очередь, поставит Коди на паузу, например по JSON-RPC

[HAL9000]

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

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

Это он погорячился. Надо было добивать. Либторрент нормально работает с приоритезацией чанков.

[HAL9000]

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

А что если в ответ на запрос отсутствующего куска сервер, в свою очередь, поставит Коди на паузу, например по JSON-RPC, пока он будет докачивать куски? А по окончании снимет с паузы.

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

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

А может поступить проще? Перехватывать события управления, но плеером управлять штатными методами (xbmc.Player, JSON-RPC или built-ins).

Я как раз на днях и пытался это сделать. Я про свое прокси-окно. Я хотел отлавливать все события от юзера и самостоятельно принимать решения что с ними делать (в зависимости от состояния плеера и либторрента). При этом, нам нужны всего несколько экшенов (пауза, перемотка и т.д.).
А остальные события (не нужные нам) необходимо было проксировать в нижнее окно (то, которое с контролами плеера). Так вот как раз проксирование у меня и не получилось. А оно нужно, так как там в контролах меню ОГРОМНОЕ. Всякие субтитры, звуковые дороги и т.д. Нельзя же лишаться всего этого...

Или засучить рукава и все-таки сделать ручками конвертор всех 100% событий в команды JSON-RPC... Теоретически... оно наверное будет работать... Но за такой объем работы страшно браться
Думаю надо еще помучить думалку Может поэлегантней решение придет в голову...

[yevgenb]

Может все таки нттр поток отдавать? Xbmctorrent вроде умел неплохо прыгать с места на место

[Roman_V_M]

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

Может все таки нттр поток отдавать? Xbmctorrent вроде умел неплохо прыгать с места на место

Наша песня хороша, начинай сначала. А мы что здесь на последних нескольких страницах обсуждаем? Кроме того, в Xbmctorrent, как и в Пульсаре, самое интересно написано на golang, и исходники этого "самого интересного" закрыты.

Проблема с http в том, что не получив данных в течение некоторого времени, Коди отваливается по таймауту. Если не ошибаюсь, по умолчанию таймаут составляет 10 с.
Но я вот что подумал. Каковы критерии этого отваливания? Если полное отсутствие ответа от сервера, тогда проще.

У себя в YATP я серверную часть реализовал на базе WSGI - стандартного питоновского протокола для веб-приложений. Особенность этого протокола в том, что WSGI-сервер ожидает на входе любой итерируемый объект, который затем побайтно скармливает клиенту.

Короче, можно написать кастомный обработчик файлов с интерфейсом итератора, который будет передавать файл от сервера клиенту (Коди). Если Коди запрашивает отсутствующий кусок, обработчик файлов, в свою очередь, начинает буферизацию, ставя первому куску запрошенного фрагмента максимальный приоритет. При этом обработчик следит за таймаутом и как только таймаут подходит к концу, скармливает Коди небольшую порцию данных, например 1 КБ, чтобы Коди продолжил ожидать завершения буферизации. И так, пока буферизация не закончится, обработчик периодически скармливать маленькие куски данных, поддерживая соединение. А когда буфер нужного размера заполнится, обработчик опять начать выдавать данные на нормальной скорости.
Т. е. нам нужен некий обработчик файлов с интерфейсом итератора, умеющий контролируемо выдавать куски файла.
Единственное, что меня беспокоит - производительность такого решения. bottle, на базе которого сделана серверная часть YATP, при выдаче файла скармливает WSGI-серверу стандартный питоновский файловый объект (open), написанный на C, а значит очень быстрый.
Как бы не пришлось писать этот обработчик файлов на C++ или на худой конец на Cython и компилировать в бинарный модуль.