Информация о типе пользовательского ПО для публикации потока, типе сжатия (CBR, VBR, ABR)
Здравствуйте.
Можно ли каким-то образом через REST API получить информацию о том, через какое ПО пользователь паблишит RTMP-поток?
Use-case следующий:
- пользователь может паблишить RTMP-поток через Flash из браузера и через OBS с десктопа
- Flash использует VBR, его битрейт нестабилен и может часто проседать из-за нагрузки, тогда как OBS паблишит поток с CBR (задаётся в настройках) и не подвержен проблемам проседания битрейта
- перед дальнейшей обработкой такого потока, он проксируется через сервис по контролю качества потока, который собирает различные его метрики - битрейт, fps, gop size и т.п. - и согласно некоторым критериям, принимает решеие, пропускать такой поток дальше, или нет
- для потока, полученного с Flash, битрейт может штатно быть "плохим", тогда как для потока, полученного с OBS, такого быть не должно (в настрйоках стоит CBR). Что бы не рубить потоки с якобы "плохим" битрейтом и не пугать пользователя сообщениями о плохом потоке, необходимо знать, через что этот поток паблишится, ведь в зависимости от ПО, такое проседание битрейта может быть приемлемым
Понятно, что вариантов такого ПО, в том числе, для мобильных устройств, может быть и больше, пара Flash и OBS приведена лишь как пример. Собственно, стоит задача понять, через что паблишит пользователь, что бы правильно трактовать колебания метрик его потока. Видится, что сделать это можно, либо получая данные от энкодера о типе сжатия (что предпочтительнее), либо из "flashVer, которые передаёт ПО:
- по REST API в обеих случаях (Flash и OBS) передаётся одинаковая информация, каких-либо даже косвенных, но стабильно повторяющихся отличий в данных, получаемых по API, недостаточно, что бы определить, через что паблишит пользователь. Параметр "mediaProvider" в обеих случаях Flash (что, в прочем, ожидаемо).
- логи сервера (logs/server_logs) так же дают лишь косвенные намёки: в случае стриминга через OBS, можно найти лишь такую подстроку "encoder=obs-output module (libobs version 24.0.3)}", тогда как в переменной "flashVer" значится только "FMLE/3.0 (compatible; FMSc/1.0)", чего недостаточно для явной идентификации ПО, да и парсинг логов для какой-либо автоматизации - тот ещё костыль, такая информация всё же нужна в API. При паблишинге через Flash значение "flashVer" будет чем-то вроде "LNX 32,0,0,270".
Добавить передачу "flashVer" по REST API в сыром виде (предпочтительно), либо, например, таким образом http://docs.evostream.com/ems_user_guide/security помогло бы решить проблему, пусть и не самым надёжным образом: наличие упоминания FMLE в строке может говорить о том, что это, по крайней мере, "не Flash". Но более надёжным способом было бы получение информации от энкодера, что позволило бы избежать костылей: например, тот же OBS, в зависимости от версий и, предположительно, ОС (Mac или Linux) в переменную "flashVer" пишет разную информацию, добавляя подстроку вида "obs-studio/1.2.3;".
Возможно, вы предложите какой-либо третий вариант решения этой проблемы?
Спасибо.
Здравствуйте.
Можно ли каким-то образом через REST API получить информацию о том, через какое ПО пользователь паблишит RTMP-поток?
Use-case следующий:
- пользователь может паблишить RTMP-поток через Flash из браузера и через OBS с десктопа
- Flash использует VBR, его битрейт нестабилен и может часто проседать из-за нагрузки, тогда как OBS паблишит поток с CBR (задаётся в настройках) и не подвержен проблемам проседания битрейта
- перед дальнейшей обработкой такого потока, он проксируется через сервис по контролю качества потока, который собирает различные его метрики - битрейт, fps, gop size и т.п. - и согласно некоторым критериям, принимает решеие, пропускать такой поток дальше, или нет
- для потока, полученного с Flash, битрейт может штатно быть "плохим", тогда как для потока, полученного с OBS, такого быть не должно (в настрйоках стоит CBR). Что бы не рубить потоки с якобы "плохим" битрейтом и не пугать пользователя сообщениями о плохом потоке, необходимо знать, через что этот поток паблишится, ведь в зависимости от ПО, такое проседание битрейта может быть приемлемым
Понятно, что вариантов такого ПО, в том числе, для мобильных устройств, может быть и больше, пара Flash и OBS приведена лишь как пример. Собственно, стоит задача понять, через что паблишит пользователь, что бы правильно трактовать колебания метрик его потока. Видится, что сделать это можно, либо получая данные от энкодера о типе сжатия (что предпочтительнее), либо из "flashVer, которые передаёт ПО:
- по REST API в обеих случаях (Flash и OBS) передаётся одинаковая информация, каких-либо даже косвенных, но стабильно повторяющихся отличий в данных, получаемых по API, недостаточно, что бы определить, через что паблишит пользователь. Параметр "mediaProvider" в обеих случаях Flash (что, в прочем, ожидаемо).
- логи сервера (logs/server_logs) так же дают лишь косвенные намёки: в случае стриминга через OBS, можно найти лишь такую подстроку "encoder=obs-output module (libobs version 24.0.3)}", тогда как в переменной "flashVer" значится только "FMLE/3.0 (compatible; FMSc/1.0)", чего недостаточно для явной идентификации ПО, да и парсинг логов для какой-либо автоматизации - тот ещё костыль, такая информация всё же нужна в API. При паблишинге через Flash значение "flashVer" будет чем-то вроде "LNX 32,0,0,270".
Добавить передачу "flashVer" по REST API в сыром виде (предпочтительно), либо, например, таким образом http://docs.evostream.com/ems_user_guide/security помогло бы решить проблему, пусть и не самым надёжным образом: наличие упоминания FMLE в строке может говорить о том, что это, по крайней мере, "не Flash". Но более надёжным способом было бы получение информации от энкодера, что позволило бы избежать костылей: например, тот же OBS, в зависимости от версий и, предположительно, ОС (Mac или Linux) в переменную "flashVer" пишет разную информацию, добавляя подстроку вида "obs-studio/1.2.3;".
Возможно, вы предложите какой-либо третий вариант решения этой проблемы?
Спасибо.
