[Ffmpeg-devel] H.264 encoder

[Panagiotis Issaris]

Hi,

On Thu, Oct 12, 2006 at 02:01:17PM +0200, Michael Niedermayer wrote:
>[...]
> > > 
> > > hmm, after reconsidering this, i think its best to forget sharing
> > > pred_non_zero_count() between your encoder and h264.c the result looks
> > > too messy :(
> > I agree.
> > 
> > For sharing pred_motion() between h264.c and our encoder, I'm having similar
> > problems: pred_motion() uses h->ref_cache[][] and mv_cache[][] which are being
> > filled by the same fill_caches() which uses MpegEncContext.  Furthermore,
> > pred_motion() calls fetch_diagonal_mv() which also uses h->ref_cache[][] and
> > MpegEncContext. To be able to reuse it, I could do it in a similar way by
> > changing the arguments of pred_motion() and fetch_diagonal_mv(), but that would
> > give similar problems as in the pred_non_zero_count() case imho. I would have to
> > put the following before every call to pred_motion() [1]:
> >   const int index8= scan8[n];
> >   const int top_ref=      h->ref_cache[list][ index8 - 8 ];
> >   const int left_ref=     h->ref_cache[list][ index8 - 1 ];
> 
> what about changing your encoder to use a similar cache system?
> would in improve speed? simplicity?
Speed, possibly, but for the moment I do not yet understand the reasoning behind
this specific cache. With "use a similar", do you mean, to reuse the existing
code or write a similar system? Because in case of the reusing, I think I would
have the same problems with the MpegEncContext which I would need to pull in.

Simplicity, ... I do not think so, adding code (especially performance related
code) rarely makes things simpler.

I would prefer makes such intrusive changes after I've gotten a basic version of
the patch in SVN. This way these changes would be revisioned too and it would
make it easier for others to help. But that decision is course up to you :)

With friendly regards,
Takis