nginx-rtmp + дополнительные аргументы + флеш плеер

1,399 views
Skip to first unread message

tos

unread,
Jan 22, 2013, 11:18:57 AM1/22/13
to nginx-...@googlegroups.com
Пытаюсь сделать авторизацию стримов используя директиву on_play
Конфиг nginx

[skip]
    server {
        listen 1940;
        application q {
        live on;
        pull rtmp://backend-server:1935 app=live live=1;
        }
}
[skip]
В числе параметров для авторизации анализируются в том числе передаваемые дополнительные параметры, то есть строка, передаваемая клиенту выглядит так
rtmp://server:1940/q/StreamName?login=qwerty
Если я эту строку скармливаю ffprobe - всё работает, как описано в документации. 
Если пытаюсь скормить флеш-плееру - тот не может законнектится, причём причина - дополнительный параметр, без него - работает.
Проверял также без директивы on_play, просто используя модуль как ретранслятор - с дополнительными параметрами флеш-плеер (OSMF) не работает. 
Точно такая же конструкция на wowza работает без нареканий. 
Также плейлисты для XBMC с дополнительным параметром(и) для wowza работают, для nginx-rtmp - нет.
В чём может быть проблема?

Roman Arutyunyan

unread,
Jan 22, 2013, 11:29:37 AM1/22/13
to tos, nginx-...@googlegroups.com
Вы должны передавать дополнительный параметр к имени стрима, а не к имени приложения.
Проверьте, что делаете именно так.

2013/1/22 tos <t...@tos.org.ua>

--
 
 



--
--
Roman Arutyunyan

tos

unread,
Jan 22, 2013, 11:46:45 AM1/22/13
to nginx-...@googlegroups.com, tos


