[Ffmpeg-devel] H.264 encoder

Panagiotis Issaris takis.issaris
Thu Oct 12 13:54:31 CEST 2006


Hi,

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 :(
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 ];

With friendly regards,
Takis

[1] There are currently 8 calls to it in h264.c.




More information about the ffmpeg-devel mailing list