[Ffmpeg-devel] [PATCH] Basic H.264 encoder / Mo Comp Code
Wed Apr 26 19:52:22 CEST 2006
At 02:32 AM 4/26/2006, Panagiotis Issaris wrote:
>Was the idea to keep this mocomp framework outside of FFmpeg, or to actually
>bring it back into FFmpeg thus refactoring it?
I don't think my first cut will be the one that will fly- but once I am done it
might be good as a reference/api example.
>I am mostly interested in having a nice mocomp API _within_ FFmpeg for the
>various codecs to use.
I am also interested in having a nice mocomp interface (and possibly a
transform and coding one also), or at least separating those motion functions
that can be, which could include:
parts of : encode_thread
The other question is what constitutes codec specific motion that
shouldn't be in a general library- there are h263, msmpeg4, wmv, mpeg4
specific motion functions (and I am sure many others that aren't mpeg-ish.
Maybe the thing to do is look at what is in dsputil and start with those.
One difficulty is that there are so many codec specific flags everywhere that
there almost needs to be an API just to handle/simplify that (i.e.
kind of like
how flags is now, except it would be codecflags or something).
The final issue is that I don't know which h.264 specific features are
important to support, including:
-weighted prediction (I am guessing this is probably a good thing)
-variable block size mo comp (seems to only be important if you have a
segmentation/quality algorithm driving encoding).
-multi reference pictures (seems important- but how many makes sense?
3? 5? 32? And how is this signalled?)
- anything else new I may have missed...
So understanding that would probably help decide what to tackle first, and
what is actually salvageable from the current code base.
More information about the ffmpeg-devel