Re: Streaming AAC with libshout?

Hi,

On 25 June 2013 22:56, Romain Beauxis <[email protected]> wrote:
> Hi,
>
> 2013/6/25 "Thomas B. Rücker" <[email protected]>:
>> On 06/24/2013 06:27 PM, Thomas Rücker wrote:
>>> Just going to drop my 0,02€ here too.
>>>
>>> On 24 June 2013 16:47, Daniel James <[email protected]> wrote:
>>>> Hi Greg,
>>>>
>>>>> The open source AAC/HE-AAC encoders offer pretty poor audio quality.
>>>>> Sometimes you really do get what you pay for, and this is a perfect example.
>>>> An alternative explanation might be that open source developers were not
>>>> particularly motivated to work on improving AAC encoders, because of
>>>> difficulties experienced when trying to distribute patent-encumbered code.
>>> This is at least the explanation why the earlier sent patch by Paul is
>>> unlikely to get merged in mainline libshout, as helpful and valuable
>>> it might be for some people. We encourage open and patent-problem-free
>>> formats.
>>
>> My opinion remains unchanged on this topic, but to help defuse this
>> matter here is my diplomatic proposal of a possible way forward:
>>
>> Patches that directly, openly target problematic formats, codecs, etc.
>> will still be unlikely to be merged (not a categoric no, very well
>> justified exceptions may be made, e.g. to ensure backwards
>> compatibility, but certainly not a blanket approval).
>>
>> Generic patches supplied by the community that target the 'pass through'
>> legacy functionality of Icecast will be merged pending usual review. In
>> the causa at hand, think 'allow a mime-type to be passed to libshout'
>> this would also address codec extensions: 'audio/ogg; codecs=opus' and
>> be generally useful.
>>
>> We focus our development efforts on matters aligned with the Xiph
>> mission statement: "media technology that is open and free for anyone to
>> use". When it comes to legacy functionality we do our best not to break
>> things, but we expect and welcome the interested community to report
>> problems AND supply patches where necessary.
>>
>>
>> I would like to further elaborate why I think such a direction is
>> necessary. We are carried by many downstream projects, including Debian,
>> Ubuntu, Fedora, etc. Some of which have quite strict policies when it
>> comes to copyrights, patents and various definitions of 'free'. We have
>> so far had no significant problems with regard to that, as opposed to
>> other projects that were, removed, patched or otherwise affected.
>> Also being agnostic of problematic technologies minimizes possible legal
>> attack surface against each and every contributor to our projects.
>
> Thanks for your feedback, Thomas. From my previous contribution, I
> gather that we have a different standpoint on the matter and I
> appreciate that your shared yours.
>
> Back 3 years ago, when I realized that our patch would not be
> accepted, I decided to go on and implement a new library that we now
> use instead of libshout. It has never been a big deal and I am glad
> that we are still able to benefit from icecast because that is a
> project that I support and respect. We also have always supported as
> many available xiph format as possible in liquidsoap and I wrote most
> of this support myself.
>
> That being said, I would like to point that there seems to be a little
> under-statement behind the "backward" compatibility that you
> mentioned. The so-called "backward compatibility" support may as well
> be renamed "mp3 format" support, because that is what we are talking
> about. And right now, judging from the stats on dir.xiph.org, there is
> stunning ratio of one vorbis stream per 50 mp3 stream...

From a code point of view it is backwards compatibility. This happened
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
_______________________________________________
Icecast-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/icecast-dev