No subject

way before I was involved with Icecast. Icecast 1 was actually purely
MP3. Icecast 2 is a rewrite that targeted Ogg formats and tried to
maintain backwards compatibility with Icecast 1 and consequently
Shoutcast. As AAC, NSV and whatever else there may be uses pretty much
the same concept as MP3 that's the code we use for that. You can see
that format_mp3.c handles those things. I actually have been pondering
for a while to rename that to format_passthru to reflect the use case
and avoid the problematic name.

When it comes to the directory you can not do the simple math I'm
afraid. I know because I ended up with the challenging task of
maintaining dir.xiph.org. There is one ginormously huge streaming
provider which is serving thousands of constantly changing streams and
listing them on the YP. This is compounded by the fact, that they
actually run a cluster of 6-8 servers. They exclusively stream mp3.
Although I was quite tempted, also due to the fact, that they produce
90% of system load and are a constant source of additional work and
problems, I haven't delisted them.

For the sake of a balanced statistic I will not count them in, as they
are essentially one big hunk of radio with 17k streams on average
(sic!). Feel free to add '1' to the MP3 count at your own discretion.
Vorbis:  350
Opus:   8
Theora: 3
MP3:    2310
AAC:    976
Those are the average values for the last month, generated straight
from the database by my custom Munin scripts.
Some statistical error is expected due to our clustering not behaving
properly and thus I'm counting streams and not stations.

As you see that paints a quite different picture.


> I think xiph formats are really innovant and I love to experience with
> them and to support and promote them. However, it is also fair to say
> that without mp3 support, icecast would bare almost no relevance to
> the streaming ecosystem. This is a perfect example of the point I was
> trying to convey in my previous email: without mp3 support, icecast
> wouldn't be used and, thus, support for xiph and other open formats
> would be lost for all its users.

My personal line on this is to encourage users to use mp3 or aac only
as a transitional codec towards a primary Vorbis or now Opus stream,
especially those coming from an Shoutcast background and with skewed
perception of 'you must stream AAC/MP3 to be relevant'. There are many
native players, also for mobile devices. The reality is, that in the
recent uptick of 'HTML5' marketing it is easily possible, also on
mobile devices, to use a pure Vorbis or Opus stream. Firefox supports
both for <audio> natively and for other cases/browsers there are
highly efficient JavaScript libraries for decoding those, that I've
seen mentioned on IRC.

I'd love to ship such a solution in the Icecast web interface and on
YP to show-case the power and ease of Opus and Vorbis as open
technologies. If someone has the time to help, please get in touch and
let's work on this!

> I believe that AAC(+) falls in the same line of though. It is the
> de-facto format for mobile streaming and is widely supported. Having
> readily available support for this format will increase the adoption
> of icecast and, through this, the availability of alternative,
> open-source, solutions.

Yes, here comes the difference of our view points into play. You
justify your arguments with history and the 'now'. I justify mine with
shaping a better future, while not disrespecting the now and the past.
Others would like to go further and only see the future their way. And
those view points are highly unlikely to change. We should accept that
and try to get along, which is not always easy as we can see by
example of this thread.
Icecast, as is, copes sufficiently well with AAC and MP3. Libshout
should not be too hard to fix, see RJ's comment; actions should be
synced with Philipp as the de-facto libshout maintainer. I'd suggest a
separate thread and or tracking item on http://trac.xiph.org to
establish consensus.

I hope this has sufficiently cleared the air and we can go back to
making things better. :-)

Cheers

Thomas