On Tue, 2019-01-22 at 22:06 +0100, Marvin Scholz wrote:
> On 22 Jan 2019, at 20:29, c0re wrote:
>
> > Hi all,
> >
> > Today as I tried to implement transcoding a videofeed to an
> > icecast
> > audio-only stream I have encountered some behavior that, in my
> > opionion, leaves room for improvement.
> >
> > The setup used in this scenario consists of
> > * an Open Broadcaster Studio (OBS) instance sending a video/audio
> > feed
> > * an nginx endpoint to receive and re-stream said feed to various
> > hosts (including localhost)
> > * and lastly an AzuraCast
> > (https://github.com/AzuraCast/AzuraCast)instance which employs
> > Icecast2.4 for audio broadcasting.
> >
> > AzuraCast allows streamer/DJ accounts to live-broadcast to any of
> > its
> > radio-stations by connecting through a Broadcasting software of
> > your
> > choice (noteworthy mentions are BUTT or Mixxx) to a dedicated port
> > (e.g. 8005) and a static[1] mountpoint "/" and providing
> > credentials.
>
> This sounds quite weird, it would make a lot more sense to just use
> the
> same port and different mountpoints for this.
> The lack of multiple mountpoints is an old SHOUTcast limitation and
> Icecast does not suffer from it.
Having looked further into the issue I can now say that the behavior
is derived from Liquidsoaps' handling of so-called harbors.
If you google around a bit you'll see that the trailing slash (harbor
named = "") is quite a popular scheme around there.
So indeed the issue isn't _exactly_ icecast specific.
> >
> > [1]static as in there is no easy way for me to change this design
> > consideration)
> >
> > The way in which the icecast protocol is currently implemented in
> > ffmpeg, it will check for characters after the trailing slash and
> > assume this as a valid mountpoint.
> >
> > A trailing slash by itself will always be discarded with the
> > following
> > error:
> >
> > "No mountpoint (path) specified!"
> >
> > see: https://ffmpeg.org/doxygen/2.5/icecast_8c_source.html
> > [lines 157-161]
> >
> > so icecast://source:pass@host:port/ is considered invalid by
> > ffmpeg (I
> > cannot think of a quick and dirty workaround either).
>
> Hi,
> yes indeed Icecast does allow a mountpoint of /, but I would rather
> not
> allow that in the FFMpeg Icecast protocol helper, as IMO using / for
> a
> mountpoint is not a good idea. Users could accidentally use / as
> mount-
> point without this check and would get confused why it does not work
> out
> of the box (as by default / is an internal redirect to the status
> page).
>
> I wonder why AzuraCast decides to use / as mountpoint and why it
> does
> not even offer you a way to change it.
>
> Regards,
> Marvin Scholz
I filed an issue with AzuraCast which now has been resolved and an
implementation for custom named Liquidsoap harbors (which translate to
icecast streaming mount-points) is now fully implemented.
For what it's worth I also gave the ol' hack a go and patched
icecast.c and compiled from source.
Lo and behold... the change of a single character delivered the
desired result without any apparent drawbacks.
==
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index c93b06b553..aca043f59b 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -155,7 +155,7 @@ static int icecast_open(URLContext *h, const char
*uri, int flags)
s->pass ? s->pass : "");
// Check for mountpoint (path)
- if (!path[0] || strcmp(path, "/") == 0) {
+if (!path[0] || strcmp(path, "") == 0) {
av_log(h, AV_LOG_ERROR, "No mountpoint (path) specified!\n");
ret = AVERROR(EIO);
goto cleanup;
==
I leave it up to anyone whether or not that is the more sane
implementation (according to spec) or not. :)
Kind Regards
c0re
> >
> > To my understanding assigning a lone slash as a mountpoint name
> > isn't
> > considered invalid by the IceCast specification and therefore I
> > suggest that it would be an enhancement to lift this current
> > limitation on the way that mountpoints are parsed in an
> > ffmpeg+icecast
> > instruction.
> >
> > kind regards,
> > c0re___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
