[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 11:48:34AM +0100, Reimar D?ffinger wrote:
> On Mon, Jan 05, 2009 at 11:25:02AM +0100, Diego Biurrun wrote:
> > On Mon, Jan 05, 2009 at 09:02:28AM +0000, Carl Eugen Hoyos wrote:
> > > Ivan Kalvachev <ikalvachev <at> gmail.com> writes:
> > > 
> > > > > + * Codec can export data for HW decoding (VDPAU).
> > > > > + */
> > > > > +#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.
> 
> I disagree, IMHO the idea of an hardware-independent
> hardware-acceleration (as CAP_HWACCEL suggests) is nonsense, and
> it should have been called CAP_XVMC or some such instead.
> What is the point of CAP_HWACCEL anyway?

Well, then let us just rename it.  Is there any problem with renaming it?

Diego