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

[srg70]

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

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

Очень хорошая идея, на мой взгляд. И, по-мому, не стОит бояться С++ . Он хороший

[HAL9000]

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

Но я вот что подумал. Каковы критерии этого отваливания? Если полное отсутствие ответа от сервера, тогда проще.

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

В DelugeStream я пробовал сразу отдавать HTTP заголовок, что все ОК, а потом только выставлял приоритеты на нужные чанки. В целом - работает... Но тут сразу видна дыра - мы не имеем гарантии того, что первый чанк из выставленных в приоритет придет быстро. Если он задержится, то опять будет беда

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

Update:
Еще пробовал отдавать заголовок HTTP 202, но Коди его игнорировал.

[DiMartino]

Парни, подскажите, вот есть класс http сервера StreamServer и есть там цикл ожидания запроса, что естественно, но почему как только класс заводится у меня никогда не пропадает справа внизу "Подождите" и пока его не убьешь правой кнопкой мыши гуи плеера недоступно. Пытался запустить этот класс в отдельном потоке через thread, но результат тот же. Из подробностей скажу только что перемотка работает, я запускал скрипт в отдельном python, потом запускал урл в Коди и пытался перемотать, все работало.


Упс, скорее всего было из-за isFolder листайтема.

[Roman_V_M]

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

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

Интересная информация. Сам класс представляет собой несколько модифицированный стандартный питоновский HTTP-сервер и интереса не представляет. Зато хендлер запросов ниже интересен хотя бы тем, какие заголовки он добавляет к ответу.

[Roman_V_M]

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

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

В DelugeStream я пробовал сразу отдавать HTTP заголовок, что все ОК, а потом только выставлял приоритеты на нужные чанки. В целом - работает... Но тут сразу видна дыра - мы не имеем гарантии того, что первый чанк из выставленных в приоритет придет быстро. Если он задержится, то опять будет беда


Update:
Еще пробовал отдавать заголовок HTTP 202, но Коди его игнорировал.

А как насчет (206, 'Partial Content'), как в реализации ниже, которую нашел DiMartino, и отдавать то, что реально имеем?

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

Мне в работе с локальным контентом (не через сервер) не нравится то, что мы не можем никак узнать, какие куски нужны Коди в данный момент. Или я чего-то не понимаю.

[DiMartino]

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

Интересная информация. Сам класс представляет собой несколько модифицированный стандартный питоновский HTTP-сервер и интереса не представляет. Зато хендлер запросов ниже интересен хотя бы тем, какие заголовки он добавляет к ответу.

Я же говорил, что тема клевая, мы уже тестирует Торрентер с этим проигрывателем, перемотка отлично работает на популярных раздачах, как говорится, ни единого разрыва. Другой вопрос в начале и конце воспроизведения у меня на компе жуткие лаги от этого всего, боюсь что будет на слабых машинах. Хорошо бы если ты себе вставил наработки izderadicka. Могу выложить что уже есть, посмотришь.

[HAL9000]

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

А как насчет (206, 'Partial Content'), как в реализации ниже, которую нашел DiMartino, и отдавать то, что реально имеем?

Я писал уже, что DelugeStream работает на основе заголовка Range. А Range без Partial Content не работает. Только в связке с ним.

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

Мне в работе с локальным контентом (не через сервер) не нравится то, что мы не можем никак узнать, какие куски нужны Коди в данный момент. Или я чего-то не понимаю.

С точностью до бита (как в случае с HTTP и Range) не узнаем. Это так. Но можно смотреть на прогресс-бар. Он в процентах. Нужно только хотя бы примерно рассчитать битрейт видео, чтобы проценты сконвертировать в биты.

И еще.
Я не уверен, что те форматы, которые FullHD (всякие там Аватары с файликами по 40 Гбайт), можно смотреть через HTTP. Но это уже спецы должны подсказать. Я в форматах - середнячок и четверочник

[HAL9000]

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

Я же говорил, что тема клевая, мы уже тестирует Торрентер с этим проигрывателем, перемотка отлично работает на популярных раздачах, как говорится, ни единого разрыва. Другой вопрос в начале и конце воспроизведения у меня на компе жуткие лаги от этого всего, боюсь что будет на слабых машинах. Хорошо бы если ты себе вставил наработки izderadicka. Могу выложить что уже есть, посмотришь.

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

[Roman_V_M]

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

Хорошо бы если ты себе вставил наработки izderadicka. Могу выложить что уже есть, посмотришь.

Выкладывайте. Информации много не бывает.

[DiMartino]

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

Выкладывайте. Информации много не бывает.

Выложил в свое репо тестовую версию, еще не все функции работают, но уже понятно как оно будет выглядеть.

Установить Torrenter 2.3.6 из репо, зависимости подтянутся
В настройках Libtorrent выбрать версию 1.0.6 (с 0.16.19 не работает)
В настройках Torrenter в качестве плеера установить BTClient

Лучше попробовать играть .torrent, хотя и через поиск должно работать. По результатам отпиши, интересно.