[Ffmpeg-devel] [PATCH] Basic H.264 encoder

[Michael Niedermayer]

Hi

iam both happy and unhappy to see a h264 encoder being developed for lavc
happy obviously as h.264 encoding is no doubt the most important thing which
is missing
unhappy as this will probably seperate x264 and lavc further over time which
is the opposite of what i would have hoped for ...
then again i wont accept or reject patches due to political reasons so if
your encoder is clean and otherwise fit for cvs ill apply it


On Wed, Apr 12, 2006 at 04:01:49PM +0200, Panagiotis Issaris wrote:
[...]
> A quick summary of what the encoder does:
> ?- it always uses one slice per frame

thats no problem


> ?- intra 16x16 encoding is used for I slices

that is a problem quality wise, but no reason to reject


> ?- motion vectors are set to zero

that is a reason to reject it unless you convice me that it will be fixed
soon


> ?- the previous frame is used for inter coding

not optimal either ....


> ?- no macroblock partitioning is used

not optimal ...


> ?- the image width and height are reduced to a multiple of 16

why?


> ?- for debugging purposes, the NAL units are written to a file
> ? ?/tmp/teststream.264 and reconstructed frames are appended to
> ? ?the file /tmp/teststream.yuv

obviously not ok for lavc, but you didnt submit it for inclusion into lavc
yet so everythings fine ...


> 
> We would like some suggestions about how we should proceed
> further to integrate a LGPL H.264 encoder into libavcodec. Is
> there an encoder we can use as an example about how the code
> should be structured? For example, we've noticed a large
> difference in the way the H.261 (and also H.263) and Snow codecs
> are organized.

hmm, i dont think theres a ideal reference codec, choose the structure
which seems best to you


[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is