[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...
Mon Jan 5 11:43:53 CET 2009
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.
More information about the ffmpeg-cvslog