Повторно транслируйте поток Shoutcast / Icecast с помощью PHP

Мне нужно как-то перезапустить поток Shoutcast / Icecast с помощью PHP.

Почему?

Поскольку потоки Shoutcast / Icecast не являются https. Причем отправляется не через порт 80 и 443, а через какие-то другие странные порты. И мне нужны ссылки https на нормальных / стандартных портах, таких как 80 или 443. Это самая большая причина, хотя я думаю, что есть некоторые более, но менее важные.

Эти ссылки похожи на http://hostname.com:5921/stream, а вместо них мне нужны ссылки типа https://hostname.com/stream?user=x.

Я провел глубокое исследование и мало что нашел.

Я нашел такие вещи, как:

https://stackoverflow.com/questions/7998773/is-it-possible-to-restream-an-internet-radio-using-php-php-guru-needed
https://www.svnlabs.com/blogs/radio-icecast-shoutcast-php-proxy-to-re-stream-radio-stream-on-https/
https://stackoverflow.com/questions/36306457/read-mp3-stream-and-echo-back-to-client-in-php

Лучший код, который я собрал на данный момент из всех ресурсов и моих собственных попыток:

$link = 'http://shoutStreame.streamland.com/proxy/radioGame?mp=/1'; //example link to a Shoutcast stream (not working, only example)

ob_start();
header("Content-Transfer-Encoding: binary");
header("Content-Type: audio/mpeg, audio/x-mpeg, audio/x-mpeg-3, audio/mpeg3");
header('Content-Disposition: attachment; filename="stream.mp3"');
header('X-Pad: avoid browser bug');
header('Cache-Control: no-cache');
$handle = fopen($link, 'r');

while (($data = fread($handle, 1024))) {
    echo $data;
    ob_flush();
    flush();
}

И этот код не кажется ... хорошим? отлично?

Мне просто кажется, что я делаю это неправильно с этим кодом, и это неэффективно и может привести к проблемам.

Мои основные опасения:

  • эффективность, особенно при большом количестве запросов
  • юридические проблемы? есть ли какие-то реальные проблемы при таком подходе? перезапуск с использованием php?
  • проблемы сбоя? как сбой всего php, nginx или даже машины?
  • потеря соединения, например, этот php-скрипт продолжит умирать через некоторое время или что-то в этом роде

А может быть и больше.

Мне действительно сложно найти какие-либо дополнительные ресурсы, данные и информацию по этой конкретной теме перенаправления аудиопотока с использованием PHP.

Пока я действительно не знаю, что мне делать. Я просто исследую и размышляю, но, как я уже сказал, действительно сложно найти что-то еще по этой теме. И это единственный код, который у меня есть на данный момент, и я не знаю, хорошо ли его использовать ... :)


person Krystian Walicki    schedule 14.01.2020    source источник
comment
Подтверждены ли какие-либо из этих опасений тестированием, или это всего лишь теоретические опасения? P.S. Большинство, если не все из нас, вероятно, не обладают квалификацией, чтобы проконсультировать вас по юридическим вопросам.   -  person ADyson    schedule 14.01.2020
comment
@ADyson, это просто мои теоретические заботы и чувства   -  person Krystian Walicki    schedule 14.01.2020
comment
P.S. В вопросе, который вы упомянули, вам нужен этот код, потому что потоки, к которым вы хотите получить доступ, не являются HTTP и обслуживаются через порты, которые не являются стандартными HTTP / HTTPS (я предполагаю, что вы хотите передавать поток через корпоративный брандмауэр или что-то в этом роде). Тем не менее, в примере кода вы, кажется, получаете данные с URL-адреса HTTP ... так что, честно говоря, немного неясно, в чем проблема. Есть ли другие ссылки, с которых вы захотите скачать, но не на основе HTTP? Если это так, возможно, имеет смысл вместо этого продемонстрировать их.   -  person ADyson    schedule 14.01.2020
comment
Что касается опасений, вам действительно нужно провести конкретное нагрузочное тестирование, чтобы увидеть, как он ведет себя при более интенсивном использовании, чтобы увидеть, будут ли какие-либо из этих проблем реальными. Нам ничего не известно ни о развернутой серверной среде, ни об ожидаемых уровнях использования, ни о емкости сайтов, с которых вы транслируете, ни о пропускной способности сетевого соединения между этими сайтами и вашим, поэтому сложно предсказать многое.   -  person ADyson    schedule 14.01.2020
comment
@ADyson Эти ссылки shoutcast / icecast имеют вид: hostname.com:5921/stream и, как вы можете видеть порт 5921 + не https. Мне нужны ссылки вроде: hostname.com/stream?user=x   -  person Krystian Walicki    schedule 14.01.2020
comment
да, я вижу по этим ссылкам, что они не HTTP, но это не то, что вы используете в своем коде - в вашем коде ссылка в примере явно основана на HTTP. Так вы говорите, что вам нужно поддерживать разные типы протоколов?   -  person ADyson    schedule 15.01.2020
comment
@ADyson Да, потому что я получаю поток http, но этот скрипт / моя страница является сервером в https. Итак, я повторно транслирую http-поток с моей конечной точки https.   -  person Krystian Walicki    schedule 15.01.2020
comment
да ладно, но тогда почему бы просто не загрузить поток http прямо в свой клиент? Это была моя точка зрения. Зачем повторно транслировать то, что уже является http.   -  person ADyson    schedule 15.01.2020
comment
@ADyson загрузка из http создает смешанный контент + еще один конкретный ввод в моей системе требует ссылки на стандартный порт, например, обычную ссылку www.   -  person Krystian Walicki    schedule 15.01.2020


