[FFmpeg-devel] [RFC] the future of libamr

Pavel Pavlov pavel
Sat Jun 6 19:40:58 CEST 2009


> -----Original Message-----
> OpenCORE is released under the Apache 2.0 license and is thus 
> free software.  I have seen no reason to question the 
> validity of the OpenCORE license.
> 
> If you have such reasons, you need to provide us with facts.

I'm sure they took reference implementation and made some not so big
changes.
Reference implemtation has some uniqly ugliest identing and in many
places some 
extra whitespace at the end of lines, amr in android has the same
identing 
and whitespace in the same places. I'm not going to search for it right
now, 
but when I worked on amr I saw that.
It can't be released anywhere close to apache license unless they tried 
to make their code look exactly as the ref impl (to make
it bitexact :) or they got permission to modify reference impl code
anyway
they like *and* release it under any licence.

Here's a list of changes that most likely was done using some sort of 
regex or script (while working on amrnb codec I studied their changes
and 
for that I compared their code to ref impl. So, essentially I had to
guess what
regex to apply to the ref impl to get something close to opencore-amr :)
 they don't like /* one line coomments */ and they change them to // one
line comments
 they have some sort of function jumbo declaration template, that makes
their src code
twice bigger than it actually is. 
 they raname all .c files to .cpp.
 in every place where there is a global overflow/carry flag used they
replaced it
with a pointer to overflof flag which they made to be a part of
encoder/decoder context.
in many place they manually inlined functions


Ref impl doesn't have a copyright notice in every file; they added  
* Copyright (C) 1998-2009 PacketVideo
And below they mention that:
Portions of this file are derived from the following 3GPP standard:
...blah-blah-blah
(C) 2004, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA,
TTC)
Permission to distribute, modify and use this file under the standard
license
terms listed above has been obtained from the copyright holder.


So, it means that they somehow found/contacted copyright holder of the
reference 
implementation and got permission to mess with and distribute their
code. The changes 
libopencore did to the reference code is uncomparably tiny compared to
writing it 
from scratch. If it was anyhow possible to find/contact copyright holder
on the 
ref impl code for the code that libamr uses probably they would also
alow to use
it in any way.
They clearly profiled code and added optimizations in the cpu 
intensive parts. I did same steps and saw similar changes they were
doing.

See at the end for two random functions I took from reference impl and
opencore

If you dump list of symbols of the opencore and reference impl static
libs, you won't be able to 
tell which one is which. Absolutely identical.

> 
> So why don't you release your implementation and get it 
> merged into FFmpeg?
> 

I would personally do so. However the work was done for some company
and they will never allow anything like that. It's easier to get
permission to mess with the reference impl. This company by the way 
is member of amr patent holders and quite possible has some relation to 
ref impl, since it's physically located like 500 meters away from the 
place that sells licenses for amr, g729 and others (ref code for all 
of these codecs looks like it was written by the same person also)
The other issue is that the code won't compile with gcc. It doesn't use 
inline assembly, but uses rvct/ms intrinsic functions for arm.
By the way, g729 code is so similar to amr that I did
g729a+annexB(vad/dtx) in a 
week or so.






I just opened two random files from ref and opencore implementations:
Ref impl:
static Word32 energy_old( /* o : return energy of signal     */
    Word16 in[],          /* i : input signal (length l_trm) */
    Word16 l_trm          /* i : signal length               */
)
{
    Word32 s;
    Word16 i, temp;

    temp = shr (in[0], 2);
    s = L_mult (temp, temp);
    
    for (i = 1; i < l_trm; i++)
    {
        temp = shr (in[i], 2);
        s = L_mac (s, temp, temp);
    }

    return s;
}

Libopencore:
[jumbo 80 lines long function declaration template which ALSO 
contains reference implementation code as is, and calls it PSEUDO-CODE
:) ]

static Word32 energy_old(       /* o : return energy of signal      */
    Word16 in[],        /* i : input signal (length l_trm)  */
    Word16 l_trm,       /* i : signal length                */
    Flag   *pOverflow   /* overflow: flag to indicate overflow */
)

{
    Word32  s = 0;
    Word16  i;
    Word16  temp;

    for (i = 0; i < l_trm; i++)
    {
        temp = in[i] >> 2;
        s = L_mac(s, temp, temp, pOverflow);
    }

    return(s);
}

Now if it was a forum and we could make a poll whether the second
function 
is a bit modified 1st function I think pretty much evryone would agree
with that.








More information about the ffmpeg-devel mailing list