[FFmpeg-devel] [FFMPEG] [PATCH] cavs encoder

[Stefan Gehrer]

Michael Niedermayer wrote:
> On Fri, Nov 20, 2009 at 10:16:53PM +0800, zhihang wang wrote:
> [...]
>>> we already have ME  code, so this could be considered duplicated
>>> iam against having seperate ME code in every encoder (h264, avs and mpeg*)
>>>
>>> *Yes. there are ME code in ffmpeg. But perhaps it is difficult to use for
>> 264 or avs because of using RDO.
>> Let me check again.* * If you have some idea, welcome your help!*
> 
> I know what you mean but maybe h264 and avs could share code. There was
> some attempt at writing a LGPL h264 encoder for ffmpeg that could maybe
> use it ...
> Sharing code would be a big help for both encoders because improvments
> done to one would benefit the other automatically.
> But Iam not saying it has to be done at any cost, just that i would like
> to hear why it cannot be done in more detail.

On my first attempt of an encoder I decided to put my own motion
estimation code in, even if it was a very simple one.
The code in motion_est_template.c and motion_est.c seems to have
some unsuitable assumptions:
- that a skipped macroblock has motion vector (0,0)
- that qpel needs different filter functions
- how the chroma vector is calculated from luma (in qpel case and else)
- that mid_pred is used for mv prediction
- and maybe more
Even if not all of above is correct I think it would be very difficult
to extend this optimized-for-MPEG-type-video code to a more generic
handling without having a speed regression. But I do certainly agree
that H.264 and AVS encoders could share a lot of motion estimation
code if that were to be written.

Stefan