[Ffmpeg-devel] Motion estimation related refactoring (was: Native H.264 encoder)
Panagiotis Issaris
takis.issaris
Fri Jan 19 11:15:47 CET 2007
Hi,
On Thu, 2007-01-18 at 18:17 +0100, Michael Niedermayer wrote:
> [...]
> i meant something like:
> #define ME_FIELDS\
> int width;\
> int height;\
> ...
>
> struct MotionEstContext {
> ME_FIELDS
> }
>
> struct SnowContext {
> ME_FIELDS
>
> ...
> }
>
> struct MpegEncContext {
> ME_FIELDS
>
> ...
> }
Ah, I kinda feared you meant that (as that is what FF_COMMON_FRAME is
doing).
> but the more i think about it the less i like it ...
I am not really fond of this either.
> 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 ...
Hmm. Personally, I do not see it as a _big_ readability problem, but of
course you are the maintainer :)
I do see a problem with it, in the sense that it makes it appear as if
width and height are conceptually tightly related with the motion
estimation, while they are in fact more general properties of the video
which are only needed for the motion estimation to work.
After writing the above, I'm starting to think that that was exactly
what you meant, as currently the s.me.penalty_factor and other were
already being used in the way you described (albeit by taking a
reference to MotionEstContext first).
With friendly regards,
Takis
--
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key
More information about the ffmpeg-devel
mailing list