rtmpgw.exe -r rtmp://video.tvr.by/radio/radio1

И да, foobar заработал. Про плагин то я и забыл.
Но вот ffplay разочаровал. rtmpgw ругается так:

processTCPrequest, Range request not supported

а ffplay так:

[http @ 03030280] HTTP error 416 Requested Range Not Satisfiable0
http://127.0.0.1:80: Server returned 4XX Client Error, but not one of 40{0,1,3,4}

rtmpgw.exe rtmp://video.tvr.by/radio/radio1

vlc подключается к 127.0.0.1:80, а foobar и ffplay не могут.

PS Может кто то объяснить, в чем разница между rtmp, rtp, rtsp? Хотя бы вкратце.

"vlc для Windows не умеет принимать данные на stdin" - есть непонятная мне хитрость, надо в конце строки с vlc поставить просто тире. Тогда будет работать. Что это за ключ - мне неизвестно. Так: rtmpdump.exe -r rtmp://video.tvr.by/radio/radio1 -q | vlc.exe -

Но меня больше интересует, что за поток качает foobar по третьей Вашей строке. Там же должен быть flv с aac (это видно, если сохранить такой поток с пом. rtmpdump на диск), разве это зависит от того, понимает foobar rtmp, или не понимает? Такой же поток  flv с aac, получаемый по http, foobar понимает, проверил (moskva.fm, например).

"Нюансы":
1. foobar работает, только если сначала в нём дать команду на подключение, а уж потом запускать vlc. Если же сначала запустить vlc, то - не выйдет.
2. Даже при правильном порядке подключается не сразу, а иногда -  очень долго.

М.б. стоит поиграться с настройками буферизации в foobar?
Не пробовали проиграть полученный поток в самом vlc (во втором экземпляре)?

В качестве теста попробуйте и др. плееры (чтоб понять где ошибка) + можно попробовать др. версии vlc (напр. 2.1.x).
Также можете заменить localhost в ком. строке vlc на 127.0.0.1 и в ссылке указывать именно ip + уменьшить "битрейт" потока (правда возрастёт нагрузка на CPU):

vlc.exe -I dummy http://74.208.71.58:8078/listen.pls --sout=#transcode{acodec=mp3,ab=128}:standard{access=http,mux=dummy,dst=127.0.0.1:8000,novideo}

И в foobar указывать:

http://127.0.0.1:8000

vlc.exe -I dummy http://74.208.71.58:8078/listen.pls --sout=#transcode{acodec=mp3,ab=256}:standard{access=http,mux=dummy,dst=localhost:8000,novideo}

ssh.exe -R 127.0.0.1:8000:127.0.0.1:8000 user@home-workstation

cvlc "rtmp://video.tvr.by/radio/radio1" --sout '#transcode{acodec=vorb,ab=256}:standard{access=http,mux=ogg,dst=localhost:8010}' 

Тут уже скорее на форумы поддержки foobar.

Вторая строка работает, названия треков не передаются.

Первая строка с нюансами заработала. Нюансы:
1. foobar работает, только если сначала в нём дать команду на подключение, а уж потом запускать vlc. Если же сначала запустить vlc, то - не выйдет.
2. Даже при правильном порядке подключается не сразу, а иногда -  очень долго.

