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

[OpenDivX] General Development Discussion - All Projects -> OpenDivX







Topic:		Don't understand thing about performance. Need realtime.
Author:		Constantine
Posted:		 2001-03-01 04:39
------------------------------------------------------------------------
--------
Quote:
It's not because it is written in C that it isn't efficient.
I suppose you think that Assembler code is faster? 

Firstly, thanks for your answer. My english is not too good, so don't be
sorry.
I don't "think", I do know that Assembler code is the only thing for
time critical sections. And if we use mmx we get really speed
improvement. I tell this just becouse write Assembler optimization code
myself. 

Quote:
Next, don't expect realtime in a MPEG4 codec, unless you've got a 10Ghz
bazillum... But, maybe in 2-3 years...
Computer power double each 18 months, that's Moore's Law!!! 

yep... well, not too good - my boss has found this code and asked me to
test it... 
My own codec (used... hmmm... some ideas of h261 - i need to write video
only from static cameras) uses about 10-20 ms (pIII-650) to encode 1
frame 384*288 RGB24 and result is about 1600 kbps (25 fps) - not too
good but I keep thinking about using Huffman code (I use RLE now ) and
is waiting for 400-800 kbps same quality. 
That's why I'm looking for fast code or some ideas that I can use. For
example, I can't find any literature about movement prediction - but
keep thinking about it... Although I don't think it's a great idea
becouse of speed deterioration.
So the one thing to improve quality is using more efficient algorithm
deciding what block to send... or using filters to smooth image... Just
haven't literature here and time to look for it via internet.
Well, sorry for such a lot of my speech. Thanks for help anyway.

[ This message was edited by: Constantine on 2001-03-01 04:40 ][ This
message was edited by: Constantine on 2001-03-01 04:43 ]


Topic:		Don't understand thing about performance. Need realtime.
Author:		eagle
Posted:		 2001-03-01 05:34
------------------------------------------------------------------------
--------
Actually, real-time encoding at the resolutions quoted should be
feasible with today's desktop machines.  HOWEVER, the thing to remember
is that video coding is a three way tradeoff between:
<!-- BBCode ulist Start --><UL> 
<LI> Video quality
<LI> Bitrate
<LI> CPU usage, i.e. encode speed
</UL><!-- BBCode ulist End --> 
By tweaking codec design we can optimise for a given set of constraints
- for example if we need faster encoding then we would have to accept an
increase in bitrate and/or a reduction in video quality. 

Right now, we have a lot of serious optimisations planned for our encode
engine, "encore", such as MMX/SSE.  So, in the near future you can
expect an improvement in speed with no detriment to bitrate of quality.
Real-time encoding might not be too far off..... 



Topic:		Don't understand thing about performance. Need realtime.
Author:		Constantine
Posted:		 2001-03-01 09:50
------------------------------------------------------------------------
--------
Yep. I know it. I already use MMX and it's real speed improvement...
Just keep thinking about hardware RGB<->YUV transform - it would be good
to save a few milliseconds on it. 
Now I use Intel image processing library (hope they did their best...),
but continue to looking for faster ways... And the slowest procedure is
as sure IDCT - don't want to write it by myself.


Topic:		The other approach
Author:		duartix
Posted:		 2001-03-01 15:11
------------------------------------------------------------------------
--------
Why don't you coders try the wavelet approach at least to key frames?

>From what I've been reading it a win/win/win situation because it's a
+speed/+quality/-bandwidth change.

I know that keyframe totals won't probably account for more than 2-5% of
the file size but it's still something AND if you follow this link you
will see that it can also be applied to MOTION COMPENSATION:

http://cal046200.student.utwente.nl/~marco/3D_coding/[ This message was
edited by: duartix on 2001-03-01 15:13 ]


Topic:		AVICapture codec + DirectShow
Author:		rak
Posted:		 2001-03-01 16:04
------------------------------------------------------------------------
--------
Our developers have run into some issues with DirectShow + AVICapture
(with DivX as the codec)-- wonder if someone here can help:  basically
we attempt to programmatically set the bit rate of encoding via
DirectShow but it always reverts to the codec's default bit rate (which
is typically very high) when the capture session begins.  We've also
tried to pop-up the standard dialog boxes where the settings are made
but the changes still don't stick -- when our code goes to initiate the
directshow capture, the bit rate settings, again, revert to the default
bit rate settings for the codec.

so the question is how to set the bit rate for an AVI Capture codec and
have them "stick" during the DirectShow capture process.  any assistance
on this one?[ This message was edited by: rak on 2001-03-01 16:08 ]


Topic:		The other approach
Author:		e7abe7a
Posted:		 2001-03-01 20:22
------------------------------------------------------------------------
--------
The main reason for which we didn't use wavelet is that we decided to
adopt the MPEG-4 standard. 
Thank you for your suggestion. As you can see in this forum and in the
OpenDivX mailing list, the Wavelet topic is discussed and taken in
consideration.


Topic:		Don't understand thing about performance. Need realtime.
Author:		sanhan
Posted:		 2001-03-01 20:37
------------------------------------------------------------------------
--------
Why not use Intel Parallel Primitives?

It's good for Intel AND AMD Cpu's.

Quote:
On 2001-03-01 09:50, Constantine wrote:
Yep. I know it. I already use MMX and it's real speed improvement...
Just keep thinking about hardware RGB<->YUV transform - it would be good
to save a few milliseconds on it. 
Now I use Intel image processing library (hope they did their best...),
but continue to looking for faster ways... And the slowest procedure is
as sure IDCT - don't want to write it by myself.


Topic:		Not YCbCr420?
Author:		sanhan
Posted:		 2001-03-01 20:42
------------------------------------------------------------------------
--------
FYI:

YUV2RGB:
------------------------------
R'=Y' +1.140*V
G' = Y' - 0.394*U - 0.581*V
B'=Y' +2.032*U


YCbCr2RGB:
---------------------------------------
R' = 1.164*(Y - 16) + 1.596*(Cr - 128 )
G' = 1.164*(Y-16)-0.813*(Cr -128 )-0.392*
   (Cb -128 )
B' = 1.164*(Y - 16) + 2.017*(Cb - 128 )


Any help?


[ This message was edited by: sanhan on 2001-03-01 20:44 ]


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


Reply To Poster

Local References / HOW-TO / FAQs