On Thu, Mar 19, 2015 at 11:05:30AM +0100, Olliver Schinagl wrote:
> Luc, Sunxi-community,
>
> It looks like they replaced a few function (names only) so the symbols
> don't show up with a simple grep (I cannot find ff_huff_build_tree for
> example). Can anybody confirm/deny that they went over a list of a few
> functions just to change the names/obfuscate things? The symbols still
> show a mix and match of coding style (camelcase etc etc) which still
> indicates a lot of copy/paste.
>
> I don't even know how this all works legally, so curious on that regard too.
>
> Anyhow, if somebody can help with some 'proof', that'd be great, though
> I'm sure they just obfuscate (if i'm right about that) some more.
>
> Olliver
>
> -------- Forwarded Message --------
> Subject: Re: [media-codec] media-codec / cedar released as LGPL, but
> where is the source? (#5)
> Date: Thu, 19 Mar 2015 00:42:57 -0700
> From: allwinner-zh <notificati...@github.com>
> Reply-To: allwinner-zh/media-codec
> <reply+0013009d911e6a9cdfd4aa8b9bd4bea2b90606ffdbe5170792cf000000011122400192a169ce03bfc...@reply.github.com>
>
>
>
> To: allwinner-zh/media-codec <media-co...@noreply.github.com>
> CC: Olliver Schinagl <oli...@schinagl.nl>
>
>
>
> No, there is none GPL issues in the media-codec-lib.
> Please provide the evidence to me.
Yes. Jens Kuske alerted me to that a few days ago. I have done the
legwork on one of those functions, but was too busy yesterday to make a
stink about it yet.
What is shown below is next to lgpl symbols that i had identified before
and which (also) still remain, and which i will not expose to allwinner
today, as i know how they will react. What Jens told me about is
separate, and new, and therefor shows just how nasty this game of
Allwinner is.
H264FillDefaultRefList() and a lot of code around it is straight out of
the libavcodec h264 decoder. The original name for that function is
ff_h264_fill_default_ref_list() in libavcodec/h264_refs.c:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L115
This is new, as some totally different code for h264 was available in
the previous versions of the cedarx binaries.
When Allwinner stated that they did CedarX2.0 about two months ago, they
added _more_ lgpled code. But this time they tried to trivially disguise
the code origins. This is a totally new low for Allwinner, and it shows
clearly that they have no licensing control over the contents of their
binary driver, and that no-one can believe them when they state that
they are adhering to licenses. No matter what binaries Allwinner
produces, nobody can believe that these are completely Allwinners
property and that Allwinner has the right to distribute such software.
Attached is the manual decompilation of H264BuildDefList() (originally
build_def_list() in h264.c). This can be compared easily by
looking at
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L67
Luc Verhaegen.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
int
H264BuildDefList(uint8_t *arg0, uint32_t *arg1, uint32_t arg2, uint32_t arg3,
uint32_t arg4)
{
int j = 0;
int k = 0;
int i = 0;
while ((j < arg2) || (k < arg2)) {
while ((k < arg2) && (!arg1[k] || !(arg4 & arg1[k][0xA4])))
k++;
while ((j < arg2) && (!arg1[j] ||
!((arg4 ^ 3) & arg1[j][0xA4])))
j++;
if (k < arg2) {
if (arg3)
arg1[k][0x10] = k;
else
arg1[k][0x10] = arg1[k][0x0C];
H264SplitFieldCopy(arg0[224 * i], arg1[k], arg4, 1);
k++;
i++;
}
if (j < arg2) {
if (arg3)
arg1[j][0x10] = j;
else
arg1[j][0x10] = arg1[j][0x0C];
H264SplitFieldCopy(arg0[224 * i], arg1[j], arg4 ^ 3, 0);
j++;
i++;
}
}
return i;
}
