View Full Version : real magic codec?
DaveEL
29th June 2002, 03:40
Was looking at the real magic codec and it seemed in features rather similar to xvid (in fact the only things xvid cant do that it can AFAIK are some of the interlace options) so i ran strings on the dll and quite a lot of it seemed to match to make me think its probably at least opendivx based (references to encore and decore etc) but i had a quick scan through the divx4windows source and couldnt find this string in found in both xvid and the real magic codec.
"colorspace: inverted input format not supported" which in xvid at least seems to be a debug message (vfw/src/codec.c) so i assume this is not a standard part of vfw codecs so again the codecs seem to be based on common code but as i cant find this in divx4windows i cant see how thats possible if rea lmagic hasnt used xvid code.
Just wondering if anyone can confirm if real magic really has taken xvid code as i cant get access to the original versions of xvid from cvs as its all been renamed and i dont know how to use cvs properly :) perhaps xvid and real magic both used some other code which is where this string is from or perhaps i missed it in opendivx but i would at least like to know.
DaveEL
AsPiRiN
29th June 2002, 11:33
There is alrady a discussion about it:
http://forum.doom9.org/showthread.php?s=&threadid=28098
@Dave: Interesting one mate....Ill disassemble it now & get back to you.
-Nic
Damn! Already found code that relates to XviD's Image.c (I know that code well, as its used in my filter)
Im pretty sure about that, but ill have to disassemble some of the main routines (motion, colorspace, etc) & compare with XviD.
-Nic
"colorspace: inverted input format not supported"
Does not appear in the OpenDivX VFW frontend (or at least not on the copy on my machine)..So one could assume that the vfw code is straight from XviD
Another interesting point there is when using Resources (such as Bitmaps, dialog boxs) a resource number has to be given. Xvid's resource numbers end at 1204 (roughly) RealMagic's start at almost exactly 1205. Looks like they deleted all the old resources & just created there own in the same workspace.
Another thing is the resource name for XviD's Logo is IDB_LOGO, The one for RealMagic's is also IDB_LOGO (as one of my friends would say "Coincidence or something more sinister".
Even still, this could all be innocent & just me mis-interpreting things, but ill keep digging :D
-Nic
Just disassembled the RealMagics YUY2 -> YV12 routine...the code is _exactly_ the same as the conversion asm code in XviD. Ill post the disassembled code in a little while....
TheXung
29th June 2002, 14:42
If this is fact the same code base, the acclaimed 9% speed increase really seems to just be Xvid running at motion search level 5 instead of 6.
ChristianHJW
29th June 2002, 21:03
Hmmmpppfff !!
A few questions come to mind :
1. Is there any chance to prove that they have been stolen code from XviD ?
2. If they have, bearing in mind XviD is only an educational project and doesnt pay licensing fees to MPEG-LA for using its specs, is there any possibility to hinder them from doing that or to charge money as a compensation payment ?
3. To do so, is there a XviD Inc. with a CEO and a assurance to cover the trial costs ( i guess not ).
If i can help please let me know ...
Emp3r0r
29th June 2002, 22:10
whoa, WTF is going on here... it isn't sounding good
gldblade
29th June 2002, 22:28
If this gets any worse, I hope doom9 posts this thread in the news to alert people of RealMagic.
>Is there any chance to prove that they have been stolen code from XviD ?
Nic's way is doing fine in my opinion. But I think we need more people to help crack this mystery. We'd have to prove a lot of similarities in order to prove anything at all. Volunteers?
It would be so much easier if the string 'XviD' could be found in the RealMagic codec. I hope the "developers" were stupid enough to do such a thing. Assuming that all this is true of course...
>If they have, bearing in mind XviD is only an educational project and doesnt pay licensing fees to MPEG-LA for using its specs, is there any possibility to hinder them from doing that or to charge money as a compensation payment ?
That's a good point if the MPEG-LA doesn't come after us after we butcher RealMagic :). That may be a problem. How well does the "educational" argument stand up in the court of law? Nic, Koepi and uManiac are distributing builds of XviD, so this gives MPEG-LA something to latch on to. Then there is Doom9's website and forum...
>To do so, is there a XviD Inc. with a CEO and a assurance to cover the trial costs ( i guess not ).
This may cause a problem. Suing them would make XviD known to the public. Is that a good or bad thing? Well, what if XviD is portrayed as a video codec for DVD rippers? Ouch, definitely not a good impression. If push comes to shove, we need that "educational project" image.
About the trial costs, I'm sure many XviD supporters would be willing to support the cause. I'm even sure the DivX community will help, even if they are ignorant to the might of XviD! Just kidding of course. :D
What if we gave this to the press at first? I think we would have slightly more control (and it would initially cost less as well). There is still the possibility of the DVD ripper image, but at least the press would be getting information from the official source itself instead of from the court case itself. Getting information secondhand is definitely not the best way to create an accurate impression.
I'm getting ahead of myself. Let's just find out if things are as bad as they seem. My first impression, BURN IN H*LL RealMagic :devil:. But I could always be wrong.
trbarry
29th June 2002, 23:16
Maybe these sorts of GPL things are more often tried in the court of public opinion than a court of law.
If even a few people talk about it a bit then RealMagic will probably have to publicly respond. Likely they will tell the truth at that point since it would be sorta embarrasing to be caught lying on something that could be fairly easily verified.
Just my bet, but let's see what happens there.
- Tom
int 21h
29th June 2002, 23:26
A) The only real problem here is the fact that Real Magic doesn't release their changed source code.
B) An interesting saying comes to mind "You catch more flies with honey than with shit". Translated to-> Approach Real Magic and utilize the best of both worlds. XviD obviously can't pay the Mpeg-LA fees, Real Magic could. XviD has no bundled power, Sigma has tons. The fact that Sigma is already familiar with the source code could be a huge benefit.
In short, instead of attacking them and tempting them to move on to something else more proprietary, befriend them, perhaps get them as an ally instead of an enemy.
Try to have some vision before pursuing something purely on the one dimensional issue of GPL compliance.
int 21h
29th June 2002, 23:31
One should also ask themselves, if the following in the Sigma License agreement, exempts them from Mpeg-LA stuffs,
Infringement. You are hereby advised and you understand that your use of the Software may infringe existing patents. You understand that you are solely responsible for obtaining the necessary licenses from such patent owners and for paying all applicable fees and royalties. You agree that Sigma shall have no liability for use of this Software or any derivation thereof.
Nasse
29th June 2002, 23:49
_IF_ sigma can steal from xvid why dont do the same thing? couldn't xvid "borrow" the b frame code from sigma... and maybe the other fancy thinges too... that wouldnt be more than right...
int 21h
29th June 2002, 23:53
Sigma has not stolen from XviD. It is well within Sigma's rights and the XviD license to use the demonstrated ISO code in XviD to make a work based on that source.
The only thing Sigma has not done correctly is credited the original authors, and released the source code.
Even then, Sigma could just obfuscate the code and no one would be the wiser (except for the ASM portions).
Again, stop using such negative connotations. The XviD team should be proud that their educational source code is being embraced by a corporation and work on developing a relationship rather than alienating a possible ally.
Furthermore, the b-frame code in the Sigma codec cannot just be taken and put into the XviD codebase without a sourcecode release from Sigma. It would be much much too complicated and nearly impossible, the work needed to just write the B-Frame implementation would be less time-consuming than trying to hack out the code (in ASM) in the .dll and using that.
Koepi
30th June 2002, 01:20
Please, stop discussing this for some days.
We don't want a pre-biased public or users, so just cope with it for now - you're doing bad things to the XviD developers by talking bad about sigma.
I'll close this thread now and hope you'll understand that.
Just wait for news from us in this matter!
Thanks,
best regards,
Koepi
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.