[Ffmpeg-devel] Native H.264 encoder

[Panagiotis Issaris]

Hi,

On Fri, Dec 15, 2006 at 06:09:26PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Dec 15, 2006 at 06:10:01PM +0100, Luca Abeni wrote:
> [...]
> > > It
> > > seems most codecs reuse parts of MpegEncContext code combined with some
> > > conditional parts added to mpegvideo.c. I would prefer to see the motion
> > > estimation code separated from the codecs,
> > In snow.c, I found the following comment at line 471:
> >     MpegEncContext m; // needed for motion estimation, should not be
> > used for anything else, the idea is to make the motion estimation
> > eventually independant of MpegEncContext, so this will be removed then
> > (FIXME/XXX)
> > 
> > Since it seems that making the motion estimation codec independant of
> > MpegEncContext is in the plans (and can be useful for the whole ffmpeg
> > project), I'll try to have a better look to see how to do this (as soon
> > as I'll have some time :)...
> > I do not promise anything, but I'll try.
> 
> i would be very happy if someone did seperate the motion estimation code
> from MpegEncContext and make it more generic ...
I would certainly like to help out on this, if given some guidance...


> > Anyway, do you agree that motion estimation can be the cause of the
> > artefacts in the encoded H.264 video? Or is this a bad interpretation?
> 
> a simple way to test is to encode at very high quality / very low quantizer
> if any artifacts remain then its not motion estimation ...
Yes, I tried this earlier today with -qscale 2 to 10 and quality was pretty good,
no artifacts to be seen. So, I guess it is the ratecontroller forcing the
quantizer up because of insufficient motion estimation benefits. The artifacts
appearing when using bitrates such as 700k look similar to those when using very
high QP.

With friendly regards,
Takis