Printable View
Да я наверное больше "к сведению", чем проблема/баг.Quote:
Originally Posted by AlexeyS
Насколько я понимаю в это процессе участвуют провайдер+роутер+плеер (в моем случае - vlc).
Самый непредсказуемый это наверное провайдер (невалинк, питер).
Не являюсь ярым фанатом ТВ, поэтому работает "из коробки" - неплохо, если не работает - не трагедия. Но, время тратить на его настройку совсем не хочется.
Всезнающий Олл !
Вопрос следующего плана: есть желание использовать UDP_to_HTTP прокси во избежание тормозов и искажений при просмотре... не важно под какую платформу, важна суть...
Attachment 9666
Соответственно 192.168.1.1 адрес на домашнем роутере который должен принимать мультикаст-пакеты в порт 4022 и транслировать поток по HTTP.
Wan-IP-Address соответственно мой адрес инет-подключения.
Свой провайдер не вещает IP - телевидение, по-этому пользуюсь попавшимися в инете рабочими плей-листами...
Могу ли адреса из попавшегося рабочего плей-листа, например:
#EXTINF:0,5 Канал
http://109.87.126.216:81/udp/238.0.0.6:1234
#EXTINF:0,7 Канал
http://109.87.126.216:81/udp/238.0.64.8:1234
и др.
просматривать используя СВОЙ прокси ? или это глупая затея ?
Помогите решить проблему с udpxy. У меня наблюдается вот что:
После перезагрузки роутера я открываю VLC-плеер и вбиваю адрес интересующего меня HD-канала: http://wan_ip:1212/udp/адрес:1234
Всё показывает идеально, никаких нареканий. После чего я либо переключаюсь на другой канал из плейлиста, либо переподключаюсь по той же ссылке, к тому же каналу.
И начинает жутко хлюпать и квадратить.
Далее я захожу в браузере по ссылке http://wan_p:1212/status и жму Restart. Снова подключаюсь из VLC к каналу и снова всё хорошо. Попытка повторного подключения - и снова всё плохо.
Т.е. проблема заключается в том, что updxy даёт мне возможность безглючно подключаться к себе только один раз после рестарта.
Если что, то у меня роутер Asus RT-N10U, прошивка 1.9.2.7-rtn, версия udpxy там 1.0-23.9 (prod).
Подскажите, кто в курсе, с чем может быть связана проблема? Как решить?
может проблема в том, что при переключении или переподключении роутер считает это другим потоком, т.е. запускает второй процесс.
посмотрите логи и команду ps давайте.
а на второй поток может просто не хватать мощности процессора.
Скажу сразу, что я запуск врукопашную с вручную указанными параметрами в post-firewall не прописывал, переменные окружения не трогал.
Т.е. udpxy запускается как оно и есть в прошивке по умолчанию.
ps сразу после рестарта:
[admin@RT-N10U root]$ ps
PID USER VSZ STAT COMMAND
1 admin 1520 S /sbin/init
2 admin 0 SW< [kthreadd]
3 admin 0 SW< [ksoftirqd/0]
4 admin 0 SW< [events/0]
5 admin 0 SW< [khelper]
27 admin 0 SW< [kblockd/0]
56 admin 0 SW [pdflush]
57 admin 0 SW [pdflush]
58 admin 0 SW< [kswapd0]
109 admin 0 SW< [mtdblockd]
198 admin 1380 S syslogd -m 0 -O /tmp/syslog.log -S -D -l 7 -b 1
200 admin 1380 S klogd
202 admin 956 S eapd
204 admin 1148 S nas
208 admin 1380 S telnetd
211 admin 1184 S dropbear -4
213 admin 1084 S httpd vlan1
218 nobody 1028 S dnsmasq
219 admin 944 S miniupnpd
232 admin 0 SW< [khubd]
236 admin 1016 S lld2d br0 eth1
272 admin 768 S {p910nd} p9100d -f /dev/lp0 0
319 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
322 admin 800 S /usr/sbin/igmpproxy /etc/igmpproxy.conf
323 admin 1392 S /sbin/udhcpc -i vlan1 -p /var/run/udhcpc0.pid -b -O3
325 admin 1520 S watchdog
329 admin 900 S infosrv br0
336 admin 1252 R dropbear -4
337 admin 1388 S -sh
356 admin 1384 R ps
После подключения к прокси из VLC-плеера:
[admin@RT-N10U root]$ ps
PID USER VSZ STAT COMMAND
1 admin 1520 S /sbin/init
2 admin 0 SW< [kthreadd]
3 admin 0 SW< [ksoftirqd/0]
4 admin 0 SW< [events/0]
5 admin 0 SW< [khelper]
27 admin 0 SW< [kblockd/0]
56 admin 0 SW [pdflush]
57 admin 0 SW [pdflush]
58 admin 0 SW< [kswapd0]
109 admin 0 SW< [mtdblockd]
198 admin 1380 S syslogd -m 0 -O /tmp/syslog.log -S -D -l 7 -b 1
200 admin 1380 S klogd
202 admin 956 S eapd
204 admin 1148 S nas
208 admin 1380 S telnetd
211 admin 1184 S dropbear -4
213 admin 1084 S httpd vlan1
218 nobody 1028 S dnsmasq
219 admin 944 S miniupnpd
232 admin 0 SW< [khubd]
236 admin 1016 S lld2d br0 eth1
272 admin 768 S {p910nd} p9100d -f /dev/lp0 0
319 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
322 admin 800 S /usr/sbin/igmpproxy /etc/igmpproxy.conf
323 admin 1392 S /sbin/udhcpc -i vlan1 -p /var/run/udhcpc0.pid -b -O3
325 admin 1520 S watchdog
329 admin 900 S infosrv br0
336 admin 1252 R dropbear -4
337 admin 1388 S -sh
355 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
356 admin 1384 R ps
----------
Т.е. второй процесс с pid 355 как бы появился. Но разве это так и не должно быть? Или по-вашему при этом процесс с pid 319 должен был пропасть?
При последующих перезапусках ссылки из VLC процессы не плодятся, их остаётся два, только вместо pid 355- там каждый раз новый pid.
Опытным путём установил, что проблема вот в чём.
Постоянно запущенным является серверный процесс udpxy (с pid 319).
Каждый раз при подключении к прокси создаётся также клиентский процесс, каждый раз с новым pid. (пусть для примера - 355)
Пусть в VLC-плеере у меня показывает канал (поток, соответствующий клиентскому процессу с pid 355). Если (пока канал показывает) я в плейлисте жамкаю на другой канал или даже на этот же - то, судя по всему, происходит попытка запустить новый клиентский процесс перед тем, как не умер ещё старый (с pid 355). Это и приводит к тому, что вновь запущенный клиентский процесс начинает лагать/квадратить.
Если же я перед перещелкиванием на другой канал перезапускаю VLC-плеер или в явном виде убиваю старый клиентский процесс:
kill -19 355
то перезапуск канала приводит к полному успеху (т.е. отсутствию любых лагов).
--------------
Ну то есть вы поняли проблему: при быстром переключении на другой канал в плейлисте VLC (пока показывает первый) - возникает ситуация, что новый клиентский процесс (для нового канала) пытается запуститься пока старый (для проигрывающегося канала) ещё живой. В итоге, конечно, ps мне показывает, что после этого живёт только новый клиентский процесс, но он по факту оказывается ущербным (лагающим).
-----------
Если про эту особенность знать, то конечно перед переключением на другой канал можно перезапускать VLC-плеер (или даже рестартить прокси через страницу статуса), чтобы старый клиентский процесс гарантированно сдох. Вот только все нормальные люди хотят в VLC (или в IP-TV плеере) быстро переключаться по каналам. И, как правило, люди делают именно так: жамкают на другой канал пока старый ещё играет.
Что можно поделать?
У меня такое ощущение, что я разговариваю на этом форуме сам с собой =)
Чтобы окончательно отринуть версию о "нехватке мощности процессора" роутера я специально установил Ubuntu на виртуальную машину. Далее я перепробовал устанавливать все версии udpxy отсюда:
sourceforge.net/projects/udpxy
от самых старых, до самых новых. Во всех версиях одно и то же: начинает квадратить после быстрого переключения на следующий канал без предварительного отключения от уже проигрываемого. Кстати, заметил, что битрейт потока после такого переключения ниже должного. В том смысле, что если остановить просмотр канала кнопкой СТОП, чуть подождать и только потом запускать следующий канал, то битрейт потока у него будет правильный и всё будет чётко. Если же прямо во время просмотра канала щёлкнуть на следующий, то в свойствах потока для него я вижу битрейт вдвое ниже положенного и половина кадра - зелёные квадраты. Баг лучше всего заметен на HD-каналах (битрейты от 8 до 15 Мб/c) в VLC и Ip-tv-плеерах. С телека (в программах Smart IPTV, SS IPTV) эффект схожий, хотя и не так ярко выражен, т.к. эти программы в силу своей тормозной природы долго переключают каналы и, видимо, клиентский процесс udpxy для старого канала всё-таки зачастую успевает сдохнуть до запуска клиентского процесса для нового канала. Но если быстро щёлкать каналы один за другим, то в итоге приходим всё к тому же, к квадратам.
Вроде бы описываемая проблема не является в отдельности ни проблемой VLC, ни проблемой udpxy, но в связке она хорошо выражена.
Испытал также программу для Windows - UDP-to-HTTP прокси (borpas.info/utils). Вот с ней такого бага нету, работает чётко. Но мне нужна прокси именно на роутере, чтоб работала при выключенных компах. Так что программа под винду мне не подходит.
Перепробовал использовать все доступные параметры командной строки для запуска, во всех мыслимых и немыслимых комбинациях. Т.е. жонглирование параметрами -B, -R, -H, -n привело к потере времени, а к успеху не привело.
Есть ли смысл следующим шагом исследовать влияние заявленных переменных окружения? Я имею в виду вот эти:
UDPXY_RCV_TMOUT, UDPXY_DHOLD_TMOUT, UDPXY_SREAD_TMOUT, UDPXY_SWRITE_TMOUT, UDPXY_SSEL_TMOUT, UDPXY_LQ_BACKLOG
UDPXY_SRV_RLWMARK, UDPXY_SSOCKBUF_NOSYNC, UDPXY_DSOCKBUF_NOSYNC, UDPXY_TCP_NODELAY, UDPXY_HTTP200_FTR_FILE, UDPXY_HTTP200_FTR_LN,
UDPXY_ALLOW_PAUSES, UDPXY_PAUSE_MSEC.
Может изменение каких-либо из них помочь проблеме или это будет опять пустая трата времени?
В сущности, мне надо добиться того, чтобы прокси рестартилась перед каждым к ней обращением (перед созданием нового клиентского процесса). Хотя бы так. Или же, если уже установлено соединение прокси с клиентом с определенным ip, то при попытке нового обращения к ней с того же ip - чтобы она в явном виде сначала убивала старый клиентский процесс, а потом только запускала новый.
Автор программы (Паша Черенков), который активно тестировал прогу на первых страницах темы, - уже забросил проект?
Попробуйте ради интереса мою прошивку - там есть udpxy в составе
Под видной понятно -там ресурсов больше
Кстати иногда для решения проблем помогает включение свопа!
Очень мало народа вообще в курсе темы, а уж в потроха udpxy не залезал никто.Quote:
Originally Posted by Npspacer
Это замечательно что проверили работу на Ubuntu со свежими ядрами, значит ньюанс в подписке/отписке на мультикаст в самом udpxy.
Судя по сайту автора http://www.udpxy.com/ они заняты коммерческим вариантом - Gigapxy.Quote:
Автор программы (Паша Черенков), который активно тестировал прогу на первых страницах темы, - уже забросил проект?
AndreyPopov
Самому udpxy своп как рыбке зонтик - если уж поток пойдёт в своп, то это будут уже не квадраты, а треугольники ;)
Там банально не хватает ресурсов процессора на несколько потоков HD одновременно, udpxy очень сильно нагружает любой процессор - а квадратит, потому как не успевает выбирать очереди.Quote:
Originally Posted by lly
В свап может выгружаться что-то другое, чтобы освободить ресурсыQuote:
Originally Posted by lly
А пробовали запускать udpxy с опцией -с 1 - один клиент?Quote:
Originally Posted by Npspacer
С опцией -с 1, честно говоря, не пробовал. Т.к. приемлемым будет не в принципе ограничить число клиентов одним, а ограничить число клиентов с одного конкретного айпи одним (чтобы со всякого ip можно было одновременно смотреть не более одного тв канала). Но всё-таки проверю, помогает ли это в принципе.
Что касается нехватки ресурсов любого процессора на несколько потоков HD одновременно, то получается, что два - уже много что ли? Да и то, после переключения канала старый клиентский процесс (от старого канала) должен бы умирать, а оставаться только один новый клиентский процесс (для нового канала). Связан ли баг с тем, что в какой-то малый миг существуют оба процесса и это приводит к дальнейшим глюкам? Я не знаю..
Виндовая прокси почему-то позволяет смотреть много HD-каналов сразу и процессор даже не жужжит, справляется легко...
В сущности меня бы устроило от прокси добиться того, чтобы она гарантированно убивала все старые клиентские процессы перед каждым новым обращением, т.е. созданием нового клиентского процесса.
----
Или даже устроило бы рестартить прокси перед каждым новым обращением. Ну типа перед каждым переключением на другой тв-канал (http://ip_роутера:1212/udp/адрес:1234) засылать GET-запрос на URL "http://ip_роутера:1212/restart/". Занимает рестарт, как я понимаю, около 15 миллисекунд. Ведь "на свежую голову", т.е. сразу после рестарта прокси показывает прекрасно любой HD-канал, это факт. Увы, ни VLC-плеер, ни имеющиеся программы IPTV для телевизоров - этого не делают, т.е. запросы на рестарт прокси не посылают (даже не знают, что получают поток от udpxy).
----
Я понимаю, что код udpxy никто особо не ковырял. Но может кто-то в принципе неплохо шарит и подскажет, какое изменение нужно внести в исходный код udpxy, чтобы прокся сама себя рестартила перед каждым новым подключением?
рассмотрим примерно как все происходит:Quote:
Originally Posted by Npspacer
- вы смотрите один канал, под него сформировался поток
- потом вы переключаетесь на другой канал
ведь udpxy не в курсе, что вы просто переключили канал. udpxy получил запрос на формирование нового потока
но старый-то поток убить ему кто-то должен сказать. делает ли это плеер? или udpxy сам решает когда убить поток по отсутствию запросов на поток?
ну мягко говоря - это НЕправильное поведение, потому что вдруг у udpxy несколько клиентов подключены? и что? каждый раз, когда кто-то переключает канал у всех должна прерываться трансляция?Quote:
Originally Posted by Npspacer
Ну да, судя по всему сам решает. Потому что по факту старый поток (точнее старый клиентский процесс) после переключения реально не существует. Во-всяком случае, ps показывает, что появился новый клиентский процесс с другим pid, а старого уже нету. Вот только этот новый клиентский процесс почему-то становится ущербным и квадратит. Хотя, если в плеере нажать в явном виде кнопочку СТОП (а не просто даблкликнуть по другому каналу), а потом запустить новый канал - то всё хорошо.Quote:
Originally Posted by AndreyPopov
Понимаю, что неправильное. Но на крайняк меня устроит и это для моих целей. Ну а GET-запрос на рестарт может всё равно послать кто угодно, это не запрещено. Т.е. каждый может итак оборвать трансляцию всем простым переходом по ссылке "http://ip_роутера:1212/restart/" в браузере...Quote:
Originally Posted by AndreyPopov
убивание(остановка) процесса тоже занимает некоторое время.
я так понимаю с начала создается новый процесс, а уж потом убивается старый. вот новому ресурсов не хватает.
а ресурсы освобождаются уже после убийства старого процесса.
потому и предлагаю свап - при недостатке ресурсов неактивный процесс может быть выгружен в свап.