вторник, 22 января 2013 г., 18:29:37 UTC+2 пользователь Roman Arutyunyan написал:
Вы должны передавать дополнительный параметр к имени стрима, а не к имени приложения.
Проверьте, что делаете именно так.
Именно так и делаю. 
Скрипт авторизации (который ВСЕГДА выдаёт 200) подтверждает передачу параметров, но только с использованием ffprobe.
Строка 
rtmp://server:1940/q/StreamName?login=qwerty
одинакова для всех плееров. 
UPD. Только что проверил на другом плеере (отдельно указывается Server+app, отдельно Stream+args). Так работает.
Однако для wowza работает несколько другая комбинация Server+app+args и отдельно Stream.
Получается несколько неодинаковое поведение. 
К тому же для многих плееров ссылка указывается в полном виде (rtmp://server:1940/q/StreamName?login=qwerty).
Как заставить проверять аргументы как у wowza?

Roman Arutyunyan

unread,
Jan 22, 2013, 11:51:33 AM1/22/13
to tos, nginx-...@googlegroups.com
А какой у вас плеер?

2013/1/22 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 22, 2013, 11:58:06 AM1/22/13
to nginx-...@googlegroups.com, tos


вторник, 22 января 2013 г., 18:51:33 UTC+2 пользователь Roman Arutyunyan написал:
А какой у вас плеер?
Уже используется отдельно написанный на базе osmf. Плеер поменять пока возможности нет - на него много завязано.
Работу всех стримов проверяю на вот этом

Да и пользователи пользуются плейлистами, тоже не хотелось бы их формат менять.
Да и wowza пока трудится, поэтому зоопарка с форматами не хотелось бы.
Плеер из примеров для wowza работает в указанной последовательности.

Roman Arutyunyan

unread,
Jan 22, 2013, 12:01:28 PM1/22/13
to tos, nginx-...@googlegroups.com
Aга, вижу, osmf передает параметры в имени приложения. Подумаю, что можно сделать.

Roman Arutyunyan

unread,
Jan 22, 2013, 1:41:34 PM1/22/13
to tos, nginx-...@googlegroups.com
Выкачайте новый мастер. Я поправил это.
OSMF (он же strobe) шлет эти параметры два раза - один раз при коннекте, второй - в play.
Первое сейчас просто игнорится чтобы  правильно находилось приложение.

Жду от вас ответа.

2013/1/22 Roman Arutyunyan <arutyuny...@gmail.com>



--
--
Roman Arutyunyan

tos

unread,
Jan 22, 2013, 4:36:58 PM1/22/13
to nginx-...@googlegroups.com, tos
Спасибо за оперативность! Так работает.
Насколько я понял событие Connect в модуле не контролируется?
Если это так, то это потенциальная дыра - клиент в состоянии connect может находиться некоторое время не переходя ни в состояние play ни в состояние publish. 
В той же вовзе первым контролируется как раз событие Connect, а затем только - Play и Publish.
То есть для полноценного контроля таки напрашивается директива on_connect


Вівторок, 22 січня 2013 р. 20:41:34 UTC+2 користувач Roman Arutyunyan написав:

Roman Arutyunyan

unread,
Jan 22, 2013, 4:57:48 PM1/22/13
to tos, nginx-...@googlegroups.com
Да, такого события не было т.к. не было никаких аргументов, которые можно было там проверить.
А насчет дыры - клиент в любом случае сможет совершенно спокойно находиться в состоянии "до connect".
Состояние connect никаких преимуществ клиенту не дает, оно лишь определяет приложение.
В nginx клиент не создает сколь либо значимой нагрузки на сервер, в отличие от wowza.

А с on_connect не все так просто. Он получается не вполне интуитивный.

2013/1/23 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 23, 2013, 6:05:38 PM1/23/13
to nginx-...@googlegroups.com, tos
Роман, а какие параметры передаются обработчику при включённой директиве on_update?

Roman Arutyunyan

unread,
Jan 24, 2013, 12:21:53 AM1/24/13
to tos, nginx-...@googlegroups.com
name и args

2013/1/24 tos <t...@tos.org.ua>
Роман, а какие параметры передаются обработчику при включённой директиве on_update?

--
 
 



--
--
Roman Arutyunyan

Roman Arutyunyan

unread,
Jan 24, 2013, 12:22:31 AM1/24/13
to tos, nginx-...@googlegroups.com
ну и, конечно, все стандартрые переменные типа flashVer, pageUrl и т.д.

2013/1/24 Roman Arutyunyan <arutyuny...@gmail.com>



--
--
Roman Arutyunyan

tos

unread,
Jan 24, 2013, 1:56:56 AM1/24/13
to nginx-...@googlegroups.com, tos
Ситуация такая, подключил директиву on_update, скармливаю обработчику.
В обработчике разбираю параметры (addr, name и один из args). Для контроля пишу в лог.
Получается интересное - первый запрос апдейта идёт с ожидаемыми параметрами, второй - передаётся name, в качестве addr - server_address:server_port, args  - пустой. Следующий запрос - опять ожидаемые параметры и так далее.
В чём ошибка?

Четвер, 24 січня 2013 р. 07:21:53 UTC+2 користувач Roman Arutyunyan написав:

tos

unread,
Jan 24, 2013, 2:01:04 AM1/24/13
to nginx-...@googlegroups.com, tos


Четвер, 24 січня 2013 р. 08:56:56 UTC+2 користувач tos написав:
Ситуация такая, подключил директиву on_update, скармливаю обработчику.
В обработчике разбираю параметры (addr, name и один из args). Для контроля пишу в лог.
Получается интересное - первый запрос апдейта идёт с ожидаемыми параметрами, второй - передаётся name, в качестве addr - server_address:server_port, args  - пустой. Следующий запрос - опять ожидаемые параметры и так далее.
Добавлю. Запрсы идут один за одним, а не через notify_update_timeout.
 

Roman Arutyunyan

unread,
Jan 24, 2013, 4:00:29 AM1/24/13
to tos, nginx-...@googlegroups.com
Так, вероятно, это запросы от разных соединений.
Для каждого соединения должен идти свой on_update.

"server_address:server_port" - прям такая строка приходит?

2013/1/24 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 24, 2013, 4:05:04 AM1/24/13
to nginx-...@googlegroups.com, tos


четверг, 24 января 2013 г., 11:00:29 UTC+2 пользователь Roman Arutyunyan написал:
Так, вероятно, это запросы от разных соединений.
Нет, это одно соединение. Сервер тестовый и клиент ровно один.
 
Для каждого соединения должен идти свой on_update.

"server_address:server_port" - прям такая строка приходит?

Ну нет конечно, приходит имя сервера и порт, на котором слушает модуль.

Roman Arutyunyan

unread,
Jan 24, 2013, 4:09:42 AM1/24/13
to tos, nginx-...@googlegroups.com
А в стате что?
Кстати, апдейты будут приходить как для publish-клиента, так и для play.
Кроме того, у вас сколько воркеров? Вероятно, это auto-push.

В общем, покажите статистику, станет ясно. И еще во все нотификации передается
параметр call. Чему он у вас равен?

2013/1/24 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 24, 2013, 4:27:51 AM1/24/13
to nginx-...@googlegroups.com, tos


четверг, 24 января 2013 г., 11:09:42 UTC+2 пользователь Roman Arutyunyan написал:
А в стате что?
Да, Вы правы. В стате - 2 коннекшена - клиентский и инициированный pull-ом.
 
Кстати, апдейты будут приходить как для publish-клиента, так и для play.
Ммм, а как быть если я не просил апдейта для publish (у меня модуль в позе ретранслятора)?
Можно ввести отдельно on_play_update, on_publish_update? 

Кроме того, у вас сколько воркеров? Вероятно, это auto-push.

Такое происходит и с 1-м воркером.
 
В общем, покажите статистику, станет ясно. И еще во все нотификации передается
параметр call. Чему он у вас равен?
Разный для разных событий. В принципе можно по нему фильтровать. 
В общем тоже решение. Спасибо за подсказку.

Roman Arutyunyan

unread,
Jan 24, 2013, 4:32:36 AM1/24/13
to tos, nginx-...@googlegroups.com
Play от publish вы можете легко отделить в самом запросе по аргументу call: update_play или update_publish.

tos

unread,
Jan 24, 2013, 4:42:17 AM1/24/13
to nginx-...@googlegroups.com, tos


четверг, 24 января 2013 г., 11:32:36 UTC+2 пользователь Roman Arutyunyan написал:
Play от publish вы можете легко отделить в самом запросе по аргументу call: update_play или update_publish.

Уже так и делаю. Просто в доке об этих аргументах ни слова :(

И ещё вопрос.
Как для приложения можно ограничить количество клиентов, исполняющих play?

Roman Arutyunyan

unread,
Jan 24, 2013, 5:14:27 AM1/24/13
to tos, nginx-...@googlegroups.com
on_play, on_play_done

tos

unread,
Jan 24, 2013, 5:48:10 AM1/24/13
to nginx-...@googlegroups.com, tos
Возможно мы друг друга не поняли.
Мне надо, в случае, если пришёл на приложение N-ый клиент, отказывать ему в обслуживании. Либо, как опция, - делать редирект на другой URL.
То есть суммарно в приложении - не более заданного числа клиентов.

четверг, 24 января 2013 г., 12:14:27 UTC+2 пользователь Roman Arutyunyan написал:

Roman Arutyunyan

unread,
Jan 24, 2013, 6:08:01 AM1/24/13
to tos, nginx-...@googlegroups.com
Я понял. Я предложил вам самому считать число зрителей в on_play и on_play_done.
Там же проверять, не превышено ли максимальное значение.

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

2013/1/24 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 25, 2013, 9:38:51 AM1/25/13
to nginx-...@googlegroups.com, tos
С флеш плеером работает нормально.
Однако мы ещё даём возможность клиенту скачивать плей-лист, чтобы можно было проигрывать потоки в xbmc & Co.
Плейлист имеет такой формат
#EXTM3U
#EXTINF:0,1, Channel Name
rtmp://stream.server/live?login=qwerty playpath=streamName live=1
#EXT-X-ENDLIST

С вовзой - работает. С nginx-rtmp - нет. А именно - обработчику не передаются параметры.
Из тех, что я анализирую вижу только addr и name (хотя тут просто передаётся "play").


вторник, 22 января 2013 г., 20:41:34 UTC+2 пользователь Roman Arutyunyan написал:

tos

unread,
Jan 25, 2013, 9:44:23 AM1/25/13
to nginx-...@googlegroups.com, tos
С форматом плейлиста
rtmp://stream.server/live playpath=streamName?login=qwerty live=1
работает.
Может можно всё же реализовать директиву on_connect? 

пятница, 25 января 2013 г., 16:38:51 UTC+2 пользователь tos написал:

Roman Arutyunyan

unread,
Jan 25, 2013, 9:52:22 AM1/25/13
to tos, nginx-...@googlegroups.com
а можете отладочный лог показать?

2013/1/25 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 25, 2013, 10:09:26 AM1/25/13
to nginx-...@googlegroups.com, tos


пятница, 25 января 2013 г., 16:52:22 UTC+2 пользователь Roman Arutyunyan написал:
а можете отладочный лог показать?
Напомните, плиз, как его включить, а то сразу не нашёл.

Roman Arutyunyan

unread,
Jan 25, 2013, 10:09:58 AM1/25/13
to tos, nginx-...@googlegroups.com
https://github.com/arut/nginx-rtmp-module/wiki/Debug-log

2013/1/25 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 28, 2013, 6:27:56 AM1/28/13
to nginx-...@googlegroups.com, tos
Сделал пока формат плейлиста

rtmp://stream.server/live?login=qwerty playpath=streamName?login=qwerty live=1

Так работает везде. Но это костыль :(
Лог выслал на мыло.

пятница, 25 января 2013 г., 16:44:23 UTC+2 пользователь tos написал:

Roman Arutyunyan

unread,
Jan 28, 2013, 7:00:36 AM1/28/13
to tos, nginx-...@googlegroups.com
Ну все понятно. Этот клиент присылает аргументы только с коннектом.

2013/1/28 tos <t...@tos.org.ua>

--
Вы получили это сообщение, поскольку подписаны на группу nginx-rtmp-ru.
 
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу nginx-rtmp-r...@googlegroups.com.
Подробнее о функциях можно узнать на странице https://groups.google.com/groups/opt_out.
 
 



--
--
Roman Arutyunyan

tos

unread,
Jan 28, 2013, 10:01:36 AM1/28/13
to nginx-...@googlegroups.com, tos
В общем я об этом из нашей переписки и догадался.
Придётся адаптировать модуль для вовзы (там я как раз событие connect проверяю, полагая, что дешевле не пустить клиента на сервер, чем позволять ему висеть до команды play/publish).

понедельник, 28 января 2013 г., 14:00:36 UTC+2 пользователь Roman Arutyunyan написал:

Roman Arutyunyan

unread,
Jan 28, 2013, 10:06:09 AM1/28/13
to tos, nginx-...@googlegroups.com
Я сделаю on_connect/on_disconnect. Было бы здорово, если б вы помогли его протестить.

2013/1/28 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Jan 28, 2013, 10:13:56 AM1/28/13
to nginx-...@googlegroups.com, tos


понедельник, 28 января 2013 г., 17:06:09 UTC+2 пользователь Roman Arutyunyan написал:
Я сделаю on_connect/on_disconnect. Было бы здорово, если б вы помогли его протестить.
Конечно протестирую. Спасибо!

Roman Arutyunyan

unread,
Jan 28, 2013, 1:25:19 PM1/28/13
to tos, nginx-...@googlegroups.com
Бранч называется on-connect.

Две новые директивы - on_connect и on_disconnect.
Синтаксис тот же, что и раньше.

Есть нюанс: эти директивы нельзя указывать в блоке application{} т.к.
они относятся не к конкретному приложению, а к серверу. Коннекта
к приложению еще нет на момент вызова.

server {
    listen 1935;


    ...

    application myapp {
        on_play http://example.com/on_play;
        ...
    }
}

2013/1/28 tos <t...@tos.org.ua>



--
--
Roman Arutyunyan

tos

unread,
Feb 1, 2013, 8:24:41 AM2/1/13
to nginx-...@googlegroups.com, tos
В общем работает ожидаемо. Единственное неудобство, что приложение надо проверять скриптом авторизации.
Из-за этого при смене приложения придётся делать изменения в скрипте.
С другой стороны - проверка на стадии коннекта к серверу вообще, а не к конкретному приложению должна быть ещё более эффективной.
Попробую под нагрузкой проверить.
Спасибо огромное за Вашу работу!


понедельник, 28 января 2013 г., 20:25:19 UTC+2 пользователь Roman Arutyunyan написал:
Reply all
Reply to author
Forward
0 new messages