Печать

[quepassa]

Добрый день!
Я занимаюсь разработкой специального приложения на Android, которое будет выступать в качестве клиента по отношению к вашему серверу tsengine, запускаемому на компьютере, например, в домашней сети.
В процессе разработки я столкнулся с некоторыми сложностями, связанными с взаимодействием с вашим ПО.

Версия tsengine: 2.0.8.6, версия Windows: 7 (x64)

1. Почему сервер, при старте на Windows каждый раз динамически меняет порт, который слушает команды API? Скажу честно, решение странное, тем более, что если я не ошибаюсь, версия сервера под linux не меняет динамически этот порт. Просто становится не очень удобно каждый раз перенастраивать клиента указывая новый порт для соединения в случае рестарта Windows или самого сервера tsengine на этом Windows.

2. Не знаю, в курсе вы или нет, но tsengine запустившись на Windows способен слушать лишь loopback-интерфейс (127.0.0.1). Если же на компе есть еще один сетевой интерфейс (ну, естественно, комп же подключен к лок. сети) и его IP, например, 192.168.1.200 то сервер tsengine не доступен при попытке подключения к нему с указанием этого IP. Это странно, т.к. тот же клиент на Android фактически не имеет возможности подключиться к вашему серверу tsengine. Для того, что бы обойти эту проблему мне пришлось использовать маленькое стороннее приложение portforwarder, которое умеет слушать все интерфейсы на компе и позволяет организовать перенаправление подключений. Я его настроил так: IN (host: *, port: 50555) -> OUT (host: 127.0.0.1, port: 53677 (ваш динамический порт)). Это позволило решить проблему, но все же хотелось бы обойтись без такого промежуточного слоя.

3. Я обнаружил, что при попытке воспроизведения некоторых трансляций (в частности, трансляция  канала 2x2) происходит странное: tsengine как положено качает данные из инета, соответствующий временный файл в папке с кэшами растет в размере, сам tsengine постоянно бомбардирует моего клиента сообщениями о том, что идет процесс скачивания контента

Код: [Выделить]

03-18 14:29:17.485: DEBUG/AceStreamController(12998): ENGINE/IN/EVENT livepos is_live=0 last=6866 live_last=1163 buffer_pieces=22 live_first=321 pos=1136 first_ts=1363601950 last_ts=1363602550
03-18 14:29:18.615: DEBUG/AceStreamController(12998): ENGINE/IN/STATUS main:dl;0;0;375;0;0;15;0;3997696;0;0;{"is_live": true, "live_last_ts": 1363602553, "last": 6866, "have": [[1136, 1160], [1164, 1165]], "live_last": 1164, "live_first": 307, "pos": 1139, "live_first_ts": 1363601953, "first": 0}

подключение к предоставленному им URL http://127.0.0.1:6878/content/b10e8a6910bef2e1924e5593bf310f5dd4802699/0.567822385262

тоже происходит успешно, но вот данные с этого урла похоже не стримятся. Просто ничего не поступает и запущенный медиа-плеер на телефоне тупо ждет пока начнут поступать данные. Я тестировал этот кейс в разном окружении, в частности пытался воспроизвести этот URL и на компе с помощью разных плееров - поведение такое же - ожидание. Я хочу сказать, что tsengine качает контент, URL считает им актуаленым (в его логах не было инфы что он приостановил действие этого урла из-за отсутствия интереса) но по данному урлу ничего нельзя получить. Другой канал, например "Первый канал HD" стримится нормально. Я тестировал только два этих канала. Проверьте сами, это очень странно.

Вот .acelive файл для Первого канала: https://dl.dropbox.com/u/12528791/1TV.acelive
А вот для 2x2: https://dl.dropbox.com/u/12528791/2x2.acelive

И, кстати, проблема, описанная в п.2 (доступность сервера только на loopback) мною также обойдена, так что проблема не в этом. Когда я скармливаю ваш контент-URL  плееру я меняю его host:port на другие значения, которые предоставлены тем же portforwarder, так что коннект к этому урлу реально осуществляется. Просто данные не идут.

4. Я хотел бы еще на всякий случай уточнить, не производит ли сервер tsenigine перекодирование на лету? Я правильно понимаю, что он просто стримит через http тот контент, который скачал из инета as-is никак не меняя его?

Спасибо за ответы

UPD: по п.3. хотел бы добавить что ситуация переменчивая. Иногда поток 2x2 воспроизводится.
UPD 2: опять п.3: проблема касается не только канала 2x2. На любом канале наблюдается такая переменчивость.

[quepassa]

Пункт 3 предлагаю игнорировать. Я разобрался в чем дело. С TS Engine все в порядке. Он реализован таким образом, что дает только одному клиенту подключиться по указанному урлу. Другие соединения ждут, пока тот, первый, отключится.
Так вот проблема была в том, что сторонний плеер на андроиде, который я использовал для воспроизведения почему-то осуществлял два соединения по указанному урлу. В итоге он ничего не мог показать, видимо, вторым соединением как раз было то, что отвечает за вывод картинки на экран, а первое видимо для каких то своих нужд. Что интересно, этим грешит не одна программа. Но есть и такие, которым хватает одного соединения.

[Пур Иванов]

Может я чего-то не понимаю, но по моему вы изобретаете велосипед. TS плеер запускаемый в винде и так может передавать хоть на ТВ, хоть на Андроид, хоть в любую другую сеть, тот сигнал который принимает в винде. Как это сделать написано хотя бы тут http://forum.samez.eu/topic.php?forum=11&topic=12&p=1 Только вместо сети используем Wi-Fi, (3G или что там у вас), а вместо телевизора используем Андроид с любым плеером который умеет проигрывать http поток.

[quepassa]

Вы немного не поняли. Приведенный вами пример работает так: настраивается TS Player таким образом, что организуется дополнительный порт, подключившись к которому можно будет получить поток того, что запущено на самом TS Player. Но, что бы запустить что-то на TS Player надо будет встать с удобного дивана и сделать телодвижения. Особенно, весело так тв-каналы переключать, как в старое доброе время когда телевизоры были без пультов

Я предлагаю скажем так более комфортное решение, но, в связи с ограничениями ACE Stream Engine, использование этого решения осложнено необходимость предварительной нетривиальной работы по конфигурированию.

А вот, собственно, и программа, которую я реализовал.
https://play.google.com/store/apps/details?id=ru.vidsoftware.acestreamcontroller.free

[Constantin]

quepassa, очень интересно и спасибо вам за хорошее и удобное решение.

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