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. Cheers! Daniel
Just going to drop my 0,02? here too. On 24 June 2013 16:47, Daniel James <daniel.james at sourcefabric.org> 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. Especially now that with Opus there is a codec, that can at the least match the AAC/HE-AAC efficiency and has already gained main-stream browser support with Firefox, Opera and Chrome probably soon to join. Also it's one of the WebRTC codecs and as such will see further adoption. Cheers Thomas
2013/6/24 Thomas R?cker <thomas.ruecker at tieto.com>:> Just going to drop my 0,02? here too. > > On 24 June 2013 16:47, Daniel James <daniel.james at sourcefabric.org> 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. > > Especially now that with Opus there is a codec, that can at the least > match the AAC/HE-AAC efficiency and has already gained main-stream > browser support with Firefox, Opera and Chrome probably soon to join. > Also it's one of the WebRTC codecs and as such will see further > adoption.I know this will sound a bit harsh but it stems from the fact that I also did submit such a patch 3 years ago. I find it interesting that open source is often labeled as user freedom yet open source projects will block small patches such as this one to advance their own agenda, despite users requests. There's no need to favor one format over another. If opus is better then it'll get the recognition it deserves, not matter whether you add AAC support or not. In fact, excluding AAC from libshout locks up its users while having support for AAC mime-type would allow libshout and icecast to be more mainstream and, as such, would probably do a better job at promoting the opus format. Romain
Thomas, it is a bit ridiculous, to be honest. If whole open source community have been thinking like this none of the linux distros would have ever had any multimedia player that is usable by regular user because all of the would have been supporting only Vorbis and Theora. For me, one of the best things in open source is its interoperability, not that it is a ghetto. And you won't reverse the fact that it is AAC which is supported even by oldest Android phones, not Opus by banning AAC support in libshout. Your argument about Opus will be valid in let's say 2016 when most users will migrate to hardware & software that supports Opus. Not earlier. Personally I would be glad to see Opis widely supported ASAP but truth is that AD 2013 it is supported by no major software and hardware and I, and possibly not only me, have clients right now that are requesting low-bandwidth solution possible to integrate with their SaaS service (sorry, Orban). I can't tell them "wait till Opus will be popular". Now, and before it happens such policy just forces people to create patches, non-standard builds of libshout which basically just adding unnecessary overhead. m. 2013/6/24 Thomas R?cker <thomas.ruecker at tieto.com>> Just going to drop my 0,02? here too. > > On 24 June 2013 16:47, Daniel James <daniel.james at sourcefabric.org> 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. > > Especially now that with Opus there is a codec, that can at the least > match the AAC/HE-AAC efficiency and has already gained main-stream > browser support with Firefox, Opera and Chrome probably soon to join. > Also it's one of the WebRTC codecs and as such will see further > adoption. > > Cheers > > Thomas > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast-dev/attachments/20130624/3e5ad45b/attachment.htm
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 <daniel.james at sourcefabric.org> 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. Cheers Thomas