[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
OpenDivX digest, Vol 1 #39 - 11 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. OpenDivX optimalization (Gigant)
2. Re: OpenDivX optimalization (John Funnell)
3. OpenDivX optimalization: +30-40% (Andrew Woznytsa)
4. Re: OpenDivX optimalization: +30-40% (John Funnell)
5. Re: OpenDivX optimalization: +30-40% (Andrew Woznytsa)
6. OpenDivx on Trimedia status (zap twentyfive)
7. getbits.c (Andreas John)
8. How to feed decore() and read its output ? (Vincent BARAT)
9. Re: OpenDivX optimalization: +30-40% (Remy Chibois)
10. Re: OpenDivX optimalization: +30-40% (Mattias Blomqvist)
11. Optimization questions (Mattias Blomqvist)
--__--__--
Message: 1
Date: Tue, 13 Mar 2001 19:28:43 +0100 (MET)
From: Gigant <[email protected]>
To: [email protected]
Subject: [OpenDivX] OpenDivX optimalization
Hello
I`m trying to turn to optimalize source code by insert MMX
instruction. Now I`m working with rgb2yuv.c, but I don`t know it`s geat
idea. Please mail to me, if you have better idea which code is slowest in
OpenDivX Encode.
Best wishes
Lukasz "Gigant" Tomczykiewicz
from Poland
--__--__--
Message: 2
From: "John Funnell" <[email protected]>
To: "Gigant" <[email protected]>, <[email protected]>
Subject: Re: [OpenDivX] OpenDivX optimalization
Date: Wed, 14 Mar 2001 09:12:12 -0000
rgb2yuv.c might be a good place to start - but if you are going to do this
start with an open mind; try not to just convert the existing C to MMX.
Bear in mind also that it might be necessary to change the colourspace
conversion matrix in the future.
MMX optimisations in the Intel asm syntax belong int the ./intel_mmx
subdirectory - we want to keep nice, clean C versions of every file in
decore/ and encore/
decore is already quite well optimised though we have some ideas to go
further with this. Very soon, we will start a lot of work on encore speed,
so anything you can do ahead of us would be very useful. Please try to
benchmark your improvements - measure the speed increase you create.
Without quantification, performance improvements are little use to us.
Thanks, Gigant for your e-mail and offer of help!
John (eagle)
----- Original Message -----
From: Gigant <[email protected]>
To: <[email protected]>
Sent: Tuesday, March 13, 2001 6:28 PM
Subject: [OpenDivX] OpenDivX optimalization
>
> Hello
> I`m trying to turn to optimalize source code by insert MMX
> instruction. Now I`m working with rgb2yuv.c, but I don`t know it`s geat
> idea. Please mail to me, if you have better idea which code is slowest in
> OpenDivX Encode.
>
> Best wishes
> Lukasz "Gigant" Tomczykiewicz
> from Poland
>
>
> _______________________________________________
> OpenDivX mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx
--__--__--
Message: 3
From: "Andrew Woznytsa" <[email protected]>
To: <[email protected]>
Subject: [OpenDivX] OpenDivX optimalization: +30-40%
Date: Wed, 14 Mar 2001 12:46:59 +0200
Hi All,
I'm quite confused...
look below and compare these algorithms.. results will be the same but
perfomance gain will be 30-40%..
regards,
Andrew
decoder/mp4_mblock.c/macroblock(), line 120:
1. original algorithm:
// motion compensation
if (interFlag)
{
reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
// texture decoding add
for (j = 0; j < 6; j++) {
int coded = mp4_hdr.cbp & (1 << (5 - j));
blockInter(j, (coded != 0));
addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
}
}
else
{
// texture decoding add
[skiped]
2. my version
// motion compensation
if (interFlag)
{
reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
// texture decoding add
for (j = 0; j < 6; j++) {
int coded = mp4_hdr.cbp & (1 << (5 - j));
if(coded){
blockInter(j, (coded != 0));
addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
}
}
else
{
// texture decoding add
[skiped]
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--__--__--
Message: 4
From: "John Funnell" <[email protected]>
To: "Andrew Woznytsa" <[email protected]>,
<[email protected]>
Subject: Re: [OpenDivX] OpenDivX optimalization: +30-40%
Date: Wed, 14 Mar 2001 11:04:21 -0000
Had a quick look and it seems that IntraBlock() runs clearblock and an iDCT
on each block even if it was not coded! I think we need to fix this, well
spotted.
So, where's the cleanest place to make the change: as indicated below, or
inside IntraBlock()?
This might take a couple of days to get into CVS as e7abe7a's away today and
he should approve this first as this is his code.
Thanks again,
John (eagle)
----- Original Message -----
From: Andrew Woznytsa <[email protected]>
To: <[email protected]>
Sent: Wednesday, March 14, 2001 10:46 AM
Subject: [OpenDivX] OpenDivX optimalization: +30-40%
> Hi All,
>
> I'm quite confused...
>
> look below and compare these algorithms.. results will be the same but
> perfomance gain will be 30-40%..
>
> regards,
>
> Andrew
>
> decoder/mp4_mblock.c/macroblock(), line 120:
>
> 1. original algorithm:
>
> // motion compensation
> if (interFlag)
> {
> reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
>
> // texture decoding add
> for (j = 0; j < 6; j++) {
> int coded = mp4_hdr.cbp & (1 << (5 - j));
>
> blockInter(j, (coded != 0));
> addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> }
> }
> else
> {
> // texture decoding add
> [skiped]
>
> 2. my version
>
> // motion compensation
> if (interFlag)
> {
> reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
>
> // texture decoding add
> for (j = 0; j < 6; j++) {
> int coded = mp4_hdr.cbp & (1 << (5 - j));
> if(coded){
> blockInter(j, (coded != 0));
> addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> }
> }
> else
> {
> // texture decoding add
> [skiped]
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> OpenDivX mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx
--__--__--
Message: 5
From: "Andrew Woznytsa" <[email protected]>
To: <[email protected]>
Subject: Re: [OpenDivX] OpenDivX optimalization: +30-40%
Date: Wed, 14 Mar 2001 13:33:20 +0200
inside macroblock(), because addblockInter() also takes a lot of cpu and
does nothing if block is not coded, and it will be possible to eliminate
for(;;) if there are no coded blocks..
----- Original Message -----
From: "John Funnell" <[email protected]>
To: "Andrew Woznytsa" <[email protected]>;
<[email protected]>
Sent: Wednesday, March 14, 2001 1:04 PM
Subject: Re: [OpenDivX] OpenDivX optimalization: +30-40%
> Had a quick look and it seems that IntraBlock() runs clearblock and an
iDCT
> on each block even if it was not coded! I think we need to fix this, well
> spotted.
>
> So, where's the cleanest place to make the change: as indicated below, or
> inside IntraBlock()?
>
> This might take a couple of days to get into CVS as e7abe7a's away today
and
> he should approve this first as this is his code.
>
> Thanks again,
>
> John (eagle)
>
>
> ----- Original Message -----
> From: Andrew Woznytsa <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, March 14, 2001 10:46 AM
> Subject: [OpenDivX] OpenDivX optimalization: +30-40%
>
>
> > Hi All,
> >
> > I'm quite confused...
> >
> > look below and compare these algorithms.. results will be the same but
> > perfomance gain will be 30-40%..
> >
> > regards,
> >
> > Andrew
> >
> > decoder/mp4_mblock.c/macroblock(), line 120:
> >
> > 1. original algorithm:
> >
> > // motion compensation
> > if (interFlag)
> > {
> > reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos,
mp4_hdr.derived_mb_type);
> >
> > // texture decoding add
> > for (j = 0; j < 6; j++) {
> > int coded = mp4_hdr.cbp & (1 << (5 - j));
> >
> > blockInter(j, (coded != 0));
> > addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> > }
> > }
> > else
> > {
> > // texture decoding add
> > [skiped]
> >
> > 2. my version
> >
> > // motion compensation
> > if (interFlag)
> > {
> > reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos,
mp4_hdr.derived_mb_type);
> >
> > // texture decoding add
> > for (j = 0; j < 6; j++) {
> > int coded = mp4_hdr.cbp & (1 << (5 - j));
> > if(coded){
> > blockInter(j, (coded != 0));
> > addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> > }
> > }
> > else
> > {
> > // texture decoding add
> > [skiped]
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > _______________________________________________
> > OpenDivX mailing list
> > [email protected]
> > http://lists.projectmayo.com/mailman/listinfo/opendivx
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--__--__--
Message: 6
From: "zap twentyfive" <[email protected]>
To: [email protected]
Date: Wed, 14 Mar 2001 12:49:37 +0100
Subject: [OpenDivX] OpenDivx on Trimedia status
Ok, a short status report on the progress I made so far:
I finally got most of the source code through the Trimedia compiler. All
source files except the postprocessing and yuv2rgb compile now.
Postprocessing causes a lot of errors of which I haven't found the cause
yet.
Yuv2rgb uses memcpy routines which aren't available in the Trimedia
libraries.
Issues:
1. What is the format of the frames before postprocessing and yuv2rgb? From
the name yuv2rgb I'm assuming the output is of some yuv format. If so all I
need to know is which format and I can directly route it to the Trimedia's
video output.
Otherwise I have to make a separate yuv2rgb for Trimedia.
2. The hardware filters provided by the Trimedia coprocessors are for
upscaling, downscaling and de-interlacing only. They're useless for
postprocessing. For now I've given this a lower priority.
I've now started on adding basic file handling so I can run some test
streams through the decoder.
Question: Are there any sources that I can use as a reference for this? All
I need is some code that can get the video information from an opendivx avi
file and feed it to decore.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
--__--__--
Message: 7
From: "Andreas John" <[email protected]>
To: <[email protected]>
Date: Tue, 13 Mar 2001 14:21:01 +0100
Subject: [OpenDivX] getbits.c
Hi!
I have just recently noticed and realized optimizations in the
h263-tmndecode-Source at work.
As I travelled through the web on the look for even better optimizations I
found the OpenDivX-Source.
So I downloaded it, and you can guess that my surprise was big, as I read:
>getbits.c, bit level routines for tmndecode (H.263 decoder)
The optimizations I did in the h263-Decoder (corellated with the used
stream, I know) made around 8% improvements at the end (using the compiler
from Visual C++).
The ideas were: No explicit masks (less memory-access -> higher
performance),
and getbits(), showbits() and flushbits() as inlined functions (meaning,
putting not only the prototype into global.h but also the body of the
functions - I would say, Linker cannot inline code; must be done by the
compiler...).
I already saw in the decore, that there is a special version of the
getbit-stuff, but it still uses the mask-array.
Is there someone who has a little test-suite for OpenDivX so that I can test
my ideas regarding optimization?
Bye!
--__--__--
Message: 8
Date: Wed, 14 Mar 2001 12:18:30 +0100
From: Vincent BARAT <[email protected]>
Organization: NexWave Solutions
Cc: [email protected]
Subject: [OpenDivX] How to feed decore() and read its output ?
hi,
I'm new to divx and I try to write a simpler player that output raw PPM
files from a divx stream using decore.
I can not figure out how to get divx frame size (ie width and height of
frames as encoded in a divx stream). It seems to have no call to do that
in the API. So, as we must give x_dim and y_dim in DEC_PARAM structure,
how can we do to given original values ?
By the way, is it possible to get a particular frame (as there is no way
to tell the API to return a particular frame, to forward or backward) ?
In fact, I can not grab a simgle frame from a divx stream, whereas I've
succeded in compiling libdivxcore4.7 (even CVS version) and XMPS plugin
(it works with project mayo's trailers).
Thanks a lot
--__--__--
Message: 9
Date: Wed, 14 Mar 2001 12:49:36 +0100
From: Remy Chibois <[email protected]>
To: John Funnell <[email protected]>
Cc: Andrew Woznytsa <[email protected]>,
[email protected]
Subject: Re: [OpenDivX] OpenDivX optimalization: +30-40%
On Wed, Mar 14, 2001 at 11:04:21AM -0000, John Funnell wrote:
> Had a quick look and it seems that IntraBlock() runs clearblock and an iDCT
> on each block even if it was not coded! I think we need to fix this, well
> spotted.
>
> So, where's the cleanest place to make the change: as indicated below, or
> inside IntraBlock()?
Perhaps it's best to keep the test outside IntraBlock() in order to avoid
unnecessary function calls
--
Remy Chibois
--__--__--
Message: 10
Date: Wed, 14 Mar 2001 17:37:34 +0100
From: Mattias Blomqvist <[email protected]>
To: [email protected]
Subject: Re: [OpenDivX] OpenDivX optimalization: +30-40%
Disclaimer... I have no knowledge of the internals of OpenDivx yet so
everything below is based only on the code provided in the original
post...
No. This will not produce the same output if blockInter(j, FALSE)
contribute to the result. And/or if addblockInter(j, mp4_hdr.mb_xpos,
mp4_hdr.mb_ypos) contribute to the result when coded is 0.
If that is not the case I can see why this gets faster.
If either of the above is true (they do contribute to the result even
when coded is 0) the result will not be the same since they are never
called in that case...
/Mattias
Andrew Woznytsa wrote:
>
> Hi All,
>
> I'm quite confused...
>
> look below and compare these algorithms.. results will be the same but
> perfomance gain will be 30-40%..
>
> regards,
>
> Andrew
>
> decoder/mp4_mblock.c/macroblock(), line 120:
>
> 1. original algorithm:
>
> // motion compensation
> if (interFlag)
> {
> reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
>
> // texture decoding add
> for (j = 0; j < 6; j++) {
> int coded = mp4_hdr.cbp & (1 << (5 - j));
>
> blockInter(j, (coded != 0));
> addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> }
> }
> else
> {
> // texture decoding add
> [skiped]
>
> 2. my version
>
> // motion compensation
> if (interFlag)
> {
> reconstruct(mp4_hdr.mb_xpos, mp4_hdr.mb_ypos, mp4_hdr.derived_mb_type);
>
> // texture decoding add
> for (j = 0; j < 6; j++) {
> int coded = mp4_hdr.cbp & (1 << (5 - j));
> if(coded){
> blockInter(j, (coded != 0));
> addblockInter(j, mp4_hdr.mb_xpos, mp4_hdr.mb_ypos);
> }
> }
> else
> {
> // texture decoding add
> [skiped]
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> _______________________________________________
> OpenDivX mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx
--__--__--
Message: 11
Date: Wed, 14 Mar 2001 17:47:10 +0100
From: Mattias Blomqvist <[email protected]>
To: [email protected]
Subject: [OpenDivX] Optimization questions
Hello
I'm thinking of doing some work optimizing the decore. Foremost in intel
(mmx-)assembler.
What I've seen so far that can be quite easily optimised is the routines
in yuv2rgb_mmx.c and basic_prediction_mmx.c. My questions are:
Is any of the routines in basic_prediction used alot so there is any use
in optimizing them?
Is the yuv2rgb routines used at all? Considering allmost all relatively
modern graphic cards have that feature in hardware and it is available
atleast under Windows and Linux (dont know about the others).
BR,
Mattias Blomqvist
--__--__--
_______________________________________________
OpenDivX mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx
End of OpenDivX Digest
Reply To Poster
Local References / HOW-TO / FAQs