[Ffmpeg-devel] New Video Codec for low grunt embedded CPU's
Tue Mar 21 13:29:49 CET 2006
Alex Beregszaszi wrote:
>>>Please make it LGPL so it can be enabled by the default distribution in
>>>FFmpeg. As FFmpeg is licensed under LGPL, while some codecs are GPL,
>>>which are only enabled in case of the user requests it with --enable-gpl
>>The problem is if I use NRV it has to be GPL, because NRV is GPL.
>You mean LZO? NRV is like ZIP (container+compressor), while it uses LZO
>by default. But I could be mistaken. And we have an LZO decompressor.
>The encoder being GPL is not a problem, but the decoder should be LGPL
>if you want to get it widespread :)
It academic, but thats not how I understood it. Some of the algorithms
that Oberhumer uses are called NRV2B, NRV2D and NRV2E which are all
variants on a theme, and ive gotten them from the UCL Library. The
actual NRV2B/D/E are just compressed bit streams, they dont specify
container. LZO is a different algorithm. As Oberhumer.com says: "As
compared to LZO <http://www.oberhumer.com/opensource/lzo/>, the UCL
algorithms <UCL is an OpenSource re-implementation of some NRV
compression algorithms <http://www.oberhumer.com/products/nrv/>> achieve
a better compression ratio but decompression is a little bit slower."
I use it cause a good assembler decompresser for NRV is pretty damn
quick, easy to implement, takes up 2 tenths of stuff all code space, and
is still pretty well compressed.
>Also note that we ate FFmpeg are working at "reimplementing the wheel",
>that is, rewriting everything from scratch, reusing as much code as
>possible from other parts of the source, thus making the whole thing a
>bit better: wheel v2.
I have no problem with the philosophy, its just that I dont have the
time, and I find with compression that decompression is the easy bit,
the hard bit is an efficient compressor. Like I said re-implementing
the decompresser would be pretty easy, so there would be no impediment
to an LGPL decoder.
More information about the ffmpeg-devel