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:
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 

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.
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])))

		while ((j < arg2) && (!arg1[j] ||
				      !((arg4 ^ 3) & arg1[j][0xA4])))

		if (k < arg2) {
			if (arg3)
				arg1[k][0x10] = k;
				arg1[k][0x10] = arg1[k][0x0C];
			H264SplitFieldCopy(arg0[224 * i], arg1[k], arg4, 1);

		if (j < arg2) {
			if (arg3)
				arg1[j][0x10] = j;
				arg1[j][0x10] = arg1[j][0x0C];
			H264SplitFieldCopy(arg0[224 * i], arg1[j], arg4 ^ 3, 0);

	return i;

Reply via email to