[Ffmpeg-devel] Motion estimation related refactoring (was: Native H.264 encoder)

[Panagiotis Issaris]

Hi,

On Thu, 2007-01-18 at 18:17 +0100, Michael Niedermayer wrote:
> On Thu, Jan 18, 2007 at 04:59:19PM +0100, Panagiotis Issaris wrote:
> [...]
> > Or do imply moving all the fields needed for motion estimation out of
> > MpegEncContext into MotionEstContext (at the top)?
> > 
> > struct MotionEstContext { 
> > /* new MotionEstContext fields */
> > int width;
> > ... 
> > /* older MotionEstContext fields */
> > ...
> > };
> > 
> > struct MpegEncContext { MotionEstContext me; ... };
> > struct SnowContext { MotionEstContext me; ... };
> 
> 
> i meant something like:
> #define ME_FIELDS\
> int width;\
> int height;\
> ...
> 
> struct MotionEstContext { 
> ME_FIELDS
> }
> 
> struct SnowContext {
> ME_FIELDS
> 
> ...
> }
> 
> struct MpegEncContext {
> ME_FIELDS
> 
> ...
> }
> 
> but the more i think about it the less i like it ...
> 
> the problem with your suggestion above is that it would result in code like
> s.me.width instead of s.width which is a big problem readability wise ...

Currently the MpegEncContext struct is huge imho:
sizeof(MpegEncContext): 8672
compared to f.e.:
sizeof(MotionEstContext): 344. 

Having a separate struct which contains only the variables which need to
be available for all codecs might ameliorate this problem a bit.


 struct BaseCodecContext {
 int width;
 ...
 };
 
 struct MotionEstContext { 
   BaseCodecContext sn;
   ... 
   
 };
 
 struct MpegEncContext { MotionEstContext me; ... };
 struct SnowContext { MotionEstContext me; ... };
 
If it appears first in the struct and you object to using s.me.width,
you can still cast it ;)

With friendly regards,
Takis

-- 
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key