My experience with such things leads me to believe that this current
domination of shoutcast is temporary. It reminds me of the yahoo!
directories and the struggle to get listed prior to Google. Whether it
is temporary or not, it is a real concern of anyone implementing a
server with Icecast. I hope the moderators of this list will allow the
community to discuss the issue, but if it is too spicy, I don't mind
moving the discussion a rogue list.
(I don't agree that it is viable to ignore mp3. My decision has been to
ignore ogg/vorbis for now, because my radio station uses feeds from many
sources, almost all of which are mp3. Only one feed I have found is
.aac, and none are .ogg. In my attempts to convert mp3 to ogg, I have
not found a reliable solution yet. Plus, this is guaranteed to be worse
than just transmitting the mp3 directly, since both formats are lossy. I
have been told that it is smart to convert mp3 to ogg but that just
sounds silly to me.)
The shoutcast directory issue is a real issue for any icecast user that
wants to promote their streams on various directories, including the
shoutcast directory.
As background, I use a fairly extensive perl script that feeds mp3
content to ices0.4 and to icecast2.3.2. The script runs on the server
but I also want to support live feeds on a separate mount point.
(http://www.AirProgressive.org)
I see five options (please correct my thinking on these -- I haven't
tried them all):
1) emulate the interaction with shoutcast both when streaming and with
YP interaction to fool it into thinking that an shoutcast server is
talking to it. (Q: does a stream look identical from icecast as from sc?
If you have any information on this or want to discuss it further
separate from xiph.org, please contact me directly.)
2) install shoutcast server and relay from icecast to sc_serv. Thus
streaming is through shoutcast but YP interaction is still (from what I
have extracted from the documentation) with the source of the relay, and
thus the icecast server would need to emulate the sc YP protocol as in
option 1.
3) install shoutcast server and sc_trans and use the new calendar.xml
setup to accept a relay stream from icecast and feed it through sc_trans
and sc_serv. That "should" eliminate both the streaming interaction
and
YP interaction from any need for emulation and be in complete compliance
with any expectations of nullsoft.
4) establish a scripting wrapper that will allow a single script to be
callable from both icecast and shoutcast. The main difference here (if
using perl) is that icecast "use"es the perl module, gracefully
calling
the initialization and shutdown procedures, maintaining data in memory
between calls, etc. while shoutcast simply calls a command-line script
and expects a list of tracks as STDOUT. The wrapper would wind up
calling a script the way sc does, so no program state can be stored in
memory, which is now possible with icecast. Other entry points of the
API would be to move to the next track, restart, etc. I already had to
implement a number of watchdogs to keep track of the processes and
restart them if there were any glitches.
Certainly, option 4 does not violate any expectations of nullsoft,
because it means we have to run the entire shoutcast server and sc_trans
in parallel with the icecast server, so they should be happy. The
downside to this option is I don't know how to deal with live-feeds
going to two servers at the same time.
5) perform all the work as #4 and move the script to shoutcast as the
primary server and use icecast only as a relay server. I think this may
eliminate the troublesome live feed issue, complies with nullsoft
expectations.
As a side comment, I notice there is no common use of RSS 2.0 to
describe the radio station content. Since RSS 2.0 commonly describes
static documents or media, It would require a "best practices"
standard
to be written to say exactly how a given radio station would describe
itself. This would be a viable project for xiph.org, and the result
would be that any radio station could describe itself and be aggregated
into directories without the proprietary hooks that are currently being
utilized. A source to the server would update the RSS page each time a
track was changed and number of listeners changed. (Drawback would be
that it would be easier for station owners to inflate the number of
listeners.)
-- Ray Lutz
On 8/9/2011 1:44 AM, Thomas.Rucker at tieto.com wrote:> I hear rumours that it's not too hard.
> There was implicit discussion.
>
> STILL we can not encourage that people violate the express rules of
Nullsoft.
> This would make the Icecast project look bad.
>
> Besides we encourage to use ogg/vorbis for streaming and there the
situation
> is constantly improving. I think even streaming to Android devices should
> work now (someone please confirm on latest version). Firefox already
> supports it (including the mobile browser Fennec AFAICT) and Mozilla is
slowly
> crawling closer to finalizing chaining support. There are flash objects
that
> allow playback of ogg/vorbis streaming.
>
> Using ogg/vorbis for streaming is viable.
> It takes us and you to tell that to the potential streaming services that
> they don't have to use mp3 for everything. How would they else know?
>
> My 0,02?
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
--
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com