Re: Streaming AAC with libshout?

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...

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.

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.


Romain