[FFmpeg-cvslog] r10610 - trunk/libavcodec/error_resilience.c

Ivan Kalvachev ikalvachev
Fri Sep 28 23:36:04 CEST 2007


2007/9/29, Rich Felker <dalias at aerifal.cx>:
> On Fri, Sep 28, 2007 at 09:46:37PM +0100, M?ns Rullg?rd wrote:
> > iive <subversion at mplayerhq.hu> writes:
> >
> > > Author: iive
> > > Date: Fri Sep 28 22:38:32 2007
> > > New Revision: 10610
> > >
> > > Log:
> > > On bitstream error is_intra_more_likely() could use dsp.sad[0]() that will segfault when xvmc is in use.
> > >
> > > Modified:
> > >    trunk/libavcodec/error_resilience.c
> > >
> > > Modified: trunk/libavcodec/error_resilience.c
> > > ==============================================================================
> > > --- trunk/libavcodec/error_resilience.c     (original)
> > > +++ trunk/libavcodec/error_resilience.c     Fri Sep 28 22:38:32 2007
> > > @@ -563,6 +563,11 @@ static int is_intra_more_likely(MpegEncC
> > >
> > >      if(undamaged_count < 5) return 0; //allmost all MBs damaged -> use temporal prediction
> > >
> > > +#ifdef HAVE_XVMC
> > > +    //prevent dsp.sad() check, that requires access to the image
> > > +    if(s->avctx->xvmc_acceleration && s->pict_type==I_TYPE) return 1;
> > > +#endif
> > > +
> >
> > This looks *very*, VERY hackish to me.
>
> What would be better? Setting all the dsp functions to a no-op
> function when using xvmc?

And this would probably give wrong result as they would return 0, that
would cause  inter blocks to be used instead intra.

Another possible solution is to move the xvmc check to the existing
I_TYPE one. However it would be inside the loop and as I_TYPE frames
by definition can hold only I-type MB (not even skipped are allowed)
then the result would be the same, but calculated by wasting more cpu
cycles.




More information about the ffmpeg-cvslog mailing list