Ответы (1)


Потому что потоки Shoutcast / Icecast не являются https.

Ложь! Icecast отлично поддерживает HTTPS. См. Тег <ssl-certificate> в файле конфигурации. http://www.icecast.org/docs/icecast-2.4.1/config-file.html

Причем отправляется не через порт 80 и 443, а через какие-то другие странные порты.

Также ложь! И SHOUTcast, и Icecast можно настроить для работы на любом порту, который вам нужен. Большинство станций используют стандартные порты, и вы тоже можете.

Эти ссылки похожи на http://hostname.com:5921/stream, и мне нужны ссылки типа https://hostname.com/stream?user=x.

Зачем это нужно? Вероятно, проще всего сделать перенаправление на URL-адрес потока из вашего скрипта на /stream. Это удовлетворит большинство потребностей.

Все ваши технические вопросы действительны. Я бы точно не рекомендовал ретранслировать поток через PHP. Тем, что вы делаете, вы каждый раз вызываете восходящее соединение, и на самом деле без всякой пользы. Кроме того, в Icecast есть некоторые хаки для совместимости с клиентами, которые вы теряете, если проксируете соединение.

person Brad    schedule 15.01.2020
comment
Ложь! Icecast отлично поддерживает HTTPS. -но это тоже о shoutcast, они оба тоже ложь! И SHOUTcast, и Icecast можно настроить для работы на любом порту, который вам нужен. -Не знаю, можно ли обрабатывать около 1000+ станций - person Krystian Walicki; 15.01.2020
comment
Зачем тебе это нужно? Вероятно, проще всего сделать перенаправление на URL-адрес потока из вашего скрипта в / stream. Это удовлетворит большинство потребностей. -Я не думаю, что это сработает, потому что это просто перенаправление, а последняя ссылка за перенаправлением похожа на http://hostname.com:5921/stream. - person Krystian Walicki; 15.01.2020
comment
@KrystianWalicki Почему нельзя использовать исключительно Icecast? Почему вы не можете настроить свои серверы на использование нужных портов? И почему у вас не работает перенаправление? Не могли бы вы подробнее рассказать о своем конкретном сценарии использования? - person Brad; 15.01.2020
comment
1. У меня есть пользователи, много пользователей, очень много их. И некоторые из них используют Icecast и некоторые Shoutcast. 2. Они находятся на таких панелях, как centovacast и everestcast, и каждая учетная запись имеет свои собственные определенные порты для своих серверов icecast / shoutcast, ссылки для потоковой передачи с разными и странными портами. И мне нужны обычные https-ссылки на эти потоки и на нормальные порты. 3. перенаправление просто перенаправляет, последняя ссылка за перенаправлением все еще находится на странном порте и без https - person Krystian Walicki; 15.01.2020
comment
Эти панели также обслуживают прокси-ссылки (на обычных портах, больше как ссылки с www) - не знаю, как, но у них есть прокси-ссылки, которые я хочу создать. Но без https. - person Krystian Walicki; 15.01.2020
comment
Ой! Думаю, теперь я понимаю ... вы не контролируете серверы и потоки. Да, в этом случае вам придется проксировать запросы. Вы можете сделать это, явно настроив Icecast, или написать свою собственную систему. Раньше я писал для этого свои собственные серверы Node.js. Это намного больше, чем просто вопрос о переполнении стека. Если вы заинтересованы в лицензировании этого проекта, свяжитесь со мной по адресу [email protected]. - person Brad; 15.01.2020
comment
Но у меня тоже есть Shoutcast. Icecast + Shoutcast. Как вы думаете, мой PHP-код в этом вопросе подходит? И использование php в целом для этой проблемы нормально? И этого кода недостаточно? Нужно написать намного больше кода, чтобы он работал хорошо? - person Krystian Walicki; 15.01.2020
comment
@KrystianWalicki Определенно, код, который у вас есть, будет проблематичным. Во-первых, почти все заголовки неверны. Буфер чтения должен быть больше. Если бы вы пошли по этому пути, вы могли бы просто настроить свой веб-сервер на обработку проксирования, а не на уровень приложения. Я не говорю, что вы не могли бы сделать это на PHP, но это определенно не тот инструмент, к которому я бы обратился в данном случае. - person Brad; 15.01.2020
comment
Но я думаю, проблема не только в заголовках и маленьком буфере, верно? Я просто не знаю, что добавить в этот код, чтобы он был хорошим кодом для этой проблемы, и не знаю, сколько работы осталось, если сделать это на php таким образом - person Krystian Walicki; 15.01.2020
comment
Вам необходимо обрабатывать метаданные ICY. Вам нужно добавить X-Forwarded-For в запрос. Вам необходимо настроить PHP, чтобы этот скрипт работал бесконечно. Вам нужно добавить код для залога, если буферы нисходящего потока становятся слишком большими (медленные клиенты). Возможно, что-то еще. - person Brad; 15.01.2020
comment
Я понимаю. Но даже тогда, после того, как все это добавит и изменит код ... это не будет хорошо? особенно под нагрузкой примерно 10к-100к запросов минимум я думаю - person Krystian Walicki; 16.01.2020
comment
Нет. Icecast поддерживает SSL ТОЛЬКО под LINUX (до версии 2.4.4). Говорят, ВЕРОЯТНО, начиная с версии 2.5.0 он будет и под Windows. - person Tormy Van Cool; 12.11.2020
comment
@TormyVanCool Нет, это неправильно. У меня есть несколько экземпляров Icecast, работающих с SSL в Windows. - person Brad; 12.11.2020
comment
@Krystian Walicki Icecast под Windows не поддерживает SSL. Они так говорят. Он будет реализован (говорят) с 2.5.0. Это та версия, которую я с нетерпением жду. - person Tormy Van Cool; 18.11.2020
comment
Сама команда @Brad Icecast заявила, что 2.4.4 еще не поддерживает SSL под Windows. Таким образом, если у вас есть что-то еще: разместите здесь настройки, пожалуйста, и используйте возможность воспроизвести это. Или, к сожалению, это не имеет никакого значения. Если вы компилируете с ним: это работает, но я говорю о: просто используя предварительно скомпилированный пакет, который они предлагают. Как есть. Если вы используете его за прокси: да. Но прокси, который использует SSL, а не сам Icecast P.S. это будет действительно здорово, потому что это то, чего я жду на Icecast ;-) - person Tormy Van Cool; 18.11.2020
comment
@TormyVanCool 2.4.4 - это версия, которую я использую, и я загрузил ее с сайта ftp.osuosl.org/pub/xiph/releases/icecast/. Я не знаю, что еще тебе сказать. - person Brad; 18.11.2020
comment
Однако @Brad не является официальным сайтом (возможно, перекомпилирован с поддержкой SSL?). Здесь я говорю о том, что единственное упоминание о реализации SSL в Windows, которое я нашел, было на специальном форуме. В 2019 году было заявлено, что 2.44 не поддерживает SSL. Но будет с 2.5.0 и далее. И я искал решение, потому что моя установка не будет работать с SSL. Вот как я это обнаружил. downloads.xiph.org/releases/icecast/icecast_win32_2.4.4.exe - person Tormy Van Cool; 22.11.2020
comment
@TormyVanCool Это официальный сайт. Это зеркало. Если вы мне не верите ... хэшируйте их. CRC32 - это 735CAF36. - person Brad; 22.11.2020