[Ffmpeg-devel] Native H.264 encoder

[Panagiotis Issaris]

Hi,

On Wed, 2006-12-13 at 10:41 +0100, Luca Abeni wrote: 
> > But no need to get excited, cause although the DCT is considerably
> > faster, the overall execution time remains the same.
> You are right... I just performed some quick tests on a 20-seconds-long
> video captured from tv, and here are the results:
> ffmpeg's mpeg4 encoder (for reference):
> time ./ffmpeg -y -i /tmp/test.y4m -b 400k test.m4v) ---> 1.13s
> your non-mmx patch:
> time ./ffmpeg -y -i /tmp/test.y4m -b 400k -vcodec ffh264 test.h264 ---> 4.89s
> your mmx patch (same command line): 4.98s
> The results are consistent across multiple runs... So, it seems that the
> non-mmx patch is slightly faster? (The ffmpeg binary generated with the
> non-mmx patch is a little bit smaller, so maybe it's a cache effect? I
> do not know).
Well, the separate START|STOP_TIMER timed code seems considerably faster
(nearly 2x) _but_ as [*] shows, the DCT only takes 6.37% of the encoding
time. The reason for it being a tiny bit slower... well, I have no idea
yet. If you disable all the MMX versions except for the DCT, it is not
slower anymore, but not faster either...


> > Furthermore, I haven't cleaned this patch up yet, as I think it might be
> > wiser to focus first on getting the C version in the main FFmpeg tree.
> I perfectly agree with you.
> 
> 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. 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, but I do not understand the
code well enough to be able to do this refactoring myself. Of course, I
prefer to be able to get the codec integrated without any refactoring
then not having it integrated at all :)

> If you agree that motion estimation can be one of the problems for the
> quality, I'll try to have a look at using libavcodec's routines... But
> I'll be able to work on it only in background, after finishing with the
> swscale stuff.
That would be great! :) Thanks in advance!


[*] http://static.flickr.com/144/320518337_e59e102ee2_o.png


With friendly regards,
Takis
-- 
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key