Странно: то же самое, но с ogg (строка:  --sout=#transcode{acodec=vorb,ab=256}:standard{access=http,mux=ogg,dst=localhost:8000,novideo} ) - не работает (хотя поток с заголовком ogg качает, и Mediainfo его опознаёт, но он не проигрывается ничем). 

Третья строка не заработала, в смысле, что foobar не воспроизводит звук. Но опять же, какой-то неизвестный поток точно качает. Сохранил с пом. HC на диск,  Mediainfo его не опознал.

Ещё я попытался слушать localhost:8000 не через foobar, а через сам vlc (копию, разумеется) - ничего не вышло: не сработала даже первая строка! Пишет: "VLC не может открыть MRL 'http://127.0.0.1:8000'. Ищите более подробную информацию в лог-файле". А лог отсутствует.

Ваша строка не заработала у меня, как её не крутил.  Пытался сам создать такую строку с пом. vlc-help.txt (написал: --sout-standard-access="http" --sout-standard-dst="localhost:8010") - трансляции тоже  нет, появился звук в самом vlc, наверное, строка неправильная.  Пробовал делать через "Инструменты - Конфигурация VLM" - какой-то мутный мастер, и результат никакой.

Верно, по документации синтаксис ком. строки под Windows и Linux различается (Under MS Windows). Верный вариант:

vlc.exe -I dummy rtmp://video.tvr.by/radio/radio1 --sout=#transcode{acodec=mp3,ab=256}:standard{access=http,mux=dummy,dst=localhost:8000,novideo}

vlc.exe -I dummy http://74.208.71.58:8078/listen.pls --sout=#standard{access=http,mux=dummy,dst=localhost:8000,novideo}

Для rtmp-потока без перекодировки, скорее всего, не выйдет, т.к. foobar не умеет rtmp, но можете попробовать:

vlc.exe -I dummy rtmp://video.tvr.by/radio/radio1 --sout=#standard{access=http,mux=dummy,dst=localhost:8000,novideo}

mocp, который я использовал в качестве плеера, "ругался" на неверный поток, хотя "умеет играть" flv.

Можете посмотреть примеры с wiki vlc.

Radio Dismuke - 1920s & 1930s Popular Music & Jazz - весёлое радио

PS: использовал vlc 2.2.0

Хорошо, постараюсь, только проверю - Windows есть только на работе, не всегда есть время протестировать (работаю ), пожалуйста, потерпите немного.

Перекодировать - т.к. foobar поддерживает flv только отдельным плагином (сторонним) и я не уверен, что нормально воспроизведёт flv-поток (flv-файл и flv-поток несколько разные вещи). Зато поддержка mp3/ogg/aac медиапотока есть много где ("из коробки") и более отлажена.

Несовсем корректно выразился, точнее так - "rtmpdump получает поток, передаёт по stdout в перекодировщик (VLC/ffmpeg/mencoder/lame, например), тот передаёт перекодированный поток (через stdout) на "стример" (ПО, формирующее медиапоток, например ezstream), полученный поток раздаёт сервер потокового вещания (icecast или аналог). Чуть ниже под спойлером нарисую схему работы организации потокового вещания "из личного опыта" и опишу почему нужна перекодировка потока (из flv в mp3/ogg)

Впринципе, VLC умеет все перечисленные действия в одну команду (и у меня получилось заставить его работать под Linux).

    +-------------+           +-----------------+
    | консольный  |           |                 |
    |   плеер     |  stdout   | ezstream        |
    | типа mpg123 +---------->+ mp3 256kB/s abr |
    | или mplayer |           |                 |
    +-------------+           +--------+--------+                 
                                       | tcp
                                       V
                              +--------+--------+
                              |     icecast     |
                              | в качестве http |
                              |     сервера     |
                              | раздающего mp3  |
                              |      поток      |
                              +--------+--------+
                                       | http://localhost:8080/play.m3u
                                       V
                              +--------+--------+
                              |    плеер типа   |
                              |      WinAmp     |
                              +-----------------+

Действительно:
- Foobar умеет воспроизводить  flv (с плагином) - файл и http-поток;
- Foobar не знает rtmp;
- Streamripper тоже не знает rtmp,
- Streamripper умеет принимать http -  и раздавать по http (и одновременно сохранять поток в файл). 
Конкретно: поток mp3 от Streamripper  (строка: streamripper.exe  http://74.208.71.58:8078  -r)  я  слышу в foobare по адресу http://localhost:8000 .
- VLC 2.2.1 понимает rtmp, проверил.

Ваша строка не заработала у меня, как её не крутил.  Пытался сам создать такую строку с пом. vlc-help.txt (написал: --sout-standard-access="http" --sout-standard-dst="localhost:8010") - трансляции тоже  нет, появился звук в самом vlc, наверное, строка неправильная.  Пробовал делать через "Инструменты - Конфигурация VLM" - какой-то мутный мастер, и результат никакой.

Напишите, пожалуйста, ком. строку для самого простого случая: без конвертации звука, и для входного http потока mp3 .  Адрес такой: http://74.208.71.58:8078  . Пусть поток транслируется на http://127.0.0.1:8000 , который услышу в foobare. Или, как вариант, - файл .vlm, который создаёт мастер "Конфигурация VLM".
Заработает это - потом попробуем rtmp flv.

И я не понял:
- "В теории - сохраняем rtmp-поток (в rtmpdump или VLC)" - сохраняем в файл? - зачем?
- "перекодируем поток в mp3" - зачем нужно перекодировать?

Netcat не умеет обрабатывать HTTP, но получать/отправлять - пожалуйста, естественно, в рамках TCP

Согласен, но тогда и грузчик "работает с компьютерами", потому что грузит их и выгружает. Однако ведь для грузчика компьютер — не компьютер, а просто единица груза. Т.е. грузчик работает с грузами, а не с компьютерами, холодильниками и т.п. То же самое и netcat в отношении HTTP. Поэтому считаю моё высказывание вполне корректным.

А в чём неверность? Получать, как веб-клиент, она ведь тоже не умеет.

Фраза не совсем корректна. Netcat оперирует с транспортным уровнем и естественно ничего не знает о HTTP (прикладной уровень).
Но HTTP-сервер работает поверх TCP и никто не отменяет обмена трафиком между конечными узлами. Также никто не запрещает загнать данные из netcat в стороннее приложение (и наоборот), которое будет формировать/читать http-заголовки.
Netcat не умеет обрабатывать HTTP, но получать/отправлять - пожалуйста, естественно, в рамках TCP (куча изворотов под спойлером).

while true ; do echo -e 'HTTP/1.1 200 OK\r\n' | ncat -l -p 2080 ; done

user@machine:/usr/local/bin# cat ./bash_httpd
#!/bin/bash
x=0;
Log=$( echo -n "["$(date "+%F %T %Z")"] $REMOTE_HOST ")$(
       while read I[$x] && [ ${#I[$x]} -gt 1 ];do
                 echo -n '"'${I[$x]} | sed -e's,.$,",'; let "x = $x + 1";
       done ;
); echo $Log >> /var/log/bash_httpd

Body=$(echo -en '<html>Sample html</html>')
echo -en "HTTP/1.0 200 OK\nContent-Type: text/html\nContent-Length: ${#Body}\n\n$Body"

ncat -l localhost 8080 < hello.http

[localhost@user ~]% cat hello.http
HTTP/1.0 200 OK

<html>
  <body>
    <h1>Hello, world!</h1>
  </body>
</html>

ncat -lk -p 8080 --sh-exec "echo HTTP/1.1 200 OK& echo(&type index.html"

mkfifo proxypipe
cat proxypipe | nc -l 80 | tee -a inflow | sed 's/^Host.*/Host: www.google.fr/' |  nc www.google.fr 80 | tee -a outflow >proxypipe

ncat.exe -l -p 2080 | ncat.exe www.ru 80 > www.ru
telnet localhost 2080

По теме:

Foobar умеет воспроизводить flv (плагином), но не умеет играть rtmp? (спрашиваю, потому что не использую foobar)
Streamripper умеет раздавать (и сохранять) потоковое аудио (mp3), но не умеет rtmp-поток? (судя по описанию на сайте, streamripper создавался для сохранения потокового радио с Shoutcast-серверов, а "он только mp3 умел")

В теории - сохраняем rtmp-поток (в rtmpdump или VLC), перекодируем поток в mp3 (напр ffmpeg или mplayer/mencoder, или VLC), и отдадим полученный mp3 как поток по http (icecast+ezstream или VLC).
В идеале пока вырисовывается схема с VLC (меньше ПО используется):

 vlc "rtmp://video.tvr.by/radio/radio1" --sout '#transcode{acodec=vorb,ab=256}:standard{access=http,mux=ogg,dst=localhost:8010}'

Такой вариант у меня работает (Arch Linux, VLC 2.2.0, в качестве плеера mocp и/или VLC).
Можете попробовать изменить кодек ("#transcode{acodec=vorb,ab=256}" ... "mux=ogg").
И разработчики VLC очень часто "ломают" те или иные ф-ии (проскакивали сообщения, что в релизах 2.0.х не работало воспроизведение rtmp-потоков - я солгал, поддержка rtmp была заявлена к релизу 2.1), обновляйте VLC и проверяйте всё ли работает + сохраняйте старые дистрибутивы (чтобы была возможность откатиться на предыдущую версию).

Если VLC не подходит по каким-либо причинам (ресурсов много кушает, например), тогда отпишетесь, я постараюсь вспомнить и расписать как "стримить" через icecast+ezstream.

Не совсем верно, но - да, netcat не умеет раздавать данные по http как web-сервер.

А в чём неверность? Получать, как веб-клиент, она ведь тоже не умеет.

Сам - точно не разберусь, помогите. Я боюсь наврать в терминах, но - да,  http-сервер.

Нужно вот что: беру rtmpdump.exe, беру звук по протоколу rtmp, и беру Foobar.

1. rtmpdump.exe передаёт по pipe свой выходной поток на искомую программу x.exe (говорят, что так он работает с плеером vlc, который умеет принимать поток через конвейер);

2. x.exe даёт мне возможность слушать этот поток в Foobar, если я задаю ему http://127.0.0.1:8010/  (так Foobar легко работает с streamripper, проверял сам).

Задача - найти x.exe.

Скорее всего для медиапотока придётся использовать что-то вроде vlc/mplayer/ffmpeg (который умеет как принимать поток так и транслировать). А для текста - netcat или аналог. Т.е. разбить задачу на варианты, т.к. поиск универсального решения скорее закончится ничем.
Чуть позднее попробую обыграть варианты.

Ругань скорее всего из-за:

Собственно поигрался с Ncat (прямая ссылка на бинарники, ~20 Mb):

@echo off & setlocal ENABLEEXTENSIONS
pushd %~dp0 2>&1 >nul
SET NCBIN=ncat.exe
echo Hello>TESTFILE
start cmd.exe /c "%~dp0%NCBIN% -l -p 2389 > test.txt"
call :sleep 4
cmd.exe /c "TYPE TESTFILE" | %~dp0%NCBIN% localhost 2389
popd 2>&1 >nul


exit /b 0

:sleep
setlocal ENABLEEXTENSIONS & set /a n=%1+1
ping -n %n% 127.0.0.1 >nul
endlocal & exit /b 0

Описанных вами проблем не наблюдается (при передаче текста), так что прошу прощения за ссылки на "кривые версии" :'(. Вечером попробую поиграться с медиапотоками.

Не совсем верно, но - да, netcat не умеет раздавать данные по http как web-сервер.