Best way to publish music from mpd (music player daemon) to mediamtx server?

[iconoclasthero]

Question

When the client Rhino Linux laptop is on the same lan as my Rhino Linux server I was using the client's pipewire-pulse's pactl load-module module-native-protocol-tcp to receive a stream from a mpd system daemon server which was sending it to the client IP:

audio_output {
    type        "pulse"
    name        " Remote Pulse "
    server      "192.168.1.3"       # optional
    scale_volume "1.0"
    enabled     "no"
#   sink        "remote_server_sink"    # optional
}

Now that they're not longer primarily on the same lan but I still want music that doesn't have large delays when I change tracks (e.g., icecast2), I've been looking for another way to do this.

So right now, the server's remote and I'm listening to Jerry for the end of Days Between...that's coming from the first of the two following mpd audio outputs and this running in screen:

ffmpeg -loglevel error -nostdin -hide_banner -y -f s16le -ar 48000 -ac 2 -vn -i /tmp/mpd.fifo -c:a libopus -f rtsp rtsp://localhost:8554/mystream

audio_output {
    type                    "fifo"
    name                    "mpd.fifo"
    path                    "/tmp/mpd.fifo"
    format                  "48000:16:2"
}

audio_output {
     name            "pipe to ffmpeg"
     type            "pipe"
     enabled         "no"
     format          "48000:16:2"
     command         "ffmpeg -loglevel error -hide_banner -y -f s16le -ar 48000 -ac 2 -vn -i - -c libopus -f rtsp rtsp
://localhost:8554/mystream"
}

Clearly, in the latter, it the intention was to just have that controlled by enabling/disabling the output with mpc making it a significantly simpler setup.

It seemed to me in my shot time comparing them that the former was more robust, but I'm interested in opinions about that.

Further, and more to the point of my actual question, is there some other audio protocol that is native to mpd that would work better to communicate with MediaMTX?

[iconoclasthero]

https://mpd.readthedocs.io/en/latest/plugins.html#output-plugins

[iconoclasthero]

Also, how can I capture an rtsp stream with ffmpeg if there's no named file at the end of the url?
Once mediamtx has it from mpd (which it does), I still understand it to be agnostic to the source at that point.

I believe that I need some sort of named file for the stream to be able to use ffmpeg, e.g.,
rtsp://url:8554/mystream/mpd.opus

Right now I'm using mpv (as vlc wouldn't/couldn't be bothered to work) but I'd much rather use a more basic cli like ffmpeg.

[aler9]

is there some other audio protocol that is native to mpd that would work better to communicate with MediaMTX?

by looking at the MPD plugin list, the thing that comes closer to a network protocol is the httpd plugin but unfortunately it's still far from modern streaming protocols, therefore piping to FFmpeg remains the only way.

Also, how can I capture an rtsp stream with ffmpeg if there's no named file at the end of the url?
Once mediamtx has it from mpd (which it does), I still understand it to be agnostic to the source at that point.
I believe that I need some sort of named file for the stream to be able to use ffmpeg, e.g.,

In the RTSP protocol, the track list and their codecs are transmitted automatically from the server to any reader during the handshake. FFmpeg is perfectly capable of parsing the handshake and act accordingly. The path name doesn't have any influence and can be anything you want.