[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OpenDivX] Questions

Hello Lionel,

Tuesday, May 15, 2001, 12:45:11 PM, you wrote:

LU> Hi all,

LU> As suggested on the forum, here I am :-)

LU> So I can repeat my first question : if I want to contribute for a specific
LU> platform (in my case Linux/ARM), should I do it on OpenDivX or on the Linux
LU> project ? (BTW as the OpenDivX core code compiles on Linux, do we really
LU> need a Linux project anymore ?).

I also think that we don't need a Linux project anymore.

LU> To summarize quickly, my patches would be :
LU>  - first remove all FPU code from the core for example this :
LU>     ceil(log((double)mp4_state->hdr.time_increment_resolution)/log(2.0));
LU>  - add some ASM optimization where needed / useful

LU> Secondly, I am trying to get the current OpenDivX core running on Linux.
LU> After some changes in OpenDivX (I did not even try to compile MMX in, the
LU> removal of the 'bswap' optimization and some BIGENDIAN define that was set
LU> because of a '#ifdef LINUX' and not a '#ifdef _LINUX') and some in my test
LU> program (due essentially to the fact that you cannot have 'raw' separate Y,
LU> U, V frames anymore (why this API change BTW ?)

To have the same API in Linux and in Windows. Now you can use
DEC_USER, it has the functionality you want.

LU>  and need to do the memory
LU> allocations ourselves), I finally got some pictures.

LU> The good news is that I can now decode without crashing the AVIs that were
LU> encoded with the latest version of the codec. The bad news is that I have
LU> some strange 'smearing' effects on these AVIs (even with the standard one
LU> that worked with the previous Decore version) as if the buffer was not
LU> erased between each frame and the drawings are 'accumulating'.

If you update your sources to current CVS, most of your problems will
be solved. 'Smearing' effects were due to incorrect clipping of iDCT
output. Now they are fixed.

LU>  Moreover, 
LU> why do I need to use the 565_INV setting to get a 'correct' picture ?

Just a guess: maybe you are running your X server in 16-bit color

LU> Another point is that API changes (like the fact that raw YUV support is
LU> dropped or that you need to alloc from outside the memory for the codec)
LU> should be documented somewhere :-)

Of course...

Best regards,
mailto:[email protected] or [email protected]
[Team GADGET]  [Team Two Divided By Zero]  [Team Hackzone.ru]

OpenDivX mailing list
[email protected]

Reply To Poster

Local References / HOW-TO / FAQs