[XviD-devel] Re: [Fwd: Data partitioning for encoder]

[sigdrak at free.fr]

Hello,

Quoting SuperMMX <supermmx at 163.com>:
> in one side, it is done in doing my research in our lab and i don't
> know how to handle this. of course if possible , i am very glad to
> make it committed into XviD. :))

Yes, you'd better check this. I think that for instance in the US (and for the
sake of the example, as you don't seem to live there), the administrations have
to publish in the public domain. (universities can hold patents, so...)

But please make us aware of the final decision. Anyway, it seems you are still
entitled to discuss about it, so let's go on with that. :-)

> in another side, it is only for research , i mean i did not optimize it
> very much, but it works...

This is experimental code, so if people find it slow, they can contribute
improvements :-)

My DP patch is for instance very wasteful, as you have to pass 3 buffers. If DP
is always used, the last buffer is the bigger, but in case it's adaptative, the
first one also needs to be big enough. Besides, there's no overflow control...
Maybe not the best design, but untill I see yours, I'll say it's OK.

> till now, RM and DP works great with compatibility with other decoders
> (i only test with FFMEPG), but FFMPEG decode the RVLC  with mess colors
> of the output. I have no time to debug it... maybe it is the problem
> of my implementation.

So did I to test my code. But in the end, it needs to be checked against for
instance MoMuSys. FFMPEG project will be glad if we ever find a bug and fix it.

> OK, we can dicuss here and the patch is a little bit large with modifications

Thanks a lot.

> of some function calls. (btw, i work it based on 1.0.1 cvs, a little old )

Same here for the function calls. I don't know how much the API has changed
since then, but it will surely have to change again. "Not for 1.1"

> I take a look at your patch, at least, my implementationis is far different
> from yours :))

Let's hope for a merge of good ideas at the end :)

> I can send you my patch to review...(but i can't find out what the exact
> version of the original files... pity :((

As you wish, considering any restriction from your direction.

As for the patch, cvs has a diff command that is very handy (except for new
files), as it for instance gives the version used. Good to know.

If your patch/diff is made with the -u switch, it should not matter that much.
Otherwise, sending the whole file might be easier.