ретрансляция на другой RTMP-сервер.

[Ilya K.]

Здравствуйте.
Версия 5.2.969
Пробуем опубликовать микшированный поток на другой RTMP-сервер (https://gcorelabs.com/ru/support/articles/360014153118/)

Запрос:
{
"streamName": "name",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in/130062?*key*/",
"rtmpTransponderFullUrl": false,
"options": {}
}
Ответ:
{
"mediaSessionId": "*mediaSessionId*",
"streamName": "name",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in/130062?*key*/",
"rtmpFlashVersion": "LNX 9,0,124,2",
"rtmpTransponderStreamNamePrefix": "",
"width": 0,
"height": 0,
"fps": 0,
"keyFrameInterval": 0,
"rtmpTransponderKframeInterval": 60,
"muted": false,
"soundEnabled": false,
"rtmpTransponderForceKframeInterval": true,
"rtmpTransponderFullUrl": false
}
Вопросы:
1. Транспондер создаётся со 2-3 раза (проверяли запросом push/find_all ), но ответ, о котором писал выше, приходит всегда.
2. В gcore-labs статус live потока так и остаётся в offiline. Тот же самый поток в g-core labs переходит в live, если публиковать через OBS. Не уверен, что проблема на стороне WCS, но возможно сможете что-то посоветовать. Возможно, нужно запросить какую-то дополнительную информацию от них? Их техподдержка пока советует использовать в качестве rtmpUrl "rtmp://vp-push-ix1.gvideo.co/in/" Но тогда непонятно, как передать и ключ, имя потока.

 

[Max]

Добрый день.
В rtmpUrl нужно передавать полный URL, включая ключ потока. При этом необходимо установить параметр "rtmpTransponderFullUrl":true. Также желательно поменять версию RTMP-клиента:

{
"streamName": "name",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in/130062?*key*",
"rtmpTransponderFullUrl": true,
"rtmpFlashVersion": "LNX 76.219.189.0"
}

1. Транспондер создаётся со 2-3 раза (проверяли запросом push/find_all ), но ответ, о котором писал выше, приходит всегда.

Запрос только создает транспондер, а дальше он либо соединяется с RTMP сервером, либо нет. Если соединение не устанавливается, необходимо смотреть лог сервера /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
Также необходимо учесть, что канал до RTMP сервера должен быть достаточным для потока 1080p 4 Mbps. Попробуйте опубликовать на WCS поток с более низкими параметрами в примере Media Devices и ретранслировать его.

Их техподдержка пока советует использовать в качестве rtmpUrl "rtmp://vp-push-ix1.gvideo.co/in/" Но тогда непонятно, как передать и ключ, имя потока.

Техподдержка смотрит на OBS, а там эти поля разделены. Но под капотом OBS работает ffmpeg, в котором всегда задается полный URL.

 

[Ilya K.]

В целом получилось добиться статуса live.
По наблюдениям - публикация всегда удаётся с первой попытки после рестарта сервиса.
В логах есть ошибка
08:45:53,826 ERROR ClientHandler - pool-57-thread-2 RTMP error [id: 0x16734470, /x.x.x.x:20004 :> xxx/x.x.x.x:1935]
java.nio.channels.ClosedChannelException
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(Unknown Source)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(Unknown Source)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(Unknown Source)
at org.jboss.netty.channel.Channels.close(Unknown Source)
at org.jboss.netty.channel.AbstractChannel.close(Unknown Source)
at com.flashphoner.server.remote.D.K$2.run(Unknown Source)
Полный лог высылаю в отчете.

 

[Max]

Сообщение

08:07:09,490 INFO         ClientHandler - pool-62-thread-2 channel closed: [id: 0x778e8090, /***.**.*.***:20004 :> vp-push-ix1.gvideo.co/**.***.***.***:1935] CLOSED

означает, что соединение закрыто RTMP сервером.
Мы проверили на нашем сервере, сборка 5.2.1023. При запросе

curl -H "Content-Type: application/json" -X POST http://localhost:8081/rest-api/push/startup -d '{"streamName":"test","rtmpUrl":"rtmp://vp-push-ix1.gvideo.co/in/130062?key","rtmpTransponderFullUrl": true,"rtmpFlashVersion": "LNX 76.219.189.0"}'

RTMP сервер не закрывает соединение, трафик передается.
По логу, в Вашем запросе видно две проблемы:
1. Лишний слэш после ключа. В этом случае ключ считается частью URL, а имя потока будет пустым.
2. Не указана версия RTMP клиента, как мы рекомендовали выше

08:07:17,527 INFO  ransponderController - HTTPS-pool-5-thread-4 handleRequest /rest-api/push/startup params:{streamName=9884p7HeR1lbWeQ1LuJ, rtmpUrl=rtmp://vp-push-ix1.gvideo.co/in/130062?key/, rtmpTransponderFullUrl=true}

Если эти проблемы исправить, соединение рваться не должно.

 

[Ilya K.]

Запрос:
{
"streamName": "9884p7HeR1lbWeQ1LuJ",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in/130062?key",
"rtmpFlashVersion": "LNX 76.219.189.0",
"rtmpTransponderFullUrl": true
}
Ответ:
{
"mediaSessionId": "loidim47m98rdf0sb0hhdmmq1p",
"streamName": "130062?key",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in",
"rtmpFlashVersion": "LNX 76.219.189.0",
"rtmpTransponderStreamNamePrefix": "",
"width": 0,
"height": 0,
"fps": 0,
"keyFrameInterval": 0,
"rtmpTransponderKframeInterval": 60,
"muted": false,
"soundEnabled": false,
"rtmpTransponderForceKframeInterval": true,
"rtmpTransponderFullUrl": true
}
rtmpUrl всегда корректный, т.е., получается, проблемы в слеше нет. Ответ всегда однотипный для удачной и неудачной попытки. Меняется только mediaSessionId. В запросе передается rtmpFlashVersion и "rtmpTransponderFullUrl": true.

Результаты push/find_all :
Для неудачной публикации:

[
{
"mediaSessionId": "loidim47m98rdf0sb0hhdmmq1p",
"streamName": "130062?key",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in",
"rtmpFlashVersion": "LNX 76.219.189.0",
"rtmpTransponderStreamNamePrefix": "",
"width": 0,
"height": 0,
"fps": 0,
"keyFrameInterval": 0,
"rtmpTransponderKframeInterval": 60,
"muted": false,
"soundEnabled": false,
"rtmpTransponderForceKframeInterval": true,
"rtmpTransponderFullUrl": true
}
]
Для удачной:
[
{
"mediaSessionId": "d93g353snvaor66v0e6t1lmn49",
"streamName": "130062?key",
"rtmpUrl": "rtmp://vp-push-ix1.gvideo.co/in",
"rtmpFlashVersion": "LNX 76.219.189.0",
"rtmpTransponderStreamNamePrefix": "",
"width": 1920,
"height": 1080,
"fps": 0,
"keyFrameInterval": 0,
"rtmpTransponderKframeInterval": 60,
"muted": false,
"soundEnabled": false,
"rtmpTransponderForceKframeInterval": true,
"rtmpTransponderFullUrl": true
}
]
разница в
"width": 1920,
"height": 1080,
Отправляю новый отчет. Неудачная попытка коннекта была в 10:40

 

[Max]

По предоставленному логу, соединение было закрыто на стороне RTMP сервера.
Попробуйте снизить выходные параметры микшера (например, 720p, 2000 кбит/с). Если это не помогает, предоставьте, пожалуйста, SSH доступы к серверу с возможностью публикации в стандартных примерах, а также RTMP URL для проведения тестов. Используйте эту форму для отправки данных.

 

[Ilya K.]

Отправил доступ. Мы должны транслировать именно поток с разрешением 1080p.

 

[Max]

Мы воспроизвели проблему на Вашем сервере: после успешной публикации потока по /push/startup и последующей остановки по /push/terminate, новые републикации того же потока создают объект транспондера, но не устанавливают RTMP соединение. Проблема была исправлена в рамках тикета WCS-3026 и в последней сборке WCS не воспроизводится.
Пожалуйста, обновите WCS до сборки 5.2.1031 и проверьте.

Мы должны транслировать именно поток с разрешением 1080p.

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

 

[Ilya K.]

Здравствуйте. Обновили до 5.2.1031. Результаты внешне те же. После рестарта сервиса на origin удалось опубликовать с первого раза. Затем выполняется push/terminate , следует повторная попытка публикации push/startup Внешне также публикуется, но не передаётся на другой rtmp-сервер. В отчете высылаю лог, в форме новый доступ.

 

[Ilya K.]

Пытаемся ретранслировать именно микшированный поток.

 

[Max]

Нашли проблему в настройках сервера. Дело в том, что для ретрансляции RTMP выделен всего один исходящий порт (т.к. последний порт из диапазона не используется):

rtmp_port_from=20004
rtmp_port_to=20005

Поэтому после первой успешной републикации потока на RTMP сервер порт 20004 уходит в карантин и находится там не менее минуты. В связи с этим последующие републикации работать не будут.
Рекомендуем использовать значения по умолчанию для этих настроек, либо выделить диапазон с запасом, особенно, если планируется ретранслировать одновременно несколько микшеров. Как минимум, необходимо выделить порты по количеству одновременных ретрансляций плюс 10 портов в запас.