[Ffmpeg-devel] H.264 encoder
Thu Oct 12 13:54:31 CEST 2006
On Thu, Oct 12, 2006 at 11:49:13AM +0200, Michael Niedermayer wrote:
> > [...]
> > > > > probably not -> change pred_non_zero_count() so it takes the top and left
> > > > > values as arguments instead of H264Context, or change it so a it takes a
> > > > > pointer to non_zero_count_cache ...
> > > >
> > > > Something like the attached patch does? Or should I drop the const and move left
> > > > and top to the outer scope?
> > >
> > > id move them out as the resulting code is simpler ...
> > I've attached two patches, one moving them to the outermost scope (well, within
> > the function) and one one scopelevel higher. Which one do you prefer (if any :)
> > )
> > ?
> 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 :(
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() :
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 ];
With friendly regards,
 There are currently 8 calls to it in h264.c.
More information about the ffmpeg-devel