On Sunday, 13 July 2003 at 23:24, Stefan Neufeind wrote:> On 13 Jul 2003 at 14:45, Brendan Cully wrote: > > > ices 0.3 outputs MP3, not Vorbis. For Vorbis you will need ices > > 2. We know this is confusing, so ices 0.x will probably have a new > > name for the next release. Ideas? > > I'm glad to hear that 0.x is still maintained and, as it seems, still > updates. Well, but why don't you just integrate 2.x and 0.x into each > other, I mean, use 2.x as a "major brandnew rewrite" of 0.x and > simply add MP3-support (just an option to link against lame) to 2.x? > It would be up to every user if he / she wants to live with the legal > "problems" connected with MP3 or not. But where's the problem? Does > maintaining two separate tools doing almost the same make that much > sence?I'm speaking for myself and not in any way for xiph.org: I think this is a reasonable suggestion. I now remember that my original goal when I started working on ices 0.3 was to get one last stable, fairly complete version out the door that worked with current Xiph software (libshout 2 and icecast 2). That is, I wanted something that wasn't deprecated for the users out there who still need to stream MP3 (I'm one of them). Now that I think that's done, I personally like the idea of providing MP3 support for ices 2. I have some ideas about how to do it fairly cleanly, though I haven't read the ices2 code in any detail. But, whether this happens depends not just on the code getting written, but on whether other Xiph developers are willing to lend any more aid and shelter to the proprietary MP3 format and its litigious owners. My personal perspective may tend more toward the practical and the short term than theirs, but I can certainly understand if they don't want to include MP3 support in any new code. If I didn't have other people depending on an ices with MP3 support, I might feel the same way myself. -b --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 13 Jul 2003 at 17:53, Brendan Cully wrote:> On Sunday, 13 July 2003 at 23:24, Stefan Neufeind wrote:[...]> I think this is a reasonable suggestion. I now remember that my > original goal when I started working on ices 0.3 was to get one last > stable, fairly complete version out the door that worked with current > Xiph software (libshout 2 and icecast 2). That is, I wanted something > that wasn't deprecated for the users out there who still need to > stream MP3 (I'm one of them). > > Now that I think that's done, I personally like the idea of providing > MP3 support for ices 2. I have some ideas about how to do it fairly > cleanly, though I haven't read the ices2 code in any detail. > > But, whether this happens depends not just on the code getting > written, but on whether other Xiph developers are willing to lend any > more aid and shelter to the proprietary MP3 format and its litigious > owners. My personal perspective may tend more toward the practical and > the short term than theirs, but I can certainly understand if they > don't want to include MP3 support in any new code. If I didn't have > other people depending on an ices with MP3 support, I might feel the > same way myself.Well okay, I can understand their attitude. But it seems more like a religious thing: "no mp3 is evil, we don't do that". If anybody might implement streaming of wmv, ra or maybe some other format - whatever - will they say "we don't want to do that"? Why not make a good and flexible product out of it? What "bad sides" do they fear when implementing an "open" interface so that e.g. Brendan could add mp3- support? If somebody has problems with lame-support (legal matters) okay - he just doesn't have to turn the "--with-lame-support"-switch on when compiling and thats it. I just don't get the point folks. Well, maybe we should leave the discussion here .. I guess it should now be the Xiph-people to start a "well okay, let's do it". And if they don't nobody will doom them for it. But that's not the poing. Ogg / Vorbis is brilliant, icecast2 and ices 2.x are very brilliant (I really like those very much). But since some customers really insist on using mp3 I must advocate Brendan and thank him for the nice work he has done when finishing ices 0.3. Mp3 will never be dead. And maybe if we (me included) would vote with all our voice for Ogg still somebody would cry Mp3. Who cares ... But as long as there's the possibility to support this format (and I guess there's not that much chaos in the ices 2.x-code after implementing it) why not do? Again some two cents. Good night Stefan --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Mon, Jul 14, 2003 at 12:01:48AM +0200, Stefan Neufeind wrote:> On 13 Jul 2003 at 17:53, Brendan Cully wrote: > > > On Sunday, 13 July 2003 at 23:24, Stefan Neufeind wrote: > [...] > > Now that I think that's done, I personally like the idea of providing > > MP3 support for ices 2. I have some ideas about how to do it fairly > > cleanly, though I haven't read the ices2 code in any detail. > > > > But, whether this happens depends [...] on whether other Xiph developers > > are willing to lend any more aid and shelter to the proprietary MP3 > > format and its litigious owners. [...] > > Well okay, I can understand their attitude. But it seems more like a > religious thing: "no mp3 is evil, we don't do that".Why don't you try, for a moment, to look at it in a purely competitive way: why should xiph.org build support for their competition into one of their products? Would Microsoft do that? See Java. To me, this sounds a bit like "If a Free Software developer doesn't want to support Windows, he's *bad*, but if Microsoft doesn't support Linux, that's okay." And, btw, nobody stops anybody from implementing all that you mentioned (apart from the owners of those formats) in icecast[12]. That's what Free Software is all about. It's just that it won't be in the official release (if xiph.org doesn't okay it, of course). Bye, J -- Jürgen A. Erhard Invasion! http://invasion.jerhard.org "We must learn from our mistakes, so we can make bigger and better ones." -- Bruce M Krawetz -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20030714/5f751447/part.pgp
> Now that I think that's done, I personally like the idea of providing > MP3 support for ices 2. I have some ideas about how to do it fairly > cleanly, though I haven't read the ices2 code in any detail. > > But, whether this happens depends not just on the code getting > written, but on whether other Xiph developers are willing to lend any > more aid and shelter to the proprietary MP3 format and its litigious > owners. My personal perspective may tend more toward the practical and > the short term than theirs, but I can certainly understand if they > don't want to include MP3 support in any new code. If I didn't have > other people depending on an ices with MP3 support, I might feel the > same way myself. >Our attitude towards mp3 support in the 'icecast suite' has generally been "we're not that interested in doing the work ourselves, but have no objections to integrating work done by others". So basically, as long as it's entirely optional (i.e. you could compile ices2 without any mp3 (encoding or decoding) support), I'd have absolutely no problems with having mp3 support in there - but it's not work I'm interested in doing myself. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Monday, 14 July 2003 at 11:14, Michael Smith wrote:> > > Now that I think that's done, I personally like the idea of providing > > MP3 support for ices 2. I have some ideas about how to do it fairly > > cleanly, though I haven't read the ices2 code in any detail. > > > > But, whether this happens depends not just on the code getting > > written, but on whether other Xiph developers are willing to lend any > > more aid and shelter to the proprietary MP3 format and its litigious > > owners. My personal perspective may tend more toward the practical and > > the short term than theirs, but I can certainly understand if they > > don't want to include MP3 support in any new code. If I didn't have > > other people depending on an ices with MP3 support, I might feel the > > same way myself. > > Our attitude towards mp3 support in the 'icecast suite' has generally been > "we're not that interested in doing the work ourselves, but have no > objections to integrating work done by others". > > So basically, as long as it's entirely optional (i.e. you could compile ices2 > without any mp3 (encoding or decoding) support), I'd have absolutely no > problems with having mp3 support in there - but it's not work I'm interested > in doing myself.So here's my idea about how to support MP3 fairly simply in ices: 1. tag the input module with an audio type (or "auto" to guess). This lets us read MP3 sources as well as Ogg or PCM, without necessarily having to parse it at all. 2. tag the output module with an audio type (Vorbis or MP3). ices would just use this to set the right parameters in libshout. 3. Add an additional optional parameter to the reencode section, "command". If this were set, it would be a shell command that read the input on stdin and wrote the appropriate encoded output on stdout. The nice thing about this setup is there's no LAME code at all, and you don't need to decide at compile time whether you want MP3 encoding support. There are two things missing that I can think of: 1. MP3 metadata. 2. timing (ices2 isn't using the libshout timing methods). I will need to do a little more research there, though I suspect if libshout were extended a bit it might solve both of those problems. For instance, if libshout had a nonblocking API like Karl's work in progress, I bet ices2 could use libshout's own timing methods. -b --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.