[FFmpeg-cvslog] r16431 - in trunk: configure libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/h264.c libavcodec/h264_parser.c libavcodec/imgconvert.c libavcodec/mpegvideo.c libavcodec/vdp...

[Diego Biurrun]

On Mon, Jan 05, 2009 at 10:35:40AM +0000, Carl Eugen Hoyos wrote:
> Diego Biurrun <diego <at> biurrun.de> writes:
> 
> > > > > +#define CODEC_CAP_HWACCEL_VDPAU    0x0080
> > > > 
> > > > May I request the removal of this new CAP flag, before something
> > > > starts using it,
> > > > and advertise the usage of the existing generic CAP_HWACCEL ?
> > > 
> > > That would lead to strange behaviour in vd_ffmpeg.c (look at line 256):
> > > It would
> > > act as if XVMC was asked by the user while it was actually VDPAU.
> > > 
> > > If you change that code, CODEC_CAP_HWACCEL_VDPAU could be removed.
> > 
> > This is backwards.  Bad design decisions in MPlayer should not negatively
> > influence FFmpeg.  It's preferable to break MPlayer instead of hurting
> > FFmpeg.
> 
> Then allow me to reword my answer:
> Please read the comment for CODEC_CAP_HWACCEL carefully!
> 
> (It says clearly "XVMC" and is already part of a public header for a long time)

xvmc is unusable without xvmc_render.h, which was never installed.  So
you cannot really consider it part of the public API.  And yes, this is
the main shortcoming of the xvmc support in FFmpeg.

Diego