Re: esd



On  4 Jan, Robert Bihlmeyer scribbled:
->  Hi,
->  
->  >>>>> On Sun, 03 Jan 1999 14:28:02 +0000
->  >>>>> "Yo 'Ric Dude" <ericmit@ix.netcom.com> said:
->  
->   ebm> Encoding mpeg3 audio is a bit too CPU intensive for a compress
->   ebm> at the client, decompress on the server,
->  
->  Sure compression is slow as molasses, but many people have lots off
->  already compressed mp3s lying around, and decompression is reasonably
->  fast (plus needs to be done anyway).
->  
->   ebm> but i now see the special "mpeg3-esd" that simply sends the mp3
->   ebm> data over to the server for decompression.
->  
->  What I envisioned is more like this:
->  
->  You can tell the what format the data is in. Apart from RAW, and the
->  already present (but unimplemented) ADPCM, there could be things like
->  MPG3, S3M, you name it. Support for all these beasts should probably
->  not be compiled into the server itself, but reside in shared objects
->  or even external filters ("mpg123 -s -" is already such a thing).

1. S3M is not a compression format - its a mod format - completely
different ketel of fish.
2. MP3 is patented and proprietary. ou cannot put an encoder on a
distribtuion as just a plugin or utility and sell it withotu paying
royalties - ehll even decoders are still in dispute - there is no clear
policy on when you do or do not have to pay royalties.

As long as MP3 is patented and royalties are being actively pursued
forget it. This is orthogonal to the fact mp3's even on a PI-300 take
twice as long to compress as to play thus you canot compress ealtime
even on a fast machine.

->  esdcat could take the format on the commandline and just set the right 
->  flags before sending the thing. esdplay would use libaudiofile or
->  other magic to autodetect the type of data and do the right thing.
->  
->   ebm> Except of course for the potiential patent probelms with mpg3
->   ebm> audio (?)
->  
->  I am not sure, but I think *de*compressors are not patented. Putting
->  the mpg3 code into a seperate shared object or binary should protect
->  esd from those problems.

yes they are - if you sell a decompressor you can be asked to pay
rolaties. now there is a big fuzzy line as to if you have to pay if
they decoder is pat of a distribution - like a linux dist - but aslong
as its fuzzy no distribution that wants to stay legal will touch this.

->   ebm> The only potential problem there is then you also wind up with
->   ebm> s3m-esd, it-esd, other-mod-format-esd, realaudio-esd, etc.
->  
->  Sure, support for those formats would have to be written, but your
->  average user would just download & install the right backends, and
->  issue esdplay on everything (or say to the control-center: "Play this
->  mod file when I log in, and this mp3 when I log out").
->  
->  	Robbe
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/
							   



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]