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

OpenDivX digest, Vol 1 #70 - 6 msgs



Send OpenDivX mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.projectmayo.com/mailman/listinfo/opendivx
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenDivX digest..."


Today's Topics:

   1. Re: decore API feature requests (Eugene Kuznetsov)
   2. Questions (Lionel Ulmer)
   3. Re[2]: [OpenDivX] decore API feature requests (Eugene Kuznetsov)
   4. Re: Questions (Eugene Kuznetsov)
   5. Re: Questions (Lionel Ulmer)
   6. Re[2]: [OpenDivX] Questions (Eugene Kuznetsov)

--__--__--

Message: 1
Date: Tue, 15 May 2001 11:15:53 -0700
From: Eugene Kuznetsov <[email protected]>
Reply-To: Eugene Kuznetsov <[email protected]>
To: Arpi <[email protected]>
Subject: Re: [OpenDivX] decore API feature requests

Hello Arpi,

> Hi,
> 
> Just started to change MPlayer to use decore4linux, but I got some
> problems:
> 
> - I want to get pointers and strides to YV12 planes, without any
>   conversion or extra memcpy. currently it isn't possible :(((
>   (in old versions, up to 0.48 there was a callback to convert_linux())
>   You should allow users to set up their own (and fast) YUV converter!!!
>
>   A possible and simlpe implementation is adding a special colorspace
>   format called DEC_USER, and then store pointers and strides into
>   a structure pointed by *bmp (insetad of storing image there).
>   Other way is using *bmp as a pointer to conversion callback function.
>

Done.

> - When will be MMX postprocessing code for linux available?
>   The C version is extermly sloooow and so unusable.
>   I suggest including my optimized version of postprocess.c until
>   it finished. Linux users also want fast postprocessing...

We plan to start significant rewrite of postproc code in a couple of
weeks. Nobody here seems to be eager to port postproc to Linux
until new algorithms are ready. Can you describe what your version of
postprocess.c does?

> 
> - decore_init and decore_release are static, but declared non-static in .h

Fixed.

> 
> - there are -D_LINUX in Makefile, but #ifdef references to LINUX (without
>   the underscore) -> occurs many symbol redefinition and other warnings
>

Fixed.

> - doc (Codec Core Interface.txt) is outdated, at least about memory
>   allocation...
>   btw it's somehow bad... at least for hte future. in current version
>   there is a stuct with fields for currently used memory blocks.
>   users have to allocate them and pass pointers back. but if you add
>   a new field for a new memory block, then old progs will segfault :(
>   I prefer a malloc callback here, or just using a single memory size
>   and memory pointer.

With current CVS version you can simply do a 'memset(&param.buffers, 0,
sizeof(DEC_BUFFERS))'. I will update the doc.

> 
> - that bswapl asm instruction doesn't compiles under linux, at least
>   with binutils-2.9.1 (yes, this one can be compiler bug...)

With 'as' from 2.9.1.0.25 the instruction is perfectly recognizable. Try
to rename it into bswap if it doesn't work for you.

> 
> - and finally:
> Does it (current CVS version) work at all?
> Finally I get it compile and run, but:
> MMX version: segfaults...
> non-MMX: works, but buggy, motion vectors are bad.
> (I tried to play a file made with 0.47, isn't it compatible?)

It works with files from 0.48+ and should be compatible with 0.47 too,
though I didn't check that.

-- 
Best regards,
 Eugene
mailto:[email protected] or [email protected]

[Team GADGET]  [Team Two Divided By Zero]  [Team Hackzone.ruArpi [email protected]




--__--__--

Message: 2
Date: Tue, 15 May 2001 21:45:11 +0200
From: Lionel Ulmer <[email protected]>
To: [email protected]
Subject: [OpenDivX] Questions

Hi all,

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

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

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

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

The good news is that I can now decode without crashing the AVIs that were
encoded with the latest version of the codec. The bad news is that I have
some strange 'smearing' effects on these AVIs (even with the standard one
that worked with the previous Decore version) as if the buffer was not
erased between each frame and the drawings are 'accumulating'. Moreover, 
why do I need to use the 565_INV setting to get a 'correct' picture ?

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

          Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/


--__--__--

Message: 3
Date: Tue, 15 May 2001 12:56:11 -0700
From: Eugene Kuznetsov <[email protected]>
Reply-To: Eugene Kuznetsov <[email protected]>
To: Arpi <[email protected]>
Subject: Re[2]: [OpenDivX] decore API feature requests

Hello,

Tuesday, May 15, 2001, 11:15:53 AM, you wrote:

>>
>> - that bswapl asm instruction doesn't compiles under linux, at least
>>   with binutils-2.9.1 (yes, this one can be compiler bug...)

EK> With 'as' from 2.9.1.0.25 the instruction is perfectly recognizable. Try
EK> to rename it into bswap if it doesn't work for you.

I've discovered what the problem is. Update your source from CVS or replace "=g"
with "=r" in getbits.h ( problem only occurs when compiling w/o
optimizations ).


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




--__--__--

Message: 4
Date: Tue, 15 May 2001 13:49:02 -0700
From: Eugene Kuznetsov <[email protected]>
Reply-To: Eugene Kuznetsov <[email protected]>
To: Lionel Ulmer <[email protected]>
Cc: [email protected]
Subject: 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
depth?

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,
 Eugene
mailto:[email protected] or [email protected]
[Team GADGET]  [Team Two Divided By Zero]  [Team Hackzone.ru]




--__--__--

Message: 5
Date: Tue, 15 May 2001 23:08:20 +0200
From: Lionel Ulmer <[email protected]>
To: Eugene Kuznetsov <[email protected]>
Cc: [email protected]
Subject: Re: [OpenDivX] Questions

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

If you (if your CVS username is 'sparky' :-) ) just added this option now, I
think you forgot to add a 'break;' after the DEC_USER case :-) Moreover, to
be more consistant with the rest of the switch, you could remove the '&'
before the function name.

But well, I can hardly complain : 30 minutes between my mail and the feature
addition :-)

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

OK, fixed now on my desktop. Did not try it yet on my iPAQ (but as it's
little-endian too, it should not be different).

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

I am running in 565 depth, yes. But I do not see why it should invert the
'Y' coordinates.

Anyway, let's use this new DEC_USER feature to test the decoding speed
independtly of any image postprocessing (including YUV conversions).

Thanks,
      Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/


--__--__--

Message: 6
Date: Tue, 15 May 2001 17:26:46 -0700
From: Eugene Kuznetsov <[email protected]>
Reply-To: Eugene Kuznetsov <[email protected]>
To: Lionel Ulmer <[email protected]>
Cc: [email protected]
Subject: Re[2]: [OpenDivX] Questions

Hello Lionel,

Tuesday, May 15, 2001, 2:08:20 PM, you wrote:

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

LU> If you (if your CVS username is 'sparky' :-) ) just added this option now, I
LU> think you forgot to add a 'break;' after the DEC_USER case :-)

Oops :-) Thanx for pointing out.


LU> But well, I can hardly complain : 30 minutes between my mail and the feature
LU> addition :-)

Feature addition was committed 20 minutes _before_ your message (
14:02:26 2001 EST ; your message in the forum is posted on 14:19 ). You
can think that I am a seer :-)

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

LU> I am running in 565 depth, yes. But I do not see why it should invert the
LU> 'Y' coordinates.

The whole thing about directions of picture in Linux & Windows is
rather complicated. In Windows and in Linux it is done in different
way.

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





--__--__--

_______________________________________________
OpenDivX mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx


End of OpenDivX Digest


Reply To Poster

Local References / HOW-TO / FAQs