[Ffmpeg-devel] Native H.264 encoder

[Panagiotis Issaris]

Hi Luca,

On Fri, Dec 15, 2006 at 06:10:01PM +0100, Luca Abeni wrote:
> On Thu, 2006-12-14 at 14:35 +0100, Panagiotis Issaris wrote:
> [...]
> > > BTW, I tried to have a better look at the quality of the encoded
> > > video... Looking at the artefacts, someone suggested that they might be
> > > due to poor motion estimation.
> > > Your encoder is using its own code for motion estimation, right? How
> > > difficult would it be to reuse ffmpeg's code?
> > Well, for me, pretty hard... The reason we started writing our own
> > ME-code was because we did not find any structured way to reuse the
> > motion estimation code. There appears to be no api or guidelines.
> Ok... I tried to have a quick look, and I understand what you mean ;-)
:-)

> > 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)
Yep, I saw that comment too, but if I recall correctly, it has been there for
quiet a while :)

> 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.
Ah! That would be awesome! :) I'll help out whereever I can!

> 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?
I tried encoding with a low QP to verify that there was no true bug causing the
artifacts, and with low QP the quality seemed very good to me (-qscale 8 or so).

So, at first it would seem that the ratecontroller forced the QP up, causing the
artifacts, so, the artifacts would be caused by high QP in turn caused by
insufficient motion estimation.

But, in H.264 there's a difference in behavior for the 0-23 and 24-51. So, it
could also be a bug in the quantisation when using QP>23, causing an artifact,
which afterwards would be propagated even for frames afterwards having QP<24.

With friendly regards,
Takis